gmp 4.3.2 regressions when compiled with llvm-gcc

[Jack Howarth]

On Thu, Mar 31, 2011 at 08:21:54PM +0200, Stefan Krah wrote:
> Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> > Torbjörn,
> >     If you have access to a x86_64 linux box which defaults gmp to core2,
> > you could test this problem locally using the prebuilt linux x86_64 binaries
> > for llvm-gcc4.2 from http://llvm.org/releases/download.html#2.8. I suspect
> > this issue may not be darwin specific but a general llvm-gcc/-mtune=core2
> > issue.
> >    Note I also tried a build under clang 2.9 but ran into a darwin linker
> > bug. Once that is fixed upstream, I'll let you know if clang exhibits
> > the same issues.
> >            Jack
> > ps Aren't the other BSDs moving to llvm/clang? If so, I think these issues
> > may have a wider audience than just darwin.
> 
> 
> All tests pass on FreeBSD-8.0-amd64:
> 
> clang version 2.9 (trunk 124029)
> Target: x86_64-unknown-freebsd8.0
> Thread model: posix
> 
> 
> # Qemu reports Id = 0x623 as the processor id:
> ./configure CC=clang --build=core2-unknown-freebsd8.0 --enable-cxx
> 
> # The provided libtool exits with an error:
> cp /usr/local/bin/libtool .
> make
> make check
> 
> 
> Perhaps this is another Mac OS X specific problem?

Stefan,
   It appears the problem with clang vs gmp on darwin is due to the configure test for
'checking how to switch to read-only data section' which results in the use
of '.section        __TEXT,__literal4,4byte_literals' inappropriately under
clang. The same test under Apple's gcc-4.2 always returns just '.text'...

clang:

configure:26417: checking how to switch to read-only data section
Test program:
const int foo = 123;
configure:26436: clang -O2 -pedantic -m64 -mtune=core2 -march=core2  -S conftest.c >&5
configure:26439: $? = 0
Compiler output:
        .section        __TEXT,__text,regular,pure_instructions
        .section        __TEXT,__literal4,4byte_literals
        .globl  _foo                    ## @foo
        .align  2
_foo:
        .long   123                     ## 0x7b


.subsections_via_symbols
Match:  .section        __TEXT,__literal4,4byte_literals
configure:26470: result:        .section        __TEXT,__literal4,4byte_literals


Apple gcc-4.2

configure:26417: checking how to switch to read-only data section
Test program:
const int foo = 123;
configure:26436: gcc -std=gnu99 -O2 -pedantic -m64 -mtune=core2 -march=core2 -fexceptions -I/sw/include -S conftest.c >&5
configure:26439: $? = 0
Compiler output:
.globl _foo
        .literal4
        .align 2
_foo:
        .long   123
        .subsections_via_symbols
Match: 
configure:26470: result: .text

According to the Apple linker developer...

>> .subsections_via_symbols
>> Match:  .section        __TEXT,__literal4,4byte_literals
>> configure:26470: result:        .section        __TEXT,__literal4,4byte_literals
>
>
> It is fine for single 4-byte constants to be in the literal4 section.  
> The problem is having arrays of constants.    The configure test seems 
> to be assuming that the section that holds one 4-byte constant can also
> be used to hold an array.  If you try an array, you'l see clang uses a different section:
> 
> [/tmp]> cat > a.c
> const int foo[] = { 1,2,3 };
> [/tmp]> clang -Os a.c -S
> [/tmp]> cat a.s
>        .section        __TEXT,__text,regular,pure_instructions
>        .section        __TEXT,__const
>        .globl  _foo                    ## @foo
>        .align  2
> _foo:
>        .long   1                       ## 0x1
>        .long   2                       ## 0x2
>        .long   3                       ## 0x3

The linkage problem stems from the mpn/.libs/invert_limb.o file...

[/tmp/clang_gmp5_linkage_bug/build]> size -l ./mpn/.libs/invert_limb.o
Segment : 146 (vmaddr 0x0 fileoff 368)
        Section (__TEXT, __text): 145 (addr 0x0 offset 368)
        Section (__TEXT, __literal4): 0 (addr 0x92 offset 514)
        total 145
total 146

where the __literal4 size is 0.

because of the config.m4 line.

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

The Apple linker developer also commented...

> 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
> approx_tab:
>        .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).