Re: FLT_ROUNDS failures ... gcc/binutils regression ?

[Matt Thomas <matt%3am-software.com@localhost>]

On Sep 27, 2011, at 11:27 AM, David Laight wrote:

> On Tue, Sep 27, 2011 at 08:05:15PM +0200, Nicolas Joly wrote:
>> On Tue, Sep 27, 2011 at 06:58:14PM +0100, David Laight wrote:
>>> On Tue, Sep 27, 2011 at 07:10:30PM +0200, Nicolas Joly wrote:
>>>> 2c2
>>>> < flt_rounds.old:     file format elf64-x86-64
>>>> ---
>>>>> flt_rounds.new:     file format elf64-x86-64
>>>> 18c18
>>>> <   1e: 48 8d 0d db ff ff ff    lea    -0x25(%rip),%rcx        # 0 <_map>
>>>> ---
>>>>>  1e: 48 8d 0d 00 00 00 00    lea    0x0(%rip),%rcx        # 25 
>>>>> <__flt_rounds+0x15>
>>>> 
>>>> The new code, which does not work, looks suspicious to me ...
>>> 
> ...
>> 0000000000000021 R_X86_64_GOTPCREL  _map+0xfffffffffffffffc
> 
> That is some kind of pc-relative relocation for _map.
> 
> So it looks like _map (or rather its address?) has moved sections (or similar)
> so that the offset isn't a compile time constant - or gcc is allowing for 
> that.
> 
> Dunno it that is the right relocation type.
> Might be worth linking the .o into a static program to see what 'ld'
> makes of it.
> Also link into a shlib, load, and see what the dynamic linker has done.
> Might be a bug in the dynamic linker!

_map probably should be in .rdata

you could recode it to extract two bits from 0x78 (01.11.10.00) which
avoid a memory reference.  Something like:

        fnstcw  -4(%rsp)
        movl    -4(%rsp),  %ecx
        shrl    $9, %ecx
        andl    $6, %ecx
        movl    $120, %eax
        sarl    %cl, %eax
        andl    $3, %eax
        ret