With 139231 this test passed. With 139233 and on, I now see for cris-elf: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/weak/weak.exp ... FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j I see this regression in posted testresults from ia64 and powerpc64 too. Apparently, this is caused by revision 139233 which appears to rely on output_operand to catch all weaks, but the change to output_operand on July 21 to call assemble_external is incomplete and only works for targets where variable references are always wrapped in exactly one MEM around a symbol_ref. (Missing cases of multiple mems, or where symbol_ref¨s aren't valid addresses and offset references). I'm testing a patch.
Patch at <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01407.html>.
This test also fails recently for avr-unknown-elf. Also fails: weak-2.c, weak-3.c, weak-4.c, weak-5.c, weak-12.c. May be related: also fails on gcc.dg/attr-weakref-1.c. These tests are known fail revision 139269, known success 139231
(In reply to comment #2) > This test also fails recently for avr-unknown-elf. Does the patch work for you?
Same thing here on i686-apple-darwin9. > Does the patch work for you? No! I still get: FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c I also get the following answers for different regexps: [ibook-dhum] f90/bug% egrep "weak[^ ]*[ \t]_?vfoo1k" weak-4.s .weak_definition _vfoo1k [ibook-dhum] f90/bug% egrep "weak[^ \t]*[ \t]_?vfoo1k" weak-4.s [ibook-dhum] f90/bug%
(In reply to comment #4) > Same thing here on i686-apple-darwin9. But was the failures you see too introduced with r139233? I can't tell myself because I see no test-results for i686-apple-darwin on gcc-testresults@ (hint hint). > FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j > FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo > FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a > FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b > FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c > FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e > FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a > FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b > FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c If not, given the failures, I'd guess you're looking at a different bug. (Please open a separate PR, this one will cover just the weak-related bug matching the original description.)
> But was the failures you see too introduced with r139233? It is not in r139096, but appeared in r139293. So it is the right window, but I don't have anything in between. From what I have seen it looks more like a regexp problem. If nobody comes with a better idea by tomorrow, I'll open a nex PR. > I can't tell myself because I see no test-results for > i686-apple-darwin on gcc-testresults@ (hint hint). \begin{rant} Looking at the fate of darwin posts on gcc-testresults (the length of the ggc failures for ppc-darwin is increasing at a steady state while producing 3 results a day), I have decided to concentrate on PR now and then (my main interest is gfortran on Darwin, I just post C* results because I see them). \end{rant}
Patch did not fix any those regressions for the AVR: FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1i FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1j
(In reply to comment #7) > Patch did not fix any those regressions for the AVR: > Stupid me: There were problems when it tried to patch that I didn't notice. Fixing that and retesting...
(In reply to comment #7) > Patch did not fix any those regressions for the AVR: > > FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) > FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j > FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo > FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a > FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b > FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c > FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e > FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a > FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b > FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c > FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e > FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a > FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b > FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c > FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a > FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b > FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c > FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1i > FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1j > Ok, patched correctly, and verified that the patch does NOT fix the above regressions.
I have had a closer look to the failures on i686-apple-darwin9 and they are due to the replacement of '.weak_definition' with '.indirect_symbol' in the assembly code (the regexp problem seems related to different engines in Tcl and egrep). It could be worth looking to the origin of the failures on other targets.
Ok, I see why it doesn't work for you guys now: there's another bug; the weak handling is buggily put inside code gated by #ifdef ASM_OUTPUT_EXTERNAL. Simply moving it after that hunk should work. But I also see a wart with the original fix; I should iterate over the operand using for_each_rtx, not just peel off mem references and check for a const... (no, I can't imagine a target affected by that, but anyway) And I see where the code was copied from, same bug there (not really weak-related, rather extern-related, so I'll save it for later). Patch retracted, new patch coming up.
Created attachment 16125 [details] Patch, take 2. Against r139233.
Patch in comment #12 is as previously mentioned, except because of Darwin's weird symbol handling, the symbol_ref's didn't pass through the same way as other operands, so it has to mark weak references "manually". (No, this is not how -fPIC usually works; targets still pass around a symbol_ref, just wrapped in unspec rtx's.) Tested manually on crosses to ia64-elf, cris-elf, avr-elf and i686-darwin; AFAICT the failures still present with the previous version are gone. Currently testing this patch native x86_64-unknown-linux-gnu and cross to cris-elf, plan to post a RFA to gcc-patches@ tomorrow (in about 12h, that is). If you read this before reading the RFA, you're very welcome to test the patch.
I tried testing with 139423, but I'm getting a separate error during build: ../../../../gcc/libgcc/../gcc/libgcc2.c: In function '__mulsc3': ../../../../gcc/libgcc/../gcc/libgcc2.c:1831: internal compiler error: tree check: expected tree that contains 'decl with visibility' structure, have 'result_decl' in assemble_external, at varasm.c:2318 I don't think this has anything to do with your patch. I'll have to test it later after this ICE gets fixed.
> I don't think this has anything to do with your patch. Unfortunately it has (at least on i686-apple-darwin9). Reverting the patch for gcc/varasm.c I have bootstrapped without any problem and the good news it that the remaining patch fixes: FAIL: gcc.dg/darwin-weakimport-2.c scan-assembler weak_reference _foo and FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \\t]*[ \\t]_?j FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \\t]*[ \\t]_?foo FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \\t]*[ \\t]_?ffoo1a FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \\t]*[ \\t]_?ffoo1b FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \\t]*[ \\t]_?ffoo1c FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \\t]*[ \\t]_?ffoo1e FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \\t]*[ \\t]_?vfoo1a FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \\t]*[ \\t]_?vfoo1b FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \\t]*[ \\t]_?vfoo1c but not FAIL: gcc.dg/darwin-weakimport-1.c scan-assembler weak_reference _a
Note the patch in comment #12 minus the varasm.c part fixes also FAIL: g++.dg/ext/weak2.C scan-assembler weak[^ \\t]*[ \\t]_?_Z3foov All the results for 32-bit mode only, but I am pretty confident that they will hold with -m64.
Could one (or both) please attach preprocessed code and command line so I can reproduce the ICE you see with the *whole* patch applied? I don't see it for neither cris-elf nor native and I don't see where it comes from. Thanks in advance.
> Could one (or both) please attach preprocessed code and command line so I can > reproduce the ICE you see with the *whole* patch applied? I don't see it for > neither cris-elf nor native and I don't see where it comes from. My command line is: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w --mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info --build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib Concerning the "preprocessed code", although I assume that I'll have to (re)break the bootstrap, I have no more idea about how I can get it.
(In reply to comment #17) > Could one (or both) please attach preprocessed code and command line so I can > reproduce the ICE you see with the *whole* patch applied? I don't see it for > neither cris-elf nor native and I don't see where it comes from. > Thanks in advance. > Sure. I'll have it for you in a little while as it's still morning here...
(In reply to comment #18) > My command line is: > > ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w > --mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info > --build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java > --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib > --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib The *gcc* command line at the point of the ICE is the interesting one. Add -v -save-temps to get the preprocessed code and show the "internal" command line. > Concerning the "preprocessed code", although I assume that I'll have to > (re)break the bootstrap, I have no more idea about how I can get it. Yes. Then repeat manually the last gcc command, adding -v -save-temps. Just like always for gcc bug reports involving an ICE. Thanks.
Created attachment 16128 [details] Preprocessed source of ICE from building with patch.
ICE from building gcc target=avr with patch: Reading specs from /usr/local/avrdev/gcc/build/./gcc/specs Target: avr Configured with: ../gcc/configure --prefix=/usr/local/avr-test --target=avr --datadir=/usr/local/avr-test/doc/gcc --with-pkgversion='WinAVR test' --with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse' --with-dwarf2 --with-gmp=/usr/local --with-mpfr=/usr/local --enable-win32-registry=WinAVR-test --enable-languages=c --enable-doc --disable-nls --disable-shared --disable-libada --disable-libssp : (reconfigured) ../gcc/configure --prefix=/usr/local/avr-test --target=avr --datadir=/usr/local/avr-test/doc/gcc --with-pkgversion='WinAVR test' --with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse' --with-dwarf2 --with-gmp=/usr/local --with-mpfr=/usr/local --enable-win32-registry=WinAVR-test --enable-languages=c,c++,objc,ada --enable-doc --disable-nls --disable-shared --disable-libada --disable-libssp Thread model: single gcc version 4.4.0 20080822 (experimental) [trunk revision 139423] (WinAVR test) COLLECT_GCC_OPTIONS='-B/usr/local/avrdev/gcc/build/./gcc/' '-B/usr/local/avr-test/avr/bin/' '-B/usr/local/avr-test/avr/lib/' '-isystem' '/usr/local/avr-test/avr/include' '-isystem' '/usr/local/avr-test/avr/sys-include' '-g' '-D__USE_MINGW_ACCESS' '-mmcu=avr25' '-O2' '-g' '-D__USE_MINGW_ACCESS' '-DIN_GCC' '-DCROSS_DIRECTORY_STRUCTURE' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual' '-Wold-style-definition' '-isystem' './include' '-DDF=SF' '-Dinhibit_libc' '-mcall-prologues' '-Os' '-g' '-DIN_LIBGCC2' '-D__GCC_FLOAT_NOT_NEEDED' '-Dinhibit_libc' '-I.' '-I.' '-I../../.././gcc' '-I../../../../gcc/libgcc' '-I../../../../gcc/libgcc/.' '-I../../../../gcc/libgcc/../gcc' '-I../../../../gcc/libgcc/../include' '-DHAVE_CC_TLS' '-o' '_mulsc3.o' '-MT' '_mulsc3.o' '-MD' '-MP' '-MF' '_mulsc3.dep' '-DL_mulsc3' '-c' '-v' '-save-temps' /usr/local/avrdev/gcc/build/./gcc/cc1 -E -quiet -v -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -imultilib avr25 -iprefix /usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/ -isystem /usr/local/avrdev/gcc/build/./gcc/include -isystem /usr/local/avrdev/gcc/build/./gcc/include-fixed -MD _mulsc3.d -MF _mulsc3.dep -MP -MT _mulsc3.o -D__USE_MINGW_ACCESS -D__USE_MINGW_ACCESS -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DDF=SF -Dinhibit_libc -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DHAVE_CC_TLS -DL_mulsc3 -isystem /usr/local/avr-test/avr/include -isystem /usr/local/avr-test/avr/sys-include -isystem ./include ../../../../gcc/libgcc/../gcc/libgcc2.c -mmcu=avr25 -mcall-prologues -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -g -g -g -fworking-directory -O2 -Os -fpch-preprocess -o libgcc2.i ignoring nonexistent directory "/usr/local/avr-test/avr/sys-include" ignoring nonexistent directory "./include" ignoring nonexistent directory "/usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/include" ignoring nonexistent directory "/usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/include-fixed" ignoring nonexistent directory "/usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/../../../../avr/sys-include" ignoring nonexistent directory "/usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/../../../../avr/include" ignoring nonexistent directory "/usr/local/avrdev/gcc/build/gcc/../lib/gcc/../../lib/gcc/avr/4.4.0/include" ignoring nonexistent directory "/usr/local/avrdev/gcc/build/gcc/../lib/gcc/../../lib/gcc/avr/4.4.0/include-fixed" ignoring nonexistent directory "/usr/local/avrdev/gcc/build/gcc/../lib/gcc/../../lib/gcc/avr/4.4.0/../../../../avr/sys-include" ignoring nonexistent directory "/usr/local/avrdev/gcc/build/gcc/../lib/gcc/../../lib/gcc/avr/4.4.0/../../../../avr/include" ignoring duplicate directory "." ignoring duplicate directory "../../../../gcc/libgcc/." #include "..." search starts here: #include <...> search starts here: . ../../.././gcc ../../../../gcc/libgcc ../../../../gcc/libgcc/../gcc ../../../../gcc/libgcc/../include /usr/local/avrdev/gcc/build/./gcc/include /usr/local/avrdev/gcc/build/./gcc/include-fixed /usr/local/avr-test/avr/include End of search list. COLLECT_GCC_OPTIONS='-B/usr/local/avrdev/gcc/build/./gcc/' '-B/usr/local/avr-test/avr/bin/' '-B/usr/local/avr-test/avr/lib/' '-isystem' '/usr/local/avr-test/avr/include' '-isystem' '/usr/local/avr-test/avr/sys-include' '-g' '-D__USE_MINGW_ACCESS' '-mmcu=avr25' '-O2' '-g' '-D__USE_MINGW_ACCESS' '-DIN_GCC' '-DCROSS_DIRECTORY_STRUCTURE' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual' '-Wold-style-definition' '-isystem' './include' '-DDF=SF' '-Dinhibit_libc' '-mcall-prologues' '-Os' '-g' '-DIN_LIBGCC2' '-D__GCC_FLOAT_NOT_NEEDED' '-Dinhibit_libc' '-I.' '-I.' '-I../../.././gcc' '-I../../../../gcc/libgcc' '-I../../../../gcc/libgcc/.' '-I../../../../gcc/libgcc/../gcc' '-I../../../../gcc/libgcc/../include' '-DHAVE_CC_TLS' '-o' '_mulsc3.o' '-MT' '_mulsc3.o' '-MD' '-MP' '-MF' '_mulsc3.dep' '-DL_mulsc3' '-c' '-v' '-save-temps' /usr/local/avrdev/gcc/build/./gcc/cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mmcu=avr25 -mcall-prologues -auxbase-strip _mulsc3.o -g -g -g -O2 -Os -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -version -o libgcc2.s GNU C (WinAVR test) version 4.4.0 20080822 (experimental) [trunk revision 139423] (avr) compiled by GNU C version 4.3.1 20080801 (Red Hat 4.3.1-6), GMP version 4.2.1, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 3c07b34f3fe1bd9cb7289161710162bb ../../../../gcc/libgcc/../gcc/libgcc2.c: In function '__mulsc3': ../../../../gcc/libgcc/../gcc/libgcc2.c:1831: internal compiler error: tree check: expected tree that contains 'decl with visibility' structure, have 'result_decl' in assemble_external, at varasm.c:2318 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse> for instructions.
Here is the command line and its result from directory /opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libgcc: [ibook-dhum] x86_64/libgcc% /opt/gcc/i686-darwin/./gcc/xgcc -v -save-temps -B/opt/gcc/i686-darwin/./gcc/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -g -O2 -m64 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I../../../../gcc-4.4-work/libgcc -I../../../../gcc-4.4-work/libgcc/. -I../../../../gcc-4.4-work/libgcc/../gcc -I../../../../gcc-4.4-work/libgcc/../include -DHAVE_CC_TLS -o _mulxc3.o -MT _mulxc3.o -MD -MP -MF _mulxc3.dep -DL_mulxc3 -c ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS xgcc: warning: -pipe ignored because -save-temps specified Reading specs from /opt/gcc/i686-darwin/./gcc/specs Target: i686-apple-darwin9 Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w --mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info --build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib Thread model: posix gcc version 4.4.0 [revision 139455p5] 20080822 (experimental) (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.4' '-v' '-save-temps' '-B/opt/gcc/i686-darwin/./gcc/' '-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/' '-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/' '-isystem' '/opt/gcc/gcc4.4w/i686-apple-darwin9/include' '-isystem' '/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include' '-g' '-O2' '-m64' '-O2' '-g' '-O2' '-DIN_GCC' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual' '-Wold-style-definition' '-isystem' './include' '-fPIC' '-pipe' '-g' '-DHAVE_GTHR_DEFAULT' '-DIN_LIBGCC2' '-D__GCC_FLOAT_NOT_NEEDED' '-I.' '-I.' '-I../../.././gcc' '-I../../../../gcc-4.4-work/libgcc' '-I../../../../gcc-4.4-work/libgcc/.' '-I../../../../gcc-4.4-work/libgcc/../gcc' '-I../../../../gcc-4.4-work/libgcc/../include' '-DHAVE_CC_TLS' '-o' '_mulxc3.o' '-MT' '_mulxc3.o' '-MD' '-MP' '-MF' '_mulxc3.dep' '-DL_mulxc3' '-c' '-fvisibility=hidden' '-DHIDE_EXPORTS' '-mtune=generic' /opt/gcc/i686-darwin/./gcc/cc1 -E -quiet -v -I. -I. -I../../.././gcc -I../../../../gcc-4.4-work/libgcc -I../../../../gcc-4.4-work/libgcc/. -I../../../../gcc-4.4-work/libgcc/../gcc -I../../../../gcc-4.4-work/libgcc/../include -imultilib x86_64 -iprefix /opt/gcc/i686-darwin/gcc/../lib/gcc/i686-apple-darwin9/4.4.0/ -isystem /opt/gcc/i686-darwin/./gcc/include -isystem /opt/gcc/i686-darwin/./gcc/include-fixed -MD _mulxc3.d -MF _mulxc3.dep -MP -MT _mulxc3.o -D__DYNAMIC__ -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_CC_TLS -DL_mulxc3 -DHIDE_EXPORTS -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -isystem ./include ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c -fPIC -feliminate-unused-debug-symbols -mmacosx-version-min=10.5.4 -m64 -mtune=generic -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -fPIC -fvisibility=hidden -g -g -g -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory "/opt/gcc/gcc4.4w/i686-apple-darwin9/include" ignoring nonexistent directory "/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include" ignoring nonexistent directory "./include" ignoring nonexistent directory "/opt/gcc/i686-darwin/gcc/../lib/gcc/i686-apple-darwin9/4.4.0/include" ignoring nonexistent directory "/opt/gcc/i686-darwin/gcc/../lib/gcc/i686-apple-darwin9/4.4.0/include-fixed" ignoring nonexistent directory "/opt/gcc/i686-darwin/gcc/../lib/gcc/i686-apple-darwin9/4.4.0/../../../../i686-apple-darwin9/include" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/opt/gcc/i686-darwin/gcc/../lib/gcc/../../include" ignoring nonexistent directory "/opt/gcc/i686-darwin/gcc/../lib/gcc/../../lib/gcc/i686-apple-darwin9/4.4.0/include" ignoring nonexistent directory "/opt/gcc/i686-darwin/gcc/../lib/gcc/../../lib/gcc/i686-apple-darwin9/4.4.0/include-fixed" ignoring nonexistent directory "/opt/gcc/i686-darwin/gcc/../lib/gcc/../../lib/gcc/i686-apple-darwin9/4.4.0/../../../../i686-apple-darwin9/include" ignoring duplicate directory "." ignoring duplicate directory "../../../../gcc-4.4-work/libgcc/." #include "..." search starts here: #include <...> search starts here: . ../../.././gcc ../../../../gcc-4.4-work/libgcc ../../../../gcc-4.4-work/libgcc/../gcc ../../../../gcc-4.4-work/libgcc/../include /opt/gcc/i686-darwin/./gcc/include /opt/gcc/i686-darwin/./gcc/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.4' '-v' '-save-temps' '-B/opt/gcc/i686-darwin/./gcc/' '-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/' '-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/' '-isystem' '/opt/gcc/gcc4.4w/i686-apple-darwin9/include' '-isystem' '/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include' '-g' '-O2' '-m64' '-O2' '-g' '-O2' '-DIN_GCC' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual' '-Wold-style-definition' '-isystem' './include' '-fPIC' '-pipe' '-g' '-DHAVE_GTHR_DEFAULT' '-DIN_LIBGCC2' '-D__GCC_FLOAT_NOT_NEEDED' '-I.' '-I.' '-I../../.././gcc' '-I../../../../gcc-4.4-work/libgcc' '-I../../../../gcc-4.4-work/libgcc/.' '-I../../../../gcc-4.4-work/libgcc/../gcc' '-I../../../../gcc-4.4-work/libgcc/../include' '-DHAVE_CC_TLS' '-o' '_mulxc3.o' '-MT' '_mulxc3.o' '-MD' '-MP' '-MF' '_mulxc3.dep' '-DL_mulxc3' '-c' '-fvisibility=hidden' '-DHIDE_EXPORTS' '-mtune=generic' /opt/gcc/i686-darwin/./gcc/cc1 -fpreprocessed libgcc2.i -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase libgcc2.c -mmacosx-version-min=10.5.4 -m64 -mtune=generic -auxbase-strip _mulxc3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -version -fPIC -fvisibility=hidden -o libgcc2.s GNU C (GCC) version 4.4.0 [revision 139455p5] 20080822 (experimental) (i686-apple-darwin9) compiled by GNU C version 4.0.1 (Apple Inc. build 5465), GMP version 4.2.3, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 25abad1404d851b8e278eaadfbd54285 ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c: In function '__mulxc3': ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c:1831: internal compiler error: tree check: expected tree that contains 'decl with visibility' structure, have 'result_decl' in assemble_external, at varasm.c:2322 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. I'll attach libgcc2.i.
Created attachment 16129 [details] libggc2.i for i686-apple-darwin9
Created attachment 16130 [details] Patch, take 3. Thanks for your reports! I stupidly forgot to move out the tree type checks from inside the #ifdef and just couldn't see it! Odd that the weak-test-cases didn't trig this. Now fixed. Lightly checked that it still fixes the C regressions covered by weak.exp for avr and darwin-i686, new regression runs started for cris-elf and native. Please, test on your targets!
Bootstrap fails at [ibook-dhum] x86_64/libjava% /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc -B/opt/gcc/i686-darwin/./gcc -nostdinc++ -L/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src -L/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../gcc-4.4-work/libjava -I./include -I./gcj -I../../../../gcc-4.4-work/libjava -Iinclude -I../../../../gcc-4.4-work/libjava/include -I../../../../gcc-4.4-work/libjava/classpath/include -Iclasspath/include -I../../../../gcc-4.4-work/libjava/classpath/native/fdlibm -I../../../../gcc-4.4-work/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../../gcc-4.4-work/libjava/libltdl -I../../../../gcc-4.4-work/libjava/libltdl -I../../../../gcc-4.4-work/libjava/.././libjava/../gcc -I../../../../gcc-4.4-work/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/opt/gcc/gcc4.4w\" -DTOOLEXECLIBDIR=\"/opt/gcc/gcc4.4w/lib/x86_64\" -DJAVA_HOME=\"/opt/gcc/gcc4.4w\" -DBOOT_CLASS_PATH=\"/opt/gcc/gcc4.4w/share/java/libgcj-4.4.0.jar\" -DJAVA_EXT_DIRS=\"/opt/gcc/gcc4.4w/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/opt/gcc/gcc4.4w/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/opt/gcc/gcc4.4w/lib/x86_64/gcj-4.4.0-10\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"/opt/gcc/gcc4.4w/share/java/ecj.jar\" -DLIBGCJ_DEFAULT_DATABASE=\"/opt/gcc/gcc4.4w/lib/x86_64/gcj-4.4.0-10/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.4.0-10/classmap.db\" -g -O2 -m64 -MT prims.lo -MD -MP -MF .deps/prims.Tpo -c ../../../../gcc-4.4-work/libjava/prims.cc -fno-common -DPIC /var/tmp//cctr5h82.s:unknown:Undefined symbol: __Z19_Jv_AllocPtrFreeObjiPN4java4lang5ClassE can't be a weak_definition /var/tmp//cctr5h82.s:unknown:Undefined symbol: __Z12_Jv_AllocObjiPN4java4lang5ClassE can't be a weak_definition
(In reply to comment #26) > Bootstrap fails at Gosh darn. Please attach preprocessed code and I'll try to figure out what's going on...
Well, a bit of good news: patch #3 fixes all test case regressions regarding "weak" for the AVR.
(In reply to comment #28) > Well, a bit of good news: patch #3 fixes all test case regressions regarding > "weak" for the AVR. Thanks for testing! Hopefully I can get that preprocessed code soon and with a bit of luck the bug would be in the darwin-specific changes.
Created attachment 16132 [details] preprocessed source prims.ii
/Volumes/development/gcc/head/objdir-x86_64/./gcc/cc1plus -fpreprocessed prims.ii -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase prims.cc -mmacosx-version-min=10.5.4 -mtune=generic -auxbase-strip .libs/prims.o -g -O2 -Wswitch-enum -Wextra -Wall -version -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -fomit-frame-pointer -fno-common -o prims.s GNU C++ (GCC) version 4.4.0 20080822 (experimental) [trunk revision 139497] (x86_64-apple-darwin9) compiled by GNU C version 4.4.0 20080822 (experimental) [trunk revision 139497], GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: d33cfb8d3b429a09faa5a0175497a6bb COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.4' '-shared-libgcc' '-B/Volumes/development/gcc/head/objdir-x86_64/./gcc' '-nostdinc++' '-L/Volumes/development/gcc/head/objdir-x86_64/x86_64-apple-darwin9/libstdc++-v3/src' '-L/Volumes/development/gcc/head/objdir-x86_64/x86_64-apple-darwin9/libstdc++-v3/src/.libs' '-B/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/bin/' '-B/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/lib/' '-isystem' '/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/include' '-isystem' '/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/sys-include' '-DHAVE_CONFIG_H' '-I.' '-I/Volumes/development/gcc/head/gcc/libjava' '-I./include' '-I./gcj' '-I/Volumes/development/gcc/head/gcc/libjava' '-Iinclude' '-I/Volumes/development/gcc/head/gcc/libjava/include' '-I/Volumes/development/gcc/head/gcc/libjava/classpath/include' '-Iclasspath/include' '-I/Volumes/development/gcc/head/gcc/libjava/classpath/native/fdlibm' '-I/Volumes/development/gcc/head/gcc/libjava/../boehm-gc/include' '-I../boehm-gc/include' '-I/Volumes/development/gcc/head/gcc/libjava/libltdl' '-I/Volumes/development/gcc/head/gcc/libjava/libltdl' '-I/Volumes/development/gcc/head/gcc/libjava/.././libjava/../gcc' '-I/Volumes/development/gcc/head/gcc/libjava/../zlib' '-I/Volumes/development/gcc/head/gcc/libjava/../libffi/include' '-I../libffi/include' '-fno-rtti' '-fnon-call-exceptions' '-fdollars-in-identifiers' '-Wswitch-enum' '-D_FILE_OFFSET_BITS=64' '-fomit-frame-pointer' '-Wextra' '-Wall' '-D_GNU_SOURCE' '-DPREFIX="/Volumes/development/gcc/head/testbin-x86_64"' '-DTOOLEXECLIBDIR="/Volumes/development/gcc/head/testbin-x86_64/lib"' '-DJAVA_HOME="/Volumes/development/gcc/head/testbin-x86_64"' '-DBOOT_CLASS_PATH="/Volumes/development/gcc/head/testbin-x86_64/share/java/libgcj-4.4.0.jar"' '-DJAVA_EXT_DIRS="/Volumes/development/gcc/head/testbin-x86_64/share/java/ext"' '-DGCJ_ENDORSED_DIRS="/Volumes/development/gcc/head/testbin-x86_64/share/java/gcj-endorsed"' '-DGCJ_VERSIONED_LIBDIR="/Volumes/development/gcc/head/testbin-x86_64/lib/gcj-4.4.0-10"' '-DPATH_SEPARATOR=":"' '-DECJ_JAR_FILE="/Volumes/development/gcc/head/testbin-x86_64/share/java/ecj.jar"' '-DLIBGCJ_DEFAULT_DATABASE="/Volumes/development/gcc/head/testbin-x86_64/lib/gcj-4.4.0-10/classmap.db"' '-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="gcj-4.4.0-10/classmap.db"' '-g' '-O2' '-MT' 'prims.lo' '-MD' '-MP' '-MF' '.deps/prims.Tpo' '-c' '-fno-common' '-DPIC' '-v' '-save-temps' '-o' '.libs/prims.o' '-mtune=generic' /Volumes/development/gcc/head/objdir-x86_64/./gcc/as -arch x86_64 -force_cpusubtype_ALL -o .libs/prims.o prims.s prims.s:unknown:Undefined symbol: __Z19_Jv_AllocPtrFreeObjiPN4java4lang5ClassE can't be a weak_definition prims.s:unknown:Undefined symbol: __Z12_Jv_AllocObjiPN4java4lang5ClassE can't be a weak_definition
Thanks, I got everything I need. The problem seen for the Darwin bootstrap is caused not by the output_operand call to assemble_external, but by another call, in cp/decl2.c:mark_used. Plainly treating that (as now) the same as the assemble_external call from output_operand, causes lots of actually not used (perhaps inlined, but not referenced) functions to be marked as weak. You can see this diffing e.g. prims.s for unpatched 139232 and 139233 for x86_64-linux but you don't see it for unpatched darwin because of the assemble_external call being masked by the #ifdef. For GNU/Linux, having random .weak annotations for unreferenced and undefined symbols apparently has no visible effect. The reason that the Darwin assembler complains when it sees some of these, is that they're coupled with annotations specifically for weak *definitions* for one reason or another (without a matching symbol definition), while with more common targets the weak annotations for references and definitions look the same, the absence/presence of the actual definition defines what weakness type it is. I'm not sure why there are assemble_external calls all over and from language front-ends; there should be only one in output_operand (for code) and one where data is output. Come to think of it, they shouldn't be there either, but in expand, so we don't have to play target-specific tricks. Not sure whether that change would fit in this PR, or if I should go with just remove or gate the bogus and redundant assemble_external calls. Bah, I guess I should just have asked for revert of 139233; that and related earlier changes obviously weren't fit for trunk. Ok, one more try.
> All the results for 32-bit mode only, but I am pretty confident that they will > hold with -m64. This is wrong: the tests pass in 32-bit mode, but fail with -m64.
[ibook-dhum] f90/bug% gfc -m64 -S -fno-common /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/weak/weak-2.c [ibook-dhum] f90/bug% grep ffoo1a weak-2.s movq _ffoo1a@GOTPCREL(%rip), %rax
Created attachment 16139 [details] Testcase exposing the (on darwin) breaking aspect of prims.ii See comments in the test-case. The test-case breaks for all targets with ASM_OUTPUT_EXTERNAL (e.g. x86_64-linux) with r139233, but e.g. not for unpatched darwin.
Created attachment 16140 [details] Weak testing weak: testing weak stronger. I was missing tests that referenced a weak address, but offset, and the address of a weak variable, but from data, not code. Also is something of an attempt to verify that the prims.ii situation doesn't happen in C.
Created attachment 16141 [details] Patch, take 4. Fourth time's a charm. The difference is just strengthening the early-return in assemble_external so inlined functions (or any actually defined functions) aren't handled as externs. Tests started on native x86_64-linux and cris-elf. Please, test on darwin and avr.
With the patch in comment #37 I bootstraped Using built-in specs. Target: i686-apple-darwin9 Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w --mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info --build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib Thread model: posix gcc version 4.4.0 [revision 139556p5] 20080825 (experimental) (GCC) Regtesting started.
More good news, the weak gcc tests pass now for 32 and 64 bit modes. Also bad news, I have extra failures in the g++ tests (32-bit mode so far), e.g.: [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.mike/offset1.C /var/tmp//ccLGtbMk.s:unknown:Undefined symbol: __ZTV4Barf can't be a weak_definition
Here is the list of new g++ failures (32 and 64 bit modes, except g++.dg/abi/empty7.C): FAIL: g++.dg/abi/empty7.C (test for excess errors) <--- 32-bit mode only FAIL: g++.dg/abi/layout2.C (test for excess errors) FAIL: g++.dg/abi/vbase12.C (test for excess errors) FAIL: g++.dg/inherit/thunk7.C (test for excess errors) FAIL: g++.old-deja/g++.brendan/misc11.C (test for excess errors) FAIL: g++.old-deja/g++.mike/offset1.C (test for excess errors) FAIL: g++.old-deja/g++.mike/virt2.C (test for excess errors) FAIL: g++.old-deja/g++.other/rtti4.C (test for excess errors) FAIL: g++.old-deja/g++.other/rttid4.C (test for excess errors) FAIL: g++.old-deja/g++.other/virtual9.C (test for excess errors) FAIL: g++.old-deja/g++.robertl/eh990323-2.C (test for excess errors) FAIL: g++.old-deja/g++.robertl/eh990323-4.C (test for excess errors) It looks like a missing test for some "virtual".
(In reply to comment #37) > Created an attachment (id=16141) [edit] > Patch, take 4. <snip> > Please, test on darwin and avr. Testing started on avr.
(In reply to comment #41) > (In reply to comment #37) > > Created an attachment (id=16141) [edit] > > Patch, take 4. > <snip> > > Please, test on darwin and avr. > > Testing started on avr. > Patch #4 still fixes all "weak" test regressions on avr.
> Patch #4 still fixes all "weak" test regressions on avr. Did you test g++?
(In reply to comment #43) > > Patch #4 still fixes all "weak" test regressions on avr. > > Did you test g++? > Yes. I build and test for c, c++, ada, and objc (yes, it actually builds for AVR). I have 2 less fails now on c++ than I did on 2008-08-21 (revision 139385), but that could be due to almost anything. I don't pay attention much to c++ test results for avr, mainly because there are 1064 failures and I don't have very many users of c++ on avr.
> I have 2 less fails now on c++ On Darwin there is one test which now passes: g++.dg/ext/weak2.C scan-assembler weak[^ \\t]*[ \\t]_?_Z3foov but several new failures (comment #40).
(In reply to comment #39) > More good news, the weak gcc tests pass now for 32 and 64 bit modes. > > Also bad news, I have extra failures in the g++ tests (32-bit mode so far), > /var/tmp//ccLGtbMk.s:unknown:Undefined symbol: __ZTV4Barf can't be a Hm, looks like the equivalent of the inlined-function test is needed, but for data. To help shorten the number of iterations, can you please verify that the failures all look as above in the .log files? For the record, the main reasons avr results are so different to darwin can be seen in my earlier comments. To wit: 1) very different symbol handling in the target (where avr is mainstream, I think) 2) annotation for weak references are different to weak definitions on darwin, with stricter checking in the assembler. The reason avr was getting different failures is that it, unlike most ELF targets, does not define ASM_OUTPUT_EXTERN, which most other ELF targets get by including the "general" config/elfos.h. This "missing include" is possibly by itself a buglet. On the other hand, elfos.h contains lots of arbitrary crud, like the weird and target-specific reason for defining ASM_OUTPUT_EXTERN! Really, elfos.h should be called svr4.h, but that name's already taken... I'll get started on a new patch...
> To help shorten the number of iterations, can you please verify that the > failures all look as above in the .log files? You have to realize that I am C* illiterate. So I need more precise directives. For instance, do ... class Barf : virtual public Bar { public: virtual void init(int argc, char **argv) { Bar::init(argc, argv); } }; ... [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.mike/offset1.C/var/tmp//ccIY8j6p.s:unknown:Undefined symbol: __ZTV4Barf can't be a weak_definition and ... struct B : virtual A { virtual int f() { return 1; } virtual int g() = 0; }; ... [ibook-dhum] f90/bug% g++44 -c /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.brendan/misc11.C /var/tmp//cccB5iE4.s:unknown:Undefined symbol: __ZTV1B can't be a weak_definition look the same? My answer is "yes", but in the first case the symbol is a class and in the second one a struct(ure?), so the "yes" may be a mistake.
I get: [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/abi/empty7.C /var/tmp//ccCa6HmC.s:unknown:Undefined symbol: __ZTV2S3 can't be a weak_definition /var/tmp//ccCa6HmC.s:unknown:Undefined symbol: __ZTV2S4 can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/abi/layout2.C /var/tmp//cc6U13JE.s:unknown:Undefined symbol: __ZTV1D can't be a weak_definition /var/tmp//cc6U13JE.s:unknown:Undefined symbol: __ZTV1B can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/abi/vbase12.C /var/tmp//ccTo47cP.s:unknown:Undefined symbol: __ZTV1C can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/inherit/thunk7.C /var/tmp//cckYOBdw.s:unknown:Undefined symbol: __ZTV1D can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.brendan/misc11.C /var/tmp//cc6Kf47c.s:unknown:Undefined symbol: __ZTV1B can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.mike/offset1.C /var/tmp//cc98DFie.s:unknown:Undefined symbol: __ZTV4Barf can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.mike/virt2.C /var/tmp//ccZeI4BH.s:unknown:Undefined symbol: __ZTV2S1 can't be a weak_definition /var/tmp//ccZeI4BH.s:unknown:Undefined symbol: __ZTV2S2 can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/rtti4.C /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/rtti4.C:49: warning: direct base 'B' inaccessible in 'E' due to ambiguity /var/tmp//ccphb9BU.s:unknown:Undefined symbol: __ZTV1E can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/rttid4.C /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/rttid4.C:50: warning: direct base 'B' inaccessible in 'E' due to ambiguity /var/tmp//ccWsGUAt.s:unknown:Undefined symbol: __ZTV1E can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/virtual9.C /var/tmp//ccjNVoz2.s:unknown:Undefined symbol: __ZTV1C can't be a weak_definition /var/tmp//ccjNVoz2.s:unknown:Undefined symbol: __ZTV1B can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.robertl/eh990323-2.C /var/tmp//cc6nnIz5.s:unknown:Undefined symbol: __ZTV1B can't be a weak_definition [ibook-dhum] f90/bug% g++44 /opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.robertl/eh990323-4.C /var/tmp//ccau8OGJ.s:unknown:Undefined symbol: __ZTV1B can't be a weak_definition
(In reply to comment #48) > I get: (many "X.s:unknown:Undefined symbol: Y can't be a weak_definition" elided) Yes, those look sufficiently similar. (No C or C++ knowledge required. :) Good to know that it's probably just "that" bug. I have what I need. Thanks.
I think the C++ failures are related to PR 37167.
(In reply to comment #50) > I think the C++ failures are related to PR 37167. Depends on how you define "related". Maybe the patch for this bug will include the fix for it (see proposed varasm.c:assemble_external changes), but not the other way round.
While we are at the "weak" arcanes on Darwin, we have also the following since at least revision 136913 (revision 136903 seems the most likely candidate, the others being 136899, 136905, and 136912): FAIL: g++.dg/abi/key2.C scan-assembler .globl __ZTI1f\\\\n\\t.weak_definition __ZTI1f\\\\n\\t.section __DATA,__const_coal,coalesced The corresponding part of the assembly code reads: 42 - .long __ZN1f1hEv 43 - .globl __ZTI1f 44 : .weak_definition __ZTI1f 45 + .align 2 46 + __ZTI1f: If one can shot two birds with one stone, this will be nice. Otherwise I'll fill another PR.
(In reply to comment #52) > While we are at the "weak" arcanes on Darwin, we have also the following since > at least revision 136913 (revision 136903 seems the most likely candidate, the > others being 136899, 136905, and 136912): That's not nearly around the window for the revisions for the behavior in the description of this PR. FeaPR-creep is strictly frowned upon: open a new PR.
Created attachment 16146 [details] Patch, take 5. Removing the "TREE_CODE (decl) == FUNCTION_DECL && ..." part helped to elide the bogus weak declarations for vtables that had been taken care of locally. Doh. :) On Darwin, there were also some spurious .weak_reference X emitted for locally-defined X. Fixed by gating that output as in assemble_external. Trivially tested with the test-cases that have appeared here. Test runs started for native x86_64-linux and cross to cris-elf. I'd be thankful for your testing.
> FeaPR-creep is strictly frowned upon: open a new PR. This now pr37241. With the patch in comment #54 all the failures reported in comment #40 are gone without regressions (currently regtesting gfortran). Thanks for the patch(es). Just in case, I am bootstraping gcc on ppc darwin9 with the patch. It should finish tonight (GMT+2) and regtesting results available tomorrow morning. I'll report any problem.
(In reply to comment #55) > Just in case, I am bootstraping gcc on ppc darwin9 with the patch. It should > finish tonight (GMT+2) and regtesting results available tomorrow morning. I'll > report any problem. Thanks. Any news on the ppc-darwin and i686-darwin test results? (FWIW, my results were clean, but that was expected as they'd been for earlier revisions too.)
>> I'll report any problem. > > Thanks. Any news on the ppc-darwin and i686-darwin test results? I meant: no news == good news == nothing to report, but success on both platforms!-)
(In reply to comment #57) > I meant: no news == good news == nothing to report, but success on both > platforms!-) Thanks for telling and for testing. (Really, I try to avoid interpreting lack of information as other than possibly communications failure, and I don't think I'm wrong. So many other things can and will happen.) I'll post the patch, finally.
Patch at <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02037.html>.
(In reply to comment #59) > Patch at <http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02037.html>. > Patch still works on AVR.
Created attachment 16165 [details] preprocessed source from hppa2.0w-hp-hpux11.11
Looks like the HPPA port, like Darwin, transforms the original symbol_refs upon seeing them, such that output_operand doesn't see all required,
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c > Looks like the HPPA port, like Darwin, transforms the original symbol_refs upon > seeing them, such that output_operand doesn't see all required, If the encoding for function names is getting stripped, then ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly. Dave
(In reply to comment #63) > If the encoding for function names is getting stripped, then > ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly. Not sure what you meant by that comment; that's not what happens here AFAICT. I stated that output_operand does not see the same symbol_ref as was passed to the rtl insn expander, so target-specific code is needed just like for Darwin - or maybe it's just missing in generic code, for the constant pool.
If the extern references had been "sort -u":ed, they'd had looked like this, diff from unpatched to patched for the attachment in comment #61, compiled with -O2: --- ../../../comboo/hppa2/gcc/hppa2.s 2008-08-29 22:32:02.000000000 +0200 +++ ./hppa2.s 2008-08-29 22:31:38.000000000 +0200 @@ -6664,13 +6664,7 @@ L$ASFDE0143: .align 4 L$EFDE0143: .word 0x0 - .IMPORT _ZNSdD0Ev,CODE - .IMPORT _ZNSdD1Ev,CODE .IMPORT _ZNSdD2Ev,CODE - .IMPORT _ZNSiD0Ev,CODE - .IMPORT _ZNSiD1Ev,CODE - .IMPORT _ZNSoD0Ev,CODE - .IMPORT _ZNSoD1Ev,CODE .IMPORT _ZNSt15basic_streambufIcSt11char_traitsIcEE4syncEv,CODE .IMPORT _ZNSt15basic_streambufIcSt11char_traitsIcEE5imbueERKSt6locale,CODE .IMPORT _ZNSt15basic_streambufIcSt11char_traitsIcEE5uflowEv,CODE @@ -6684,13 +6678,6 @@ L$EFDE0143: .IMPORT _ZNSt8ios_baseD2Ev,CODE .IMPORT _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E,CODE .IMPORT _ZNSt9basic_iosIcSt11char_traitsIcEED2Ev,CODE - .IMPORT _ZTISd,DATA - .IMPORT _ZTISi,DATA - .IMPORT _ZTISo,DATA - .IMPORT _ZTISt15basic_streambufIcSt11char_traitsIcEE,DATA - .IMPORT _ZTVN10__cxxabiv120__si_class_type_infoE,DATA - .IMPORT _ZTVSt15basic_streambufIcSt11char_traitsIcEE,DATA - .IMPORT _ZTVSt9basic_iosIcSt11char_traitsIcEE,DATA .IMPORT _ZThn8_NSdD0Ev,CODE .IMPORT _ZThn8_NSdD1Ev,CODE .IMPORT _ZTv0_n12_NSdD0Ev,CODE
(In reply to comment #61) > Created an attachment (id=16165) [edit] > preprocessed source from hppa2.0w-hp-hpux11.11 Could you please dig out the cc1plus options too, so I'm not missing the original case?
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c > If the extern references had been "sort -u":ed, they'd had looked like this, > diff from unpatched to patched for the attachment in comment #61, compiled with > -O2: > > --- ../../../comboo/hppa2/gcc/hppa2.s 2008-08-29 22:32:02.000000000 +0200 > +++ ./hppa2.s 2008-08-29 22:31:38.000000000 +0200 > @@ -6664,13 +6664,7 @@ L$ASFDE0143: > .align 4 > L$EFDE0143: > .word 0x0 > - .IMPORT _ZNSdD0Ev,CODE > - .IMPORT _ZNSdD1Ev,CODE > .IMPORT _ZNSdD2Ev,CODE > - .IMPORT _ZNSiD0Ev,CODE > - .IMPORT _ZNSiD1Ev,CODE > - .IMPORT _ZNSoD0Ev,CODE > - .IMPORT _ZNSoD1Ev,CODE If any of these functions is present in the .s, then there's a problem. The default for a 32-bit HP-UX symbol that isn't imported is DATA. Dave
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c > > If the encoding for function names is getting stripped, then > > ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly. > > Not sure what you meant by that comment; that's not what happens here AFAICT. > I stated that output_operand does not see the same symbol_ref as was passed to > the rtl insn expander, so target-specific code is needed just like for Darwin > - or maybe it's just missing in generic code, for the constant pool. I believe that the only special aspect of symbol_ref processing on the 32-bit hppa port is the symbol name encoding. There's also some flag bits. Other than that, it's not clear why output_operand would see something different from what was passed to the rtl insn expander. There's nothing new in the hppa backend wrt symbol references. Besides the .import issue, function pointers have to point to a function descriptor (not the real code). This is done using a plabel which is a relocation which tells the linker to create a pointer to a function descriptor. This happens automatically if the output for the function pointer output uses assembler_integer (assuming the name encoding is correct). Because the output of .import directives is a two stage process, there might be an issue if a symbol_ref was garbage collected after the assemble_external call. Dave
(In reply to comment #64) > Not sure what you meant by that comment; that's not what happens here AFAICT. > I stated that output_operand does not see the same symbol_ref as was passed to > the rtl insn expander, so target-specific code is needed just like for Darwin > - or maybe it's just missing in generic code, for the constant pool. No, that's not it. The TREE_STATIC test is wrong. I should merge extern and (extern) weak handling somehow.
(In reply to comment #67) > > - .IMPORT _ZNSoD1Ev,CODE > > If any of these functions is present in the .s, then there's a problem. > The default for a 32-bit HP-UX symbol that isn't imported is DATA. The problem here, is just that the .IMPORT lines are gone.
Created attachment 16169 [details] Patch, take 6. Sigh. This just moves the TREE_STATIC check from the early-return to the weak-test, since it's wrong for *some* external declarations. It shouldn't matter for Darwin (which doesn't define ASM_OUTPUT_EXTERNAL, right?) but will fix the test-case for hppa2.0w-hp-hpux11.11, which BTW seems not to support weak. Test in progress, native and cris-elf as before. I'm thankful as always for any testing, this time particularly on hppa-hpux targets.
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c > It shouldn't matter for Darwin (which doesn't define ASM_OUTPUT_EXTERNAL, > right?) but will fix the test-case for hppa2.0w-hp-hpux11.11, which BTW seems > not to support weak. SUPPORTS_WEAK is defined on hppa2.0w-hp-hpux11.11 depending on GAS support. See som.h. Dave
(In reply to comment #72) > SUPPORTS_WEAK is defined on hppa2.0w-hp-hpux11.11 depending on GAS > support. See som.h. Good to know. It can't be compiled cross out of the box though, and the default is off: /bin/sh ./libtool --tag=CC --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -o size \ size.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a -lz libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -o size size.o bucomm.o version.o f\ ilemode.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz ../bfd/.libs/libbfd.a(targets.o):(.data+0x10): undefined reference to `som_vec' ../bfd/.libs/libbfd.a(targets.o):(.rodata+0x20): undefined reference to `som_vec' collect2: ld returned 1 exit status make[5]: *** [size] Error 1 make[5]: Leaving directory `/home/hp/combq/hppa2-obj/binutils'
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c > ------- Comment #71 from hp at gcc dot gnu dot org 2008-08-30 06:27 ------- > Created an attachment (id=16169) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16169&action=view) > Patch, take 6. This one is a significant improvement. In the C testsuite, I'm seeing a few failures like this one: Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_global_array.c -O3 -fwhole- program -combine -fipa-type-escape -fprofile-generate -lm -o /test/gnu/gcc/ob jdir/gcc/testsuite/gcc/w_prof_global_array.x01 (timeout = 300) /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__FI_w_prof_global_array_x01 (first referenced in +init option) (code) _GLOBAL__FD_w_prof_global_array_x01 (first referenced in +fini option) (code) collect2: ld returned 1 exit status and in the C++ suite, Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/ gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja /g++.other/static14.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/ libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hp ux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/ gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/tests uite/util -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -L/test/ gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/gnu/gcc/o bjdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa 2.0w-hp-hpux11.11/./libiberty -lm -o static14.exe (timeout = 300) /usr/ccs/bin/ld: Unsatisfied symbols: basic_string::~basic_string() (first referenced in /var/tmp//ccI3Feaf.o) (code) Side::name()::sname (first referenced in /var/tmp//ccI3Feaf.o) (data) collect2: ld returned 1 exit status compiler exited with status 1 and Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/ gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja /g++.other/static20.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/ libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hp ux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/ gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/tests uite/util -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -L/test/ gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/gnu/gcc/o bjdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa 2.0w-hp-hpux11.11/./libiberty -lm -o static20.exe (timeout = 300) /usr/ccs/bin/ld: Unsatisfied symbols: foo::func()::x (first referenced in /var/tmp//ccG3jpCC.o) (data) collect2: ld returned 1 exit status Sorry, this is so hard. Dave
(In reply to comment #74) > > Patch, take 6. > > This one is a significant improvement. In the C testsuite, I'm > seeing a few failures like this one: > > Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ > /te > st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_global_array.c -O3 > -fwhole- > program -combine -fipa-type-escape -fprofile-generate -lm -o > /test/gnu/gcc/ob > jdir/gcc/testsuite/gcc/w_prof_global_array.x01 (timeout = 300) > /usr/ccs/bin/ld: Unsatisfied symbols: > _GLOBAL__FI_w_prof_global_array_x01 (first referenced in +init option) > (code) > _GLOBAL__FD_w_prof_global_array_x01 (first referenced in +fini option) > (code) > collect2: ld returned 1 exit status Is this really a regression? What unpatched revision did you use as a baseline? When I compile that testcase, edited because of the stdlib include as follows: --- w_prof_global_array.c 2008-01-03 16:12:42.000000000 +0100 +++ /home/hp/wp.c 2008-08-31 21:09:44.000000000 +0200 @@ -1,4 +1,4 @@ -#include <stdlib.h> +extern void abort(void); typedef struct { int a; I don't see a difference unpatched/patched at revision 139233 in the generated assembly code, compiling with: ./xgcc -B./ -S ~/wp.c -o wp.s -O3 -fwhole-program -combine -fipa-type-escape -fprofile-generate (and no, adding "__attribute__ ((__noreturn__))" still makes no difference.) > Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ > -B/test/gnu/ > gcc/objdir/gcc/testsuite/g++/../../ > /test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja > /g++.other/static14.C -nostdinc++ > -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/ > libstdc++-v3/include/hppa2.0w-hp-hpux11.11 > -I/test/gnu/gcc/objdir/hppa2.0w-hp-hp > ux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ > -I/test/ > gnu/gcc/gcc/libstdc++-v3/include/backward > -I/test/gnu/gcc/gcc/libstdc++-v3/tests > uite/util -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long > -L/test/ > gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs > -L/test/gnu/gcc/o > bjdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs > -L/test/gnu/gcc/objdir/hppa > 2.0w-hp-hpux11.11/./libiberty -lm -o static14.exe (timeout = 300) > /usr/ccs/bin/ld: Unsatisfied symbols: > basic_string::~basic_string() (first referenced in /var/tmp//ccI3Feaf.o) > (code) > Side::name()::sname (first referenced in /var/tmp//ccI3Feaf.o) (data) > collect2: ld returned 1 exit status > compiler exited with status 1 No difference here either "-ansi -pedantic-errors -Wno-long-long". Weirdness: I see references in the generated code to basic_string::~basic_string() and Side::name()::sname, and that generated code isn't there for cris-elf or native. Ditto static20.C Maybe I'd see a difference if I force weak support? Let me check...
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c > Is this really a regression? Yes, but it may not have anything to do with your change. Looking through my test results, I see it started failing between 136817 and 136971. At 136817, there were no test failures with undefined symbols, wrong symbol type, etc. static14.C and static20.C started betweea 137850 and 138833. I just did a quick scan through the test logs for issues that looked like they might be related to the current problem. > What unpatched revision did you use as a baseline? Your patch was applied to 139805. Dave
(In reply to comment #76) > Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c > > > Is this really a regression? I mean "regression, compared to unpatched". > Yes, but it may not have anything to do with your change. Then *please* leave them out of this PR. I need results just compared to an unpatched revision no earlier than 139233. I can't take on all weak-related or extern-related regressions, and this PR is only supposed to fix the one in the description (without regressing for any targets). Thanks for testing!
FWIW, the results in <http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02792.html> certainly look clean enough to be usable as a baseline.
Any news on the hppa testing?
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c > Any news on the hppa testing? I didn't do anything further with the 32-bit port. I did do a hppa64-hpux11.11 build with your change. I went through the C test results yesterday. Although there are lots of failures, I didn't see any problem related to your proposed change. So, if there are no other problems, I would say submit the change for review. Dave
Subject: Bug 37170 Author: hp Date: Mon Sep 22 01:54:03 2008 New Revision: 140539 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140539 Log: PR middle-end/37170 PR middle-end/37280 * final.c (mark_symbol_ref_as_used): New helper function. (output_operand): Instead of just looking inside MEMs for SYMBOL_REFs, use new helper function and for_each_rtx. * varasm.c (assemble_external): Move #ifndef ASM_OUTPUT_EXTERNAL to after weak-handling. Don't mark decls with TREE_STATIC as weak. Make head comment more general. * config/darwin.c (machopic_output_indirection): Handle weak references here, like in assemble_external. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/final.c trunk/gcc/varasm.c
Subject: Bug 37170 Author: hp Date: Mon Sep 22 01:54:41 2008 New Revision: 140540 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140540 Log: PR middle-end/37170 PR middle-end/37280 * gcc.dg/weak/weak-15.c, gcc.dg/weak/weak-16.c, g++.dg/ext/inline1.C: New tests. Added: trunk/gcc/testsuite/g++.dg/ext/inline1.C trunk/gcc/testsuite/gcc.dg/weak/weak-15.c trunk/gcc/testsuite/gcc.dg/weak/weak-16.c Modified: trunk/gcc/testsuite/ChangeLog
committed
The fix doesn't seem to work for me on arm: $ cat pr-weak.c /* tell the compiler that the count isn't in the small data section if the arch * has one (eg: FRV) */ extern const unsigned long kallsyms_num_syms __attribute__((weak, section(".rodata"))); int main(void) { return !!kallsyms_num_syms; } $ /there.arm/usr/bin/arm-linux-uclibcgnueabi-gcc -Os -S -o - pr-weak.c -v Using built-in specs. Target: arm-linux-uclibcgnueabi Configured with: /srcs/toolchain_build_arm_nofpu/gcc-4.4.0/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibcgnueabi --enable-languages=c,fortran --with-sysroot=/there.arm --with-build-time-tools=/there.arm/usr/arm-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/srcs/toolchain_build_arm_nofpu/gmp --with-mpfr=/srcs/toolchain_build_arm_nofpu/mpfr --disable-nls --enable-threads --disable-multilib --with-float=soft --with-abi=aapcs-linux --disable-libssp --disable-libssp --disable-libmudflap --disable-libgomp --enable-decimal-float=no Thread model: posix gcc version 4.4.0 20080923 (experimental) [trunk revision 140602] (GCC) COLLECT_GCC_OPTIONS='-Os' '-S' '-o' '-' '-v' '-mfloat-abi=soft' '-mabi=aapcs-linux' /there.arm/usr/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.4.0/cc1 -quiet -v -iprefix /there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/ pr-weak.c -quiet -dumpbase pr-weak.c -mfloat-abi=soft -mabi=aapcs-linux -auxbase-strip - -Os -version -o - ignoring nonexistent directory "/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/include" ignoring nonexistent directory "/there.arm/usr/local/include" ignoring duplicate directory "/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include" ignoring duplicate directory "/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include-fixed" ignoring nonexistent directory "/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/include" #include "..." search starts here: #include <...> search starts here: /there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include /there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include-fixed /there.arm/usr/include End of search list. GNU C (GCC) version 4.4.0 20080923 (experimental) [trunk revision 140602] (arm-linux-uclibcgnueabi) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 071bc0f306e6057c8a651fee23ec8dfa .cpu arm10tdmi .fpu softvfp .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .eabi_attribute 26, 2 .eabi_attribute 30, 4 .eabi_attribute 18, 4 .file "pr-weak.c" .text .align 2 .global main .type main, %function main: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldr r3, .L3 ldr r0, [r3, #0] subs r0, r0, #0 movne r0, #1 bx lr .L4: .align 2 .L3: .word kallsyms_num_syms .size main, .-main .ident "GCC: (GNU) 4.4.0 20080923 (experimental) [trunk revision 140602]" .section .note.GNU-stack,"",%progbits COMPILER_PATH=/there.arm/usr/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.4.0/:/there.arm/usr/bin/../libexec/gcc/:/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/bin/ LIBRARY_PATH=/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/:/there.arm/usr/bin/../lib/gcc/:/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/lib/:/there.arm/lib/:/there.arm/usr/lib/ COLLECT_GCC_OPTIONS='-Os' '-S' '-o' '-' '-v' '-mfloat-abi=soft' '-mabi=aapcs-linux' works with 4.3.2 configured in the same way.
Subject: Bug 37170 Author: jakub Date: Sat Nov 22 08:22:52 2008 New Revision: 142113 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142113 Log: PR target/37170 * final.c (mark_symbol_refs_as_used): New function. * output.h (mark_symbol_refs_as_used): New prototype. * config/s390/s390.c (s390_mark_symbol_ref_as_used): Removed. (s390_output_pool_entry): Use mark_symbol_refs_as_used. * config/arm/arm.md (consttable_4): Likewise. Modified: trunk/gcc/config/arm/arm.md trunk/gcc/config/s390/s390.c trunk/gcc/final.c trunk/gcc/output.h
Subject: Bug 37170 Author: jakub Date: Sat Nov 22 08:26:24 2008 New Revision: 142114 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142114 Log: PR target/37170 * final.c (mark_symbol_refs_as_used): New function. * output.h (mark_symbol_refs_as_used): New prototype. * config/s390/s390.c (s390_mark_symbol_ref_as_used): Removed. (s390_output_pool_entry): Use mark_symbol_refs_as_used. * config/arm/arm.md (consttable_4): Likewise. Modified: trunk/gcc/ChangeLog
Fixed even on the arm.
Subject: Bug 37170 Author: ebotcazou Date: Wed Dec 10 08:46:40 2008 New Revision: 142640 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142640 Log: PR target/37170 PR target/38448 * final.c (output_addr_const) <SYMBOL_REF>: Call assemble_external on the associated SYMBOL_REF_DECL node, if any. Modified: trunk/gcc/ChangeLog trunk/gcc/final.c