powerpc-g++ 4.2.4 problem casting long long to double

powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

Hello!

We noticed a strange problem with C++ code casting long long variables to 
double, as a lot of qt-embedded code is doing.

=================
double
convert(long long l)
{
   return (double)l;	// or double(l)
}

int
main(int argc, char * argv[])
{
   long long l = 10;
   double f;

   f = convert(l);
   printf("convert: %lld => %f\n", l, f);
   return 0;
}
====================

output:
convert: 10 => 0.000000

C++ compiled via powerpc-angstrom-linux-g++ gives the above result. 
Compiling the same code as C using powerpc-angstrom-linux-gcc works fine. 
But when looking at the assembler code both compiler produce virtually 
identical output and both call __floatdidf to do the actual conversion. 
Very strange, has anyone ever seen similar effects?


MACHINE bluepro (ppc603e, used in n1200, efika, lite5200, storcenter)
DISTRO angstrom
BRANCH stable

Openembedded is used to build images and QT4 SDKs for this machine which 
work fine otherwise.  The compiler version used is the default for 
angstrom (4.2.4), that default and the gcc recipe is identical between 
stable and dev branches.

ppc405 uses the older 4.1.1 gcc which shows the identical behaviour when 
selected via ANGSTROM_GCC_VERSION.  4.3.2 and 4.3.3 failed to link but 
created the same assembler code otherwise.

How can I analyse this situation further?  I'm particular interested in 
how different __floatdidf versions get used dependend on frontend, the 
source of __floatdidf is in the gcc sourcetree and I expected it to be 
compiled just once.

Vitus


PS: fp-int-convert-long-double.c from the testsuite fails too, if
compiled via powerpc-angstrom-linux-g++

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

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Gary Thomas]

On 05/19/2010 03:38 AM, Vitus Jensen wrote:
> Hello!
>
> We noticed a strange problem with C++ code casting long long variables
> to double, as a lot of qt-embedded code is doing.
>
> =================
> double
> convert(long long l)
> {
> return (double)l; // or double(l)
> }
>
> int
> main(int argc, char * argv[])
> {
> long long l = 10;
> double f;
>
> f = convert(l);
> printf("convert: %lld => %f\n", l, f);
> return 0;
> }
> ====================
>
> output:
> convert: 10 => 0.000000
>
> C++ compiled via powerpc-angstrom-linux-g++ gives the above result.
> Compiling the same code as C using powerpc-angstrom-linux-gcc works
> fine. But when looking at the assembler code both compiler produce
> virtually identical output and both call __floatdidf to do the actual
> conversion. Very strange, has anyone ever seen similar effects?

Is this from a recent tree (i.e. post Richard Purdie's restructuring)?

I've seen similar problems with C++ code on Poky which uses the same changes.

>
> MACHINE bluepro (ppc603e, used in n1200, efika, lite5200, storcenter)
> DISTRO angstrom
> BRANCH stable
>
> Openembedded is used to build images and QT4 SDKs for this machine which
> work fine otherwise. The compiler version used is the default for
> angstrom (4.2.4), that default and the gcc recipe is identical between
> stable and dev branches.
>
> ppc405 uses the older 4.1.1 gcc which shows the identical behaviour when
> selected via ANGSTROM_GCC_VERSION. 4.3.2 and 4.3.3 failed to link but
> created the same assembler code otherwise.
>
> How can I analyse this situation further? I'm particular interested in
> how different __floatdidf versions get used dependend on frontend, the
> source of __floatdidf is in the gcc sourcetree and I expected it to be
> compiled just once.
>
> Vitus
>
>
> PS: fp-int-convert-long-double.c from the testsuite fails too, if
> compiled via powerpc-angstrom-linux-g++
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

On Wed, 19 May 2010, Gary Thomas wrote:

> On 05/19/2010 03:38 AM, Vitus Jensen wrote:
>>
>>  We noticed a strange problem with C++ code casting long long variables
>>  to double, as a lot of qt-embedded code is doing.
>>
>>  =================
>>  double
>>  convert(long long l)
>>  {
>>  return (double)l; // or double(l)
>>  }
>>
>>  int
>>  main(int argc, char * argv[])
>>  {
>>  long long l = 10;
>>  double f;
>>
>>  f = convert(l);
>>  printf("convert: %lld => %f\n", l, f);
>>  return 0;
>>  }
>>  ====================
>>
>>  output:
>>  convert: 10 => 0.000000
>>
>>  C++ compiled via powerpc-angstrom-linux-g++ gives the above result.
>>  Compiling the same code as C using powerpc-angstrom-linux-gcc works
>>  fine. But when looking at the assembler code both compiler produce
>>  virtually identical output and both call __floatdidf to do the actual
>>  conversion. Very strange, has anyone ever seen similar effects?
>
> Is this from a recent tree (i.e. post Richard Purdie's restructuring)?
>
> I've seen similar problems with C++ code on Poky which uses the same changes.

No, I'm building everything from the stable branch.  There were some 
commits cherry-picked from .dev but those only add Qt 4.5.2.

Poky is ARM only, right?  Perhaps it would be helpfull to build a compiler 
from .dev and for a widely used powerpc-platform?  How does n1200 sound? 
It uses the same ppc603e.

Vitus

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

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Gary Thomas]

On 05/19/2010 05:41 AM, Vitus Jensen wrote:
> On Wed, 19 May 2010, Gary Thomas wrote:
>
>> On 05/19/2010 03:38 AM, Vitus Jensen wrote:
>>>
>>> We noticed a strange problem with C++ code casting long long variables
>>> to double, as a lot of qt-embedded code is doing.
>>>
>>> =================
>>> double
>>> convert(long long l)
>>> {
>>> return (double)l; // or double(l)
>>> }
>>>
>>> int
>>> main(int argc, char * argv[])
>>> {
>>> long long l = 10;
>>> double f;
>>>
>>> f = convert(l);
>>> printf("convert: %lld => %f\n", l, f);
>>> return 0;
>>> }
>>> ====================
>>>
>>> output:
>>> convert: 10 => 0.000000
>>>
>>> C++ compiled via powerpc-angstrom-linux-g++ gives the above result.
>>> Compiling the same code as C using powerpc-angstrom-linux-gcc works
>>> fine. But when looking at the assembler code both compiler produce
>>> virtually identical output and both call __floatdidf to do the actual
>>> conversion. Very strange, has anyone ever seen similar effects?
>>
>> Is this from a recent tree (i.e. post Richard Purdie's restructuring)?
>>
>> I've seen similar problems with C++ code on Poky which uses the same
>> changes.
>
> No, I'm building everything from the stable branch. There were some
> commits cherry-picked from .dev but those only add Qt 4.5.2.
>
> Poky is ARM only, right? Perhaps it would be helpfull to build a
> compiler from .dev and for a widely used powerpc-platform? How does
> n1200 sound? It uses the same ppc603e.

Actually, Poky also supports PowerPC now :-)

That said, it may or may not be related.  I'll do some investigating.

Thanks for isolating this problem to such a simple example.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

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:
>> > 
>> >   We noticed a strange problem with C++ code casting long long variables
>> >   to double, as a lot of qt-embedded code is doing.
>> > 
>> >   =================
>> >   double
>> >   convert(long long l)
>> >   {
>> >   return (double)l; // or double(l)
>> >   }
>> > 
>> >   int
>> >   main(int argc, char * argv[])
>> >   {
>> >   long long l = 10;
>> >   double f;
>> > 
>> >   f = convert(l);
>> >   printf("convert: %lld => %f\n", l, f);
>> >   return 0;
>> >   }
>> >   ====================
>> > 
>> >   output:
>> >   convert: 10 => 0.000000
>> > 
>> >   C++ compiled via powerpc-angstrom-linux-g++ gives the above result.
>> >   Compiling the same code as C using powerpc-angstrom-linux-gcc works
>> >   fine. But when looking at the assembler code both compiler produce
>> >   virtually identical output and both call __floatdidf to do the actual
>> >   conversion. Very strange, has anyone ever seen similar effects?
>>
>>  Is this from a recent tree (i.e. post Richard Purdie's restructuring)?
>>
>>  I've seen similar problems with C++ code on Poky which uses the same
>>  changes.
>
> No, I'm building everything from the stable branch.  There were some commits 
> cherry-picked from .dev but those only add Qt 4.5.2.
>
> Poky is ARM only, right?  Perhaps it would be helpfull to build a compiler 
> from .dev and for a widely used powerpc-platform?  How does n1200 sound? It 
> uses the same ppc603e.

Unfortunately .dev switched to gcc-4.3.3 in the meantime which fails for 
ppc603e platforms because of undefined references to __nldbl_fprintf and 
__nldbl_sprintf during compile.

Platform tqm8540 (ppce500, just to try some other ppc cpu) fails in 
gcc-4.3.3 compile, too.  Possible related to this:

endian.h:34:4: warning: #warning Cannot determine current byte order, 
assuming big-endian.

So currently .dev should be unbuildable for ppc users?  Without selecting 
a non-default compiler that is.

Vitus

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

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:
>>> > >   We noticed a strange problem with C++ code casting long long
>>> variables
>>> >   to double, as a lot of qt-embedded code is doing.
>>> > >   =================
>>> >   double
>>> >   convert(long long l)
>>> >   {
>>> >   return (double)l; // or double(l)
>>> >   }
>>> > >   int
>>> >   main(int argc, char * argv[])
>>> >   {
>>> >   long long l = 10;
>>> >   double f;
>>> > >   f = convert(l);
>>> >   printf("convert: %lld => %f\n", l, f);
>>> >   return 0;
>>> >   }
>>> >   ====================
>>> > >   output:
>>> >   convert: 10 => 0.000000
>>> > >   C++ compiled via powerpc-angstrom-linux-g++ gives the above
>>> result.
>>> >   Compiling the same code as C using powerpc-angstrom-linux-gcc works
>>> >   fine. But when looking at the assembler code both compiler produce
>>> >   virtually identical output and both call __floatdidf to do the
>>> actual
>>> >   conversion. Very strange, has anyone ever seen similar effects?
>>>
>>>  Is this from a recent tree (i.e. post Richard Purdie's restructuring)?
>>>
>>>  I've seen similar problems with C++ code on Poky which uses the same
>>>  changes.
>>
>> No, I'm building everything from the stable branch.  There were some
>> commits cherry-picked from .dev but those only add Qt 4.5.2.
>>
>> Poky is ARM only, right?  Perhaps it would be helpfull to build a
>> compiler from .dev and for a widely used powerpc-platform?  How does
>> n1200 sound? It uses the same ppc603e.
> 
> Unfortunately .dev switched to gcc-4.3.3 in the meantime which fails for
> ppc603e platforms because of undefined references to __nldbl_fprintf and
> __nldbl_sprintf during compile.
> 
> Platform tqm8540 (ppce500, just to try some other ppc cpu) fails in
> gcc-4.3.3 compile, too.  Possible related to this:
> 
> endian.h:34:4: warning: #warning Cannot determine current byte order,
> assuming big-endian.
> 
> 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.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFL9BZaMkyGM64RGpERAl2wAJ0e6b4dQByFnOVP9LH0SPUSQeEfDwCbBFFc
bX9N5oxgcwlYQQgmGQMtNTU=
=Rijq
-----END PGP SIGNATURE-----

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

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:
>>>>>>   We noticed a strange problem with C++ code casting long long
>>>> variables
>>>>>   to double, as a lot of qt-embedded code is doing.
>>>>>>   =================
>>>>>   double
>>>>>   convert(long long l)
>>>>>   {
>>>>>   return (double)l; // or double(l)
>>>>>   }
>>>>>>   int
>>>>>   main(int argc, char * argv[])
>>>>>   {
>>>>>   long long l = 10;
>>>>>   double f;
>>>>>>   f = convert(l);
>>>>>   printf("convert: %lld => %f\n", l, f);
>>>>>   return 0;
>>>>>   }
>>>>>   ====================
>>>>>>   output:
>>>>>   convert: 10 => 0.000000
>>>>>>   C++ compiled via powerpc-angstrom-linux-g++ gives the above
>>>> result.
>>>>>   Compiling the same code as C using powerpc-angstrom-linux-gcc works
>>>>>   fine. But when looking at the assembler code both compiler produce
>>>>>   virtually identical output and both call __floatdidf to do the
>>>> actual
>>>>>   conversion. Very strange, has anyone ever seen similar effects?
>>>>
>>>>  Is this from a recent tree (i.e. post Richard Purdie's restructuring)?
>>>>
>>>>  I've seen similar problems with C++ code on Poky which uses the same
>>>>  changes.
>>>
>>> No, I'm building everything from the stable branch.  There were some
>>> commits cherry-picked from .dev but those only add Qt 4.5.2.
>>>
>>> Poky is ARM only, right?  Perhaps it would be helpfull to build a
>>> compiler from .dev and for a widely used powerpc-platform?  How does
>>> n1200 sound? It uses the same ppc603e.
>>
>> Unfortunately .dev switched to gcc-4.3.3 in the meantime which fails for
>> ppc603e platforms because of undefined references to __nldbl_fprintf and
>> __nldbl_sprintf during compile.
>>
>> Platform tqm8540 (ppce500, just to try some other ppc cpu) fails in
>> gcc-4.3.3 compile, too.  Possible related to this:
>>
>> endian.h:34:4: warning: #warning Cannot determine current byte order,
>> assuming big-endian.
>>
>> 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.

Vitus

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

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

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.

So await my patch.

Vitus

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

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

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).  At -O1 and below it is called 
and still produces incorrect results :-( Oh well, I give up for now.

Vitus

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

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Khem Raj]

On Fri, May 21, 2010 at 6:40 AM, Vitus Jensen <vjensen@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

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.

> Vitus
>
> --
> Vitus Jensen, Hannover, Germany, Universe (current)
> pgp public key available from keyservers
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3141 bytes --]

On Fri, 21 May 2010, Khem Raj wrote:

> On Fri, May 21, 2010 at 6:40 AM, Vitus Jensen <vjensen@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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: g++ 4.4.4 -O2 output --]
[-- Type: TEXT/x-asm; name=cast.g++O2.s, Size: 1544 bytes --]

	.file	"cast.cpp"
	.gnu_attribute 4, 1
	.gnu_attribute 8, 1
	.gnu_attribute 12, 2
	.globl __floatdidf
	.section	".text"
	.align 2
	.globl _Z4castx
	.type	_Z4castx, @function
_Z4castx:
.LFB12:
	mflr 0
.LCFI0:
	stwu 1,-16(1)
.LCFI1:
	stw 0,20(1)
.LCFI2:
	bl __floatdidf
	lwz 0,20(1)
	addi 1,1,16
	mtlr 0
	blr
.LFE12:
	.size	_Z4castx, .-_Z4castx
	.align 2
	.globl main
	.type	main, @function
main:
.LFB13:
	mflr 0
.LCFI3:
	lis 9,.LC2@ha
	stwu 1,-16(1)
.LCFI4:
	lis 3,.LC0@ha
	lfs 1,.LC2@l(9)
	la 3,.LC0@l(3)
	li 5,0
	li 6,10
	stw 0,20(1)
.LCFI5:
	creqv 6,6,6
	bl printf
	lwz 0,20(1)
	li 3,0
	addi 1,1,16
	mtlr 0
	blr
.LFE13:
	.size	main, .-main
	.section	.rodata.cst4,"aM",@progbits,4
	.align 2
.LC2:
	.4byte	1092616192
	.section	.rodata.str1.4,"aMS",@progbits,1
	.align 2
.LC0:
	.string	"%lld == %f\n"
	.section	.eh_frame,"a",@progbits
.Lframe1:
	.4byte	.LECIE1-.LSCIE1
.LSCIE1:
	.4byte	0x0
	.byte	0x1
	.globl __gxx_personality_v0
	.string	"zP"
	.uleb128 0x1
	.sleb128 -4
	.byte	0x41
	.uleb128 0x5
	.byte	0x0
	.4byte	__gxx_personality_v0
	.byte	0xc
	.uleb128 0x1
	.uleb128 0x0
	.align 2
.LECIE1:
.LSFDE3:
	.4byte	.LEFDE3-.LASFDE3
.LASFDE3:
	.4byte	.LASFDE3-.Lframe1
	.4byte	.LFB13
	.4byte	.LFE13-.LFB13
	.uleb128 0x0
	.byte	0x4
	.4byte	.LCFI4-.LFB13
	.byte	0xe
	.uleb128 0x10
	.byte	0x4
	.4byte	.LCFI5-.LCFI4
	.byte	0x5
	.uleb128 0x41
	.uleb128 0xffffffffffffffff
	.align 2
.LEFDE3:
	.ident	"GCC: (GNU) 4.4.4"
	.section	.note.GNU-stack,"",@progbits

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Khem Raj]

On (24/05/10 18:36), Vitus Jensen wrote:
> 
> 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.

yeah I see, its inlining the function.
> 
> 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.

Also try to generate the linker map file in faulty and good case.

try ldd on the binary on target and see if there is any difference
in libraries it is wanting 

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

You could use qemu-native from OE if thats not the one failing.
there is a script in contrib/qemu/run-qemu.sh thus far. Although one day I should
do a write-up on wiki about various qemu machines in OE

Thx
-Khem

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Vitus Jensen]

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@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, 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:

./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.

Vitus

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

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Khem Raj]

On Tue, May 25, 2010 at 8:15 AM, Vitus Jensen <vjensen@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@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.

>
> Vitus
>
> --
> Vitus Jensen, Hannover, Germany, Universe (current)
> pgp public key available from keyservers
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: 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@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@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

Re: powerpc-g++ 4.2.4 problem casting long long to double

[Khem Raj]

On Tue, May 25, 2010 at 10:34 PM, Vitus Jensen <vjensen@gmx.de> wrote:
> On Tue, 25 May 2010, Khem Raj wrote:
>>
>> On Tue, May 25, 2010 at 8:15 AM, Vitus Jensen <vjensen@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@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.

OK. If I find time I will fix gcc 4.2.4 today

>
> Vitus
>
> --
> Vitus Jensen, Hannover, Germany, Universe (current)
> pgp public key available from keyservers
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [STABLE] 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 10:34 PM, Vitus Jensen <vjensen@gmx.de> wrote:
>> On Tue, 25 May 2010, Khem Raj wrote:
>>> On Tue, May 25, 2010 at 8:15 AM, Vitus Jensen <vjensen@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@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.

...
>>> 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.

The problem is the order / preference in which libs are copied into the 
target dir.  If one ports the following commit to the stable/2009 branch 
the correct version remains on the target and resulting image should work:

commit 3fb59642b2b9afb7b8cd9769b53e24d85dc2f348
Author: Richard Purdie <rpurdie@linux.intel.com>
Date:   Thu Dec 17 21:07:31 2009 +0000

     gcc-pacpake-cross.inc: Clean up do_install function massively (from Poky)

     Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>

I need to clean TMPDIR, rebuild the image and test on the device.  Will 
post a patch if the result is good.

Vitus

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

[PATCH][STABLE] gcc-pacpake-cross.inc: Clean up do_install function massively (from Poky)

[Vitus Jensen]

This fixes floating-point problems on machine n1200 and others caused by
installing softfloat libraries while the toolchain creates hardfloat
programs.

Signed-off-by: Vitus Jensen <vjensen@gmx.de>
---
 recipes/gcc/gcc-package-cross.inc |   81 +++++++++++++-----------------------
 1 files changed, 29 insertions(+), 52 deletions(-)

diff --git a/recipes/gcc/gcc-package-cross.inc b/recipes/gcc/gcc-package-cross.inc
index 77da3fe..b205b8c 100644
--- a/recipes/gcc/gcc-package-cross.inc
+++ b/recipes/gcc/gcc-package-cross.inc
@@ -18,58 +18,35 @@ FILES_libstdc++ = "${target_libdir}/libstdc++.so.*"
 do_install () {
 	oe_runmake 'DESTDIR=${D}' install
 
-	# Move libgcc_s into /lib
-        mkdir -p ${D}${target_base_libdir}
-        if [ -f ${D}${target_base_libdir}/libgcc_s.so.? ]; then
-                # Already in the right location
-                :
-        elif [ -f ${D}${prefix}/lib/libgcc_s.so.? ]; then
-                mv -f ${D}${prefix}/lib/libgcc_s.so* ${D}${target_base_libdir} || true
-
-        elif [  -f ${D}${prefix}/*/lib/nof/libgcc_s.so.? ]; then
-                mv -f ${D}${prefix}/*/lib/nof/libgcc_s.so* ${D}${target_base_libdir}
-        else
-                mv -f ${D}${prefix}/*/lib/libgcc_s.so* ${D}${target_base_libdir} || true 
-        fi
-
-
-
-	# Move libstdc++ and libg2c into libdir (resetting our prefix to /usr
-        mkdir -p ${D}${target_libdir}
-
-        if [ -f ${D}${prefix}/*/lib/nof/libstdc++.so ]; then
-
-           mv -f ${D}${prefix}/*/lib/nof/libstdc++.so* ${D}${target_libdir} || true
-           mv -f ${D}${prefix}/*/lib/nof/libg2c.so* ${D}${target_libdir} || true
-           mv -f ${D}${prefix}/*/lib/nof/libgfortran*.so* ${D}${target_libdir} || true
-           mv -f ${D}${prefix}/*/lib/nof/libssp*.so* ${D}${target_libdir} || true 	
-
-        else
-           mv -f ${D}${prefix}/*/lib/libstdc++.so* ${D}${target_libdir} || true
-           mv -f ${D}${prefix}/*/lib/libg2c.so* ${D}${target_libdir} || true
-           mv -f ${D}${prefix}/*/lib/libgfortran*.so* ${D}${target_libdir} || true
-           mv -f ${D}${prefix}/*/lib/libssp*.so* ${D}${target_libdir} || true
-        fi
-
-
+	install -d ${D}${target_base_libdir}
+	install -d ${D}${target_libdir}
+
+	for d in ${TARGET_SYS}/lib/nof ${TARGET_SYS}/lib64 ${TARGET_SYS}/lib; do
+		if [ -d ${D}${prefix}/$d/ ]; then
+			mv -f ${D}${prefix}/$d/libgcc* ${D}${target_base_libdir} || true
+			mv -f ${D}${prefix}/$d/* ${D}${target_libdir} || true
+		fi
+	done
+
+	# Manually run the target stripper since we won't get it run by
+	# the packaging.
+	if [ "x${OLD_INHIBIT_PACKAGE_STRIP}" != "x1" ]; then
+		${TARGET_PREFIX}strip ${D}${target_libdir}/libstdc++.so.*
+		${TARGET_PREFIX}strip ${D}${target_libdir}/libg2c.so.* || true
+		${TARGET_PREFIX}strip ${D}${target_base_libdir}/libgcc_s.so.* || true
+		${TARGET_PREFIX}strip ${D}${target_libdir}/libgfortran*.so* || true
+	fi
 
-       # Manually run the target stripper since we won't get it run by
-       # the packaging.
-       if [ "x${OLD_INHIBIT_PACKAGE_STRIP}" != "x1" ]; then
-               ${TARGET_PREFIX}strip ${D}${target_libdir}/libstdc++.so.*
-               ${TARGET_PREFIX}strip ${D}${target_libdir}/libg2c.so.* || true
-               ${TARGET_PREFIX}strip ${D}${target_base_libdir}/libgcc_s.so.* || true
-               ${TARGET_PREFIX}strip ${D}${target_libdir}/libgfortran*.so* || true
+	# Link gfortran to g77 to satisfy not-so-smart configure or hard coded g77
+	# gfortran is fully backwards compatible. This is a safe and practical solution.
+	if [ -f ${CROSS_DIR}/bin/${TARGET_PREFIX}gfortran ]; then
+		currdir="$PWD"
+		cd ${CROSS_DIR}/bin/
+		ln -sf ${TARGET_PREFIX}gfortran ${TARGET_PREFIX}g77 || true
+		if [ -d ${CROSS_DIR}/${TARGET_SYS}/bin/ ] ; then
+			cd ${CROSS_DIR}/${TARGET_SYS}/bin/
+			ln -sf gfortran g77 || true
+		fi
+		cd $currdir
 	fi
-     
-       # Link gfortran to g77 to satisfy not-so-smart configure or hard coded g77
-       # gfortran is fully backwards compatible. This is a safe and practical solution.
-       if [ -f ${CROSS_DIR}/bin/${TARGET_PREFIX}gfortran ]; then
-              currdir="$PWD"
-              cd ${CROSS_DIR}/bin/
-              ln -sf ${TARGET_PREFIX}gfortran ${TARGET_PREFIX}g77 || true
-              cd ${CROSS_DIR}/${TARGET_SYS}/bin/
-              ln -sf gfortran g77 || true
-              cd $currdir
-       fi
 }
-- 
1.7.1

Re: [PATCH][STABLE] gcc-pacpake-cross.inc: Clean up do_install function massively (from Poky)

[Khem Raj]

On (09/06/10 14:13), Vitus Jensen wrote:
> This fixes floating-point problems on machine n1200 and others caused by
> installing softfloat libraries while the toolchain creates hardfloat
> programs.
> 
> Signed-off-by: Vitus Jensen <vjensen@gmx.de>

looks ok.

Acked-by: Khem Raj <raj.khem@gmail.com>

> ---
>  recipes/gcc/gcc-package-cross.inc |   81 +++++++++++++-----------------------
>  1 files changed, 29 insertions(+), 52 deletions(-)
> 
> diff --git a/recipes/gcc/gcc-package-cross.inc b/recipes/gcc/gcc-package-cross.inc
> index 77da3fe..b205b8c 100644
> --- a/recipes/gcc/gcc-package-cross.inc
> +++ b/recipes/gcc/gcc-package-cross.inc
> @@ -18,58 +18,35 @@ FILES_libstdc++ = "${target_libdir}/libstdc++.so.*"
>  do_install () {
>  	oe_runmake 'DESTDIR=${D}' install
>  
> -	# Move libgcc_s into /lib
> -        mkdir -p ${D}${target_base_libdir}
> -        if [ -f ${D}${target_base_libdir}/libgcc_s.so.? ]; then
> -                # Already in the right location
> -                :
> -        elif [ -f ${D}${prefix}/lib/libgcc_s.so.? ]; then
> -                mv -f ${D}${prefix}/lib/libgcc_s.so* ${D}${target_base_libdir} || true
> -
> -        elif [  -f ${D}${prefix}/*/lib/nof/libgcc_s.so.? ]; then
> -                mv -f ${D}${prefix}/*/lib/nof/libgcc_s.so* ${D}${target_base_libdir}
> -        else
> -                mv -f ${D}${prefix}/*/lib/libgcc_s.so* ${D}${target_base_libdir} || true 
> -        fi
> -
> -
> -
> -	# Move libstdc++ and libg2c into libdir (resetting our prefix to /usr
> -        mkdir -p ${D}${target_libdir}
> -
> -        if [ -f ${D}${prefix}/*/lib/nof/libstdc++.so ]; then
> -
> -           mv -f ${D}${prefix}/*/lib/nof/libstdc++.so* ${D}${target_libdir} || true
> -           mv -f ${D}${prefix}/*/lib/nof/libg2c.so* ${D}${target_libdir} || true
> -           mv -f ${D}${prefix}/*/lib/nof/libgfortran*.so* ${D}${target_libdir} || true
> -           mv -f ${D}${prefix}/*/lib/nof/libssp*.so* ${D}${target_libdir} || true 	
> -
> -        else
> -           mv -f ${D}${prefix}/*/lib/libstdc++.so* ${D}${target_libdir} || true
> -           mv -f ${D}${prefix}/*/lib/libg2c.so* ${D}${target_libdir} || true
> -           mv -f ${D}${prefix}/*/lib/libgfortran*.so* ${D}${target_libdir} || true
> -           mv -f ${D}${prefix}/*/lib/libssp*.so* ${D}${target_libdir} || true
> -        fi
> -
> -
> +	install -d ${D}${target_base_libdir}
> +	install -d ${D}${target_libdir}
> +
> +	for d in ${TARGET_SYS}/lib/nof ${TARGET_SYS}/lib64 ${TARGET_SYS}/lib; do
> +		if [ -d ${D}${prefix}/$d/ ]; then
> +			mv -f ${D}${prefix}/$d/libgcc* ${D}${target_base_libdir} || true
> +			mv -f ${D}${prefix}/$d/* ${D}${target_libdir} || true
> +		fi
> +	done
> +
> +	# Manually run the target stripper since we won't get it run by
> +	# the packaging.
> +	if [ "x${OLD_INHIBIT_PACKAGE_STRIP}" != "x1" ]; then
> +		${TARGET_PREFIX}strip ${D}${target_libdir}/libstdc++.so.*
> +		${TARGET_PREFIX}strip ${D}${target_libdir}/libg2c.so.* || true
> +		${TARGET_PREFIX}strip ${D}${target_base_libdir}/libgcc_s.so.* || true
> +		${TARGET_PREFIX}strip ${D}${target_libdir}/libgfortran*.so* || true
> +	fi
>  
> -       # Manually run the target stripper since we won't get it run by
> -       # the packaging.
> -       if [ "x${OLD_INHIBIT_PACKAGE_STRIP}" != "x1" ]; then
> -               ${TARGET_PREFIX}strip ${D}${target_libdir}/libstdc++.so.*
> -               ${TARGET_PREFIX}strip ${D}${target_libdir}/libg2c.so.* || true
> -               ${TARGET_PREFIX}strip ${D}${target_base_libdir}/libgcc_s.so.* || true
> -               ${TARGET_PREFIX}strip ${D}${target_libdir}/libgfortran*.so* || true
> +	# Link gfortran to g77 to satisfy not-so-smart configure or hard coded g77
> +	# gfortran is fully backwards compatible. This is a safe and practical solution.
> +	if [ -f ${CROSS_DIR}/bin/${TARGET_PREFIX}gfortran ]; then
> +		currdir="$PWD"
> +		cd ${CROSS_DIR}/bin/
> +		ln -sf ${TARGET_PREFIX}gfortran ${TARGET_PREFIX}g77 || true
> +		if [ -d ${CROSS_DIR}/${TARGET_SYS}/bin/ ] ; then
> +			cd ${CROSS_DIR}/${TARGET_SYS}/bin/
> +			ln -sf gfortran g77 || true
> +		fi
> +		cd $currdir
>  	fi
> -     
> -       # Link gfortran to g77 to satisfy not-so-smart configure or hard coded g77
> -       # gfortran is fully backwards compatible. This is a safe and practical solution.
> -       if [ -f ${CROSS_DIR}/bin/${TARGET_PREFIX}gfortran ]; then
> -              currdir="$PWD"
> -              cd ${CROSS_DIR}/bin/
> -              ln -sf ${TARGET_PREFIX}gfortran ${TARGET_PREFIX}g77 || true
> -              cd ${CROSS_DIR}/${TARGET_SYS}/bin/
> -              ln -sf gfortran g77 || true
> -              cd $currdir
> -       fi
>  }
> -- 
> 1.7.1
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel