[Bug bootstrap/28994] New: 64-bit problem in host-darwin.c
When configuring and bootstrapping with #!/bin/tcsh /bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure --prefix=/pkgs/gcc-test-64 --enable-languages=c --disable-checking; make -j 16 bootstrap BOOT_CFLAGS='-O2 -g -mcpu=970 -m64' build.log bootstrap fails with /Users/gcc-test/programs/gcc/mainline/objdir-64-c/./prev-gcc/xgcc -B/Users/gcc-test/programs/gcc/mainline/objdir-64-c/./prev-gcc/ -B/pkgs/gcc-test-64/powerpc-apple-darwin8.7.0/bin/ -c -O2 -g -mcpu=970 -m64 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber ../../gcc/config/rs6000/host-darwin.c -o host-ppc-darwin.o cc1: warnings being treated as errors ../../gcc/config/rs6000/host-darwin.c: In function 'segv_handler': ../../gcc/config/rs6000/host-darwin.c:81: warning: cast to pointer from integer of different size ../../gcc/config/rs6000/host-darwin.c:131: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'unsigned int' Now, you might say that this isn't the way to try to build a 64-bit compiler that targets 32-bit binaries, but I still think that there are 32-bit assumptions in this routine that need to be fixed. Brad -- Summary: 64-bit problem in host-darwin.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.7.0 GCC host triplet: powerpc-apple-darwin8.7.0 GCC target triplet: powerpc-apple-darwin8.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994
[Bug other/28910] New: Make install leaves files owned by root in build directory
After configure; make bootstrap; make test; make install: find . -user root ./gcc/libgcc_s.1.dylib.tmp ./gcc/ppc64/libgcc_s.1.dylib.tmp ./powerpc-apple-darwin8.7.0/libjava/.libs/libgij.8.0.0.dylibT ./powerpc-apple-darwin8.7.0/libjava/.libs/libjvm.dylibT ./powerpc-apple-darwin8.7.0/ppc64/libjava/.libs/libgij.8.0.0.dylibT ./powerpc-apple-darwin8.7.0/ppc64/libjava/.libs/libjvm.dylibT ./powerpc-apple-darwin8.7.0/ppc64/libjava/classpath/lib/classes.1 I don't think an install script (that one generally must run as root) should leave any files in the build directory. -- Summary: Make install leaves files owned by root in build directory Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.7.0 GCC host triplet: powerpc-apple-darwin8.7.0 GCC target triplet: powerpc-apple-darwin8.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28910
[Bug testsuite/28913] New: make install required before testing libgomp and gfortran
gfortran and libgomp tests do not link the just-built libraries when make check is run unless the libraries are first installed in $prefix/lib. This results in the following differences in the reported error rate for gfortran: Testing after running make install: # of expected passes 14014 # of unexpected failures 33 Testing without running make install: # of expected passes 13143 # of unexpected failures 824 For libgomp: Testing after running make install: # of expected passes 1075 # of unexpected failures 205 Testing without running make install: # of expected passes 963 # of unexpected failures 317 The results after make install, with two patches installed, can be found at http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01383.html -- Summary: make install required before testing libgomp and gfortran Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.7.0 GCC host triplet: powerpc-apple-darwin8.7.0 GCC target triplet: powerpc-apple-darwin8.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28913
[Bug bootstrap/28776] New: dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
configure and build:
/bin/rm -rf *; ../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/
--with-mpfr=/opt/local/ ; make -j 4 bootstrap build.log (make -k -j 8
check RUNTESTFLAGS=--target_board 'unix{-mcpu=970/-m64}' check.log ; make
mail-report-with-warnings.log)
with updated Xcode:
[descartes:gcc/mainline/objdir64] lucier% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
fails with the stage2 build with
/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc
-B/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/
-B/pkgs/gcc-mainline/powerpc-apple-darwin8.7.0/bin/ -c -g -O2
-mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute
-Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I/opt/local//include -I/opt/local//include -I../../gcc/../libdecnumber
-I../libdecnumber../../gcc/dwarf2out.c -o dwarf2out.o
../../gcc/dwarf2out.c: In function 'output_call_frame_info':
../../gcc/dwarf2out.c:2160: internal compiler error: in build_polynomial_chrec,
at tree-chrec.h:108
--
Summary: dwarf2out.c:2160: ICE: in build_polynomial_chrec, at
tree-chrec.h:108
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc-apple-darwin8.7.0
GCC host triplet: powerpc-apple-darwin8.7.0
GCC target triplet: powerpc-apple-darwin8.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #3 from lucier at math dot purdue dot edu 2006-08-18 21:34 --- Created an attachment (id=12094) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12094action=view) preprocessed source for dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug other/23541] All error messages produce segfault
--- Comment #24 from lucier at math dot purdue dot edu 2006-07-19 00:19 --- Well, I just hit the same bug in 4.1.1, so it survived from 4.1.0. I must be one hell of an atypical guy building 4.1.1, my bootstrap on x86-64 RHEL 4.0 didn't work (PR 28066), my 32-bit bootstrap on sparc-sun-solaris2.9 didn't work (PR27823), and now my 64-bit bootstrap fails here. Any chance of this one getting fixed in time for 4.1.2? -- lucier at math dot purdue dot edu changed: What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541
[Bug bootstrap/28428] New: parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
The build log is somewhat jumbled, but bootstrap fails a make -j 8 with stage1/xgcc -Bstage1/ -B/pkgs/gcc-4.1.1/sparc-sun-solaris2.9/bin/ -c -O2 -g -mcpu=ultrasparc -m64 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I/pkgs/gmp-4.1.4/include -I/pkgs/gmp-4.1.4/include-o build/dummy-conditions.o ../../gcc/dummy-conditions.c echo \../../gcc\ tmp-gtyp.h ltf=../../gcc/cp/cp-tree.def ../../gcc/java/java-tree.def ../../gcc/objc/objc-tree.def; for f in $ltf; do \ echo #include \$f\; \ done | sed 's|../../gcc/||' tmp-gencheck.h make[2]: *** No rule to make target `c-typeck.c', needed by `c-typeck.o'. Stop. make[2]: *** Waiting for unfinished jobs echo ; tmp-gtyp.h make[2]: *** Waiting for unfinished jobs /usr/bin/ksh ../../gcc/../move-if-change tmp-optionlist optionlist make[2]: *** Waiting for unfinished jobs -- Summary: parallel make failure: No rule to make target `c- typeck.c', needed by `c-typeck.o'. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28428
[Bug bootstrap/28429] New: parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
The build log is somewhat jumbled, but bootstrap fails a make -j 8 with stage1/xgcc -Bstage1/ -B/pkgs/gcc-4.1.1/sparc-sun-solaris2.9/bin/ -c -O2 -g -mcpu=ultrasparc -m64 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I/pkgs/gmp-4.1.4/include -I/pkgs/gmp-4.1.4/include-o build/dummy-conditions.o ../../gcc/dummy-conditions.c echo \../../gcc\ tmp-gtyp.h ltf=../../gcc/cp/cp-tree.def ../../gcc/java/java-tree.def ../../gcc/objc/objc-tree.def; for f in $ltf; do \ echo #include \$f\; \ done | sed 's|../../gcc/||' tmp-gencheck.h make[2]: *** No rule to make target `c-typeck.c', needed by `c-typeck.o'. Stop. make[2]: *** Waiting for unfinished jobs echo ; tmp-gtyp.h make[2]: *** Waiting for unfinished jobs /usr/bin/ksh ../../gcc/../move-if-change tmp-optionlist optionlist make[2]: *** Waiting for unfinished jobs -- Summary: parallel make failure: No rule to make target `c- typeck.c', needed by `c-typeck.o'. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28429
[Bug bootstrap/28429] parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
--- Comment #1 from lucier at math dot purdue dot edu 2006-07-19 04:27 --- *** This bug has been marked as a duplicate of 28428 *** -- lucier at math dot purdue dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28429
[Bug bootstrap/28428] parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
--- Comment #2 from lucier at math dot purdue dot edu 2006-07-19 04:27 --- *** Bug 28429 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28428
[Bug bootstrap/28428] parallel make failure: No rule to make target `c-typeck.c', needed by `c-typeck.o'.
--- Comment #3 from lucier at math dot purdue dot edu 2006-07-19 04:28 --- Let's close this one, it may be because the source directory is mounted on an NFS volume. -- lucier at math dot purdue dot edu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28428
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #4 from lucier at math dot purdue dot edu 2006-07-08 15:28 --- Has any progress been made on this bug? I'm kind of surprised that a bootstrap failure on sparc-solaris should be marked P3. Brad -- lucier at math dot purdue dot edu changed: What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #6 from lucier at math dot purdue dot edu 2006-07-08 18:13 --- Subject: Re: Found a problem with the JNI methods declared and implemented Well, these were the commands that failed: build.log:cd ../../../../../../../libjava/classpath /usr/bin/ksh ./ scripts/check_jni_methods.sh build.log:cd ../../../../../../libjava/classpath /usr/bin/ksh ./ scripts/check_jni_methods.sh and this is what I ended up commenting out in the Makefiles: sparc-sun-solaris2.9/libjava/classpath/native/jni/Makefile:#cd $ (top_srcdir) $(SHELL) ./scripts/check_jni_methods.sh sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni/ Makefile:#cd $(top_srcdir) $(SHELL) ./scripts/ check_jni_methods.sh Maybe it works for people using bash as their CONFIG_SHELL. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #8 from lucier at math dot purdue dot edu 2006-07-08 22:04 --- Subject: Re: Found a problem with the JNI methods declared and implemented Things really seem screwed up in my build log. Here's what I see: make[7]: Entering directory `/export/users/lucier/programs/gcc/ gcc-4.1.1/objdir/sparc-sun-solaris2.9/libjava/classpath/native/jni' cd ../../../../../../libjava/classpath /usr/bin/ksh ./scripts/ check_jni_methods.sh If you count the number of ../'s in the cd, you see you're back in 'the source directory'/libjava/classpath when you execute the script, so you get zuse-182% /bin/ksh ./libjava/classpath/scripts/check_jni_methods.sh find: native/jni: No such file or directory find: native/jni: No such file or directory find: native/jni: No such file or directory If you execute it by hand in the directory where it should be run, it seems to work just fine (this is after the completed bootstrap, though): zuse-185% pu sparc-sun-solaris2.9/libjava/classpath/ ~/programs/gcc/gcc-4.1.1/objdir/sparc-sun-solaris2.9/libjava/ classpath ~/programs/gcc/gcc-4.1.1/objdir ~/programs/gcc/gcc-4.1.1/ objdir/sparc-sun-solaris2.9/sparcv9/libjava/classpath/native/jni ~ zuse-186% /bin/ksh ../../../../libjava/classpath/scripts/ check_jni_methods.sh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27823
[Bug bootstrap/27886] New: jar: line 281: return: : numeric argument required
Configure and bootstrap: /bin/rm -rf *; ../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --with-mpfr=/opt/local/ ; make -j 16 bootstrap build.log gcc and cctools: [lindv2:gcc/mainline/objdir64] lucier% gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5341.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5341) [lindv2:gcc/mainline/objdir64] lucier% ld -v Apple Computer, Inc. version cctools-590.42.1.obj~1 Bootstrap fails with cd classpath/lib; /Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.6.0/ppc64/libjava/scripts/jar -cfM \ ../../libgcj-4.2.0.jar gnu java javax org /Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.6.0/ppc64/libjava/scripts/jar: line 281: return: : numeric argument required -- Summary: jar: line 281: return: : numeric argument required Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.6.0 GCC host triplet: powerpc-apple-darwin8.6.0 GCC target triplet: powerpc-apple-darwin8.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27886
[Bug c/27845] New: Can't build 64-bit 4.2.0 with 4.1.1 on darwin-ppc
The build compiler:
[lindv2:gcc/mainline/objdir64] lucier% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.6.0
Configured with: ../configure --with-gmp=/opt/local/ --with-mpfr=/opt/local/
--prefix=/pkgs/gcc-4.1.1
Thread model: posix
gcc version 4.1.1
The configure and make bootstrap:
/bin/rm -rf * ; env CC='gcc -mcpu=970 -m64' ../configure
--prefix=/pkgs/gcc-4.2.0 --enable-languages=c ; make -j 8 bootstrap
BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' build.log
The version of cctools:
[lindv2:gcc/mainline/objdir64] lucier% ld -v
Apple Computer, Inc. version cctools-590.42.1.obj~1
This command never finishes, and takes one entire CPU (50% cc1, 50%
kernel_task) near the end of stage1 on the command:
echo | /Users/lucier/programs/gcc/mainline/objdir64/./gcc/xgcc
-B/Users/lucier/programs/gcc/mainline/objdir64/./gcc/
-B/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/bin/
-B/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/lib/ -isystem
/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/include -isystem
/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/sys-include -E -dM - | \
sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
-e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
sort -u tmp-macro_list
I don't know what's going on; are some arguments missing from the echo
command? When I try to run gdb I get
[lindv2:gcc/mainline/objdir64] lucier% gdb
/Users/lucier/programs/gcc/mainline/objdir64/./gcc/xgcc
GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:06:22 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as powerpc-apple-darwin...Reading symbols for shared
libraries .. done
(gdb) run -B/Users/lucier/programs/gcc/mainline/objdir64/./gcc/
-B/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/bin/
-B/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/lib/ -isystem
/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/include -isystem
/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/sys-include -E -dM -
Starting program: /Users/lucier/programs/gcc/mainline/objdir64/gcc/xgcc
-B/Users/lucier/programs/gcc/mainline/objdir64/./gcc/
-B/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/bin/
-B/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/lib/ -isystem
/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/include -isystem
/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/sys-include -E -dM -
Reading symbols for shared libraries .+ done
^C
Program received signal SIGINT, Interrupt.
0x00451558 in wait4 ()
(gdb) where
#0 0x00451558 in wait4 ()
#1 0x0003904c in pex_wait (obj=0x804a60, pid=27659, status=0x800260,
time=0x0) at ../../libiberty/pex-unix.c:524
#2 0x00039914 in pex_unix_wait (obj=0x804a60, pid=27659,
status=0x800260, time=0x0, done=0, errmsg=0x7fffeed90, err=0x7fffeed98)
at ../../libiberty/pex-unix.c:524
#3 0x00038ad8 in pex_get_status_and_time (obj=0x804a60, done=0,
errmsg=0x7fffeed90, err=0x7fffeed98) at
../../libiberty/pex-common.c:575
#4 0x00038b9c in pex_get_status (obj=0x804a60, count=1,
vector=0x7fffeee30) at ../../libiberty/pex-common.c:575
#5 0x79b4 in execute () at ../../gcc/gcc.c:3657
#6 0xf790 in do_spec (spec=0x3cb98 %{!E:%e-E or -x required when
input is from standard input}%(trad_capable_cpp) %(cpp_options)
%(cpp_debug_options)) at ../../gcc/gcc.c:5016
#7 0x00017ca0 in main (argc=0, argv=0x7fffef408) at
../../gcc/gcc.c:7362
--
Summary: Can't build 64-bit 4.2.0 with 4.1.1 on darwin-ppc
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc-apple-darwin8.6.0
GCC host triplet: powerpc-apple-darwin8.6.0
GCC target triplet: powerpc-apple-darwin8.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27845
[Bug driver/27845] Can't build 64-bit 4.2.0 with 4.1.1 on darwin-ppc
--- Comment #1 from lucier at math dot purdue dot edu 2006-05-31 18:44 --- Subject: Re: Can't build 64-bit 4.2.0 with 4.1.1 on darwin-ppc OK, so you changed it from c to driver. Do you think it should be reported against 4.1.1 (as I did) or against 4.2.0? On May 31, 2006, at 1:40 PM, pinskia at gcc dot gnu dot org wrote: -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -- -- Component|c |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27845 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27845
[Bug bootstrap/27814] ICE building darwin-crt2.c in 64-bit darwin bootstrap
--- Comment #1 from lucier at math dot purdue dot edu 2006-05-31 04:42 --- Subject: Re: New: ICE building darwin-crt2.c in 64-bit darwin bootstrap I ran cc1 a bit through gdb; perhaps real.c has been miscompiled. [lindv2:mainline/objdir64/gcc] lucier% gdb /Users/lucier/programs/gcc/ mainline/objdir64/./gcc/cc1 GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:06:22 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-apple-darwin...Reading symbols for shared libraries .. done Breakpoint 1 at 0x44e55c: file ../../gcc/diagnostic.c, line 642. Breakpoint 2 at 0x44e3e0: file ../../gcc/diagnostic.c, line 586. Breakpoint 3 at 0x906f4 Breakpoint 4 at 0xf4e38 (gdb) run -quiet -v -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../ include -I./../intl -I../../gcc/../libcpp/include -I../../gcc/../ libdecnumber -I../libdecnumber -iprefix /Users/lucier/programs/gcc/ mainline/objdir64/gcc/../lib/gcc/powerpc-apple-darwin8.6.0/4.2.0/ - isystem /Users/lucier/programs/gcc/mainline/objdir64/./gcc/include - D__DYNAMIC__ -DIN_GCC -isystem /pkgs/gcc-4.2.0/powerpc-apple- darwin8.6.0/include -isystem /pkgs/gcc-4.2.0/powerpc-apple- darwin8.6.0/sys-include -isystem ./include ../../gcc/config/darwin- crt2.c -feliminate-unused-debug-symbols -fPIC -quiet -dumpbase darwin- crt2.c -auxbase-strip crt2.o -g -O2 -O2 -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - version -o /var/tmp//ccti7FKQ.s Starting program: /Users/lucier/programs/gcc/mainline/objdir64/gcc/ cc1 -quiet -v -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../ include -I./../intl -I../../gcc/../libcpp/include -I../../gcc/../ libdecnumber -I../libdecnumber -iprefix /Users/lucier/programs/gcc/ mainline/objdir64/gcc/../lib/gcc/powerpc-apple-darwin8.6.0/4.2.0/ - isystem /Users/lucier/programs/gcc/mainline/objdir64/./gcc/include - D__DYNAMIC__ -DIN_GCC -isystem /pkgs/gcc-4.2.0/powerpc-apple- darwin8.6.0/include -isystem /pkgs/gcc-4.2.0/powerpc-apple- darwin8.6.0/sys-include -isystem ./include ../../gcc/config/darwin- crt2.c -feliminate-unused-debug-symbols -fPIC -quiet -dumpbase darwin- crt2.c -auxbase-strip crt2.o -g -O2 -O2 -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - version -o /var/tmp//ccti7FKQ.s Reading symbols for shared libraries .+ done Breakpoint 3 at 0x42695718 Breakpoint 4 at 0x426f9e58 ignoring nonexistent directory /pkgs/gcc-4.2.0/powerpc-apple- darwin8.6.0/include ignoring nonexistent directory /pkgs/gcc-4.2.0/powerpc-apple- darwin8.6.0/sys-include ignoring duplicate directory ./include ignoring nonexistent directory /Users/lucier/programs/gcc/mainline/ objdir64/gcc/../lib/gcc/powerpc-apple-darwin8.6.0/4.2.0/include ignoring nonexistent directory /Users/lucier/programs/gcc/mainline/ objdir64/gcc/../lib/gcc/powerpc-apple-darwin8.6.0/4.2.0/../../../../ powerpc-apple-darwin8.6.0/include ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /pkgs/gcc-4.2.0/include ignoring nonexistent directory /pkgs/gcc-4.2.0/lib/gcc/powerpc-apple- darwin8.6.0/4.2.0/include ignoring nonexistent directory /pkgs/gcc-4.2.0/powerpc-apple- darwin8.6.0/include ignoring duplicate directory . ignoring duplicate directory ../../gcc/. #include ... search starts here: #include ... search starts here: . ../../gcc ../../gcc/../include ./../intl ../../gcc/../libcpp/include ../../gcc/../libdecnumber ../libdecnumber /Users/lucier/programs/gcc/mainline/objdir64/./gcc/include /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C version 4.2.0 20060530 (experimental) (powerpc-apple-darwin8.6.0) compiled by GNU C version 4.0.1 (Apple Computer, Inc. build 5341). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x423ac000 0x007b7378 in sticky_rshift_significand (r=0x40c48118, a=0x40c48118, n=4294967295) at ../../gcc/real.c:179 179 sticky |= a-sig[i]; (gdb) stack Undefined command: stack. Try help. (gdb) where #0 0x007b7378 in sticky_rshift_significand (r=0x40c48118, a=0x40c48118, n=4294967295) at ../../gcc/real.c:179 #1 0x007bddf0 in round_for_format (fmt=0x40c49c38, r=0x40c48118) at ../../gcc/real.c:2372 #2 0x007be4e8 in real_convert (r=0x40c48118, mode=DFmode, a=0x40c48118) at ../../gcc/real.c:2472 #3 0x007bcec8 in real_from_integer (r=0x40c48118, mode=DFmode, low=1, high=0, unsigned_p=0) at ../../gcc/real.c:2066 #4 0x004a1ac0 in init_emit_once (line_numbers=1
[Bug bootstrap/27814] New: ICE building darwin-crt2.c in 64-bit darwin bootstrap
Configure and build: #!/bin/tcsh /bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure --prefix=/pkgs/gcc-4.2.0 --enable-languages=c; make -j 8 bootstrap BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' build.log [lindv2:gcc/mainline/objdir64] lucier% ld -v Apple Computer, Inc. version cctools-590.42.1.obj~1 [lindv2:gcc/mainline/objdir64] lucier% gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5341.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5341) bootstrap fails with /Users/lucier/programs/gcc/mainline/objdir64/./gcc/xgcc -B/Users/lucier/programs/gcc/mainline/objdir64/./gcc/ -B/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/bin/ -B/pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/lib/ -isystem /pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/include -isystem /pkgs/gcc-4.2.0/powerpc-apple-darwin8.6.0/sys-include -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber \ -c ../../gcc/config/darwin-crt2.c -o crt2.o ../../gcc/config/darwin-crt2.c:1: internal compiler error: Bus error Please submit a full bug report, This is near the end of the stage1 build. -- Summary: ICE building darwin-crt2.c in 64-bit darwin bootstrap Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.6.0 GCC host triplet: powerpc-apple-darwin8.6.0 GCC target triplet: powerpc-apple-darwin8.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27814
[Bug target/27121] Undefined symbols: ___dso_handle
--- Comment #2 from lucier at math dot purdue dot edu 2006-04-25 02:40 --- It doesn't work for me, even with the updated cctools: /Users/lucier/programs/gcc/mainline/objdir64/gcc/gcj -B/Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.6.0/ppc64/libjava/ -B/Users/lucier/programs/gcc/mainline/objdir64/gcc/ -g -O2 -m64 -m64 -o .libs/grmic --main=gnu.java.rmi.rmic.RMIC -shared-libgcc -L/Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.6.0/ppc64/libjava -L/Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.6.0/ppc64/libjava/.libs ./.libs/libgcj.dylib -L/Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.6.0/ppc64/libstdc++-v3/src -L/Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.6.0/ppc64/libstdc++-v3/src/.libs -lpthread -ldl can't resolve symbols: ___dso_handle, referenced from: _atexit in crt3.o ld64 failed: symbol(s) not found collect2: ld returned 1 exit status can't resolve symbols: ___dso_handle, referenced from: _atexit in crt3.o ld64 failed: symbol(s) not found make[5]: *** [gcj-dbtool] Error 1 make[5]: *** Waiting for unfinished jobs collect2: ld returned 1 exit status can't resolve symbols: ___dso_handle, referenced from: _atexit in crt3.o ld64 failed: symbol(s) not found make[5]: *** [jv-convert] Error 1 collect2: ld returned 1 exit status can't resolve symbols: ___dso_handle, referenced from: _atexit in crt3.o ld64 failed: symbol(s) not found collect2: ld returned 1 exit status make[5]: *** [grmiregistry] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [multi-do] Error 1 make[2]: *** [all-multi] Error 2 make[1]: *** [all-target-libjava] Error 2 make: *** [bootstrap] Error 2 [lindv2:gcc/mainline/objdir64] lucier% as -v Apple Computer, Inc. version cctools-590.36~obj, GNU assembler version 1.38 ^C Interrupted by signal 2 [lindv2:gcc/mainline/objdir64] lucier% ld -v Apple Computer, Inc. version cctools-590.36~obj -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #6 from lucier at math dot purdue dot edu 2006-04-20 03:18 --- Subject: Re: Inordinate compile times on large routines Thanks a lot. Here are the timing statistics (with --disable- checking) after your patch. PS: I'm sorry it took 9 hours to compile on your box. Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 16k 14k480 1652k 12k 1144 64 1276k 1239k 19k 256 484k452k 6776 512 36k 25k504 1024 220k216k 3080 2048 24k 20k336 4096 68k 68k952 8192 56k 56k392 16384 16k 16k 56 32768288k288k504 65536 64k 64k 56 131072128k128k 56 262144512k512k112 524288512k512k 56 1048576 1024k 1024k 56 2097152 4096k 4096k112 112 34M 16M484k 208 40k 38k560 192 3344k 3287k 45k 160 28k 6240 392 176 564k261k 7896 48 2088k 1165k 32k 32 144k 68k 2592 8035M 2063k499k Total 85M 32M 1107k String pool entries 158128 identifiers 158128 (100.00%) slots 262144 bytes 1981k (169k overhead) table size 2048k coll/search 1.1434 ins/search 0.1946 avg. entry 12.83 bytes (+/- 7.82) longest entry 67 ??? tree nodes created (No per-node statistics) Type hash: size 1021, 598 elements, 0.900368 collisions DECL_DEBUG_EXPR hash: size 8191, 0 elements, 1.140991 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions Execution times (seconds) garbage collection: 1.84 ( 0%) usr 0.04 ( 0%) sys 2.47 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 1.79 ( 0%) usr 0.35 ( 0%) sys 2.67 ( 0%) wall 21241 kB ( 2%) ggc callgraph optimization: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.42 ( 0%) usr 0.14 ( 0%) sys 0.71 ( 0%) wall 7 kB ( 0%) ggc cfg construction : 0.31 ( 0%) usr 0.00 ( 0%) sys 0.48 ( 0%) wall7224 kB ( 1%) ggc cfg cleanup : 95.98 ( 9%) usr 0.62 ( 0%) sys 125.14 ( 8%) wall2098 kB ( 0%) ggc trivially dead code : 2.49 ( 0%) usr 0.06 ( 0%) sys 3.46 ( 0%) wall 0 kB ( 0%) ggc life analysis : 5.86 ( 1%) usr 3.35 ( 3%) sys 11.86 ( 1%) wall 18686 kB ( 2%) ggc life info update : 0.95 ( 0%) usr 0.02 ( 0%) sys 1.18 ( 0%) wall 526 kB ( 0%) ggc alias analysis: 1.67 ( 0%) usr 0.03 ( 0%) sys 2.07 ( 0%) wall 16385 kB ( 2%) ggc register scan : 0.93 ( 0%) usr 0.01 ( 0%) sys 1.29 ( 0%) wall 4 kB ( 0%) ggc rebuild jump labels : 0.30 ( 0%) usr 0.00 ( 0%) sys 0.37 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 7.27 ( 1%) usr 13.04 (10%) sys 25.28 ( 2%) wall2197 kB ( 0%) ggc lexical analysis : 13.10 ( 1%) usr 25.59 (20%) sys 47.58 ( 3%) wall 0 kB ( 0%) ggc parser: 9.44 ( 1%) usr 12.84 (10%) sys 28.21 ( 2%) wall 72677 kB ( 7%) ggc tree gimplify : 1.51 ( 0%) usr 0.08 ( 0%) sys 2.02 ( 0%) wall 30969 kB ( 3%) ggc tree eh : 0.17 ( 0%) usr 0.01 ( 0%) sys 0.22 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.56 ( 0%) usr 0.14 ( 0%) sys 1.02 ( 0%) wall 76077 kB ( 8%) ggc tree CFG cleanup : 5.77 ( 1%) usr 0.06 ( 0%) sys 7.60 ( 0%) wall 955 kB ( 0%) ggc tree copy propagation : 5.43 ( 0%) usr 0.39 ( 0%) sys 7.83 ( 0%) wall 10484 kB ( 1%) ggc tree store copy prop : 0.73 ( 0%) usr 0.04 ( 0%) sys 0.96 ( 0%) wall1088 kB ( 0%) ggc tree find ref. vars : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall2502 kB ( 0%) ggc tree PTA : 5.49 ( 0%) usr 0.57 ( 0%) sys 7.86 ( 0%) wall 16435 kB ( 2%) ggc tree alias analysis : 6.82 ( 1%) usr 10.23 ( 8%) sys 18.62 ( 1%) wall 12810 kB ( 1%) ggc tree PHI insertion: 1.05 ( 0%) usr 0.21 ( 0%) sys 1.62 ( 0%) wall 24377 kB ( 2%) ggc tree SSA rewrite : 2.50 ( 0%) usr 0.16 ( 0%) sys 3.34 ( 0%) wall 39166 kB ( 4%) ggc tree SSA other: 1.10 ( 0%) usr 1.49 ( 1%) sys 3.69 ( 0%) wall 0 kB ( 0%) ggc tree SSA incremental : 13.99 ( 1%) usr 3.74 ( 3%) sys 22.60 ( 1%) wall 19165 kB ( 2%) ggc tree operand scan : 626.32 (57%) usr 12.24 (10%) sys 833.21 (52%) wall 23910 kB ( 2%) ggc dominator optimization: 6.09 ( 1%) usr 0.35 ( 0%) sys 8.22 ( 1%) wall 63874 kB ( 7%) ggc tree STORE-CCP: 0.67
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #8 from lucier at math dot purdue dot edu 2006-04-20 03:39 --- Subject: Re: Inordinate compile times on large routines On Apr 19, 2006, at 10:28 PM, law at redhat dot com wrote: You'll likely get radically different pain points with mainline as well. The RTL loop invariant code goes crazy memory-wise for me, tree PRE and FRE also suck up large amounts of time. Mainline doesn't build with -m64 -mcpu=970; this was reported as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892 which is still marked as UNCONFIRMED; I just realized today that this could be listed as a 4.1 regression. In my limited understanding, I suspect it's a configure problem, as I mentioned in http://gcc.gnu.org/ml/gcc/2006-04/msg00265.html Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #3 from lucier at math dot purdue dot edu 2006-04-01 00:45 --- Subject: Re: Can't compile a 64-bit gcc OK, I'll try to give a bit more data and make a more intelligent comment. I tried to configure and build mainline with this command: /bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure --enable- checking=no --prefix=/pkgs/gcc-mainline --with-as=/usr/local/ odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ ld --enable-languages=c; make bootstrap BOOT_CFLAGS='-mcpu=970 -m64 - O2 -g' build.log and here are all the references to iconv in build.log: [lindv2:gcc/mainline/objdir64] lucier% grep iconv build.log checking for iconv... no, consider installing GNU libiconv checking for iconv.h... yes checking for iconv... no, consider installing GNU libiconv checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking for iconv... no, consider installing GNU libiconv checking for iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking for iconv.h... yes checking for iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking for iconv... yes checking how to link with libiconv... -liconv checking for iconv declaration... extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); ./../intl/libintl.a -liconv -liconv ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture _libiconv, referenced from: _convert_using_iconv in libcpp.a(charset.o) _libiconv_close, referenced from: __cpp_destroy_iconv in libcpp.a(charset.o) _libiconv_open, referenced from: _init_iconv_desc in libcpp.a(charset.o) _libiconv_set_relocation_prefix, referenced from: and bootstrap fails with /Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc -B/Users/ lucier/programs/gcc/mainline/objdir64/./prev-gcc/ -B/pkgs/gcc- mainline/powerpc-apple-darwin8.5.0/bin/ -mcpu=970 -m64 -O2 -g -o makedepend \ makedepend.o libcpp.a ../libiberty/libiberty.a \ ./../intl/libintl.a -liconv -liconv ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture can't resolve symbols: etc. When I configure and build 4.1.0 (release) with /bin/rm -rf *; env CC='gcc -mcpu=970 -m64' ../configure --prefix=/ pkgs/gcc-4.1.0 --with-as=/usr/local/odcctools-20060123/bin/as --with- ld=/usr/local/odcctools-20060123/bin/ld --enable-languages=c; make bootstrap BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' build.log I get the following references to iconv in build.log: [lindv2:gcc/gcc-4.1.0/objdir] lucier% !gr grep iconv build.log checking for iconv... no, consider installing GNU libiconv checking iconv.h usability... yes checking iconv.h presence... yes checking for iconv.h... yes checking for iconv... no, consider installing GNU libiconv checking for iconv.h... yes checking for iconv... no, consider installing GNU libiconv and no attempt is made to link libiconv into makedepend: gcc -mcpu=970 -m64 -I../../libcpp -I. -I../../libcpp/../include - I./../intl -I../../libcpp/include -g -O2 -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - Wmissing-format-attribute -pedantic -Wno-long-long -I../../libcpp - I. -I../../libcpp/../include -I./../intl -I../../libcpp/include -c - o makedepend.o -MT makedepend.o -MD -MP -MF .deps/makedepend.Po ../../ libcpp/makedepend.c gcc -mcpu=970 -m64 -g -O2 -o makedepend \ makedepend.o libcpp.a ../libiberty/libiberty.a \ ./../intl/libintl.a So it appears that configure in 4.1.0 realizes that the libiconv on powerpc-darwin-8.5.0 is not compatible with the gcc it's trying to build and doesn't try to link with it, while configure on mainline thinks libiconv is compatible (when it's not, since libiconv is 32 bit and we're trying to build a 64-bit gcc) and bootstrap fails when trying to link the 32-bit libiconv into the 32-bit makedepend. So I think that the configuration checks for iconv on mainline may be broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #4 from lucier at math dot purdue dot edu 2006-04-01 00:48 --- Subject: Re: Can't compile a 64-bit gcc On Mar 31, 2006, at 6:45 PM, lucier at math dot purdue dot edu wrote: So it appears that configure in 4.1.0 realizes that the libiconv on powerpc-darwin-8.5.0 is not compatible with the gcc it's trying to build and doesn't try to link with it, while configure on mainline thinks libiconv is compatible (when it's not, since libiconv is 32 bit and we're trying to build a 64-bit gcc) and bootstrap fails when trying to link the 32-bit libiconv into the 32-bit makedepend. Should be 64-bit makedepend of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug bootstrap/26892] Can't compile a 64-bit gcc
--- Comment #2 from lucier at math dot purdue dot edu 2006-03-31 03:01 --- Subject: Re: Can't compile a 64-bit gcc I don't know. Why does 4.2 use libiconv and 4.1 not use it? (I'm presuming that 4.1 doesn't use it because I was able to build a 64-bit gcc on darwin). Should gcc ship libiconv source and compile it using BOOTCFLAGS, like it ends up doing with libiberty? Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug bootstrap/26892] New: Can't compile a 64-bit gcc
Configured and built with env CC='gcc -mcpu=970 -m64' ../configure --enable-checking=no --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --with-mpfr=/opt/local/ --with-as=/usr/local/odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ld; make -j 8 bootstrap BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' build.log Bootstrap fails with true AR_FLAGS=rc CC_FOR_BUILD=/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc -B/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/ -B/pkgs/gcc-mainline/powerpc-apple-darwin8.5.0/bin/ CFLAGS=-mcpu=970 -m64 -O2 -g CXXFLAGS=-g -O2 CFLAGS_FOR_BUILD=-g -O2 CFLAGS_FOR_TARGET=-O2 -g -O2 INSTALL=/usr/bin/install -c INSTALL_DATA=/usr/bin/install -c -m 644 INSTALL_PROGRAM=/usr/bin/install -c INSTALL_SCRIPT=/usr/bin/install -c LDFLAGS= LIBCFLAGS=-mcpu=970 -m64 -O2 -g LIBCFLAGS_FOR_TARGET=-O2 -g -O2 MAKE=make MAKEINFO=makeinfo --split-size=500 --split-size=500 --split-size=500 PICFLAG= PICFLAG_FOR_TARGET= SHELL=/bin/sh EXPECT=expect RUNTEST=runtest RUNTESTFLAGS= exec_prefix=/pkgs/gcc-mainline infodir=/pkgs/gcc-mainline/info libdir=/pkgs/gcc-mainline/lib prefix=/pkgs/gcc-mainline tooldir=/pkgs/gcc-mainline/powerpc-apple-darwin8.5.0 AR=ar AS=as CC=/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc -B/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/ -B/pkgs/gcc-mainline/powerpc-apple-darwin8.5.0/bin/ CXX=c++ LD=ld LIBCFLAGS=-mcpu=970 -m64 -O2 -g NM=nm PICFLAG= RANLIB=ranlib DESTDIR= DO=all multi-do # make /Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/xgcc -B/Users/lucier/programs/gcc/mainline/objdir64/./prev-gcc/ -B/pkgs/gcc-mainline/powerpc-apple-darwin8.5.0/bin/ -mcpu=970 -m64 -O2 -g -o makedepend \ makedepend.o libcpp.a ../libiberty/libiberty.a \ ./../intl/libintl.a -liconv -liconv ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture ld64 warning: in /usr/lib/libiconv.dylib, file does not contain requested architecture can't resolve symbols: _libiconv, referenced from: _convert_using_iconv in libcpp.a(charset.o) __nl_find_msg in libintl.a(dcigettext.o) _libiconv_close, referenced from: __cpp_destroy_iconv in libcpp.a(charset.o) __cpp_convert_input in libcpp.a(charset.o) __nl_free_domain_conv in libintl.a(loadmsgcat.o) _libiconv_open, referenced from: _init_iconv_desc in libcpp.a(charset.o) __nl_init_domain_conv in libintl.a(loadmsgcat.o) _libiconv_set_relocation_prefix, referenced from: _libintl_set_relocation_prefix in libintl.a(relocatable.o) ld64 failed: symbol(s) not found -- Summary: Can't compile a 64-bit gcc Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.5.0 GCC host triplet: powerpc-apple-darwin8.5.0 GCC target triplet: powerpc-apple-darwin8.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26892
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #2 from lucier at math dot purdue dot edu 2006-03-25 22:22 --- Subject: Re: Inordinate compile times on large routines [lindv2:~/Desktop] lucier% /pkgs/gcc-4.0.3/bin/gcc -mcpu=970 -m64 -no- cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule- insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame- pointer -fPIC -fno-common -bundle -flat_namespace -undefined suppress -I/usr/local/Gambit-C/include/ -ftime-report -fmem-report all.i gcc: unrecognized option '-no-cpp-precomp' Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 16k 11k480 1652k 12k 1144 6410M 1841k167k 256 4096 512 56 512 12k 4608 168 1024 96k 95k 1344 204840962048 56 4096 64k 64k896 8192 16k 16k112 32768288k288k504 131072128k128k 56 1048576 3072k 3072k168 2097152 4096k 4096k112 112 19M 16M272k 208 6360k 4213k 86k 48 7344k 4315k114k 32 148k 74k 2664 8016M 1336k232k Total 67M 35M881k String pool entries 155812 identifiers 155812 (100.00%) slots 262144 bytes 1952k (167k overhead) table size 2048k coll/search 0.8640 ins/search 0.1923 avg. entry 12.83 bytes (+/- 7.87) longest entry 67 ??? tree nodes created (No per-node statistics) Type hash: size 1021, 551 elements, 0.816291 collisions Execution times (seconds) garbage collection: 2.11 ( 0%) usr 0.04 ( 0%) sys 2.71 ( 0%) wall cfg construction : 0.68 ( 0%) usr 1.22 ( 0%) sys 2.29 ( 0%) wall cfg cleanup : 94.99 ( 9%) usr 0.54 ( 0%) sys 120.62 ( 7%) wall trivially dead code : 2.87 ( 0%) usr 0.06 ( 0%) sys 3.83 ( 0%) wall life analysis : 6.78 ( 1%) usr 3.26 ( 1%) sys 12.56 ( 1%) wall life info update : 1.09 ( 0%) usr 0.01 ( 0%) sys 1.34 ( 0%) wall alias analysis: 1.89 ( 0%) usr 0.04 ( 0%) sys 2.55 ( 0%) wall register scan : 1.25 ( 0%) usr 0.02 ( 0%) sys 1.62 ( 0%) wall rebuild jump labels : 0.34 ( 0%) usr 0.01 ( 0%) sys 0.42 ( 0%) wall preprocessing : 7.70 ( 1%) usr 12.37 ( 4%) sys 25.83 ( 2%) wall lexical analysis : 13.19 ( 1%) usr 25.54 ( 9%) sys 48.16 ( 3%) wall parser: 11.06 ( 1%) usr 13.13 ( 5%) sys 30.20 ( 2%) wall tree gimplify : 1.61 ( 0%) usr 0.07 ( 0%) sys 2.14 ( 0%) wall tree eh : 0.18 ( 0%) usr 0.01 ( 0%) sys 0.21 ( 0%) wall tree CFG construction : 0.63 ( 0%) usr 0.16 ( 0%) sys 0.97 ( 0%) wall tree CFG cleanup : 2.09 ( 0%) usr 0.02 ( 0%) sys 2.62 ( 0%) wall tree find referenced vars: 0.25 ( 0%) usr 0.01 ( 0%) sys 0.37 ( 0%) wall tree PTA : 615.45 (59%) usr 155.84 (55%) sys 967.56 (58%) wall tree alias analysis : 0.63 ( 0%) usr 0.00 ( 0%) sys 0.73 ( 0%) wall tree PHI insertion: 4.27 ( 0%) usr 5.94 ( 2%) sys 12.63 ( 1%) wall tree SSA rewrite : 3.35 ( 0%) usr 0.10 ( 0%) sys 4.61 ( 0%) wall tree SSA other: 8.35 ( 1%) usr 7.78 ( 3%) sys 19.75 ( 1%) wall tree operand scan : 5.80 ( 1%) usr 7.91 ( 3%) sys 17.53 ( 1%) wall dominator optimization: 5.62 ( 1%) usr 0.45 ( 0%) sys 7.42 ( 0%) wall tree CCP : 1.78 ( 0%) usr 0.02 ( 0%) sys 2.18 ( 0%) wall tree split crit edges : 0.30 ( 0%) usr 0.04 ( 0%) sys 0.41 ( 0%) wall tree remove redundant PHIs: 3.92 ( 0%) usr 0.14 ( 0%) sys 4.96 ( 0%) wall tree linearize phis : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall tree forward propagate: 1.22 ( 0%) usr 0.01 ( 0%) sys 1.51 ( 0%) wall tree conservative DCE : 1.94 ( 0%) usr 0.01 ( 0%) sys 2.51 ( 0%) wall tree aggressive DCE : 0.82 ( 0%) usr 0.06 ( 0%) sys 1.05 ( 0%) wall tree DSE : 1.35 ( 0%) usr 0.05 ( 0%) sys 1.74 ( 0%) wall PHI merge : 0.11 ( 0%) usr 0.01 ( 0%) sys 0.16 ( 0%) wall tree record loop bounds: 0.29 ( 0%) usr 0.01 ( 0%) sys 0.37 ( 0%) wall loop invariant motion : 1.25 ( 0%) usr 0.02 ( 0%) sys 1.58 ( 0%) wall tree canonical iv creation: 0.26 ( 0%) usr 0.01 ( 0%) sys 0.34 ( 0%) wall tree loop init: 8.65 ( 1%) usr 2.11 ( 1%) sys 13.35 ( 1%) wall tree copy headers : 3.03 ( 0%) usr 1.35 ( 0%) sys 5.42 ( 0%) wall tree SSA to normal: 139.82 (13%) usr 1.01 ( 0%) sys 176.26 (11%) wall tree rename SSA copies: 0.72 ( 0%) usr 0.10 ( 0%) sys 0.97 ( 0%) wall dominance frontiers : 0.76 ( 0%) usr 0.01 ( 0
[Bug c/26854] New: Inordinate compile times on large routines
%) ggc TOTAL :1438.01 131.69 1949.05 979456 kB So, this is a very large file (and only one C routine), but the times for the various passes are very unbalanced; in particular the following three catch anyone's eye: tree operand scan : 628.65 (44%) usr 12.18 ( 9%) sys 814.05 (42%) wall 23896 kB ( 2%) ggc dominator optimization: 307.01 (21%) usr 2.88 ( 2%) sys 380.36 (20%) wall 63887 kB ( 7%) ggc tree SSA to normal: 172.90 (12%) usr 1.50 ( 1%) sys 215.20 (11%) wall 92392 kB ( 9%) ggc I don't know what the compile times are with 4.2; perhaps people who have a 64-bit profiled gcc would like to investigate more what is going on. -- Summary: Inordinate compile times on large routines Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.5.0 GCC host triplet: powerpc-apple-darwin8.5.0 GCC target triplet: powerpc-apple-darwin8.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug bootstrap/26814] New: Can't build a 64-bit C compiler on darwin-ppc
Configured and built with #!/bin/tcsh /bin/rm -rf *; ../configure --prefix=/pkgs/gcc-4.1.0 --with-gmp=/sw/ --with-mpfr=/sw/ --with-as=/usr/local/odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ld --enable-languages=c; make -j 8 bootstrap BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' build.log Bootstrap fails with stage1/xgcc -Bstage1/ -B/pkgs/gcc-4.1.0/powerpc-apple-darwin8.5.0/bin/ -mcpu=970 -m64 -O2 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-powerpc-apple-darwin8.5.0/libiberty/libiberty.a ld64 failed: in ../build-powerpc-apple-darwin8.5.0/libiberty/libiberty.a(hashtab.o), not a valid ppc64 mach-o file which seems to be right: gcc -c -DHAVE_CONFIG_H -g -O2 -I/sw//include -I/sw//include -I. -I../../../libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../libiberty/hashtab.c -o hashtab.o -- Summary: Can't build a 64-bit C compiler on darwin-ppc Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.5.0 GCC host triplet: powerpc-apple-darwin8.5.0 GCC target triplet: powerpc-apple-darwin8.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug bootstrap/26814] Bootstrapping with a non default ABI (-m64 on ppc-darwin or on ppc-linux with a compiler defaulting to 32 and now defaulting to 64)
--- Comment #6 from lucier at math dot purdue dot edu 2006-03-23 02:53 --- Subject: Re: Bootstrapping with a non default ABI (-m64 on ppc-darwin or on ppc-linux with a compiler defaulting to 32 and now defaulting to 64) On Mar 22, 2006, at 5:29 PM, ebotcazou at gcc dot gnu dot org wrote: --- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-03-22 23:29 --- CC=gcc -m64 $srcdir/configure --prefix=/pkgs/gcc-4.1.0 --with- gmp=/sw/ --with-mpfr=/sw/ --with-as=/usr/local/odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ld --enable-languages=c Well, you'd probably also need to pass powerpc64-apple-darwin8.5.0 to configure. Actually, I want the compiler to generate 32-bit binaries by default, and your earlier instructions work well. I just want cc1 to be compiled with -m64 so that it can allocate 2.4GB of storage when it's compiling some computer-generated C files. (I don't really think it should take 17 minutes and 2.4GB of storage to compile a 6.5MB .i file.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug bootstrap/26814] Bootstrapping with a non default ABI (-m64 on ppc-darwin or on ppc-linux with a compiler defaulting to 32 and now defaulting to 64)
--- Comment #7 from lucier at math dot purdue dot edu 2006-03-23 03:16 --- Subject: Re: Bootstrapping with a non default ABI (-m64 on ppc-darwin or on ppc-linux with a compiler defaulting to 32 and now defaulting to 64) By the way, the last thing the bootstrap does is build libiberty again with BOOT_CFLAGS; it would seem reasonable to me to build it earlier with BOOT_CFLAGS, so I don't have to build the stage1 compiler with CC='gcc -m64' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug libstdc++/26480] New: No rule to make cstdbool needed by stamp-tr1
make[4]: *** No rule to make target `/Users/lucier/programs/gcc/mainline/libstdc++-v3/include/tr1/cstdbool', needed by `stamp-tr1'. Stop. make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [bootstrap] Error 2 -- Summary: No rule to make cstdbool needed by stamp-tr1 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.5.0 GCC host triplet: powerpc-apple-darwin8.5.0 GCC target triplet: powerpc-apple-darwin8.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26480
[Bug libgomp/26328] Timouts in libgomp tests with --with-long-double-128
--- Comment #2 from lucier at math dot purdue dot edu 2006-02-19 01:16 --- Subject: Re: Timouts in libgomp tests with --with-long-double-128 On Feb 16, 2006, at 2:41 PM, pinskia at gcc dot gnu dot org wrote: First --with-long-double-128 does nothing on Darwin. Does it do nothing on darwin because long double is already 128bits on Darwin? Some of the messages on the lists imply that there are 64- bit long doubles as well as 128-bit long doubles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26328
[Bug libgomp/26328] New: Timouts in libgomp tests with --with-long-double-128
-- Summary: Timouts in libgomp tests with --with-long-double-128 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.4.0 GCC host triplet: powerpc-apple-darwin8.4.0 GCC target triplet: powerpc-apple-darwin8.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26328
[Bug bootstrap/26273] New: ICE: in get_attr_type, at config/rs6000/rs6000.md:12269
Bootstrap fails with configure and build: ../configure --prefix=/pkgs/gcc-mainline --with-gmp=/sw/ --with-mpfr=/sw/ --with-as=/usr/local/odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ld; make -j 8 bootstrap STAGE1_CFLAGS='-O2 -g' build.log /Users/lucier/programs/gcc/mainline/objdir64/gcc/gcj -B/Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.4.0/ppc64/libjava/ -B/Users/lucier/programs/gcc/mainline/objdir64/gcc/ -fclasspath= -fbootclasspath=/Users/lucier/programs/gcc/mainline/objdir64/powerpc-apple-darwin8.4.0/ppc64/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c -MT java/awt/color.lo -MD -MP -MF java/awt/color.deps @java/awt/color.list -fno-common -o java/awt/.libs/color.o ../../../../libjava/classpath/java/awt/color/ICC_Profile.java: In class 'java.awt.color.ICC_Profile': ../../../../libjava/classpath/java/awt/color/ICC_Profile.java: In method 'java.awt.color.ICC_Profile.makeIdentityClut()': ../../../../libjava/classpath/java/awt/color/ICC_Profile.java:1075: error: unrecognizable insn: (insn 608 564 610 10 (set (reg:SI 371) (fix:SI (reg:DF 132 [ pretmp.2587 ]))) -1 (insn_list:REG_DEP_TRUE 243 (nil)) (nil)) ../../../../libjava/classpath/java/awt/color/ICC_Profile.java:1075: internal compiler error: in get_attr_type, at config/rs6000/rs6000.md:12269 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [java/awt/color.lo] Error 1 -- Summary: ICE: in get_attr_type, at config/rs6000/rs6000.md:12269 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.4.0 GCC host triplet: powerpc-apple-darwin8.4.0 GCC target triplet: powerpc-apple-darwin8.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26273
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Comment #32 from lucier at math dot purdue dot edu 2005-11-20 07:13 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 On Nov 19, 2005, at 1:50 AM, lucier at math dot purdue dot edu wrote: Can you explain what Apple's libtool has to do with it? Is it used by gcc to find these libraries at link time? Sorry, dumb question. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Comment #27 from lucier at math dot purdue dot edu 2005-11-19 02:42 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 I don't know what Apple's priorities are here, but it would be really nice to get 64-bit dynamic libraries working on Darwin. (Or maybe they do work, and I'm just running into a dark corner case here.) Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Comment #31 from lucier at math dot purdue dot edu 2005-11-19 07:50 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 Can you explain what Apple's libtool has to do with it? Is it used by gcc to find these libraries at link time? Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Comment #25 from lucier at math dot purdue dot edu 2005-10-09 18:26 --- [lindv2:~/Desktop/gcc-test] lucier% /pkgs/gcc-mainline/bin/gcc -v -m64 -dynamiclib -o conftest conftest.c Using built-in specs. Target: powerpc-apple-darwin8.2.0 Configured with: ../configure powerpc-apple-darwin8.2.0 --enable-languages=c --prefix=/pkgs/gcc-mainline --with-gmp=/pkgs/gmp-4.1.4 --with-mpfr=/pkgs/gmp-4.1.4 Thread model: posix gcc version 4.1.0 20051007 (experimental) /pkgs/gcc-mainline/libexec/gcc/powerpc-apple-darwin8.2.0/4.1.0/cc1 -quiet -v -D__DYNAMIC__ conftest.c -fPIC -quiet -dumpbase conftest.c -m64 -auxbase conftest -version -o /var/tmp//ccJySvb8.s ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/../../../../powerpc-apple-darwin8.2.0/include #include ... search starts here: #include ... search starts here: /pkgs/gcc-mainline/include /pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/include /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C version 4.1.0 20051007 (experimental) (powerpc-apple-darwin8.2.0) compiled by GNU C version 4.1.0 20051007 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 8fa0ed40f679dd18a041425360ea4f73 as -arch ppc64 -o /var/tmp//ccpmqZ6K.o /var/tmp//ccJySvb8.s /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load -weak_reference_mismatches non-weak -o conftest -L/pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/ppc64 -L/pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/../../../ppc64 /var/tmp//ccpmqZ6K.o -lgcc_s.10.4 -lgcc -lSystemStubs -lSystem /usr/bin/libtool: can't locate file for: -lgcc_s.10.4 /usr/bin/libtool: file: -lgcc_s.10.4 is not an object file (not allowed in a library) [lindv2:~/Desktop/gcc-test] lucier% file /pkgs/gcc-mainline/./lib/libgcc_s.10.4.dylib /pkgs/gcc-mainline/./lib/libgcc_s.10.4.dylib: Mach-O fat file with 2 architectures /pkgs/gcc-mainline/./lib/libgcc_s.10.4.dylib (for architecture ppc):Mach-O dynamically linked shared library stub ppc /pkgs/gcc-mainline/./lib/libgcc_s.10.4.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library stub ppc64 -- lucier at math dot purdue dot edu changed: What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Comment #23 from lucier at math dot purdue dot edu 2005-10-04 10:31
---
This bug was triaged as a duplicate of 21757, which has now been resolved as
fixed.
And this bug still doesn't work with mainline. Here are the symptoms.
[lindv2:~/Desktop/gcc-test] lucier% cat conftest.c
int main() {
return 0;
}
[lindv2:~/Desktop/gcc-test] lucier% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.2.0
Configured with: ../configure powerpc-apple-darwin8.2.0 --enable-languages=c
--prefix=/pkgs/gcc-mainline --with-gmp=/pkgs/gmp-4.1.4
--with-mpfr=/pkgs/gmp-4.1.4
Thread model: posix
gcc version 4.1.0 20051003 (experimental)
[lindv2:~/Desktop/gcc-test] lucier% /pkgs/gcc-mainline/bin/gcc -dynamiclib -o
conftest conftest.c
[lindv2:~/Desktop/gcc-test] lucier% otool -L conftest
conftest:
conftest (compatibility version 0.0.0, current version 0.0.0)
/pkgs/gcc-mainline/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.2.1)
[lindv2:~/Desktop/gcc-test] lucier% /pkgs/gcc-mainline/bin/gcc -m64 -dynamiclib
-o conftest conftest.c
/usr/bin/libtool: can't locate file for: -lgcc_s.10.4
/usr/bin/libtool: file: -lgcc_s.10.4 is not an object file (not allowed in a
library)
[lindv2:~/Desktop/gcc-test] lucier% pushd /pkgs/gcc-mainline/
/pkgs/gcc-mainline ~/Desktop/gcc-test
[lindv2:/pkgs/gcc-mainline] lucier% find . -name '*libgcc*'
./lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/libgcc.a
./lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/libgcc_eh.a
./lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/ppc64/libgcc.a
./lib/gcc/powerpc-apple-darwin8.2.0/4.1.0/ppc64/libgcc_eh.a
./lib/libgcc_s.1.dylib
./lib/libgcc_s.10.4.dylib
./lib/libgcc_s.10.5.dylib
./lib/libgcc_s.dylib
./lib/libgcc_s_ppc64.1.dylib
./lib/libgcc_s_ppc64.dylib
--
lucier at math dot purdue dot edu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug bootstrap/22536] New: gcc/dwarf2out.c:751: internal compiler error at tree-into-ssa.c:2290
stage1/xgcc -Bstage1/ -B/pkgs/gcc-mainline/powerpc-apple-darwin8.2.0/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/pkgs/gmp-4.1.3/include -I/pkgs/gmp-4.1.3/include ../../gcc/dwarf2out.c -o dwarf2out.o ../../gcc/dwarf2out.c: In function 'def_cfa_1': ../../gcc/dwarf2out.c:751: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'component_ref' in mark_sym_for_renaming, at tree-into-ssa.c:2290 configured and built with #!/bin/tcsh /bin/rm -rf *; ../configure --prefix=/pkgs/gcc-mainline --with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3 ; make -j 4 bootstrap STAGE1_CFLAGS='-O2 -g' build.log (make -j 8 check check.log ; make mail-report-with-warnings.log) -- Summary: gcc/dwarf2out.c:751: internal compiler error at tree- into-ssa.c:2290 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin8.2.0 GCC host triplet: powerpc-apple-darwin8.2.0 GCC target triplet: powerpc-apple-darwin8.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22536
[Bug target/21757] 64bit multilib for ppc-darwin
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-28 01:08 --- I'd like to point out that as documented extensively in bug report 22082, 64-bit compilation *does* work on powerpc-darwin-8 with gcc-4.0.0, and it doesn't now work on the mainline or the 4.0 branch. Mike Stump proposed a fix in http://gcc.gnu.org/ml/gcc/2005-06/msg00615.html but then mainline couldn't find the installed libgcc_s_ppc64, as documented in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110 So while there's no discussion in *this* PR of *any* of these issues, if you follow these links you'll find useful information -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21757
[Bug target/22110] Wrong ld search paths passed to libtool for 64-bit compiles
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-18 19:37 --- This is fixed in today's cvs sources, perhaps because of http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00681.html -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
[Bug target/22110] Wrong ld search paths passed to libtool for 64-bit compiles
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-19 02:02 --- This is a simple patch that can and probably should be back-ported to 4.0.2 after the 4.0 branch is re-opened. It seems that I probably made a mistake when I marked it resolved. It is still open on the 4.0 branch, I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
[Bug target/22110] Wrong ld search paths passed to libtool for 64-bit compiles
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-19 02:21 --- Well, I made more than one mistake today. While Geoff's patch allows gcc to find libgcc_s_ppc64.dylib when running the test suite, the installed compiler can't seem to find this library when trying to build an executable. So I'm re-opening the bug. Sorry for the confusion. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
[Bug target/22118] New: ld64 failed: vanilla pointer relocation found that is not 8-bytes
After enabling multilibs, there are many c++ testsuite failures like the following (taken from gcc/testsuite/g++.log): Testing debug/const1.C, -gdwarf-21 Executing on host: /Users/lucier/programs/gcc/gcc-mainline/objdir/gcc/testsuite/../g++ -B/Users/lucier/programs/gcc/gcc-mainline/objdir/gcc/testsuite/../ /Users/lucier/programs/gcc/gcc-mainline/gcc/testsuite/g++.dg/debug/const1.C -nostdinc++ -I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple-darwin8.1.0/ppc64/libstdc++-v3/include/powerpc-apple-darwin8.1.0 -I/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple-darwin8.1.0/ppc64/libstdc++-v3/include -I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/libsupc++ -I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/include/backward -I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite -fmessage-length=0 -gdwarf-21 -O -L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple-darwin8.1.0/ppc64/libstdc++-v3/src/.libs -L/Users/lucier/programs/gcc/gcc-mainline/objdir/powerpc-apple-darwin8.1.0/ppc64/libiberty -multiply_defined suppress -lm -m64 -o const1.exe(timeout = 300) ld64 failed: in /var/tmp//ccsaGdeJ.o, vanilla pointer relocation found that is not 8-bytes^M collect2: ld returned 1 exit status^M compiler exited with status 1 output is: ld64 failed: in /var/tmp//ccsaGdeJ.o, vanilla pointer relocation found that is not 8-bytes^M collect2: ld returned 1 exit status^M FAIL: g++.dg/debug/const1.C (test for excess errors) Excess errors: ld64 failed: in /var/tmp//ccsaGdeJ.o, vanilla pointer relocation found that is not 8-bytes I can't seem to figure out how to run the command by hand to get a .i file. -- Summary: ld64 failed: vanilla pointer relocation found that is not 8-bytes Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin8.1.0 GCC host triplet: powerpc-apple-darwin8.1.0 GCC target triplet: powerpc-apple-darwin8.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22118
[Bug target/22110] New: Wrong ld search paths passed to libtool for 64-bit compiles
-apple-darwin8/4.0.0 -L/usr/lib/gcc/powerpc-apple-darwin8/4.0.0/../../.. conftest.o -lgcc_s_ppc64 -lgcc -lSystemStubs -lmx -lSystem In fact, libgcc_s_ppc64 is in $prefix/lib/gcc/powerpc-apple-darwin8.1/4.1.0/../../.. not $prefix/lib/gcc/powerpc-apple-darwin8.1/4.1.0/../../../ppc64 I have no clue about how to change the search paths for libtool. -- Summary: Wrong ld search paths passed to libtool for 64-bit compiles Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin8.1.0 GCC host triplet: powerpc-apple-darwin8.1.0 GCC target triplet: powerpc-apple-darwin8.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
[Bug target/22110] Wrong ld search paths passed to libtool for 64-bit compiles
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-18 04:53 --- I re-enabled 64-bit multilib before building and installing gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110
[Bug target/22082] New: Can't link 64-bit shared libraries with Xcode 2.1
I'm sorry, I don't know enough about shared libraries to build a small test case, but I don't think it should be hard to do for someone who does know. It's simple to reproduce the problem. I installed Xcode 2.1 and built mainline and 4.0-branch with [descartes:~/programs] lucier% /pkgs/gcc-4.0-mainline/bin/gcc -v Using built-in specs. Target: powerpc-apple-darwin8.1.0 Configured with: ../configure --prefix=/pkgs/gcc-4.0-mainline --with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3 Thread model: posix gcc version 4.1.0 20050615 (experimental) [descartes:~/programs] lucier% /pkgs/gcc-4.0-branch/bin/gcc -v Using built-in specs. Target: powerpc-apple-darwin8.1.0 Configured with: ../configure --prefix=/pkgs/gcc-4.0-branch --with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3 Thread model: posix gcc version 4.0.1 20050615 (prerelease) Next I downloaded http://www.math.purdue.edu/~lucier/bugzilla/7/gambc40b13.tar.gz expanded it, cd'ed to gambc40b13, configured with [descartes:~/programs/gambc40b13] lucier% env CC='/pkgs/gcc-4.0-mainline/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL' ./configure --enable-shared and ran make The library routines were compiled with, for example, /pkgs/gcc-4.0-mainline/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL -I../include -I. -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -D___GAMBCDIR=\/usr/local/Gambit-C\ -c _num.c and they were linked with /pkgs/gcc-4.0-mainline/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL -flat_namespace -undefined suppress -o libgambc.dylib main.o setup.o mem.o c_intf.o os.o os_base.o os_time.o os_shell.o os_files.o os_dyn.o os_tty.o os_io.o _kernel.o _system.o _num.o _std.o _eval.o _io.o _nonstd.o _thread.o _repl.o _gambc.o making all in gsi /pkgs/gcc-4.0-mainline/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL -I../include -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -c _gsi.c gcc: unrecognized option '-no-cpp-precomp' /pkgs/gcc-4.0-mainline/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL -I../include -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -c _gsi_.c gcc: unrecognized option '-no-cpp-precomp' /pkgs/gcc-4.0-mainline/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL _gsi.o _gsi_.o -L../lib -lgambc -o gsi ld64 failed: in ../lib/libgambc.dylib, unknown mach-o file type collect2: ld returned 1 exit status make[1]: *** [gsi] Error 1 make: *** [all-recursive] Error 1 [descartes:~/programs/gambc40b13] lucier% ld64 -v @(#)PROGRAM:ld64 PROJECT:ld64-26.0.80 DEVELOPER:root BUILT:May 26 2005 16:00:10 [descartes:~/programs/gambc40b13] lucier% ld -v Apple Computer, Inc. version cctools-590.obj~12 [descartes:~/programs/gambc40b13] lucier% as -v Apple Computer, Inc. version cctools-590.obj~12, GNU assembler version 1.38 The same thing happens with 4.0-branch, i.e., the 4.0.1 release candidate, which is more troubling. It doesn't happen with 4.0.0, so this is a regression from 4.0.0 to 4.0.1. Brad -- Summary: Can't link 64-bit shared libraries with Xcode 2.1 Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin8.1.0 GCC host triplet: powerpc-apple-darwin8.1.0 GCC target triplet: powerpc-apple-darwin8.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 18:42 --- This worked in 4.0.0, so it's a regression. And 4.0.0 is now the *only* version of gcc that will compile Gambit-C correctly; [descartes:~/programs/gambc40b13] lucier% /pkgs/gcc-4.0.0-apple/bin/gcc -v Using built-in specs. Target: powerpc-apple-darwin8.1.0 Configured with: ../configure --prefix=/pkgs/gcc-4.0.0-apple --with-gmp=/pkgs/gmp-4.1.4 --with-mpfr=/pkgs/gmp-4.1.4 --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 (Apple Computer, Inc. build 5018) gives me the same error; the Xcode 2.0 gcc compiler was a POS; and with [descartes:~/programs/gambc40b13] lucier% /usr/bin/gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5026.obj~19/src/configure --disable-checking --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^+.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.0 (Apple Computer, Inc. build 5026) I get [descartes:~/programs/gambc40b13] lucier% gsi Illegal instruction The last three are not the FSF gcc team's problem, of course, but why go from a compiler that works on PowerPC darwin to one that doesn't I don't know. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 18:46 --- This isn't a duplicate of 21757; 21757 is about an 8-month old, tremendously buggy, version of Apple's gcc, this report is about the current release candidate. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 18:54 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 On Jun 15, 2005, at 1:49 PM, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 18:49 --- Could you do: file libgambc.dylib in the directory which contains libgambc.dylib? /pkgs/gcc-4.0-branch/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL _gsi.o _gsi_.o -L../lib -lgambc -o gsi ld64 failed: in ../lib/libgambc.dylib, unknown mach-o file type collect2: ld returned 1 exit status make[1]: *** [gsi] Error 1 make: *** [all-recursive] Error 1 [descartes:~/programs/gambc40b13] lucier% file lib/libgambc.dylib lib/libgambc.dylib: Mach-O 64-bit executable ppc64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15
19:19 ---
Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1
On Jun 15, 2005, at 1:56 PM, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
2005-06-15 18:56 ---
(In reply to comment #6)
[descartes:~/programs/gambc40b13] lucier% file lib/libgambc.dylib
lib/libgambc.dylib: Mach-O 64-bit executable ppc64
executable, that means it is not linkable. I would double check
you GCC invocation for making
libgambc.dylib because it is not generating a library.
Thank you very much for this suggestion, I see
/pkgs/gcc-4.0-branch/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL -
flat_namespace -undefined suppress -o libgambc.dylib main.o setup.o
mem.o c_intf.o os.o os_base.o os_time.o os_shell.o os_files.o
os_dyn.o os_tty.o os_io.o _kernel.o _system.o _num.o _std.o _eval.o
_io.o _nonstd.o _thread.o _repl.o _gambc.o
versus
/pkgs/gcc-4.0.0/bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL -
dynamiclib -flat_namespace -undefined suppress -o libgambc.dylib
main.o setup.o mem.o c_intf.o os.o os_base.o os_time.o os_shell.o
os_files.o os_dyn.o os_tty.o os_io.o _kernel.o _system.o _num.o
_std.o _eval.o _io.o _nonstd.o _thread.o _repl.o _gambc.o
and the configuration log for gcc-4.0-branch says
configure:15317: checking whether /pkgs/gcc-4.0-branch/bin/gcc -
mcpu=970 -m64 -force_cpusubtype_ALL accepts -dynamiclib
configure:15338: /pkgs/gcc-4.0-branch/bin/gcc -mcpu=970 -m64 -
force_cpusubtype_ALL -o conftest -dynamiclib conftest.c 5
ld64 failed: library not found for -lgcc_s
/usr/bin/libtool: internal link edit command failed
(which is as you've been saying) versus for 4.0.0
configure:15317: checking whether /pkgs/gcc-4.0.0/bin/gcc -mcpu=970 -
m64 -force_cpusubtype_ALL accepts -dynamiclib
configure:15338: /pkgs/gcc-4.0.0/bin/gcc -mcpu=970 -m64 -
force_cpusubtype_ALL -o conftest -dynamiclib conftest.c 5
configure:15341: $? = 0
configure:15355: result: -dynamiclib
And it does work with 4.0.0:
[descartes:/pkgs/gcc-4.0.0] lucier% cat conftest.c
int
main ()
{
return 0;
}
[descartes:/pkgs/gcc-4.0.0] lucier% /pkgs/gcc-4.0.0/bin/gcc -mcpu=970
-m64 -force_cpusubtype_ALL -o conftest -dynamiclib conftest.c -v
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure --prefix=/pkgs/gcc-4.0.0 --with-gmp=/
pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3
Thread model: posix
gcc version 4.0.0
/pkgs/gcc-4.0.0/libexec/gcc/powerpc-apple-darwin8.1.0/4.0.0/cc1 -
quiet -v -D__DYNAMIC__ -D__APPLE_CC__=1 conftest.c -fPIC -quiet -
dumpbase conftest.c -mcpu=970 -m64 -auxbase conftest -version -o /var/
tmp//ccKu5zS6.s
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory /pkgs/gcc-4.0.0/lib/gcc/powerpc-apple-
darwin8.1.0/4.0.0/../../../../powerpc-apple-darwin8.1.0/include
#include ... search starts here:
#include ... search starts here:
/pkgs/gcc-4.0.0/include
/pkgs/gcc-4.0.0/lib/gcc/powerpc-apple-darwin8.1.0/4.0.0/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
GNU C version 4.0.0 (powerpc-apple-darwin8.1.0)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-
heapsize=131072
as -arch ppc64 -force_cpusubtype_ALL -o /var/tmp//ccCtfLGH.o /var/
tmp//ccKu5zS6.s
/usr/bin/libtool -dynamic -arch_only ppc64 -noall_load -
weak_reference_mismatches non-weak -o conftest -L/pkgs/gcc-4.0.0/lib/
gcc/powerpc-apple-darwin8.1.0/4.0.0 -L/pkgs/gcc-4.0.0/lib/gcc/powerpc-
apple-darwin8.1.0/4.0.0/../../.. /var/tmp//ccCtfLGH.o -lgcc_s -lgcc -
lSystemStubs -lmx -lSystem
[descartes:/pkgs/gcc-4.0.0] lucier% file conftest
conftest: Mach-O 64-bit dynamically linked shared library ppc64
So it works with 4.0.0, but not with 4.0-branch:
[descartes:~/programs/gambc40b13] lucier% /pkgs/gcc-4.0-branch/bin/
gcc -mcpu=970 -m64 -force_cpusubtype_ALL -o conftest.o -dynamiclib
conftest.c -v
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure --prefix=/pkgs/gcc-4.0-branch --with-
gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3
Thread model: posix
gcc version 4.0.1 20050615 (prerelease)
/pkgs/gcc-4.0-branch/libexec/gcc/powerpc-apple-darwin8.1.0/4.0.1/cc1 -
quiet -v -D__DYNAMIC__ -D__APPLE_CC__=1 conftest.c -fPIC -quiet -
dumpbase conftest.c -mcpu=970 -m64 -auxbase conftest -version -o /var/
tmp//cctbhV9h.s
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory /pkgs/gcc-4.0-branch/lib/gcc/powerpc-
apple-darwin8.1.0/4.0.1/../../../../powerpc-apple-darwin8.1.0/include
#include ... search starts here:
#include ... search starts here:
/pkgs/gcc-4.0-branch/include
/pkgs/gcc-4.0-branch/lib/gcc/powerpc-apple-darwin8.1.0/4.0.1/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
GNU C version 4.0.1 20050615 (prerelease) (powerpc-apple-darwin8.1.0
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15
19:32 ---
Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1
On Jun 15, 2005, at 2:27 PM, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
2005-06-15 19:27 ---
Nope, 64bit multilib support was disabled before the release of 4.0.0:
2005-04-02 Geoffrey Keating [EMAIL PROTECTED]
* config/rs6000/t-darwin8: Comment out ppc64 multilib.
You keep saying this, yet I get (as I reported in my last e-mail)
[descartes:/pkgs/gcc-4.0.0] lucier% /pkgs/gcc-4.0.0/bin/gcc -mcpu=970
-m64 -force_cpusubtype_ALL -o conftest -dynamiclib conftest.c -v
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure --prefix=/pkgs/gcc-4.0.0 --with-gmp=/
pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3
Thread model: posix
gcc version 4.0.0
/pkgs/gcc-4.0.0/libexec/gcc/powerpc-apple-darwin8.1.0/4.0.0/cc1 -
quiet -v -D__DYNAMIC__ -D__APPLE_CC__=1 conftest.c -fPIC -quiet -
dumpbase conftest.c -mcpu=970 -m64 -auxbase conftest -version -o /var/
tmp//ccKu5zS6.s
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory /pkgs/gcc-4.0.0/lib/gcc/powerpc-apple-
darwin8.1.0/4.0.0/../../../../powerpc-apple-darwin8.1.0/include
#include ... search starts here:
#include ... search starts here:
/pkgs/gcc-4.0.0/include
/pkgs/gcc-4.0.0/lib/gcc/powerpc-apple-darwin8.1.0/4.0.0/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
GNU C version 4.0.0 (powerpc-apple-darwin8.1.0)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-
heapsize=131072
as -arch ppc64 -force_cpusubtype_ALL -o /var/tmp//ccCtfLGH.o /var/
tmp//ccKu5zS6.s
/usr/bin/libtool -dynamic -arch_only ppc64 -noall_load -
weak_reference_mismatches non-weak -o conftest -L/pkgs/gcc-4.0.0/lib/
gcc/powerpc-apple-darwin8.1.0/4.0.0 -L/pkgs/gcc-4.0.0/lib/gcc/powerpc-
apple-darwin8.1.0/4.0.0/../../.. /var/tmp//ccCtfLGH.o -lgcc_s -lgcc -
lSystemStubs -lmx -lSystem
[descartes:/pkgs/gcc-4.0.0] lucier% file conftest
conftest: Mach-O 64-bit dynamically linked shared library ppc64
[descartes:/pkgs/gcc-4.0.0] lucier% cat conftest.c
int
main ()
{
return 0;
}
So, it works in practice, but not in theory?
Can you please address the examples I'm giving you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 20:43 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 On Jun 15, 2005, at 2:51 PM, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-15 19:51 --- I think you built in a directory for 4.0.0 which you built a prerelease of 4.0.0 which was built before the multilib was disabled. That's nice. I built a new gcc-4.0.0, put it in a clean directory, and got the same results. [descartes:~/programs/gcc-4.0.0/objdir] lucier% /pkgs/gcc-4.0.0-new/ bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL -o conftest -dynamiclib conftest.c -v Using built-in specs. Target: powerpc-apple-darwin8.1.0 Configured with: ../configure --prefix=/pkgs/gcc-4.0.0-new --enable- languages=c Thread model: posix gcc version 4.0.0 /pkgs/gcc-4.0.0-new/libexec/gcc/powerpc-apple-darwin8.1.0/4.0.0/cc1 - quiet -v -D__DYNAMIC__ -D__APPLE_CC__=1 conftest.c -fPIC -quiet - dumpbase conftest.c -mcpu=970 -m64 -auxbase conftest -version -o /var/ tmp//ccbXmBq6.s ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /pkgs/gcc-4.0.0-new/lib/gcc/powerpc- apple-darwin8.1.0/4.0.0/../../../../powerpc-apple-darwin8.1.0/include #include ... search starts here: #include ... search starts here: /pkgs/gcc-4.0.0-new/include /pkgs/gcc-4.0.0-new/lib/gcc/powerpc-apple-darwin8.1.0/4.0.0/include /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C version 4.0.0 (powerpc-apple-darwin8.1.0) compiled by GNU C version 4.0.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min- heapsize=131072 as -arch ppc64 -force_cpusubtype_ALL -o /var/tmp//ccv0JLb0.o /var/ tmp//ccbXmBq6.s /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load - weak_reference_mismatches non-weak -o conftest -L/pkgs/gcc-4.0.0-new/ lib/gcc/powerpc-apple-darwin8.1.0/4.0.0 -L/pkgs/gcc-4.0.0-new/lib/gcc/ powerpc-apple-darwin8.1.0/4.0.0/../../.. /var/tmp//ccv0JLb0.o -lgcc_s -lgcc -lSystemStubs -lmx -lSystem But you refuse to try it for yourself, and keep repeating that it can't be so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 21:05 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 OK, so do we now agree it works with 4.0.0, but not with 4.0-branch? You claim That is because it is picking up the libgcc_s.dylib which is included with Apple's 4.0.0 and not a newly built one. Why should this happen with 4.0.0 and not 4.0-branch? And is this the right or the wrong behavior? And how can I check whether your explanation is true? (On linux I have ldd for such a task; do you know if there is something similar for darwin?) Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 21:15 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 Already tried it and it doesn't do what I think we want: /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load - weak_reference_mismatches non-weak -o conftest -L/pkgs/gcc-4.0.0-new/ lib/gcc/powerpc-apple-darwin8.1.0/4.0.0 -L/pkgs/gcc-4.0.0-new/lib/gcc/ powerpc-apple-darwin8.1.0/4.0.0/../../.. /var/tmp//cclcGcnS.o -lgcc_s -lgcc -lSystemStubs -lmx -lSystem [descartes:~/programs/gcc-4.0.0/objdir] lucier% otool -L conftest conftest: is not an object file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15 21:48 --- Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1 Great, thanks. Here is what otool64 -L reports for a binary built with [descartes:~/programs/gcc-4.0.0/objdir] lucier% /pkgs/gcc-4.0.0-new/ bin/gcc -mcpu=970 -m64 -force_cpusubtype_ALL -o conftest -dynamiclib conftest.c -v Using built-in specs. Target: powerpc-apple-darwin8.1.0 Configured with: ../configure --prefix=/pkgs/gcc-4.0.0-new --enable- languages=c Thread model: posix gcc version 4.0.0 /pkgs/gcc-4.0.0-new/libexec/gcc/powerpc-apple-darwin8.1.0/4.0.0/cc1 - quiet -v -D__DYNAMIC__ -D__APPLE_CC__=1 conftest.c -fPIC -quiet - dumpbase conftest.c -mcpu=970 -m64 -auxbase conftest -version -o /var/ tmp//ccyaTKos.s ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /pkgs/gcc-4.0.0-new/lib/gcc/powerpc- apple-darwin8.1.0/4.0.0/../../../../powerpc-apple-darwin8.1.0/include #include ... search starts here: #include ... search starts here: /pkgs/gcc-4.0.0-new/include /pkgs/gcc-4.0.0-new/lib/gcc/powerpc-apple-darwin8.1.0/4.0.0/include /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C version 4.0.0 (powerpc-apple-darwin8.1.0) compiled by GNU C version 4.0.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min- heapsize=131072 as -arch ppc64 -force_cpusubtype_ALL -o /var/tmp//ccqcwAx7.o /var/ tmp//ccyaTKos.s /usr/bin/libtool -dynamic -arch_only ppc64 -noall_load - weak_reference_mismatches non-weak -o conftest -L/pkgs/gcc-4.0.0-new/ lib/gcc/powerpc-apple-darwin8.1.0/4.0.0 -L/pkgs/gcc-4.0.0-new/lib/gcc/ powerpc-apple-darwin8.1.0/4.0.0/../../.. /var/tmp//ccqcwAx7.o -lgcc_s -lgcc -lSystemStubs -lmx -lSystem [descartes:~/programs/gcc-4.0.0/objdir] lucier% otool64 -L conftest conftest: conftest (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0) No libgcc_s.dylib at all. It's the same for Gambit-C compiled with gcc-4.0.0: [descartes:gcc-4.0.0/objdir/4.0-branch] lucier% otool64 -L `which gsi` /usr/local/Gambit-C/bin/gsi: libgambc.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0) So does it mean that 4.0-branch wants to pull in libgcc_s.dylib while 4.0.0 does not? Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug target/22082] Can't link 64-bit shared libraries with Xcode 2.1
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-15
22:31 ---
Subject: Re: Can't link 64-bit shared libraries with Xcode 2.1
On Jun 15, 2005, at 4:57 PM, pinskia at gcc dot gnu dot org wrote:
That does not make sense as it should always include libgcc_s for
dynamic libraries.
Here's a very short test file:
[descartes:gcc-4.0.0/objdir/4.0.0] lucier% cat conftest.c
int
main ()
{
return 0;
}
[descartes:gcc-4.0.0/objdir/4.0.0] lucier% /pkgs/gcc-4.0.0/bin/gcc
-dynamiclib -o conftest conftest.c
[descartes:gcc-4.0.0/objdir/4.0.0] lucier% otool -L conftest
conftest:
conftest (compatibility version 0.0.0, current version 0.0.0)
/pkgs/gcc-4.0.0/lib/libgcc_s.1.0.dylib (compatibility version
1.0.0, current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current
version 92.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.0.0)
[descartes:gcc-4.0.0/objdir/4.0.0] lucier% /pkgs/gcc-4.0.0/bin/gcc
-dynamiclib -m64 -o conftest conftest.c
[descartes:gcc-4.0.0/objdir/4.0.0] lucier% otool64 -L conftestconftest:
conftest (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current
version 92.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.0.0)
Does your statement That does not make sense mean more than that's
puzzling, and needs more investigation?
Brad
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082
[Bug preprocessor/21410] Infinite memory usage in preprocessor
--- Additional Comments From lucier at math dot purdue dot edu 2005-05-06 09:25 --- Subject: Re: Infinite memory usage in preprocessor Ah, after I reported it I was afraid it might be something like this. Thank you for explaining this. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21410
[Bug preprocessor/21410] New: Infinite memory usage in preprocessor
You guys will like this one ... The most recent test is with 4.0.0 on Red Hat Enterprise Linux 4.0, but it also happens with 3.4.3 and 4.0.0 on sparc-sun-solaris2.9. In http://www.math.purdue.edu/~lucier/bugzilla/6/ you'll find compressed versions of test2.c and gambit.h. With this command line peano-66% /pkgs/gcc-4.0.0/bin/gcc -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -mieee-fp -rdynamic -shared -D___DYNAMIC -D___SINGLE_HOST -E test2.c -v ! test2.i Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/pkgs/gcc-4.0.0 Thread model: posix gcc version 4.0.0 /export/pkgs/gcc-4.0.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.0.0/cc1 -E -quiet -v -iprefix /export/pkgs/gcc-4.0.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.0/ -D___DYNAMIC -D___SINGLE_HOST test2.c -mieee-fp -mtune=k8 -Wall -W -Wno-unused -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -O1 ignoring nonexistent directory /export/pkgs/gcc-4.0.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.0/../../../../x86_64-unknown-linux-gnu/include ignoring nonexistent directory /usr/local/include ignoring duplicate directory /pkgs/gcc-4.0.0/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/include ignoring nonexistent directory /pkgs/gcc-4.0.0/lib/gcc/x86_64-unknown-linux-gnu/4.0.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /export/pkgs/gcc-4.0.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.0.0/include /pkgs/gcc-4.0.0/include /usr/include End of search list. memory is rapidly exhausted (even with 16GB of virtual memory). Brad -- Summary: Infinite memory usage in preprocessor Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21410
[Bug bootstrap/19146] Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'.
--- Additional Comments From lucier at math dot purdue dot edu 2005-02-10 18:34 --- Subject: Re: Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'. Yes, close it; I think it is a generic parallel build problem when the build file system is mounted using NFS. Thanks. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19146
[Bug bootstrap/19146] New: Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'.
The configure and build commands were:
/bin/rm -rf *; ../configure --prefix=/export/users/lucier/local/gcc-mainline;
make -j 6 bootstrap build.log (make -j 8 -k check
RUNTESTFLAGS=--target_board 'unix{-m64,}' check.log ; make
mail-report-with-warnings.log; ./mail-report-with-warnings.log)
The build failed in stage 1 with
make[2]: *** No rule to make target `intl.h', needed by `c-parse.o'. Stop.
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
`/export/users/lucier/programs/gcc/mainline/objdir2/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory
`/export/users/lucier/programs/gcc/mainline/objdir2/gcc'
make: *** [bootstrap] Error 2
--
Summary: Parallel bootstrap failure: No rule to make target
`intl.h', needed by `c-parse.o'.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19146
[Bug bootstrap/19146] Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'.
--- Additional Comments From lucier at math dot purdue dot edu 2004-12-24 03:55 --- Subject: Re: Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'. zorn-32% make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Perhaps it's a problem with parallel make on an NFS file system. I just got a lot of strange errors involving the po directory. I'll retry it on the slower machine where the file system resides. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19146
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From lucier at math dot purdue dot edu 2004-12-18 20:23 --- Subject: Re: [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler I can find no other problems at the moment. Thank you all for investigating and fixing this. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] New: Miscompiles code generated by Gambit-C Scheme-C compiler
-- Summary: Miscompiles code generated by Gambit-C Scheme-C compiler Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From lucier at math dot purdue dot edu 2004-11-18 19:04 --- Sorry for hitting return in the summary field ... This is a catch-all bug report for miscompilations of machine-generated code that is generated by the Gambit-C Scheme-C compiler. Giovanni Bajo suggested that I at least document the problem with proper preprocessed files, etc. All 34 megabytes of the files are at http://www.math.purdue.edu/~lucier/GNATS/GNATS-16/gambit-test.tgz They were generated and the bug was verified with the following commands: [EMAIL PROTECTED] gambc40b11]$ env CC='gcc -g -save-temps' ./configure --enable-single-host [EMAIL PROTECTED] gambc40b11]$ gcc -v Reading specs from /home/lucier/local/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../configure --prefix=/home/lucier/local/ --enable-languages=c --enable-checking=no Thread model: posix gcc version 4.0.0 20041118 (experimental) [EMAIL PROTECTED] gambc40b11]$ make stuff removed [EMAIL PROTECTED] gambc40b11]$ cd bench [EMAIL PROTECTED] bench]$ ./bench -c no gambit fib Testing fib under Gambit-C Compiling... ./bench: line 518: 25754 Segmentation fault LD_LIBRARY_PATH=../../../lib GAMBCDIR=../../../lib ../../../gsc/gsc -:=../../.. $1.scm gcc: fib.c: No such file or directory gcc: fib_.c: No such file or directory Command exited with non-zero status 1 0.00user 0.00system 0:00.01elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (153major+23minor)pagefaults 0swaps ls: fib: No such file or directory Running... time: cannot run ./fib: No such file or directory Command exited with non-zero status 127 0.00user 0.00system 0:00.00elapsed ?%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (24major+8minor)pagefaults 0swaps [EMAIL PROTECTED] bench]$ cd sys/gambit [EMAIL PROTECTED] gambit]$ ls fib.scm [EMAIL PROTECTED] gambit]$ env GAMBCDIR=../../../lib ../../../gsc/gsc -:=../../.. fib.scm Segmentation fault [EMAIL PROTECTED] gambit]$ env GAMBCDIR=../../../lib gdb ../../../gsc/gsc GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run -:=../../.. fib.scm Starting program: /home/lucier/programs/gambc40b11/gsc/gsc -:=../../.. fib.scm Program received signal SIGSEGV, Segmentation fault. 0x0815741b in ___H__20___front (___ps=0x8495ce0) at _front.c:7075 7075 ___SET_R2(___FIXMAX(___R3,___R2)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug rtl-optimization/16088] [4.0 Regression] Generates wrong code
--- Additional Comments From lucier at math dot purdue dot edu 2004-11-18 01:13 --- Maybe this bug should be closed for lack of specificity. The problem is the following: gcc-4.0 miscompiles C code generated by the Scheme-C compiler Gambit-C (http://www.iro.umontreal.ca/~gambit). I have not been able to debug the problem (all the various version of gdb I tried have not been helpful). In the meantime, two code generation bugs have been fixed (one in the past few days), and several still remain. So the specific information (such as it is) in this bug report is no longer accurate. It is still a fact that gcc-4.0 miscompiles code generated by Gambit-C (and examples of this are easy to find, e.g., the compiler itself aborts in many cases)---perhaps this should be a placeholder bug report for this general problem? I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16088
[Bug target/16975] Tremendous increase in compile times for 3.4.1 with -mcpu=G5
--- Additional Comments From lucier at math dot purdue dot edu 2004-11-10 16:31 --- Subject: Re: Tremendous increase in compile times for 3.4.1 with -mcpu=G5 The G5 time is cut in half from 3.4.*, but the G4 time is 4 times as long (roughly). I don't think this is FIXED. Or should I just open another PR? Brad [descartes:gcc/mainline/objdir] lucier% /pkgs/gcc-mainline/libexec/gcc/powerpc-apple-darwin7.6.0/4.0.0/cc1 -mcpu=G4 -I../include -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H _num.i ___H__20___num ___init_proc 20___num Execution times (seconds) cfg construction : 0.07 ( 0%) usr 0.06 ( 0%) sys 0.14 ( 0%) wall cfg cleanup : 1.63 ( 2%) usr 0.03 ( 0%) sys 2.23 ( 2%) wall trivially dead code : 0.35 ( 1%) usr 0.00 ( 0%) sys 0.56 ( 0%) wall life analysis : 2.29 ( 3%) usr 0.92 ( 6%) sys 4.42 ( 4%) wall life info update : 0.73 ( 1%) usr 0.00 ( 0%) sys 1.07 ( 1%) wall alias analysis: 0.25 ( 0%) usr 0.00 ( 0%) sys 0.33 ( 0%) wall register scan : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall rebuild jump labels : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall preprocessing : 1.66 ( 3%) usr 2.69 (16%) sys 6.03 ( 5%) wall lexical analysis : 2.76 ( 4%) usr 5.50 (34%) sys 12.20 (10%) wall parser: 2.27 ( 3%) usr 2.45 (15%) sys 7.22 ( 6%) wall tree gimplify : 0.26 ( 0%) usr 0.02 ( 0%) sys 0.39 ( 0%) wall tree eh : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall tree CFG construction : 0.10 ( 0%) usr 0.03 ( 0%) sys 0.17 ( 0%) wall tree CFG cleanup : 0.55 ( 1%) usr 0.03 ( 0%) sys 0.80 ( 1%) wall tree find referenced vars: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall tree PTA : 23.55 (36%) usr 0.18 ( 1%) sys 32.78 (28%) wall tree alias analysis : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall tree PHI insertion: 0.79 ( 1%) usr 0.31 ( 2%) sys 1.46 ( 1%) wall tree SSA rewrite : 2.08 ( 3%) usr 0.02 ( 0%) sys 3.17 ( 3%) wall tree SSA other: 2.37 ( 4%) usr 0.90 ( 6%) sys 4.40 ( 4%) wall tree operand scan : 0.71 ( 1%) usr 1.11 ( 7%) sys 2.76 ( 2%) wall dominator optimization: 4.21 ( 6%) usr 0.21 ( 1%) sys 6.41 ( 5%) wall tree CCP : 0.25 ( 0%) usr 0.01 ( 0%) sys 0.30 ( 0%) wall tree split crit edges : 0.21 ( 0%) usr 0.01 ( 0%) sys 0.32 ( 0%) wall tree PRE : 0.62 ( 1%) usr 0.10 ( 1%) sys 1.04 ( 1%) wall tree linearize phis : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall tree forward propagate: 0.15 ( 0%) usr 0.01 ( 0%) sys 0.21 ( 0%) wall tree conservative DCE : 0.31 ( 0%) usr 0.00 ( 0%) sys 0.44 ( 0%) wall tree aggressive DCE : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall tree DSE : 0.26 ( 0%) usr 0.00 ( 0%) sys 0.42 ( 0%) wall tree record loop bounds: 0.04 ( 0%) usr 0.01 ( 0%) sys 0.06 ( 0%) wall loop invariant motion : 0.16 ( 0%) usr 0.01 ( 0%) sys 0.28 ( 0%) wall tree canonical iv creation: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall tree iv optimization : 0.26 ( 0%) usr 0.03 ( 0%) sys 0.36 ( 0%) wall tree copy headers : 0.26 ( 0%) usr 0.13 ( 1%) sys 0.50 ( 0%) wall tree SSA to normal: 2.41 ( 4%) usr 0.01 ( 0%) sys 3.56 ( 3%) wall tree rename SSA copies: 0.05 ( 0%) usr 0.01 ( 0%) sys 0.08 ( 0%) wall dominance frontiers : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.18 ( 0%) wall expand: 1.61 ( 2%) usr 0.29 ( 2%) sys 2.56 ( 2%) wall varconst : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall jump : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall CSE : 0.41 ( 1%) usr 0.00 ( 0%) sys 0.52 ( 0%) wall loop analysis : 0.34 ( 1%) usr 0.09 ( 1%) sys 0.73 ( 1%) wall branch prediction : 0.54 ( 1%) usr 0.06 ( 0%) sys 0.86 ( 1%) wall flow analysis : 0.14 ( 0%) usr 0.05 ( 0%) sys 0.28 ( 0%) wall combiner : 0.68 ( 1%) usr 0.05 ( 0%) sys 1.09 ( 1%) wall if-conversion : 0.48 ( 1%) usr 0.02 ( 0%) sys 0.71 ( 1%) wall local alloc : 0.43 ( 1%) usr 0.03 ( 0%) sys 0.72 ( 1%) wall global alloc : 3.87 ( 6%) usr 0.59 ( 4%) sys 6.37 ( 5%) wall reload CSE regs : 0.57 ( 1%) usr 0.08 ( 0%) sys 0.90 ( 1%) wall flow 2: 0.20 ( 0%) usr 0.09 ( 1%) sys 0.43 ( 0%) wall if-conversion 2 : 0.14 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall rename registers : 3.12 ( 5%) usr 0.06 ( 0%) sys 4.71 ( 4%) wall scheduling 2
[Bug tree-optimization/18419] [4.0 Regression] tree-ssa aliasing slow
-- What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18419
[Bug bootstrap/18211] [4.0 Regression] Parallel bootstrap failure: No rule to make target `hard-reg-set.h', needed by `build/insn-conditions.o'
--- Additional Comments From lucier at math dot purdue dot edu 2004-11-05 18:06 --- Subject: Re: [4.0 Regression] Parallel bootstrap failure: No rule to make target `hard-reg-set.h', needed by `build/insn-conditions.o' It has not happened again. If it does, I'll open a new PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18211
[Bug tree-optimization/18270] [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146
--- Additional Comments From lucier at math dot purdue dot edu 2004-11-03 21:31 --- Subject: Re: [4.0 Regression] internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146 Was a new test case added with this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18270
[Bug rtl-optimization/16088] [4.0 Regression] Generates wrong code
--- Additional Comments From lucier at math dot purdue dot edu 2004-11-04 03:31 --- Subject: Re: [4.0 Regression] Generates wrong code I tried again, I'm having the same problems with today's 4.0. I also have the same problems on sparc-sun-solaris2.9. I tried debugging it with gdb 6.2.1 on that platform but got garbage information about variables, etc. Geoff says I can't trust gdb on powerpc-apple-darwin7.5.0, either, with -O1. Is there any gdb on any OS platform that I can use to debug this problem? Should I try it on a friend's x86 Linux box? Or should I proceed in a different way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16088
[Bug middle-end/18270] New: internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146
[descartes:~/programs/gambc40b11/lib] lucier% gcc -I../include -I. -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -D___GAMBCDIR=\/usr/local/Gambit-C\ -c _kernel.c -save-temps gcc: unrecognized option `-no-cpp-precomp' In file included from os.h:185, from _kernel.c:1557: /usr/include/dlfcn.h:35:2: warning: #warning You are using dlopen(), a legacy API. Please use the Mach-O dylib loading APIs if at all possible _kernel.c: In function '___H__20___kernel': _kernel.c:1584: internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [descartes:~/programs/gambc40b11/lib] lucier% gcc -v Reading specs from /pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin7.5.0/4.0.0/specs Configured with: ../configure --prefix=/pkgs/gcc-mainline --with-gmp=/pkgs/gmp-4.1.3 --with-mpfr=/pkgs/gmp-4.1.3 Thread model: posix gcc version 4.0.0 20041102 (experimental) The preprocessed input file is at http://www.math.purdue.edu/~lucier/GNATS/GNATS-14/_kernel.i.gz -- Summary: internal compiler error: in tree_redirect_edge_and_branch, at tree-cfg.c:4146 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.5.0 GCC host triplet: powerpc-apple-darwin7.5.0 GCC target triplet: powerpc-apple-darwin7.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18270
[Bug bootstrap/18245] New: Bootstrap failure: ../../gcc/tree-ssa-operands.c:1624: warning: 'bi$ptr2' is used uninitialized in this function
stage1/xgcc -Bstage1/ -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/pkgs/gmp-4.1.3/include -I/pkgs/gmp-4.1.3/include ../../gcc/tree-ssa-operands.c -o tree-ssa-operands.o cc1: warnings being treated as errors ../../gcc/tree-ssa-operands.c: In function 'get_expr_operands': ../../gcc/tree-ssa-operands.c:1624: warning: 'bi$ptr2' is used uninitialized in this function make[2]: *** [tree-ssa-operands.o] Error 1 make[1]: *** [stage2_build] Error 2 -- Summary: Bootstrap failure: ../../gcc/tree-ssa-operands.c:1624: warning: 'bi$ptr2' is used uninitialized in this function Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.5.0 GCC host triplet: powerpc-apple-darwin7.5.0 GCC target triplet: powerpc-apple-darwin7.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18245
[Bug bootstrap/18211] New: Parallel bootstrap failure: No rule to make target `hard-reg-set.h', needed by `build/insn-conditions.o'
The error message is in the subject, I guess.
The build command was
/bin/rm -rf *; ../configure --prefix=/export/users/lucier/local/gcc-mainline;
make -j 8 bootstrap build.log (make -j 12 -k check
RUNTESTFLAGS=--target_board 'unix{-m64,}' check.log ; make
mail-report-with-warnings.log; ./mail-report-with-warnings.log)
--
Summary: Parallel bootstrap failure: No rule to make target
`hard-reg-set.h', needed by `build/insn-conditions.o'
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18211
[Bug bootstrap/18211] [4.0 Regression] Parallel bootstrap failure: No rule to make target `hard-reg-set.h', needed by `build/insn-conditions.o'
--- Additional Comments From lucier at math dot purdue dot edu 2004-10-28 21:23 --- Subject: Re: [4.0 Regression] Parallel bootstrap failure: No rule to make target `hard-reg-set.h', needed by `build/insn-conditions.o' make bootstrap continued just fine; after insn-conditions.o was built, I switched back to a make -j 8. But you're right, I can't find another instance of hard-reg-set.h in the build.log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18211
