[oe] powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

On Tue, 25 May 2010, Khem Raj wrote:
> On Tue, May 25, 2010 at 8:15 AM, Vitus Jensen <vjensen at gmx.de> wrote:
>> On Mon, 24 May 2010, Khem Raj wrote:
>>> On (24/05/10 18:36), Vitus Jensen wrote:
>>
>>
>>>> Hmm, I'm using angstrom with glibc.  And I'm testing on the real
>>>> device and saw that -mhard-float is implied by mcpu=603e.  Using the
>>>> FPU would certainly explain differences between qemu and the real
>>>> thing.  But __floatdidf is hard to understand, all macro.  Is it
>>>> really using the FPU?
>>>
>>> Yeah that could be something to look at. In general if gcc is using
>>> fp instruction to schedule then it might be using them.
>>>
>>> You should try to find which libgcc is it linking to when using g++
>>> and gcc. It could be that its linking in two different libgcc versions
>>>
>>> secondly try to compile program statically and then run it.
>>
>>
>> Using -static-libgcc and -shared-libgcc was interesting, it just affects the
>> gcc support code.  static is default for C, shared for C++ and forcing
>> static for C++ produced correct output.  When comparing implementations:
>>
>> * static uses inline fpu code, source
>> work/i686-ppc603e-sdk-angstrom-linux/gcc-cross-sdk-4.4.4-r2.1/gcc-4.4.4/gcc/libgcc2.c
>>
>> * shared calls into libgcc_s.so.1 which uses software, excerpt:
>> Dump of assembler code for function __floatdidf:
>> => 0x0fe12878 <+0>:     stwu    r1,-32(r1)
>>   0x0fe1287c <+4>:     mflr    r0
>>   0x0fe12880 <+8>:     stmw    r26,8(r1)
>>   0x0fe12884 <+12>:    mr      r27,r4
>>   0x0fe12888 <+16>:    mr      r26,r3
>>   0x0fe1288c <+20>:    srawi   r9,r26,31
>>   0x0fe12890 <+24>:    srawi   r10,r26,0
>>   0x0fe12894 <+28>:    stw     r0,36(r1)
>>   0x0fe12898 <+32>:    mr      r3,r10
>>   0x0fe1289c <+36>:    bl      0xfe31244 <__floatsidf at plt>
>>   0x0fe128a0 <+40>:    lis     r5,16880
>>
>>
>> [STABLE/2009] There are 2 libgcc_s.so.1 versions in TMPDIR/cross, the bigger
>> ./ppc603e/powerpc-angstrom-linux/lib/nof/libgcc_s.so.1 matches the installed
>> version,
>
> thats the problem
>
> if one copies the smaller version (uses fpu code) to target:/lib/
>> the results of -shared-libgcc applications are OK.
>>
>> So, hard-fpu and soft-fpu are incompatible?  The incorrect version matches
>> (strip; cmp -l) several paths in TMPDIR/work:
>
> its more the calling convention.
>
>>
>> ./ppc603e-angstrom-linux/gcc-4.2.4-r3/image/lib/libgcc_s.so.1
>> ./ppc603e-angstrom-linux/gcc-4.2.4-r3/gcc-4.2.4/build.powerpc-angstrom-linux.powerpc-angstrom-linux/gcc/nof/libgcc_s.so.1
>> ./ppc603e-angstrom-linux/gcc-cross-4.2.4-r5/install/libgcc/lib/libgcc_s.so.1
>> ./ppc603e-angstrom-linux/gcc-cross-4.2.4-r5/image/lib/libgcc_s.so.1
>> ./ppc603e-angstrom-linux/gcc-cross-4.2.4-r5/staging-pkg/cross/powerpc-angstrom-linux/lib/nof/libgcc_s.so.1
>> ./ppc603e-angstrom-linux/gcc-cross-4.2.4-r5/gcc-4.2.4/build.i686-linux.powerpc-angstrom-linux/gcc/nof/libgcc_s.so.1
>>
>> But there are 4 other smaller versions of that library, the good one coming
>> from gcc-4.2.4. or gcc-cross-4.2.4.  Which recipes decides which version to
>> copy into the image?  For now it seems enough to copy a fpu-version by hand
>> into the image but this is hardly an universal solution.
>
> actually it should have packaged the fpu version into /lib on target
> but its a bug that it instead copied
> nof version.
>
> I think I touched this area and saw this problem in past. Can you try 
> gcc 4.4.4 and see if the problem still happens there.

I really would like to but there is no gcc 4.4.4 in stable/2009.  And .dev 
currently fails to build in virtual/kernel.

cp: cannot stat 
`/home/oe/build/out.dev/work/n1200-angstrom-linux/linux-n1200-2.6.27-rc9+git-r3/linux-2.6.27-foonas-git//home/oe/build/out.dev/work/n1200-angstrom-linux/linux-n1200-2.6.27-rc9+git-r3/linux-2.6.27-foonas-git/arch/powerpc/boot/cuImage.thecus_n1200': 
No such file or directory
ERROR: Function do_deploy failed

I think I have a buildable .dev state at work and will retry there.

Vitus

-- 
Vitus Jensen, Hannover, Germany, Universe (current)
pgp public key available from keyservers