Floating point code miscompiled on OS X PPC

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compiled latest svn toolchain today (Sep 12, 07) on PPC G4 1Ghz MacOSX 10.4
2. Compiled uikit hello world app and deployed to iPhone
3. Relaunched summerboard and launched app

What is the expected output? What do you see instead?
I expected to see the "foo" and "bar" menu buttons at the top with the
hello world message in the body.

What I got was a black screen.  I can hit the button to go back to
summerboard still so it didn't crash.

What version of the product are you using? On what operating system?
arm-apple-darwin-gcc -v:
Using built-in specs.
Target: arm-apple-darwin
Configured with: ../llvm-gcc-4.0-iphone/configure
--enable-llvm=/Users/dave/toolchain/llvm-svn
--enable-languages=c,c++,objc,obj-c++ --target=arm-apple-darwin
--enable-sjlj-exceptions --with-heavenly=/usr/local/share/heavenly
--with-as=/usr/local/bin/arm-apple-darwin-as
--with-ld=/usr/local/bin/arm-apple-darwin-ld
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5449)(LLVM build
2.0-svn-iphone-dev-0.3-svn)

sysctl -a:
kern.version = Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007;
root:xnu-792.21.3~1/RELEASE_PPC

Please provide any additional information below.

I think the resulting executable is not right for some reason.  I wish I
had an executable compiled by the toolchain on an x86 mac to compare with.
 I have attached a tarball with the hello world folder containing the
source, makefile, and compiled executable.

Original issue reported on code.google.com by d...@linuxprogrammer.org on 12 Sep 2007 at 11:48

Attachments:

• helloworld.tar.gz

[GoogleCodeExporter]

The attached program runs for me on x86. Something strange is going on with 
your compiler's floating point, 
because it's producing this:

 +001b8 00002860 00B0A0E3             mov               fp,#0x0
 +001bc 00002864 800047E2             sub               r0,r7,#0x80
 +001c0 00002868 00B08DE4             str               fp,[sp]
 +001c4 0000286c 0B10A0E1             mov               r1,fp
 +001c8 00002870 0B20A0E1             mov               r2,fp
 +001cc 00002874 0B30A0E1             mov               r3,fp
 +001d0 00002878 BD0000EB             bl                CGRectMake

i.e. it's calling CGRectMake(0, 0, 0, 0)!! Unfortunately I can't reproduce this 
myself, because your source 
compiles and runs perfectly for me.

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 2:20

• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I wonder if it's an assembler problem. Could you compile using the -save-temps 
option to GCC and send me 
the HelloApplication.s file?

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 2:25

[GoogleCodeExporter]

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 2:25

• Changed state: Waiting

[GoogleCodeExporter]

Here's the HelloApplication.s file compiled with the -save-temps flag.

Original comment by d...@linuxprogrammer.org on 13 Sep 2007 at 3:52

Attachments:

• HelloApplication.s

[GoogleCodeExporter]

Well, it is indeed a GCC problem. Somewhere in the middle end of LLVM-GCC 
everything is getting all jammed 
up w/r/t floating point numbers, but only on OS X PPC. Without a PPC to test 
myself on there's nothing I can do.

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 4:02

• Changed state: Accepted

[GoogleCodeExporter]

Well, I'll help all I can.  I noticed that I wasn't all caught up to head when I
built this toolchain.  I missed the checkin from this afternoon so I'm 
rebuilding
everything from scratch now.

Original comment by d...@linuxprogrammer.org on 13 Sep 2007 at 4:06

[GoogleCodeExporter]

Make sure that your ARM FP type is set correctly. The driver tries to set this 
via a compile flag. Run gcc with -v 
while building something and you should see a line such as the following:

 /usr/local/libexec/gcc/arm-apple-darwin/4.0.1/cc1obj -quiet -v -D__DYNAMIC__ synchronized.m -fPIC -
mfpu=vfp -mcpu=arm1176jzf-s -quiet -dumpbase synchronized.m 
-mmacosx-version-min=10.4 -
auxbase synchronized -version -o /var/tmp//cc8oNlnF.s

Notice that the -mfpu and -mcpu options are set as they are. This is important!

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 4:10

[GoogleCodeExporter]

i am having a similar problem here, but building on x86.  i built & installed 
the 
toolchain and copied the hello world source from the wiki.  i can build and run 
command line C/C++ applications fine.  however, building the UIKit hello world 
application (objC) doesn't work - running it on iPhone with ./Hello produces a 
bus 
error.  i then created a command line objc application and that works as well.  
something must be wrong with the way i am linking against UIKit.  i created my 
heavenly rootfs by scp'ing stuff over from my phone.  is that most likely the 
problem?

Original comment by visig...@gmail.com on 13 Sep 2007 at 6:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

i created my heavenly rootfs from the iTunes restore dmg and got the same 
result.  
that doesn't appear to be the problem.

i also placed some logging in there.  the application still seems to load fine, 
but 
as soon as window = [[UIWindow alloc] initWithContentRect: [UIHardware 
fullScreenApplicationContentRect]]; is reached, that is when the bus error 
occurs.  

Original comment by visig...@gmail.com on 13 Sep 2007 at 6:57

[GoogleCodeExporter]

>>10

This looks like issue 10, which is fixed in the latest SVN.

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 4:22

[GoogleCodeExporter]

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 4:33

• Changed title: Floating point code miscompiled on OS X PPC
• Added labels: Component-Logic

[GoogleCodeExporter]

Original comment by nightwat...@gmail.com on 13 Sep 2007 at 5:05

• Added labels: OpSys-OSX

[GoogleCodeExporter]

I never figured out what was wrong, but I deleted everything, and followed the
instructions again from scratch and the toolchain works now.

I can confirm that PPC Mac OSX 10.4 works.

Original comment by d...@linuxprogrammer.org on 14 Sep 2007 at 3:53

[GoogleCodeExporter]

Hmm, ok. Until this can be reproduced I'm setting this to WorksForMe.

Original comment by nightwat...@gmail.com on 15 Sep 2007 at 2:45

• Changed state: WorksForMe