Bug 48301 - Xcode 4.0's llvm-gcc can't bootstrap gcc 4.6.0 or trunk
Summary: Xcode 4.0's llvm-gcc can't bootstrap gcc 4.6.0 or trunk
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
: 48388 52293 (view as bug list)
Depends on:
Reported: 2011-03-27 17:02 UTC by Jack Howarth
Modified: 2012-02-17 19:04 UTC (History)
6 users (show)

See Also:
Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
Build: x86_64-apple-darwin10
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Jack Howarth 2011-03-27 17:02:07 UTC
While Xcode 4.0's clang can bootstrap FSF gcc trunk and 4.6.0, the llvm-gcc compiler can not. The bootstrap fails as...

mkdir x86_64-apple-darwin10.7.0/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in x86_64-apple-darwin10.7.0/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-apple-darwin10.7.0
checking host system type... x86_64-apple-darwin10.7.0
checking for x86_64-apple-darwin10.7.0-ar... ar
checking for x86_64-apple-darwin10.7.0-lipo... lipo
checking for x86_64-apple-darwin10.7.0-nm... /Users/howarth/work/./gcc/nm
checking for x86_64-apple-darwin10.7.0-ranlib... ranlib
checking for x86_64-apple-darwin10.7.0-strip... strip
checking whether ln -s works... yes
checking for x86_64-apple-darwin10.7.0-gcc... /Users/howarth/work/./gcc/xgcc -B/Users/howarth/work/./gcc/ -B/Users/howarth/dist/x86_64-apple-darwin10.7.0/bin/ -B/Users/howarth/dist/x86_64-apple-darwin10.7.0/lib/ -isystem /Users/howarth/dist/x86_64-apple-darwin10.7.0/include -isystem /Users/howarth/dist/x86_64-apple-darwin10.7.0/sys-include   
checking for suffix of object files... configure: error: in `/Users/howarth/work/x86_64-apple-darwin10.7.0/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

While this is likely a bug in llvm-gcc, we should attempt to analyze it and file the appropriate radar bug reports against llvm-gcc in case Apple switches to llvm-gcc as the system compiler in the future.
Comment 1 Jack Howarth 2011-03-27 17:06:54 UTC
This bootstrap failure backtraces as...

[MacPro:~/work/x86_64-apple-darwin10.7.0/libgcc] howarth% gdb /Users/howarth/work/./gcc/cc1

(gdb) r -quiet -v -iprefix /Users/howarth/work/gcc/../lib/gcc/x86_64-apple-darwin10.7.0/4.6.1/ -isystem /Users/howarth/work/./gcc/include -isystem /Users/howarth/work/./gcc/include-fixed -D__DYNAMIC__ -isystem /Users/howarth/dist/x86_64-apple-darwin10.7.0/include -isystem /Users/howarth/dist/x86_64-apple-darwin10.7.0/sys-include conftest.c -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase conftest.c -mmacosx-version-min=10.6.7 -mtune=core2 -auxbase conftest -g -O2 -version -o /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccGHUc47.s
Starting program: /Users/howarth/work/gcc/cc1 -quiet -v -iprefix /Users/howarth/work/gcc/../lib/gcc/x86_64-apple-darwin10.7.0/4.6.1/ -isystem /Users/howarth/work/./gcc/include -isystem /Users/howarth/work/./gcc/include-fixed -D__DYNAMIC__ -isystem /Users/howarth/dist/x86_64-apple-darwin10.7.0/include -isystem /Users/howarth/dist/x86_64-apple-darwin10.7.0/sys-include conftest.c -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase conftest.c -mmacosx-version-min=10.6.7 -mtune=core2 -auxbase conftest -g -O2 -version -o /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccGHUc47.s
Reading symbols for shared libraries .+++++++++++++..... done
GNU C (GCC) version 4.6.1 20110327 (prerelease) (x86_64-apple-darwin10.7.0)
	compiled by GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.9), GMP version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/Users/howarth/dist/x86_64-apple-darwin10.7.0/include"
ignoring nonexistent directory "/Users/howarth/dist/x86_64-apple-darwin10.7.0/sys-include"
ignoring nonexistent directory "/Users/howarth/work/gcc/../lib/gcc/x86_64-apple-darwin10.7.0/4.6.1/include"
ignoring nonexistent directory "/Users/howarth/work/gcc/../lib/gcc/x86_64-apple-darwin10.7.0/4.6.1/include-fixed"
ignoring nonexistent directory "/Users/howarth/work/gcc/../lib/gcc/x86_64-apple-darwin10.7.0/4.6.1/../../../../x86_64-apple-darwin10.7.0/include"
ignoring nonexistent directory "/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.7.0/4.6.1/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/Users/howarth/dist/include"
ignoring nonexistent directory "/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.7.0/4.6.1/include-fixed"
ignoring nonexistent directory "/Users/howarth/dist/x86_64-apple-darwin10.7.0/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000058
0x00000001011c9b8e in ix86_cfun_abi () at i386.c:5796
5796	  return cfun->machine->call_abi;
(gdb) bt
#0  0x00000001011c9b8e in ix86_cfun_abi () at i386.c:5796
#1  0x00000001011c1bd0 in ix86_option_override_internal (main_args_p=1 '\001') at i386.c:3862
#2  0x00000001011c3460 in ix86_option_override () at i386.c:4323
#3  0x0000000100d2826b in process_options () at toplev.c:1286
#4  0x0000000100d294a0 in do_compile () at toplev.c:1885
#5  0x0000000100d296a8 in toplev_main (argc=29, argv=0x7fff5fbfec60) at toplev.c:1964
#6  0x00000001001a7a80 in main (argc=29, argv=0x7fff5fbfec60) at main.c:36
Comment 2 Jack Howarth 2011-03-27 17:42:05 UTC
Same issue exists with llvm-gcc from llvm 2.9 svn.
Comment 3 Richard Biener 2011-03-28 09:35:37 UTC
So llvm miscompiles cc1.  Not a GCC bug.
Comment 4 Mike Stump 2011-03-28 17:41:36 UTC
If there is an easy work around in gcc to avoid the problem, we could entertain that, but, generally, I'd be more interested in clang failures going forward.  llvm-gcc is old and getting older every day.  The dragon egg bits are newer and more compelling.
Comment 5 Jack Howarth 2011-03-29 03:15:32 UTC
FYI, this problem also exists under linux so it isn't darwin specific. Opened...

Comment 6 Richard Biener 2011-03-31 15:31:38 UTC
*** Bug 48388 has been marked as a duplicate of this bug. ***
Comment 7 Jack Howarth 2011-03-31 16:43:28 UTC
This issue has been fixed in Apple's llvm-gcc at revision 128619. It is unclear if this fix will make it into llvm.org's llvm-gcc-4.2 2.9 release (which is slated to be the final one with llvm-gcc). The patch...


can be manually applied if it isn't. I've confirmed that this fixes the bootstraps of both 4.4.5 and 4.6.0.
Comment 8 Jack Howarth 2011-04-01 00:12:48 UTC
FYI, the fix for this bug has been checked into the llvm-gcc-4.2 2.9 branch for that release.
Comment 9 Andrew Pinski 2012-02-17 07:51:54 UTC
*** Bug 52293 has been marked as a duplicate of this bug. ***
Comment 10 Jack Howarth 2012-02-17 19:04:24 UTC
FYI, this issue appears to be fixed in the llvm-gcc-4.2 of Xcode 4.3. Of course that only helps Xcode users on Lion or later.