OS X Lion, make check stalls

Jack Howarth howarth at bromo.med.uc.edu
Thu Jul 28 14:32:23 CEST 2011

On Thu, Jul 28, 2011 at 12:16:42PM +0200, Torbjorn Granlund wrote:
> Stijn Vanden Eynde <djcomidi at gmail.com> writes:
>   I am currently trying to build gmp-5.0.2 on OS X Lion.
>   What is the problem:
>   Both ./configure and make run succesfully.
>   But "make check" stalls at a certain point.
>   The last lines I get are:
>   > PASS: t-fdiv_ui
>   > PASS: t-cdiv_ui
>   Up to this point there is nothing but a blinking cursor,
>   my guess is that the next check is in an infinite loop or so.
>   Which is strange, cause it didn't had this issue on Snow Leopard.
> Thanks for the bug report!
> Unfortunately, I cannot do much, since I have no adequate system where I
> could attempt to reproduce this odd problem.  You need to isolate it
> yourself, and report it to Apple or us, depending on the nature of the
> problem.  Alternatively, if somebody else on this list want to make a
> contribution to the project, please help with isolating this problem.
> I brave a guess: This is a compiler problem.  Apple's track record is
> really poor in this area.  I see the LLVM name in your report.  That
> compiler is very immature, and miscompiles most non-trivial programs at
> at least some optimisation level.

   I emailed you about this before. The patch applied for gmp-5.0.2 had
a minor flaw.


The test in the generated configure for "checking how to switch to read-only data section... "
should be...

const int foo[] = {1,2,3};

but since acinclude.m4 is missing the extra braces, the single braces are
chewed away by autoconf leaving...

const int foo = {1,2,3};

This flawed test case produces a warning under clang but an error under llvm-gcc.

--- acinclude.m4.orig	2011-05-17 19:03:09.000000000 -0400
+++ acinclude.m4	2011-05-17 19:03:43.000000000 -0400
@@ -1941,8 +1941,8 @@
 cat >conftest.c <<EOF
-extern const int foo[];		/* Suppresses C++'s suppression of foo */
-const int foo[] = {1,2,3};
+extern const int foo[[]];		/* Suppresses C++'s suppression of foo */
+const int foo[[]] = {1,2,3};
 echo "Test program:" >&AC_FD_CC
 cat conftest.c >&AC_FD_CC
--- configure.orig	2011-05-17 19:15:41.000000000 -0400
+++ configure	2011-05-17 19:16:00.000000000 -0400
@@ -26446,8 +26446,8 @@
 cat >conftest.c <<EOF
-extern const int foo;		/* Suppresses C++'s suppression of foo */
-const int foo = {1,2,3};
+extern const int foo[];		/* Suppresses C++'s suppression of foo */
+const int foo[] = {1,2,3};
 echo "Test program:" >&5
 cat conftest.c >&5

will eliminate the miscompilation of gmp 5.0.2 under llvm-gcc. Again the origin of
this problem is that the flawed test case produces...

define(<RODATA>, <      .section        __TEXT,__literal4,4byte_literals>)

in the generated config.m4 which is wrong.
ps The darwin linker developers comments on __literal4 are appended below.

I don't understand the context of what you sent or how it builds, but this line in invert_limb_build/config.m4 is very suspect:

define(<RODATA>, <	.section	__TEXT,__literal4,4byte_literals>)

The _literal4 section is special in mach-o.  The linker is free to reorganize and coalesce any 4-byte duplicates in the section.

The file ./invert_limb_build/mpn/tmp-invert_limb.s contains:

	mov	approx_tab at GOTPCREL(%rip), %r8
	add	$-512, %r8
	movzwl	(%r8,%rax,2), %ecx	
		.section	__TEXT,__literal4,4byte_literals
	.align	1, 0x90
	.value	0x7fd,0x7f5,0x7ed,0x7e5,0x7dd,0x7d5,0x7ce,0x7c6
	.value	0x7bf,0x7b7,0x7b0,0x7a8,0x7a1,0x79a,0x792,0x78b
	.value	0x40e,0x40c,0x40a,0x408,0x406,0x404,0x402,0x400

Even if the linker had not asserted on this, the program would surely do the wrong thing at runtime, because the linker can rearrange the content of
 the __literal4,4byte_literals section and this code depends on that big table being kept intact.

That table should just be in the __TEXT,__const section which holds any non-special constant data. (and RODATA without relocations in it).

> -- 
> Torbjörn
> _______________________________________________
> gmp-bugs mailing list
> gmp-bugs at gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-bugs

More information about the gmp-bugs mailing list