[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-04-25 12:32 --- AFAICT there are a number of factors causing this and darwin8 is also affected. A (certainly non-comprehensive) list of issues: Darwin 8 (OSX 10.4.11) (Objc) There is no 64 bit NeXT runtime. (Obj-c++) local symbol label issue (radar: 5202926) There is no 64 bit NeXT runtime. Darwin 9 (OSX10.5.6) ObjC -m32 The darwin 9 NeXT headers assume the availability of language enhancements present in Apple's 4.2 local release, but not in currently in gcc. specifically, __attribute__ extensions. (OBJC2_UNAVAILABLE expands to use this) Some interfaces are declared deprecated - which causes test failures owing to unexpected warnings. a few tests require -mdynamic-no-pic -m64 all the m32 issues + no 64 bit "Object" class implementation. also some of the "deprecated" interfaces m32 are "not available" at m64 ObjC++ all the ObjC issues + local symbol label issue (radar: 5202926) --- Part 0 of some work to deal with this is about to be posted to gcc-patches. - don't try to execute NeXT m64 on darwin 5..8 (whilst retaining the ability to test -fgnu-runtime) - fix the local label issue. Iain. -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added CC| |developer at sandoe- | |acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-04-27 19:03 --- Created an attachment (id=17769) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17769&action=view) patch for 4.4-branch (and 4.4.0 release) don't forget to add the version files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-04-27 19:04 --- Created an attachment (id=17770) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17770&action=view) added files for the libgcc_ext patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-04-27 19:05 --- Created an attachment (id=17771) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17771&action=view) patch against 4.5 trunk also needs the added files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2009-04-27 19:07 --- Sorry I got the attachments and the comment in the wrong order... The basic issue is that TLS emulation needs to be linked just once in an executable - but so does exception handling. Exception handling is already linked (for system libraries) with /usr/lib/libgcc_s.1.dylib - so we cannot simply replace that with our new lingcc_s.1.dylib version (or you will lose the ability to unwind through the system libs). I was working on the following engineering solution last year, but I'm afraid it's possibly rough around the edges and is "undiscussed" and therefore any part of all of it might be unacceptable to the various maintainers.I'm posting it now because the day job is not allowing any time to work on it -- and it might be useful to someone as it stands. The basic idea is to add a "libgcc_ext.dylib" that is versioned and contains all the added symbols between a given release of Darwin and the current state of libgcc_s. This means that we will all resolve to the same versions of symbols - but that new programs can access newly-added gcc features. There are various changes needed to accommodate this logic: changes to build the difference library (done in the libgcc mechanism). additions of the symbol version files. changes of the testsuite to make sure that the testsuite search paths include the multilib versions of libgcc_ext.dylib. As I say, the _ext dylib is versioned (so there's a 10.4 and 10.5 one built). === I'm attaching: a diff against 4.4-branch -- this applies against 4.4.0 release with one offset and I've bootstrapped & checked that - I'll post the results. a diff against 4.5-trunk. a set of added files - which are common to both. So you need to patch 4.x as appropriate and then add the new files. I don't think this change makes much sense unless you build with --enable-version-specific-runtime-libs and I haven't tested it any other way... -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added -------- CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-04-27 19:15 --- testresults: http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02886.html http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02887.html and to engage the facility you need to build your program with " -muse-shared-libgcc-ext " best luck Iain -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug bootstrap/40950] Bootstrap fails with in-tree gmp and without system C++ compiler
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2009-08-25 12:06 --- (In reply to comment #7) > Use --enable-stage1-languages=c,c++ I believe that this bug also applies to powerpc-apple-darwin8 and i686-apple-darwin9. the suggested remedy also works. This was introduced between 148251 and 151057 (OK a big gap .. but) during which time I didn't update GMP - so the change is at least in part down to gcc build process changing. if it's any clue /lib/cpp is not a fallback compiler install location for Darwin - which perhaps implies that the build process has lost its idea of the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #19 from developer at sandoe-acoustics dot co dot uk 2009-09-04 08:36 --- this also applies to powerpc-apple-darwin8 at least at 151409 -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #21 from developer at sandoe-acoustics dot co dot uk 2009-09-04 16:27 --- (In reply to comment #20) > > this also applies to powerpc-apple-darwin8 at least at 151409 > > This should be fixed now (try r151388 or newer, see pr41237). i686-apple-darwin9 appear to be fine.. (per the referenced pr41237). unfortunately, powerpc-apple-darwin8 is not... Updated to revision 151426. Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/alias.o differs etc. etc. bear in mind that darwin8 is the 'end of the road' for a bunch of PPC hardware so it would be nice if this still worked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #24 from developer at sandoe-acoustics dot co dot uk 2009-09-04 17:00 --- (In reply to comment #22 & #23) > When you run ./config ..., you should see > > rm: conftest.dSYM: is a directory > checking for default BUILD_CONFIG... conftest.o.g0.stripped > conftest.o.g.stripped differ: char 23, line 2 > stripping off .eh_frame, then retrying > failed to strip off .eh_frame > conftest.o.g0.stripped conftest.o.g.stripped differ: char 23, line 2 $ ../gcc-4-5-regtest/configure --prefix=/Volumes/ScratchCS/gcc-4-5-install --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --enable-languages=c,objc,c++,obj-c++,fortran --enable-version-specific-runtime-libs --enable-threads --enable-checking=yes --program-suffix=-4.5.0 --with-dwarf2 --with-libiconv-prefix=/usr --with-system-zlib --enable-stage1-languages=c,c++ checking build system type... powerpc-apple-darwin8 checking for correct version of CLooG... no The following languages will be built: c,c++,fortran,objc,obj-c++ *** This configuration is not supported in the following subdirectories: target-libmudflap target-libada gnattools target-libffi target-zlib target-libjava zlib target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for bison... bison -y something different.. indeed. > > bear in mind that darwin8 is the 'end of the road' for a bunch of PPC > > hardware > > so it would be nice if this still worked. > darwin9 works fine on ppc. on high end G4 & G5 with plenty of memory.. indeed - not a pleasant idea/unsupported on other variants. Jack; OK, I'll be patient... but it's sure getting in the way of trying to do some fortran work!! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug bootstrap/41224] [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at revision 151318
--- Comment #27 from developer at sandoe-acoustics dot co dot uk 2009-09-04 19:38 --- (In reply to comment #26) > (In reply to comment #25) > > Fixed with revision 151367. this is true for powerpc-apple-darwin9 (which is the mentioned system in the bug) it is NOT fixed for powerpc-apple-darwin8, as of 151420 - should I raise a new bug? > it might be fixed after the patch from... > http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00381.html I'll try later - I just rebooted the G5 into Darwin9 to try that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
[Bug bootstrap/41296] New: bootstrap fails with --with-dwarf2 trunk at 151455
with patch: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01069.html (which is approved, but not yet in the trunk). dwarf2 is needed to link m64 on darwin8 ppc (ld64 barfs on stabs). Also with the attached patch to enable compare-debug to work with dwarf on darwin. bootstrap fails with: rm -f stage_current Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/alias.o differs gcc/alloc-pool.o differs gcc/attribs.o differs gcc/auto-inc-dec.o differs gcc/bb-reorder.o differs gcc/bitmap.o differs gcc/bt-load.o differs gcc/build/errors.o differs gcc/build/gcov-iov.o differs gcc/build/genattr.o differs gcc/build/genattrtab.o differs gcc/build/genautomata.o differs gcc/build/gencheck.o differs gcc/build/genchecksum.o differs gcc/build/gencodes.o differs gcc/build/genconditions.o differs gcc/build/gencondmd.o differs gcc/build/genconfig.o differs gcc/build/genconstants.o differs gcc/build/genemit.o differs gcc/build/genextract.o differs gcc/build/genflags.o differs etc. === Looking at the stripped version of alias.o using otool -l xxx.o.stripped > xxx.ls $ diff -u s2alias-ls.txt s3alias-ls.txt --- s2alias-ls.txt 2009-09-07 13:50:54.0 +0100 +++ s3alias-ls.txt 2009-09-07 13:51:06.0 +0100 @@ -1,11 +1,11 @@ -stage2-gcc/alias.o.stripped: +stage3-gcc/alias.o.stripped: Load command 0 cmd LC_SEGMENT cmdsize 668 segname vmaddr 0x vmsize 0x713e - fileoff 976 + fileoff 1000 filesize 28496 maxprot 0x0007 initprot 0x0007 @@ -16,9 +16,9 @@ segname __TEXT addr 0x size 0x662c -offset 976 +offset 1000 align 2^2 (4) -reloff 29472 +reloff 29496 nreloc 2489 flags 0x8400 reserved1 0 @@ -28,7 +28,7 @@ segname __TEXT addr 0x662c size 0x00ec -offset 27132 +offset 27156 align 2^2 (4) reloff 0 nreloc 0 @@ -40,7 +40,7 @@ segname __TEXT addr 0x6718 size 0x0214 -offset 27368 +offset 27392 align 2^2 (4) reloff 0 nreloc 0 @@ -52,9 +52,9 @@ segname __TEXT addr 0x6930 size 0x03d0 -offset 27904 +offset 27928 align 2^4 (16) -reloff 49384 +reloff 49408 nreloc 244 flags 0x8408 reserved1 0 (index into indirect symbol table) @@ -64,9 +64,9 @@ segname __DATA addr 0x6d00 size 0x00dc -offset 28880 +offset 28904 align 2^2 (4) -reloff 51336 +reloff 51360 nreloc 16 flags 0x reserved1 0 @@ -76,7 +76,7 @@ segname __DATA addr 0x6ddc size 0x0008 -offset 29100 +offset 29124 align 2^2 (4) reloff 0 nreloc 0 @@ -88,9 +88,9 @@ segname __DATA addr 0x6de4 size 0x00f4 -offset 29108 +offset 29132 align 2^2 (4) -reloff 51464 +reloff 51488 nreloc 61 flags 0x0007 reserved1 61 (index into indirect symbol table) @@ -100,7 +100,7 @@ segname __DATA addr 0x6ed8 size 0x0078 -offset 29352 +offset 29376 align 2^2 (4) reloff 0 nreloc 0 @@ -122,9 +122,9 @@ Load command 1 cmd LC_SYMTAB cmdsize 24 - symoff 52560 + symoff 52584 nsyms 131 - stroff 54132 + stroff 54156 strsize 2540 Load command 2 cmd LC_DYSYMTAB @@ -141,13 +141,18 @@ nmodtab 0 extrefsymoff 0 nextrefsyms 0 - indirectsymoff 51952 + indirectsymoff 51976 nindirectsyms 152 extreloff 0 nextrel 0 locreloff 0 nlocrel 0 Load command 3 + cmd LC_UUID + cmdsize 24 + uuid 0x3f 0x20 0x5f 0xca 0xab 0x64 0x42 0xc5 +0xb1 0x8d 0x37 0x82 0x04 0x02 0x11 0xbb +Load command 4 cmd LC_UNIXTHREAD cmdsize 176 flavor PPC_THREAD_STATE = the difference appears to be the cmd LC_UUID in the stage3 object. In all probability this is harmless? but I've yet to find a way to strip that load command. -- Summary: bootstrap fails with --with-dwarf2 trunk at 151455 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: developer at sandoe-acoustics dot co dot uk GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41296
[Bug bootstrap/41296] bootstrap fails with --with-dwarf2 trunk at 151455
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-09-07 13:32 --- Created an attachment (id=18529) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18529&action=view) patch allowing compare-debug to work with dwarf mach-o this is needed to allow any meaningful comparison with dwarf-2 debug on darwin8/9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41296
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-09-07 13:49 --- does this help? http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00467.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2009-09-08 07:09 --- (In reply to comment #6) > I believe Mike Stump told me that it is possible that darwin's strip could > re-order the sections. Is that possibility addressed in the current patches? I don't believe re-ordering sections is the solution, in this case. > Current x86_64-apple-darwin10 has no problems with gcc trunk at the moment. can you confirm that the top level config produces lines like: target-libmudflap target-libada gnattools target-libffi target-zlib target-libjava zlib target-boehm-gc (Any other directories should still work fine.) THIS ONE >>> checking for default BUILD_CONFIG... bootstrap-debug checking for bison... bison -y and that the build produces: rm -f stage_current Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs THIS ONE >>>> Comparison successful. -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added CC| |developer at sandoe- | |acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2009-09-08 08:54 --- Created an attachment (id=18538) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18538&action=view) patch allowing compare-debug to work with dwarf mach-o this works for powerpc-apple-darwin8 (stabs or dwarf2) powerpc-apple-darwin9 i686-apple-darwin9 checked at 151491 (powerpc) and 151488 (i686) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug bootstrap/41296] bootstrap fails with --with-dwarf2 trunk at 151455
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-09-08 08:49 --- (In reply to comment #0) > the difference appears to be the cmd LC_UUID in the stage3 object. > > In all probability this is harmless? > but I've yet to find a way to strip that load command. revised patch with -no_uuid resolves this -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41296
[Bug bootstrap/41296] bootstrap fails with --with-dwarf2 trunk at 151455
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-09-08 08:48 --- Created an attachment (id=18537) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18537&action=view) revised patch adds the -no_uuid flag which is needed by powerpc darwin8 for dwarf2 debug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41296
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #14 from developer at sandoe-acoustics dot co dot uk 2009-09-08 14:44 --- (In reply to comment #13) > I'm doing x86_64-apple-darwin9 now - so no need to include that tonight - I > can > confirm that this also needs the patch to configure with the test. I'll add a > comment once the build completes as to whether that's successful. x86_64-apple-darwin9 bootstraps and successfully carries out the stage2/3 compare with the patch. w/out the patch the comparison is not carried out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #11 from developer at sandoe-acoustics dot co dot uk 2009-09-08 13:40 --- (In reply to comment #10) > (In reply to comment #9) > > Created an attachment (id=18538) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18538&action=view) [edit] > I had no problems bootstrapping r151463 on x86_64-apple-darwin10... > http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00563.html well.. the bootstrap *was* fixed (at least on darwin9) - effectively by disabling the compare-debug function. so a successful bootstrap does not indicate that the object compares were carried out - hence the two lines I indicated in comment #8 "THIS ONE>>>" > I'll try x86_64-apple-darwin9 and i686-apple-darwin10 tonight. great! .. thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #13 from developer at sandoe-acoustics dot co dot uk 2009-09-08 14:07 --- (In reply to comment #12) > I am confused then. Don't we need another patch beyond the one in > cmpdbg-1.diff.txt to re-enable the compare-debug function on darwin? the default BUILD_CONFIG fragment is "bootstrap-debug" . there is a configure test that tries to compare two binary files using contrib/compare-debug. if that test fails (it does for the unpatched compare-debug) the BUILD_CONFIG fragment is set to "" effectively this removes the comparison. when the compare-debug is patched - and thus works - the test is NOT removed .. --- I'm doing x86_64-apple-darwin9 now - so no need to include that tonight - I can confirm that this also needs the patch to configure with the test. I'll add a comment once the build completes as to whether that's successful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #19 from developer at sandoe-acoustics dot co dot uk 2009-09-18 12:56 --- (In reply to comment #18) > Fixed or what? Yes at 151650 (for example) on i686-apple-darwin9 (current trunk, 151837, appears to have a different problem). Also OK on powerpc-apple-darwin8 (configured--with-dwarf2) at 151837. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug bootstrap/41296] bootstrap fails with --with-dwarf2 trunk at 151455
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2009-09-18 12:58 --- FIXED as of 151837. -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41296
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #10 from developer at sandoe-acoustics dot co dot uk 2009-09-18 19:08 --- on i686-apple-darwin9 bootstrap fails with a variety of different errors depending on what --enable-checking=xx is set. For =yes if fails with a lot of dsymutil crashes. =runtime it fails per the #1 example, =no ... the bootstrap never complete (at least my patience ran out at 4x normal). -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #15 from developer at sandoe-acoustics dot co dot uk 2009-09-19 22:45 --- just checked; powerpc-apple-darwin9 [at 151880] this also fails. looking through the error log there do seem to be a large number of garbage strings in the informational messages; e.g. ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h: In function âÃòlast_fdeâÃô: if that's of any relevance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #11 from developer at sandoe-acoustics dot co dot uk 2009-09-20 08:00 --- see my comment #10 on PR41395 and note that this bug also shows on powerpc-apple-darwin9. It DOES NOT show on powerpc-apple-darwin8 (which makes one less sure about the likelihood of a straight dsymutil bug). -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #12 from developer at sandoe-acoustics dot co dot uk 2009-09-20 09:38 --- (In reply to comment #11) > see my comment #10 on PR41395 and note that this bug also shows on > powerpc-apple-darwin9. > It DOES NOT show on powerpc-apple-darwin8 (which makes one less sure about the > likelihood of a straight dsymutil bug). correction: the DWARFdSYM.cpp:1260: failed assertion `!"Unknown one-operand"' *IS* occurring on Darwin8 - but it is not causing a bootstrap fail. note that on Darwin9: In file included from ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde-darwin.c:35:0: ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h: In function âÃòlast_fdeâÃô: ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h:173:3: warning: cast discards qualifiers from pointer target type c.f. Darwin8: In file included from ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde-darwin.c:35:0: ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h: In function 'last_fde': ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h:173:3: warning: cast discards qualifiers from pointer target type -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #19 from developer at sandoe-acoustics dot co dot uk 2009-09-20 09:42 --- applying http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01274.html causes i686-apple-darwin9 to fail with the (long long) fault for all --enable-checking=xx I've tried. Thus, that fault seems separate (PR41405). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #19 from developer at sandoe-acoustics dot co dot uk 2009-09-20 22:37 --- (In reply to comment #16) firstly, backing out of all mods to dwarf2out.c after 151814 both allows the bootstrap to complete and checking the log files shows no dsymutil fails powerpc-apple-darwin8, i686-apple-darwin9 > Instead of reverting the patch [this might not be quite enough; backing out of only 151814->151815 for trunk version 151904 produced a working bootstrap but with still some dsymutil fails]. we should add a -gstrict-dwarf[23] switch > that darwin can use by default instead. Please can we do this; even if there is a fix applied to darwin10/9 dsymutil we are unlikely to see a fix applicable to darwin8 since active development is now on darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #22 from developer at sandoe-acoustics dot co dot uk 2009-09-21 09:04 --- Dominique has confirmed what I've found, that some changes beyond 151814->151815 are also significant. test results for powerpc-apple-darwin8 and i686-apple-darwin9 http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01885.html http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01886.html to Jack; your test case does NOT fail with this build on either powerpc D8 or i686 D9. Perhaps this gives us a starting point for producing a test-case that (a) fails on darwin toolset and (b) is demonstrably correct by some other means -- i.e. bug is squarely in the toolset. these particular tools are not currently open sourced - and therefore it is impossible for us to require them to be fixed on any particular version of darwin (if they were open I'd gladly volunteer to attempt the fix myself). To that end I have enquired on darwin-dev as to the likelihood of them being open-sourced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #25 from developer at sandoe-acoustics dot co dot uk 2009-09-21 12:45 --- (In reply to comment #23) > Created an attachment (id=18621) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621&action=view) [edit] > gcc45-pr41405.patch thanks for the patch. I bootstrapped i686-apple-darwin successfully with the addition of dwarf_strict=1; to darwin_override_options() which is invoked from SUBSUBTARGET_OVERRIDE_OPTIONS unfortunately, there are still some ASSERTS when processing libgfortran, libgnu-obj, libjg. I wonder if that's because I've not got the dwarf_strict=1; in the correct place - and I'm working my way through the options processing.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #26 from developer at sandoe-acoustics dot co dot uk 2009-09-21 14:24 --- (In reply to comment #23) > Created an attachment (id=18621) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621&action=view) [edit] > gcc45-pr41405.patch as pre previous comment - this bootstraps OK i686-apple-darwin9. 1/ but the error output contains the following : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-49/source/DWARFdSYM.cpp, line 3157. ./libtool: line 7982: 98179 Abort trap dsymutil .libs/libffi.4.dylib ditto: dsymutil .libs/libgfortran.3.dylib dsymutil .libs/libobjc-gnu.2.dylib dsymutil .libs/libgcj.11.dylib 1/ does that point to any specific area to check? 2/ I guess it's also possible that there's a bug in the darwin-specific code that emits debug info for mach-o. Where should one look for information that would allow one to prove that the output is 'correctly formed'? we'll need to do that anyway in order to formulate a radar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #28 from developer at sandoe-acoustics dot co dot uk
2009-09-21 16:46 ---
(In reply to comment #27)
> I believe I've caught all DW_OP_{implicit,stack}_value uses in dwarf2out.c, so
> likely -gstrict-dwarf wasn't used when compiling something that has been
> linked
> into those libraries.
(two bootstraps later...)
I jammed an Init(1) into the flag line and the four fail cases still appear.
With current trunk - and dwarf2out.c from 151814 there are no fails.
> No idea if Mach-O has any tools similar to readelf that would allow you to
> dump
> the debug info of object files, if not, you'll need to check for it at the
I'll have to see what dwarfdump can do (one might expect it to fail in the same
way as dsymtuil)
- but first we need a reliable simple failing case.
> assembler level (-save-temps plus -dA).
downloaded the dwarf2 and dwarf3 specs...
ah well, there's always hexdump ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #31 from developer at sandoe-acoustics dot co dot uk
2009-09-21 18:50 ---
OK. this is what I've done
(a) bootstrapped with Jakub's path but modified thus
>> Common Report Var(dwarf_strict) Init(1)
- bootstrap succeeds (with the four errors mentioned in #26).
(b) I then hand edited gcc/options.c to set dwarf_strict=0; and re-made xgcc.
Now I have a built complier that responds to the -gstrict_dwarf flag.
so I made a very simple source file:
int testfunc(void)
{
int ;
i=1;
return i;
}
I can compile this with/without -gstrict-dwarf and cmp says the .o files are
the same. -save-temps -fverbose-asm says that gstrict-dwarf is being turned on
& off.
dwarfdump succeeds with everything but --debug-frame
:Assertion failed: (reg_state_pos != cie->initial_state.regs.end()), function
ParseInstructions,
(note that for this simple file the debug-str; segment is empty - which is the
error case in the four lib ones).
any guru gonna point me to where to go next ... it's really difficult to know
where the problem really lies right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #34 from developer at sandoe-acoustics dot co dot uk
2009-09-22 14:36 ---
(In reply to comment #32)
> Updated patch: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01477.html
thanks - actually I was trying this - but in the end updated to 151978...
with BOOT_CFLAGS="-g -gdwarf-2 -gstrict-dwarf -O2" and CFLAGS_FOR_TARGET the
same/
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs
i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs
i686-apple-darwin9/libstdc++-v3/src/future.o differs
i686-apple-darwin9/libstdc++-v3/src/system_error.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs
make[2]: *** [compare] Error 1
> You used a too simple testcase which doesn't need any of the DWARF4 additions.
> Use a more complicated one, e.g. try the gcc.dg/guality/ testcases with
> -g{,no-}strict-dwarf.
well that's true - but I'd stopped there since even that simplistic case was
giving errors with
dwarfdump --debug-frame
once we figure out how to get bootstrap working again .. I'll do the
gcc.dg/guality testcases as you suggest
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #37 from developer at sandoe-acoustics dot co dot uk 2009-09-22 16:09 --- (In reply to comment #36) > Remove -gdwarf-2 as well. -gdwarf-2 is the same as -g when dwarf_version > defaults to 2 (which is true on the trunk). > Easiest quick hack to turn -gstrict-dwarf on is add Init(1) to > gno-strict-dwarf > in common.opt (that's how I've been testing it). yeah I was adding Init(1) yesterday. I did that and bootstrapped again; double-checked and the flags are correctly init-ed (=2 and =1). NO CHANGE (2 fails x 4 on compare-debug), so something else is broken. I'll try and investigate.. but time is shot now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #38 from developer at sandoe-acoustics dot co dot uk 2009-09-22 16:38 --- > Comparing stages 2 and 3 > warning: gcc/cc1-checksum.o differs > warning: gcc/cc1obj-checksum.o differs > warning: gcc/cc1objplus-checksum.o differs > warning: gcc/cc1plus-checksum.o differs > Bootstrap comparison failure! > i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs > i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs > i686-apple-darwin9/libstdc++-v3/src/future.o differs > i686-apple-darwin9/libstdc++-v3/src/system_error.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs > make[2]: *** [compare] Error 1 FWIW powerpc-apple-darwin8 exhibits the same phenomenon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-09-22
19:20 ---
(In reply to comment #6)
> I wonder if we could just trim out the symbols from libgcc that are in
> libSystem, and arrange for gcc's installed libgcc to be found first.
OK. If I understand this from the symbol PoV
- that's the same machinery as builds the _ext
(i.e. there are the same symbols left at each revision as would be in the _ext
)...
in a change-control sense, at least.
> Advantage, simplicity, less target specific work, easy to understand.
Simplicity & less work sound good... I'm working on the understanding bit ;)
> Downside, OS upgrades require recompiling the world, to the extent there are
> new symbols in libgcc that are then added to libSystem in later OS releases.
meaning that a binary from on OSX release would not work on a later one or vice
versa.
I guess there's an amount of this anyway ..
> ld has magic in it that can appear and disappear symbols from a dylib
> depending
> upon which OS is targeted. Target old OSes, all the usual symbols are there,
> target newer OSes, large swaths disappear (but are found anyway in libSystem).
>
> Also, all this fun stuff it relevant to darwin10 and later only (not
> darwin9).
why not relevant to D9 and D8?
(D8 is still the end of the road for a whole bunch of perfectly good PPC
hardware)
if we override the /usr/lib/libgcc_s we mess up the unwinding
(the whole reason I made the _ext in the first place was that we can't 'lose'
that version because it's linked with system frameworks.)
To add symbols to D9/D8 we still have to link two libgcc variants (whether one
is named _ext or not is not important) ..
> I'm not a fan of yet more compile flags in general. I'd rather have a nice
> design that covers the bases, that doesn't really need yet more flags.
>
> The hiding trick goes something like:
>
> #define NOT_HERE_BEFORE_10_6(sym) \
> extern const char sym##_tmp3 __asm("$ld$hide$os10.3$_" #sym ); \
> __attribute__((visibility("default"))) const char sym##_tmp3 = 0;
> \
where do we have to apply this macro ?
to every function in libgcc? (with appropriate 'NOT_HERE_BEFOREs' )
or is it something that could be scripted?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #39 from developer at sandoe-acoustics dot co dot uk 2009-09-22 20:17 --- object differences currently causing bootstrap fail - these look unrelated to the original bug: .. anyone throw any light on this? stripped future.o from stage 2 07e0 63 5f 5f 5f 76 33 5f 73 72 63 5f 66 75 74 75 72 |c___v3_src_futur| 07f0 65 2e 63 63 5f 30 30 30 30 30 30 30 30 5f 34 37 |e.cc__47| 0800 44 39 32 31 34 32 32 31 66 75 74 75 72 65 5f 65 |D9214221future_e| 0810 72 72 6f 72 5f 63 61 74 65 67 6f 72 79 45 00 00 |rror_categoryE..| stripped future.o from stage 3 07e0 63 5f 5f 5f 76 33 5f 73 72 63 5f 66 75 74 75 72 |c___v3_src_futur| 07f0 65 2e 63 63 5f 30 30 30 30 30 30 30 30 5f 45 35 |e.cc__E5| 0800 45 38 41 43 44 37 32 31 66 75 74 75 72 65 5f 65 |E8ACD721future_e| 0810 72 72 6f 72 5f 63 61 74 65 67 6f 72 79 45 00 00 |rror_categoryE..| === stripped system_error.o from stage 2 07a0 30 30 30 5f 37 37 34 44 41 30 30 45 32 32 67 65 |000_774DA00E22ge| 07b0 6e 65 72 69 63 5f 65 72 72 6f 72 5f 63 61 74 65 |neric_error_cate| 07c0 67 6f 72 79 45 00 00 00 00 00 00 00 00 00 00 00 |goryE...| 07d0 4e 38 39 5f 47 4c 4f 42 41 4c 5f 5f 4e 5f 2e 2e |N89_GLOBAL__N_..| 07e0 5f 2e 2e 5f 2e 2e 5f 2e 2e 5f 67 63 63 5f 34 5f |_.._.._.._gcc_4_| 07f0 35 5f 72 65 67 74 65 73 74 5f 6c 69 62 73 74 64 |5_regtest_libstd| 0800 63 5f 5f 5f 76 33 5f 73 72 63 5f 73 79 73 74 65 |c___v3_src_syste| 0810 6d 5f 65 72 72 6f 72 2e 63 63 5f 30 30 30 30 30 |m_error.cc_0| 0820 30 30 30 5f 37 37 34 44 41 30 30 45 32 31 73 79 |000_774DA00E21sy| stripped system_error.o from stage 3 07a0 30 30 30 5f 35 39 44 36 31 37 37 43 32 32 67 65 |000_59D6177C22ge| 07b0 6e 65 72 69 63 5f 65 72 72 6f 72 5f 63 61 74 65 |neric_error_cate| 07c0 67 6f 72 79 45 00 00 00 00 00 00 00 00 00 00 00 |goryE...| 07d0 4e 38 39 5f 47 4c 4f 42 41 4c 5f 5f 4e 5f 2e 2e |N89_GLOBAL__N_..| 07e0 5f 2e 2e 5f 2e 2e 5f 2e 2e 5f 67 63 63 5f 34 5f |_.._.._.._gcc_4_| 07f0 35 5f 72 65 67 74 65 73 74 5f 6c 69 62 73 74 64 |5_regtest_libstd| 0800 63 5f 5f 5f 76 33 5f 73 72 63 5f 73 79 73 74 65 |c___v3_src_syste| 0810 6d 5f 65 72 72 6f 72 2e 63 63 5f 30 30 30 30 30 |m_error.cc_0| 0820 30 30 30 5f 35 39 44 36 31 37 37 43 32 31 73 79 |000_59D6177C21sy| -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #43 from developer at sandoe-acoustics dot co dot uk 2009-09-22 21:42 --- (In reply to comment #42) > Are you building with --enable-build-with-cxx or something similar? > libstdc++-v3 isn't normally compared. The difference you are seeing is likely > related to different random seed, you'd need to pass the same > -frandom-seed= in both stage2 and stage3 builds... --enable-stage1-languages=c,c++ AFAIK this is now necessary when building in-tree GMP/MPFR . If that requirement has been lifted.. then this problem will evaporate (or I can take a diff. approach to building GMP/MPFR). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #48 from developer at sandoe-acoustics dot co dot uk 2009-09-23 09:13 --- (In reply to comment #43) > (In reply to comment #42) > > Are you building with --enable-build-with-cxx or something similar? confirmed. building with: out-of-tree gmp/mpfr and --enable-stage1-languages=c bootstrap completes with same observation as #26 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41446] New: in-tree GMP/MPFR requires c++ as stage 1 lang; 2 object compares fail.
for example; with --enable-stage1-languages=c,c++ (required for in-tree
GMP/MPFR)
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs
i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs
i686-apple-darwin9/libstdc++-v3/src/future.o differs
i686-apple-darwin9/libstdc++-v3/src/system_error.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs
make[2]: *** [compare] Error 1
stripped future.o from stage 2
07e0 63 5f 5f 5f 76 33 5f 73 72 63 5f 66 75 74 75 72 |c___v3_src_futur|
07f0 65 2e 63 63 5f 30 30 30 30 30 30 30 30 5f 34 37 |e.cc__47|
0800 44 39 32 31 34 32 32 31 66 75 74 75 72 65 5f 65 |D9214221future_e|
0810 72 72 6f 72 5f 63 61 74 65 67 6f 72 79 45 00 00 |rror_categoryE..|
stripped future.o from stage 3
07e0 63 5f 5f 5f 76 33 5f 73 72 63 5f 66 75 74 75 72 |c___v3_src_futur|
07f0 65 2e 63 63 5f 30 30 30 30 30 30 30 30 5f 45 35 |e.cc__E5|
0800 45 38 41 43 44 37 32 31 66 75 74 75 72 65 5f 65 |E8ACD721future_e|
0810 72 72 6f 72 5f 63 61 74 65 67 6f 72 79 45 00 00 |rror_categoryE..|
===
stripped system_error.o from stage 2
07a0 30 30 30 5f 37 37 34 44 41 30 30 45 32 32 67 65 |000_774DA00E22ge|
07b0 6e 65 72 69 63 5f 65 72 72 6f 72 5f 63 61 74 65 |neric_error_cate|
07c0 67 6f 72 79 45 00 00 00 00 00 00 00 00 00 00 00 |goryE...|
07d0 4e 38 39 5f 47 4c 4f 42 41 4c 5f 5f 4e 5f 2e 2e |N89_GLOBAL__N_..|
07e0 5f 2e 2e 5f 2e 2e 5f 2e 2e 5f 67 63 63 5f 34 5f |_.._.._.._gcc_4_|
07f0 35 5f 72 65 67 74 65 73 74 5f 6c 69 62 73 74 64 |5_regtest_libstd|
0800 63 5f 5f 5f 76 33 5f 73 72 63 5f 73 79 73 74 65 |c___v3_src_syste|
0810 6d 5f 65 72 72 6f 72 2e 63 63 5f 30 30 30 30 30 |m_error.cc_0|
0820 30 30 30 5f 37 37 34 44 41 30 30 45 32 31 73 79 |000_774DA00E21sy|
stripped system_error.o from stage 3
07a0 30 30 30 5f 35 39 44 36 31 37 37 43 32 32 67 65 |000_59D6177C22ge|
07b0 6e 65 72 69 63 5f 65 72 72 6f 72 5f 63 61 74 65 |neric_error_cate|
07c0 67 6f 72 79 45 00 00 00 00 00 00 00 00 00 00 00 |goryE...|
07d0 4e 38 39 5f 47 4c 4f 42 41 4c 5f 5f 4e 5f 2e 2e |N89_GLOBAL__N_..|
07e0 5f 2e 2e 5f 2e 2e 5f 2e 2e 5f 67 63 63 5f 34 5f |_.._.._.._gcc_4_|
07f0 35 5f 72 65 67 74 65 73 74 5f 6c 69 62 73 74 64 |5_regtest_libstd|
0800 63 5f 5f 5f 76 33 5f 73 72 63 5f 73 79 73 74 65 |c___v3_src_syste|
0810 6d 5f 65 72 72 6f 72 2e 63 63 5f 30 30 30 30 30 |m_error.cc_0|
0820 30 30 30 5f 35 39 44 36 31 37 37 43 32 31 73 79 |000_59D6177C21sy|
Jakub Jalinek has commented in 41405:
The difference you are seeing is likely related to different random seed, you'd
need to pass the same
-frandom-seed= in both stage2 and stage3 builds...
However, this is new since approx. 151920.
--
Summary: in-tree GMP/MPFR requires c++ as stage 1 lang; 2 object
compares fail.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: developer at sandoe-acoustics dot co dot uk
GCC build triplet: *-apple-darwin{8,9}
GCC host triplet: *-apple-darwin{8,9}
GCC target triplet: *-apple-darwin{8,9}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41446
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #52 from developer at sandoe-acoustics dot co dot uk 2009-09-23 13:57 --- (In reply to comment #51) > Is there anyway to redefine or adjust gno-strict-dwarf at a target specific > level so that for a given target that option could be set to Init(1)? Having > to > pass this through BOOT_CFLAGS seems suboptimal because, even if we set those > in > t-darwin or such, a user might accidentally clear those while testing other > BOOT_CFLAGS permutations and not understand why the build was breaking. see this thread: http://gcc.gnu.org/ml/gcc/2009-09/msg00460.html and this: http://gcc.gnu.org/ml/gcc/2009-09/msg00468.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #11 from developer at sandoe-acoustics dot co dot uk 2009-09-23 16:00 --- (In reply to comment #10) > What about just leveraging PIC-code libgcc.a on darwin by creating a > libgcc_ext > with only a dummy routine and a linkage to the FSF libgcc.a. When creating > libgcc_ext, the ld option -unexported_symbols_list would be used and a file > containing all of the symbols exported from libgcc_10.5 passed to it. as far as an _ext is concerned - I don't think there's any issue with what I proposed - it also should extend to fill any gaps in 10.6 (we just leave libgcc_s out of the link line I guess). The issue is whether there's a Better Way to do the job. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #14 from developer at sandoe-acoustics dot co dot uk 2009-09-23 16:36 --- (In reply to comment #12) > However your current > approach isn't scalable (which was Mike's complaint). anything that requires an action per added function is "non-scalable" in that way. the only action needed for the _ext is to list the function in gcc/config/darwin-libgcc-ext-32B-10.X.ver and friends. (OK there's an addition for each darwin release where the content of libgcc_s changes - but there would be a change to add a new macro for the other mechanism) the effort required of wrapping the function exports in a #define NOT_HERE_BEFORE_10_X macro is probably typographically similar .. but more intrusive in the source code. However, I don't claim to understand the full range of options available from ld; So (after putting out the current fire) I'd like to take a look at that (anyone else welcome to do it first ;)) Apropos "extra compile flags" this was only to hide the new feature behind something for test purposes -- clearly if the process were adopted the flag would not be needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #58 from developer at sandoe-acoustics dot co dot uk 2009-09-23 19:40 --- Created an attachment (id=18640) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18640&action=view) cause darwin to default to strict dwarf control. Try this.. ChangeLog: 2009-09-23 Iain Sandoe *gcc/common.opt initialize dwarf_strict to -1 as an unset value. *gcc/toplev.c catch unset dwarf_strict and set to 0 *gcc/config/darwin.c catch unset dwarf_strict and set to 1 on darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #26 from developer at sandoe-acoustics dot co dot uk 2009-09-24 07:46 --- (In reply to comment #24) > I am confused why libgcc_ext needs to be built as 10.4/10.5 versions. Aren't the _ext is versioned - precisely because the symbols included in the OS version changes between OS revisions. No only that, but there are different symbol sets between 32 and 64 bit libs. As far as darwin8 and darwin9 are concerned - I have no better offer than the _ext as formulated above (I will try and update the patches in the next couple of weeks). As far as darwin10 is concerned Mike's solution needs implementation and evaluation, if we are to adopt it. I'll try and find a free machine to put darwin10 on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug bootstrap/41457] [4.5 Regression] Bootstrap failure at revision 152100
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-09-24 15:17 --- (In reply to comment #2) > Subject: Bug 41457 > > Author: jakub > Date: Thu Sep 24 13:08:11 2009 > New Revision: 152119 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152119 Thanks Jakub! powerpc-apple-darwin8 bootstraps again with this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41457
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #29 from developer at sandoe-acoustics dot co dot uk 2009-09-24 20:55 --- Created an attachment (id=18644) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18644&action=view) updated patch for 4-5 trunk (i) the added .ver files are (as yet) unchanged - so some newer (last few months) symbols would be missing. (ii) I seem to do >= 1.5 so the thing should also work "out of the box" on 10.6 ***providing*** none of the newer symbols have been already added to 10.6 libSystem.dylib. From comments here: libSystem only subsumes the symbols from 10.5's libgcc_s so we should be good to go. (iii) it's hidden behind the -muse-shared-libgcc-ext for test purposes. (iv) you will need to add DYLD_LIBRARY_PATH entries pointing to gcc and gcc/<64bit> if you want to play with it uninstalled. (v) I'm about to regtest with 152135 with this patch applied and -muse- but that's tomorrow for a result. (vi) good luck ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #31 from developer at sandoe-acoustics dot co dot uk
2009-09-24 22:42 ---
(In reply to comment #30)
>I am getting the build failure on x86_64-apple-darwin10 of...
*** No rule to make target
> `../../../../gcc-4.5-20090924/libgcc/../gcc/config/i386/darwin-libgcc-ext-32B-10.4.ver',
> needed by `libgcc_ext.10.4.dylib'. Stop.
you need to add the files in the .zip (second attachment).
should give you:
gcc/config/{i386,rs6000}/darwin-libgcc-ext-{23,64}B-10.{4,5}.ver
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815
--- Comment #65 from developer at sandoe-acoustics dot co dot uk 2009-09-25 08:11 --- (In reply to comment #64) > Subject: Bug 41405 > > Author: rth > Date: Thu Sep 24 17:02:29 2009 > New Revision: 152127 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152127 thanks Richard, bootstrapped and regtested on powerpc-apple-darwin8 : http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02242.html i686-apple-darwin9 : http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02243.html AFAICT the remaining dsymutil problem is only affecting the availability of debug symbols for the libs; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #36 from developer at sandoe-acoustics dot co dot uk 2009-09-25 10:07 --- (In reply to comment #34) > The build on i686-apple-darwin10 is going better but has a glitch. A no > time during the different stages of the bootstrap are libgcc_s.10.4.dylib and > libgcc_s.10.5.dylib created. For example, in stage1-gcc I have... 1/ OK. IIRC I *do not* build the 10.X.dylibs unless you make --with-slibdir=/usr/lib. The reason for this is that no-one other than an entity releasing a Darwin version ever needs to make those because they, and the /usr/lib/libgcc_s* are already installed on the system (or would be used from /Developer/SDKs for a cross-build). 2/ 4.4 updated smoothly from the branch and built/regtested: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02253.html 3/ 4.5 new patch above built and regtested: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02254.html 4/ I've nearly finished installing SL/Darwin10 on another box -- so I'll take a shufftie at that this evening. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #38 from developer at sandoe-acoustics dot co dot uk 2009-09-25 10:54 --- (In reply to comment #37) > I just noticed that I have been neglecting to pass > --enable-version-specific-runtime-libs to configure. What should be the impact > of that on the build (since I did get the expected libgcc-ext.10.4/5 files)? > Could that be related to the build failure on x86_64-apple-darwin10? I don't think any of this stuff makes much sense w/out --enable-version-specific-runtime-libs; I always use this to enable multiple versions of gcc installed on the same machine. I don't know if that's the root of the D10 issue - somehow I doubt it (I try not to make assumptions about future systems - and probably excluded D10 somewhere ... but hopefully I'll look at that later). > Are you using... > make -k check RUNTESTFLAGS="--target_board=unix/-muse-shared-libgcc-ext" yes. should be listed in the test results. whether this is default or not can be determined trivially (Init(1)) as and when the approach is agreed with the relevant maintainers. > The option behavior should be -muse-static-runtimes instead. different objective not related to the _ext; mea culpa if that is present in the patch; FWIW: -muse-static-runtimes is designed to allow the building of statically linked (save libSystem) objects on Darwin (this is to assist in deployment of parallel jobs on clusters - or distibution of apps using more advanced features than are standard on a given rev) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #40 from developer at sandoe-acoustics dot co dot uk 2009-09-25 19:25 --- (In reply to comment #39) > EXLIB_64FLAG = i386 close ;) -- it should be EXLIB_64FLAG = . (I think) build is nearly finished on x86_64-apple-darwin9 i686-apple-darwin10 build completed and is reg-testing now. more later/tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #46 from developer at sandoe-acoustics dot co dot uk 2009-09-26 17:28 --- Created an attachment (id=18657) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18657&action=view) much simplified version of the ext patch OK. Jack made a Good Catch there... There is a much simpler way of doing this; using the -R option on strip one can make an "ext" lib that refers to all the symbols not in the 10.X.dylib (using the ver files that generate those stub libs). So I now generate two new stub libs (_ext.10.X.dylib) that contain the set of missing symbols. The stub files refer to the newly built libgcc_s.1.dylib installed along with gcc. I don't know that "scalable" is exactly the right term - but this is '0 maintenance' unless a new version of 10.5 or 10.4 libgcc_s is made (unlikely at this stage). bootstrapped on i686-apple-darwin9, and x86_64-apple-darwin10 (reg-testing on both). more than 20 lines... but not too too much. Log: *libgcc/configure.ac: Make sure the the rpath is correct in build tree libraries when using --enable-version-specific-runtime-libs. *libgcc/configure: Regenerated. *libgcc/config/t-slibgcc-darwin: Don't make the _s.10X.dylib stubs unless we're building for /usr/lib. Build libgcc_ext.10.X.dylib containing newer symbols *gcc/config/darwin.opt: Add muse-shared-libgcc-ext to hide behind for testing. *gcc/config/darwin.h: use libgcc_ext.10.X to provide newer gcc functionality to older systems there are NO new files needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-09-28 01:18 --- (In reply to comment #6) this issue was introduced by the changes in 151901. (I can obtain a successful bootstrap by reverting the changes of 151815, the dsymutil fail is then present, not present at 151900 with the changes of 151815 reverted). thanks for the pointer to possible libtool influence, however, the libtool-version listed in (e.g.) libgfortran claims not to have changed between 151000 and152000. > So in the end this is very likely still > a dsymutil bug - no user program should run into assertions anyway. agreed; however, at the moment I can't repeat this outside the GCC build process. running the command line (listed as failing in the log) manually on the freshly-built tree does not fail. "dwarfdump -av *.o" doesn't reveal any failures. if I build a lib by hand with the objects present and then run dsymutil on it - it doesn't fail. I'm also finding it difficult to check the dwarf-4 stuff since none of google, wiki or the gcc website are pointing to a DWARF4 spec to read. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #48 from developer at sandoe-acoustics dot co dot uk 2009-09-28 07:47 --- (In reply to comment #47) > (In reply to comment #46) > It bootstraps fine here on x86_64-apple-darwin10 as well. It does ; but there's an error message about -R not being supported any more strip. The man page doesn't make any comment about this being deprecated/removed so it needs a little more investigation. If the strip approach doesn't work universally, I can revert to linking separate stub libs (using -unexported_sybols and then strip those -c). > This will reduce the total line count for each submitted patch. Well, there are two bits to this patch, the first is generic see: http://gcc.gnu.org/ml/gcc/2009-09/msg00554.html As for the rest, hopefully it won't be long before the paperwork arrives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #49 from developer at sandoe-acoustics dot co dot uk 2009-09-28 09:02 --- (In reply to comment #48) > (In reply to comment #47) > > (In reply to comment #46) > > It bootstraps fine here on x86_64-apple-darwin10 as well. > It does ; but there's an error message about -R not being supported any more > strip. *sigh* .. I can't repeat this now; reg-test results: powerpc-apple-darwin8 : http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02531.html i686-apple-darwin9 : http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02532.html x86_64-apple-darwin10 : http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02533.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #50 from developer at sandoe-acoustics dot co dot uk 2009-09-30 16:58 --- Created an attachment (id=18677) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18677&action=view) further simplified lib ext patch after some discussion with Ian Lance Taylor, I took another look at libgcc/config/t-slibgcc-darwin. This had a bug [extra dependencies] causing the second link of libgcc_s* during the install-leaf phase (where the libsubdir is ""). This was causing the wrong rpaths in the libs. So now we don't need to chance configure.ac and the changes are confined to darwin-specific code. However, there are two changes rolled together here (a) the fix for the buggy rpaths and (b) the changes to provide the libgcc_ext* and use them. I can separate them once the overall process is finally approved (although Mike has already said OK to a slightly larger version of this). -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Attachment #17770|0 |1 is obsolete|| Attachment #17771|0 |1 is obsolete|| Attachment #18644|0 |1 is obsolete|| Attachment #18657|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #52 from developer at sandoe-acoustics dot co dot uk 2009-09-30 19:54 --- (In reply to comment #51) > Looks much better than past versions... Seems like muse-shared-libgcc-ext > should be the default, and possibly that we don't even need the switch? thanks Mike, I'll do a test run on each system with it on as default (this will also cause gcc to be built with TLS internally, IIRC) - will comment when done; Agreed, would be better not to have the switch - it's only there to hide behind for debug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #55 from developer at sandoe-acoustics dot co dot uk 2009-10-01 08:36 --- (In reply to comment #54) > The new libgcc_s.dylib appears to be only of the native target architecture... it's best thought of not as "new" but "different" - it's the target for the Makefile libgcc_s$(SHLIB_EXT). In fact, we used to have intermediate targets (xxx.dylib.tmp) which you will see are no longer present. if you check the ***gcc directories, you will see that this intermediate file is not installed in the staging - nor is it installed by make install. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #57 from developer at sandoe-acoustics dot co dot uk
2009-10-01 17:22 ---
(In reply to comment #56)
> Okay. So no problem. What do you think is the best way to default on
> libgcc-ext? Just using...
I'm reg-testing on powerpc-apple-d8, i686-apple-d9 and x86_64-apple-d10
with this:
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 152363)
+++ gcc/config/darwin.h (working copy)
@@ -391,12 +391,16 @@
#define REAL_LIBGCC_SPEC \
"%{static-libgcc|static: -lgcc_eh -lgcc; \
shared-libgcc|fexceptions|fgnu-runtime: \
- %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4) \
- %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5) \
+ %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s.10.4 ) \
+ %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5 ) \
+ %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4) \
+ %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5) \
-lgcc; \
- :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4) \
- %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5) \
- -lgcc}"
+ :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s.10.4 ) \
+ %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s.10.5 ) \
+ %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_ext.10.4) \
+ %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_ext.10.5) \
+ -lgcc } "
/* We specify crt0.o as -lcrt0.o so that ld will search the library path.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #59 from developer at sandoe-acoustics dot co dot uk 2009-10-02 08:17 --- Created an attachment (id=18691) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18691&action=view) libext patch with ext on as default, debug flag removed and white space changes removed. This should, hopefully, be final. Reg-tests have completed successfully on i686-apple-darwin9 and x86_64-apple-darwin10 at m32 and m64. log: *libgcc/config/t-slibgcc-darwin: Fix embedded rpaths for --enable-version-specific-runtime-libs, build extension stub libs exposing newer features available from current libgcc_s. *gcc/config/darwin.h: Use the extension stub libraries to access newer libgcc_s features. Unfortunately, together that still makes changes amounting to 39 lines. However, I will post the reg test results and cross-reference them to here; I will post the patch and a changelog after that. Given that this issue was raised before the 4.4 branch - I assume that it should also be back-ported? (I'd imagine the patch would just apply, in fact) -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Attachment #17769|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #60 from developer at sandoe-acoustics dot co dot uk 2009-10-02 10:39 --- Reg test results: powerpc-apple darwin8 : http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00141.html i686-apple-darwin9: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00142.html compare without patch : http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00144.html [show no new fails and a considerable number of extra passes] x86_64-apple-darwin10: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg00143.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug driver/41594] New: -static-libstdc++ is not recognized as valid by the gcc driver.
although the option is parsed by g++spec.c it is not accepted by gcc. -- Summary: -static-libstdc++ is not recognized as valid by the gcc driver. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: developer at sandoe-acoustics dot co dot uk GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41594
[Bug driver/41594] -static-libstdc++ is not recognized as valid by the gcc driver.
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-10-05 19:39 --- Created an attachment (id=18713) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18713&action=view) recognize "-static-libstdc++" as a valid option log: *gcc/gcc.c: Add -static-libstdc++ to list of recognized options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41594
[Bug objc++/41595] New: object-c++ mangled local labels are not correctly recognized.
Originally (radar: 5202926) we need to make objective c internal labels local. At present the name-mangled ones are not recognized. -- Summary: object-c++ mangled local labels are not correctly recognized. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: developer at sandoe-acoustics dot co dot uk GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41595
[Bug objc++/41595] object-c++ mangled local labels are not correctly recognized.
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-10-05 20:04 --- Created an attachment (id=18714) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18714&action=view) recognize name-mangled obj-c++ internal symbols. this is modeled on the mechanism of the fix for the radar applied to apple local 4.2. However; this implementation it is different in that I have re-written it such that its effect is local to darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41595
[Bug c++/41596] New: handling of library-related options by g++spec.c causes a failure when generating pch.
The recognition of any library-related option in g++-spec.c causes the insertion of "-lstdc++". This causes link to be invoked when trying to generate PCH, which then fails. This bit me when trying to run the testsuite with /-static-libstdc++ The behavior here appears to differ from gcc where one can put "-static-libgcc" on the CL and the link phase is not invoked for PCH-generation. -- Summary: handling of library-related options by g++spec.c causes a failure when generating pch. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: developer at sandoe-acoustics dot co dot uk GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
[Bug c++/41596] handling of library-related options by g++spec.c causes a failure when generating pch.
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-10-05 20:25 --- Created an attachment (id=18715) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18715&action=view) allow specification of -static-libstdc++ on the CL while generating PCH this patch alters the behavior of g++spec.c such that it (a) notes if libstdc++ is needed (b) notes if the user has requested static-libstdc++ It only outputs "-lstdc++" if the lib is needed- and when it does it decides on the mechanism depending on the availability of static options. Finally, for platforms that don't have Bstatic/Bdynamic - it places "static-libstdc++" back into the command line so that link specs can use it to trigger substitution. log: *gcc/cp/g++spec.c(lang_specific_driver): Do not insert -lstdc++ unless we really need it. Insert 'static-libstdc++' for platforms without Bstatic/Bdynamic to allow link spec substitution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
[Bug target/41605] New: Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
if libgcc (for example) is linked statically the eh comes from the static link, however, other libraries (e.g. libfortran or libstdc++) which are still linked dynamically can refer to a different eh in libSystem. The same problem can occur when libgfortran/libstdc++/libgcc are linked statically and libgomp remains dynamic. -- Summary: Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: developer at sandoe-acoustics dot co dot uk GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-10-06
15:56 ---
Created an attachment (id=18727)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18727&action=view)
make sure that static linking of libraries is consistent
this patch provides:
(a) new spec with direct resolution for libgomp that provides a static version
LINK_COMMAND_SPECS for darwin and darwin9+
(b) file replacement specs for libstdc++.
dependencies:
if static libgcc => link libgomp, libgfortran, libstdc++ statically
if static libstdc++ || libgfortran || libgcc link libgomp statically.
bootstrapped on powerpc-apple-darwin8, i686-apple-darwin9.
object checked by hand with otool for correct library refs, reg-tested for
check-target-libgomp {m32,m64}{-static-libgcc,
static-libgfortran,static-libstdc++,}
Note static-libstdc++ will not work without changes on PR4194/PR4196
log:
*gcc/config/darwin.h(LINK_COMMAND_SPEC): Resolve fopenmp specifically
for target
(LINK_SPEC): replace dynamic libraries by static equivalents where
necessary
*gcc/config/darwin9.h(LINK_COMMAND_SPEC): Resolve fopenmp specifically
for target
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug testsuite/41609] New: Torture tests do not check "trivial.{m,mm}" for each run case.
This means that which tests are run could depend on the order in which (say)
-m32, -m64 are given in RUNTESTFLAGS. It also produces a lot of non-useful
error output on dawin9/10 where the next runtime is not yet usable with gcc.
--
Summary: Torture tests do not check "trivial.{m,mm}" for each run
case.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: developer at sandoe-acoustics dot co dot uk
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41609
[Bug testsuite/41609] Torture tests do not check "trivial.{m,mm}" for each run case.
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-10-06 17:03 --- Created an attachment (id=18728) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18728&action=view) Make the trivial test run for each options pass. log: *gcc/testsuite/lib/objc-torture.exp: New proc (objc-set-runtime-options) to be run each pass through the suite. Do not try to run m64 tests on darwin8 which has no 64bit Next Runtime *gcc/testsuite/objc/execute/execute.exp: Check applicable runtime options on each pass. *gcc/testsuite/objc/execute/exceptions/exceptions.exp: Ditto. *gcc/testsuite/objc/compile/compile.exp: Ditto. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41609
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-10-06 17:07 --- Created an attachment (id=18729) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18729&action=view) provide -B options to allow spec replacement like libxx.a%s. you will need this for the testsuite to find the static libs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-10-14 11:20 --- (In reply to comment #4) > Oh, if one wanted to, one could have libgcc_s forward the EH calls into > /usr/lib/libgcc_s.1.dylib by dlopening it and then doing dlsym on the symbols > and calling them. This would `fix' the programs that linked against a gcc > libgcc_s file that uses EH when run on a system that has EH on the system. > With that technology, I think all the mismatching here, just goes away. note1: the dependent fixes for static-libstdc++ are 41594/41596. Would you accept the solution proposed here as suitable at present? Noting that eh forwarding could be a useful enhancement at some future time? Even with potential forwarding of eh it is still desirable to enable a statically linked executable for those cases where such is useful [excepting that libSystem is always dynamic]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2010-02-14 13:46 --- confirmed, this can be reproduced outside the testsuite framework: for example... [ppc/darwin9/156749]; $ ./gcc/xgcc -B gcc ../gcc-4-5-trunk/gcc/testsuite/objc/execute/cascading-1.m -fnext-runtime -O1 -o tc -lobjc -g -save-temps $ gdb tc GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14 UTC 2009) 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 Starting program: /Volumes/ScratchCS/gcc-4-5-trunk-build/tc Reading symbols for shared libraries +++... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x466f6f20 0x9622dfd8 in objc_msgSend () (gdb) backtrace #0 0x9622dfd8 in objc_msgSend () #1 0x1f8c in main (argc=, argv=) at ../gcc-4-5-trunk/gcc/testsuite/objc/execute/cascading-1.m:33 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2010-02-14 16:04 --- (In reply to comment #2) > Track down the regression that caused this r156519 >and see what actually is the difference in generated code and/or tree/rtl >dumps. what output would be the most useful? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2010-02-14 16:32 --- Created an attachment (id=19860) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19860&action=view) generated asm differences with/without r156519 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2010-02-14 16:33 --- Created an attachment (id=19861) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19861&action=view) optimized tree diffs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2010-02-14 16:45 --- Created an attachment (id=19862) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19862&action=view) diffs for all fdump-tree-all output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2010-02-14 18:50 --- (In reply to comment #8) > Hm. So CCP through get_symbol_constant_value causes > you run the compile inside gdb, break on get_symbol_constant_value maybe I've messed something up - but setting a break on get_symbol_constant_value .. .. the cc1obj just completes with "Program exited normally'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #13 from developer at sandoe-acoustics dot co dot uk 2010-02-14 21:13 --- Created an attachment (id=19864) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19864&action=view) gdb-output for CLASS_REFERENCES_0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #15 from developer at sandoe-acoustics dot co dot uk 2010-02-14 21:53 --- (In reply to comment #14) > That doesn't make sense. The symbol is not TREE_READONLY. > > Was that dump from inside get_symbol_constant_value? yes. that was from a clean bootstrap of trunk 156760. > As the extract only happens from CCP2 I suppose that ipa-reference might > be setting TREE_READONLY on the decl becaue it's static and not written to? > So, can you try with -fno-ipa-reference? (-fdump-ipa-reference should > show "read-only var OBJC_CLASS_REFERENCES_0" if that is the problem) -fdump-ipa-reference - is unrecognized on my build - do I need a config. option to enable? -fdump-ipa-all doesn't seem to give a file named as reference... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #16 from developer at sandoe-acoustics dot co dot uk 2010-02-14 21:55 --- Created an attachment (id=19866) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19866&action=view) gimple for cascading-1.m @ trunk 156760 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #18 from developer at sandoe-acoustics dot co dot uk 2010-02-14 22:11 --- Created an attachment (id=19867) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19867&action=view) -fdump-ipa-all/static-var cascading-1.m @ trunk 156760 this is with normal options (i.e. the default for ipa-reference) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #19 from developer at sandoe-acoustics dot co dot uk 2010-02-14 22:16 --- Created an attachment (id=19868) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19868&action=view) cascading-1.m/-fdump-ipa-all/pure-const @ trunk 15670 this is with -fno-ipa-reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #21 from developer at sandoe-acoustics dot co dot uk 2010-02-14 23:22 --- Created an attachment (id=19870) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19870&action=view) asm out from -O1 -g cascading-1.m @trunk 156760 this is the current asm output - it segfaults on the objc msg call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #23 from developer at sandoe-acoustics dot co dot uk 2010-02-14 23:57 --- (In reply to comment #22) > There are no modifications visible in the assembly. But there is magic: > > .objc_cls_refs > .align 2 > L_OBJC_CLASS_REFERENCES_0: > .long L_OBJC_CLASS_NAME_0 > > what is .objc_cls_refs? DEF_SECTION (objc_cls_refs_section, SECTION_MERGE, ".objc_cls_refs", 1) If I've got this correct - this is implementing the constraint that class names are global in the NeXT runtime [at least at release 0/1]. I assume that the section merge arranges that all references to class FOO point to the same and unique class definition. > > Well, obviously some Objective-C maintainer needs to chime in and explain > things. indeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #25 from developer at sandoe-acoustics dot co dot uk 2010-02-15 19:54 --- Hm. I tried this trivial patch: Index: gcc/objc/objc-act.c === --- gcc/objc/objc-act.c (revision 156760) +++ gcc/objc/objc-act.c (working copy) @@ -2533,7 +2533,8 @@ sprintf (buf, "_OBJC_SELECTOR_REFERENCES_%d", selector_reference_idx++); decl = start_var_decl (objc_selector_type, buf); - + if (flag_next_runtime) +TREE_ADDRESSABLE (decl) = 1; return decl; } @@ -2733,6 +2734,8 @@ sprintf (buf, "_OBJC_CLASS_REFERENCES_%d", class_reference_idx++); decl = start_var_decl (objc_class_type, buf); + if (flag_next_runtime) +TREE_ADDRESSABLE (decl) = 1; return decl; } and when I check in gdb the trees are marked as addressable [checking in objc-act.c/finish_var_decl() ]. ... but something is un-doing this later - and _OBJC_CLASS_REFERENCES_0 is ending up marked as not tree addressable according to the ipa dump. any ideas where I'm going wrong? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #27 from developer at sandoe-acoustics dot co dot uk 2010-02-15 21:51 --- (In reply to comment #26) > Addressability is recomputed several times. What you probably want is mark > the > decl with the used attribute (i.e. add "used" attribute to it, set TREE_USED > (decl) = 1 and DECL_PRESERVE_P (decl) = 1). finish_var_decl() contains: mark_decl_referenced(var); - although this doesn't do anything for csts. and TREE_USED (var) = 1; adding DECL_PRESERVE_P (decl) = 1 doesn't solve the problem either.. I'll have to dig deeper into what's actually happening/required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #29 from developer at sandoe-acoustics dot co dot uk 2010-02-15 23:10 --- Created an attachment (id=19884) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19884&action=view) attach "used" attribute as well as marking vars used. Jakub's comment seems to do the trick - thanks. I've applied a "used" attribute in the same place that the TREE_USED is placed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #30 from developer at sandoe-acoustics dot co dot uk 2010-02-16 09:23 --- apropos http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00587.html do you think that _OBJC_CLASS_REFERENCES_* and _OBJC_SELECTOR_REFERENCES_* should be marked as TREE_ADDRESSABLE and DECL_PRESERVE_P in anticipation that this change (ipa* and cgraphunit responding to PRESERVE_P) will occur in the future? (I took those changes out of this patch on the grounds that they didn't currently achieve anything). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #34 from developer at sandoe-acoustics dot co dot uk 2010-02-16 14:58 --- Created an attachment (id=19889) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19889&action=view) patch with CLASS and SELECTOR refs. marked as TREE_ADDRESSABLE & DECL_PRESERVE_P (for NeXT runtime) In view of the comments in http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00597.html and http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00587.html it's clear that people feel that the bug is actually in ipa* and cgraphunit.c. However, a grep of lookup_attribute ipa* etc. suggests that altering these has possibly wide-reaching effects, which might not be welcome at this stage. I've added back in the marking of CLASS_REFERENCES_* and SELECTOR_REFERENCES_* as TREE_ADDRESSABLE and DECL_PRESERVE_P. Of course, this doesn't solve the problem unless the addition of the "used" attribute in finish_var_decl() is left in place too (although that can be removed once the underlying problem is resolved). Would it be best to close this bug with the lookup_attribute fix - and open a new bug for ipa*.c and cgraphunit.c to support DECL_PRESERVE_P and/or TREE_USED? In fact, I'm a bit confused about what combination of flags is really needed. TREE_USED appears to match in intent with "used" attribute - which is placed on the vars in objc-act.c/finish_var_decl(). DECL_PRESERVE_P presumably should only be used on the CLASS_REFERENCES/SELECTOR_REFERENCES - and thus I've placed it local to those two definitions. -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Attachment #19884|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #37 from developer at sandoe-acoustics dot co dot uk 2010-02-19 08:43 --- (In reply to comment #36) > I've checked in a slightly updated fix in r156877. Let us know if all the > regressions are fixed now. i686/powerpc-darwin9 - YES, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #40 from developer at sandoe-acoustics dot co dot uk 2010-02-19 23:28 --- (In reply to comment #39) > I checked in the real back end change in r156907. OK on i686/powerpc d9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug testsuite/41609] Torture tests do not check "trivial.{m,mm}" for each run case.
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2010-02-19 23:32 --- Created an attachment (id=19926) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19926&action=view) updated patch against 156812 gcc/testsuite/Changelog: 2009-10-06 Iain Sandoe PR teststuite/41609 * lib/objc-torture.exp: New proc (objc-set-runtime-options) to be run each pass. This function takes optional arguments to control check (a) that resulting binaries can execute, and (b) to allow trivial testcases to utilize case-specific flags. * objc/execute/execute.exp: Check runtime options on each pass. * objc/execute/exceptions/exceptions.exp: Ditto. * objc/compile/compile.exp: Ditto. -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Attachment #18728|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41609
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2010-02-19 23:36 --- Created an attachment (id=19927) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19927&action=view) updated patch against 156812 gcc/testsuite/Changelog: 2009-12-17 Iain Sandoe PR testsuite/42348 * lib/target-supports.exp: Add support for ObjC/ObjC++ tools in standard tests, (check_effective_target_objc2) New proc. (check_effective_target_next_runtime) New proc. * lib/objc.exp: Walk through the gnu/next runtime flags to determine which is actually in force, attach the appropriate includes accordingly. * lib/obj-c++.exp: Ditto. -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Attachment #19290|0 |1 is obsolete|| Attachment #19291|0 |1 is obsolete|| Attachment #19292|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2010-02-19 23:42 --- updated patches & test results: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00742.html explanation of the intention of those patches: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00712.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug bootstrap/43287] [4.5 Regression] Bootstrap fails at stage 1 on powerpc-apple-darwin9
--- Comment #14 from developer at sandoe-acoustics dot co dot uk 2010-03-09 08:54 --- (In reply to comment #12) > Bootstrapping all languages minus ADA with the patch in comment #10 succeeded > at revision 157293. at 157294 (minus ada and java) with the patch. I see the following new 4.5 regressions (possibly unrelated) FAIL: gcc.dg/vmx/7-01.c -O3 -g (internal compiler error) FAIL: gcc.dg/vmx/7-01.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/7-01a.c -O3 -g (internal compiler error) FAIL: gcc.dg/vmx/7-01a.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -g (internal compiler error) FAIL: gcc.dg/vmx/fft.c -O3 -g (test for excess errors) > > Needs testing on darwin as well as verification that there > > really isn't any indirection etc. missed (i.e. that (lo_sum ((reg X), > > (symbol_ref "foo"))) is always equivalent to (symbol_ref "foo"). > > I'll try to some testing in the coming nights, but I am leaving the > "verification ..." to those who really know the details about Darwin. ditto [157304 is building at present] - but, to be sure, this needs someone familiar with the nitty gritty of macho. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287
