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

Vitus Jensen vjensen at gmx.de
Mon May 24 16:36:25 UTC 2010


On Fri, 21 May 2010, Khem Raj wrote:

> On Fri, May 21, 2010 at 6:40 AM, Vitus Jensen <vjensen at gmx.de> wrote:
>> On Fri, 21 May 2010, Vitus Jensen wrote:
>>> On Fri, 21 May 2010, Vitus Jensen wrote:
>>>>  On Wed, 19 May 2010, Koen Kooi wrote:
>>>>>   On 19-05-10 17:46, Vitus Jensen wrote:
>>>>>>   On Wed, 19 May 2010, Vitus Jensen wrote:
>>>>>>>   On Wed, 19 May 2010, Gary Thomas wrote:
>>>>>>>>    On 05/19/2010 03:38 AM, Vitus Jensen wrote:
>>>
>>> ...
>>>>
>>>>>>   So currently .dev should be unbuildable for ppc users?  Without
>>>>>>   selecting a non-default compiler that is.
>>>>>>   I thought I pinned powerpc at 4.1.1, but it turns out that it was
>>>>>> only
>>>>>   for ppc405:
>>>>>>   ANGSTROM_GCC_VERSION_ppc405         ?= "4.1.1"
>>>>>>   Feel free to send patches to add that for other ppc platforms.
>>>>
>>>>  I'd loved to but it should be a usable version for ppc603e.  We have
>>>> used
>>>>  ELDK gcc 3.3.3 in the past so that version would be a known good one.
>>>>
>>>>  [stable/2009]
>>>>  4.2.4  wrong result
>>>>  4.1.1  wrong result (see first posting)
>>>>  3.3.3  doesn't compile, obstack macro problem
>>>>  3.3.4  doesn't compile, signal.h stack_t problem
>>>>
>>>>  [org.openembedded.dev]
>>>>  4.3.3  doesn't compile
>>>>  4.1.1  doesn't compile
>>>>  4.2.4  doesn't compile, libstdc++ problem
>>>>
>>>>  All compilations in the .dev branch used MACHINE=n1200, in stable I used
>>>>  our bluepro.  Always a clean build of meta-toolchain.  I know that there
>>>>  are currently problems in .dev so I will wait/monitor the list and try
>>>>  to get 3.3.3 and something newer than 4.3.3. to compile.
>>>
>>> Faster than thought: 4.4.4 compiles for n1200 (ppc603e) on .dev and
>>> produces correct output.  (double)(long long)10 equals 10.0.
>>
>> Only at -O2 and -O3, at those levels the internal function __floatdidf isn't
>> called (previously it was only -O3).
>
> I dont think thats the case. It always generates the call to __floatdidf

Well, it generates the call to __floatdidf from inside cast() but that 
function is never called from main but replaced with the precomputed 
result.  See attached assembler output, there is no call to _Z4castx.


> At -O1 and below it is called and
>> still produces incorrect results :-( Oh well, I give up for now.
>>
>
> All I have to test is qemu running OE/ppc603e. So i tried this test on 
> qemu/uclibc and it seems to work for me at O1/O2/O3 using gcc 4.4.4 and 
> minimal-uclibc distro. I would also try with eglibc but I need to build 
> it.

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?

Vitus

PS, to crosscheck: is there a HOWTO for qemu and oe/ppc?  And qemu_0.12.4 
doesn't build here.

-- 
Vitus Jensen, Hannover, Germany, Universe (current)
pgp public key available from keyservers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cast.g++O2.s
Type: text/x-asm
Size: 1544 bytes
Desc: g++ 4.4.4 -O2 output
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20100524/d69ce32e/attachment-0002.bin>


More information about the Openembedded-devel mailing list