This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: FW: wrong code generation in newlib 1.1.14 PPC ?!
- From: Ralf Corsepius <ralf dot corsepius at rtems dot org>
- To: Frank Juergen-r58616 <Juergen dot Frank at freescale dot com>
- Cc: newlib at sources dot redhat dot com
- Date: Thu, 12 Jan 2006 11:52:31 +0100
- Subject: RE: FW: wrong code generation in newlib 1.1.14 PPC ?!
- References: <DF02D66C37C26B4C8018BF84F0E37FEC0B1447A0@zwg18exm01.ea.freescale.net>
On Thu, 2006-01-12 at 11:33 +0100, Frank Juergen-r58616 wrote:
> No no,
>
> after the compilation I get code like this
>
> .
> .
> .
> cmpwr cr7,r5,0
> cmpwr cr6,r9,0
> addi r3,r1,8
> .long 0x7C89209e <-- looks like an unown opcode , this address produce the crash
> li r3,-2
> .
> .
> .
>
> I dig in the assembler code and found many other values like this one.
> But all of them are only in the function which are deliverd by newlib.
This indicates using inconsistent CFLAGS when bootstrapping the
toolchain.
> The code which was written by me looks good ... I now this sounds
> strange but this is the situation. If you has this problem in general
> I would say oh this is a problem of the compiler (finally the compiler
> produce the opcodes) but why are only the newlib part buggy ??
Most probably you are using different CFLAGS for compiling the
application than those having been used when compiling newlib.
In other words, you probably compile your application for a different
architecture-variant than you had been using when building gcc/newlib.
Ralf