[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*
--- Comment #20 from developer at sandoe-acoustics dot co dot uk 2010-04-05 08:32 --- see: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #30 from developer at sandoe-acoustics dot co dot uk 2010-04-05 08:33 --- (In reply to comment #29) Iain, Do please post the revised patch to gcc-patches with a changelog. That may incite a review from the emutls maintainers. see: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00129.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug libobjc/25359] some objc.dg-struct-layout-encoding-1 failures
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2010-04-04 08:47 --- indeed, my comment #6 is probably wrong for this PR. (There are a number of m64 structure size fails across the powerpc compiler - but that issue could well be different from the objc one which also happens at m32 for -fgnu-runtime) Does the problem you identified, Andrew, also account for the objc/execute/bf-*.m fails for gnu-runtime? (these are also structure-size issues, but m64-only - therefore, possibly part of the wider issue). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25359
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #28 from developer at sandoe-acoustics dot co dot uk 2010-04-04 20:18 --- (In reply to comment #26) Iain can you post this to gcc-patches with a ChangeLog? Well, I guess it seems to do the job (I reverted the additional copies in emutls_decl() on my local branch and re-checked). Hmm. Well, it would be good to get a review form the emutls authors - but I guess this is a busy time. IMO - this PR should be closed as fixed by the -DUSE_EMUTLS patch .. and the patch I've proposed should probably be attached to 43602. Also - AFAICT there's no reason for a few of the test-suite tls entries to be marked as requiring tls_native (tls would do). So I'll put together two patches - a reduced version of the one attached here and a patch that allows more of the g++ tls tests to run on emutls targets. I'll mark them as solving PR43602 (and this one if you like)... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #22 from developer at sandoe-acoustics dot co dot uk 2010-04-03 11:00 --- Created an attachment (id=20299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20299action=view) finalize emutls control vars before varpool_assemble_ending_decls() This provides a traverse of the emutls control var htab finalizing each. It allows the race condition patch to be applied without regression. Hopefully, by inspection, it can be seen that targetm.have_tls will bypass this and, therefore, this should only effect emutls targets. I didn't try to check if vars were already finalized in the traversal callback - on the basis that varpool_finalize_decl is efficient at that itself. Of course, the disclaimers are: (a) I'm even newer to this area of gcc than others ;) so... (b) there might be a much better/more efficient way/place to do this. Additional: following Paolo's comments on gcc I've updated emutls_decl() to copy: TREE_ADDRESSABLE, DECL_VISIBILITY_SPECIFIED, DECL_PRESERVE_P and DECL_INITAL. I haven't made the efficiency improvement mod. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug libobjc/25359] some objc.dg-struct-layout-encoding-1 failures
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2010-04-03 16:40 --- (In reply to comment #4) These failures... snip FAIL: objc.dg-struct-layout-encoding-1/t024_main.m execution test still exist in current gcc trunk on powerpc-apple-darwin9. these discrepancies in the computation of structure sizes are probably the main difference in error counts between powerpc and i686 apple-darwin*. I think this extends across the compiler - and is NOT just an objc problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25359
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #20 from developer at sandoe-acoustics dot co dot uk
2010-04-02 21:15 ---
(In reply to comment #18)
TREE_USED then?
It looks to me like the problem is more subtle.
I think it is to do with the fact that the emutls variables are proxies for the
actual ones and that the proxies are not being finalized.
I've patched current tree (+ the tree-profile.c patch) with the one below ...
... this fixes the unresolved vars problems .. but, maybe causes one
regression in g++ and a few in libgomp.fortran,
I'm looking into those -- but would really welcome input from people who know
more about emutls.
Index: gcc/varpool.c
===
--- gcc/varpool.c (revision 157942)
+++ gcc/varpool.c (working copy)
@@ -281,6 +281,17 @@
varpool_finalize_decl (tree decl)
{
struct varpool_node *node = varpool_node (decl);
+
+ /* When emulating tls, we actually see references to the control
+ variable, rather than the user-level variable. Make sure that
+ these control variables are finalized. */
+ if (!targetm.have_tls
+ TREE_CODE (decl) == VAR_DECL
+ DECL_THREAD_LOCAL_P (decl))
+{
+ tree control = emutls_decl (decl);
+ varpool_finalize_decl (control);
+}
/* FIXME: We don't really stream varpool datastructure and instead rebuild
it
by varpool_finalize_decl. This is not quite correct since this way we
can't
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #21 from developer at sandoe-acoustics dot co dot uk 2010-04-02 21:31 --- (In reply to comment #20) I'm looking into those -- but would really welcome input from people who know more about emutls. for example, is this really something that should be handled in some way from emutls_finish()? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #17 from developer at sandoe-acoustics dot co dot uk 2010-04-01 08:02 --- AFAICT the root problem does not relate to export of symbols from emutls (or to its use). Although this perhaps needs a different PR The root problem is that the emutls implementation generates symbols in the data area that are (AFAICT) translated into thread-unique addresses by _emutls_get_address. The two symbols in question are declared static and private and are being optimized away. (you will find that the profile tests work at -O0). I am not sure why they are being optimized away when there is a reference to them in the asm file -- see (b) below. The variables need to be preserved and coalesced within one binary. a/ A work-round solution is to mark the two variables PUBLIC and COMMON. I've tested that this works on i686-apple-darwin and ia32-pc-linux BUT b/ Looking at http://gcc.gnu.org/ml/gcc/2010-03/msg00482.html It is perhaps the case that other attributes are not being copied that are causing this problem. Of course, maybe this is also a limitation of emutls. I don't have time to do much on this today -- and the trunk freeze is fast approaching.. input from more experienced would be welcome... -- 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=43553
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #19 from developer at sandoe-acoustics dot co dot uk 2010-04-01 08:30 --- (In reply to comment #18) TREE_USED then? It doesn't do it... tried that first ;-) [ and it is copied] However, I see the comment that variables can change status during their life - or perhaps it's a bug... I also tried TREE_ADDRESSABLE and DECL_PRESERVED_P - but now I see that these are not copied. hmmm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Comment #11 from developer at sandoe-acoustics dot co dot uk 2010-03-27 11:59 --- It seems that objc_start_function is expecting a TREE in the objcpp case - so the error marked node is indeed unexpected. I've tried this on i686-darwin and i32-linux - but there are obviously a lot of affected platforms out there - would some of you like to try this? Index: gcc/objc/objc-act.c === --- gcc/objc/objc-act.c (revision 157761) +++ gcc/objc/objc-act.c (working copy) @@ -2391,11 +2398,17 @@ objc_push_parm (build_decl (input_location, PARM_DECL, NULL_TREE, void_type_node)); +#ifdef OBJCPLUS objc_start_function (get_identifier (TAG_GNUINIT), build_function_type (void_type_node, OBJC_VOID_AT_END), + NULL_TREE, NULL_TREE); +#else + objc_start_function (get_identifier (TAG_GNUINIT), + build_function_type (void_type_node, + OBJC_VOID_AT_END), NULL_TREE, objc_get_parm_info (0)); - +#endif body = c_begin_compound_stmt (true); add_stmt (build_function_call (input_location, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug objc++/23613] obj-c++.dg/isa-field-1.mm fails with the GNU runtime
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2010-03-27 13:10 --- see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01282.html hopefully, that's a reasonable way to fix. -- 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=23613
[Bug objc++/27249] FAIL: obj-c++.dg/encode-8.mm execution test
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-27 14:38 --- shouldn't this be NeXT-specific - i.e. skipped for -fgnu-runtime, rather than XFAILED? -- 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=27249
[Bug testsuite/43512] [4.5 regression] Many objc test failures
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2010-03-26
07:47 ---
(In reply to comment #7)
Why
---
Propchange: trunk/gcc/testsuite/objc-obj-c++-shared/Object1-implementation.h
('svn:executable' added)
Propchange: trunk/gcc/testsuite/objc-obj-c++-shared/Object1.h
('svn:executable' added)
Hmm. I think that, despite the fact that I stripped the apple-double (resource
fork) from the files, tar must still believe there's an empty fork present
which would cause them to be 'executable'. I'm sure the attribute can be
removed.
Propchange: trunk/gcc/testsuite/objc-obj-c++-shared/Protocol1.h
('svn:executable' added)
Propchange: trunk/gcc/testsuite/objc-obj-c++-shared/next-abi.h
('svn:executable' added)
Propchange: trunk/gcc/testsuite/objc-obj-c++-shared/next-mapping.h
('svn:executable' added)
---
Do they have to be executable?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43512
[Bug testsuite/43512] [4.5 regression] Many objc test failures
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2010-03-26 08:09 --- (In reply to comment #8) (In reply to comment #7) Why my first reply was rubbish (should have coffee before email). This is clearly an error on my part - in fact, looking at my trail here, they picked up the exec. attribute when copied via a FAT-32 partition during testing between darwin/linux. Do they have to be executable? No. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43512
[Bug objc/43535] ICE on objc.dg/objc-gc-4.m -fgnu-runtime
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2010-03-26 12:16 --- I believe that this test was not previously carried out with -fgnu-runtime . So, technically I think it's a failed New test rather than a regression (but I will triple-check a little later). In any event, I don't suppose we want an ICE as a response to a command line error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43535
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #11 from developer at sandoe-acoustics dot co dot uk 2010-03-26 13:42 --- (In reply to comment #9) Should I close this PR as fixed, leaving people fill new PRs for the remaining failures, or should I leave it open? IMO this should be closed - it clears the faults that arose, not because of compiler changes, but becasue of Darwin changes. I think we should deal with the remaining faults one by one - as separate issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #12 from developer at sandoe-acoustics dot co dot uk 2010-03-26 13:42 --- (In reply to comment #10) Is there any plan to backport the patches to 4.4? I'll look at that in the next couple of weeks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug testsuite/41609] Torture tests do not check trivial.{m,mm} for each run case.
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-26 13:48 --- I think this is now OK following the patches and no new issues appear to have arisen elsewhere. -- 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=41609
[Bug objc/43535] ICE on objc.dg/objc-gc-4.m -fgnu-runtime
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-26 16:36 --- (In reply to comment #3) Subject: Re: ICE on objc.dg/objc-gc-4.m -fgnu-runtime This option should not be supported or a nop there. if gc is incompatible with gnu runtime then that should be thrown out either in options processing - or in objc init.. .. I'm happy to take on doing the latter ; the question then is error or remove the flag and warn? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43535
[Bug objc/35996] ICE while building simple ObjC code with -fobjc-gc
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2010-03-26 18:20 --- Created an attachment (id=20215) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20215action=view) warn that -fobjc-gc is ignored for -fgnu-runtime and set flag_objc_gc to 0 a warning seems enough here .. although error-out would be possible. NOTE; there's no reason to skip this the tests on linux - I've taken out the *-*-darwin and confirmed that the tests pass on ia32-pc-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35996
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2010-03-26 20:09 --- also fails on *-*-darwin* with -fgnu-runtime. -- 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=23716
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Comment #10 from developer at sandoe-acoustics dot co dot uk 2010-03-26 21:44 --- (In reply to comment #9) also fails on *-*-darwin* with -fgnu-runtime. note the fail does not occur (at least on ppc darwin) with -O0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug testsuite/43512] [4.5 regression] Many objc test failures
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2010-03-25 09:04 --- (In reply to comment #0) On Linux/ia32, revision 157716 gave: Revision 157712 is OK. Those checkins: http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00552.html http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00553.html may be the causes. Yes, indeed, this check-in is the cause. The tests explicitly name -fnext-runtime which should cause the NeXT headers to be used - which are not present on a stock linux system. This was being silently ignored prior to the patch. The patches above are Part 1 of 2 - and these fails are corrected by Part 2 (which, hopefully, will be applied in the next day or so). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43512
[Bug testsuite/43512] [4.5 regression] Many objc test failures
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2010-03-25 20:03 --- (In reply to comment #2) Iain, these tests pass if the tests are run after make install because then the objc header files are found in the install tree. I tested your patch but installed first, that's why I didn't see the failures. I believe that this is one of those nasty side effects of installed/uninstalled testing.. there are two sets of headers with the same names on a Darwin system - one in the gcc installation tree - one in /usr/include/objc. The tests *should* fail on Linux in an ideal world (when -fnext-runtime is given) - because they are supposed to be finding the NeXT headers at /usr/include/objc. This is a compiler-provided path. Of course, once installed the compiler's own headers are found because it searches through all the various options.. since the header names are the same .. the fail does not occur. It's a source of potentially very subtle problems... (at least, that is my understanding of the situation). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43512
[Bug testsuite/43512] [4.5 regression] Many objc test failures
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-25 21:40 --- (In reply to comment #3) (In reply to comment #2) It's a source of potentially very subtle problems... (at least, that is my understanding of the situation). I should add that, at one stage, the headers were the same but this is now not the case (and, in fact the NeXT ones are syntactically dependent on improvements made to the apple-local version of gcc that means they generate errors with FSF gcc). I'd imagine it's unlikely that the two sets will re-converge. We might be wise to make things more explicit in FSF ObjC and the testsuite - i.e. make sure that the compiler can't fall-back to a set of headers that gives an unexpected result. Part 2 of the patch which clears this PR (if accepted) has been posted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43512
[Bug target/33120] Data not put in BSS section on Mac OS
--- Comment #15 from developer at sandoe-acoustics dot co dot uk 2010-03-24 17:39 --- (In reply to comment #14) Note that there was no libjava test failure with the patch in http://gcc.gnu.org/ml/fortran/2010-03/txt7.txt . Also with this patch the test in comment #8 was not improved. since this is re-opened a few notes .. (a) the test at comment #8 is different from the original bug since it carries out explicit initialization (as opposed to implicit). (b) I don't think the issue is the segment into which the data are assembled, but rather that the .space instruction is inefficient c.f. the .zerofill one. (c) comment (b) might lead to the observation that we could further improve things by replacing .space with .zerofill as the darwin ASM_SKIP_OP .. unfortunately, .zerofill needs state information (viz-a-viz what segment is current) or, alternatively, a priori knowledge of the target segment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120
[Bug fortran/43481] New: huge object files generated for un-initialized data
simple definitions of un-initialized data are using the .space asm directive which results in huge object files where fortran common variables are sizeable. Although this is reported against fortran, it is possible that it also manifests for other components. credit for reporting this to Andy Nelson -- Summary: huge object files generated for un-initialized data Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran 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=43481
[Bug fortran/43481] huge object files generated for un-initialized data
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2010-03-22 16:18 --- Created an attachment (id=20160) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20160action=view) reduced testcase this compiles to an 7.6Mb object on current trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43481
[Bug fortran/43481] huge object files generated for un-initialized data
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2010-03-22 16:21 --- Created an attachment (id=20161) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20161action=view) provisional fix against 157594 this is plagiarized in its entirety from apple/llvm 4.2 (was fixed in that tree in 2002 apparently). Credit for the fix should go to turley. reg-tested on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43481
[Bug target/43481] huge object files generated for un-initialized data
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2010-03-22 16:59 --- (In reply to comment #3) Also, unless turley has a copyright assignment on file with the FSF (didn't find him/her in the MAINTAINERS file), the patch unfortunately cannot be accepted. It's from the apple / llvm tree which is already under FSF license - albeit V2. INAL - but I'm under the impression that there's no barrier to ports from that tree (other than time/effort/skill). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43481
[Bug target/43481] huge object files generated for un-initialized data
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2010-03-22 18:55 --- (In reply to comment #3) Also, unless turley has a copyright assignment on file with the FSF (didn't find him/her in the MAINTAINERS file), the patch unfortunately cannot be accepted. for the record also - my typo: the fix author was Turly O'Connor (tu...@apple.com) listed in the MAINTAINER's file for the tree revision from which the patch was taken [although not listed in MAINTAINERs for trunk] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43481
[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
[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=19926action=view) updated patch against 156812 gcc/testsuite/Changelog: 2009-10-06 Iain Sandoe iain.san...@sandoe-acoustics.co.uk 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=19927action=view) updated patch against 156812 gcc/testsuite/Changelog: 2009-12-17 Iain Sandoe iain.san...@sandoe-acoustics.co.uk 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 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=19889action=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 #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=19884action=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 #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=value temporarily unavailable, due to optimizations, argv=value temporarily unavailable, due to optimizations) 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=19860action=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=19861action=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=19862action=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=19864action=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=19866action=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=19867action=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=19868action=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=19870action=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 bootstrap/42842] New: missing _MOVE_RATIO
ranlib: file: libbackend.a(graphite-scop-detection.o) has no symbols ranlib: file: libbackend.a(graphite-sese-to-poly.o) has no symbols ranlib: file: libbackend.a(vmsdbgout.o) has no symbols ranlib: file: libbackend.a(xcoffout.o) has no symbols Undefined symbols: _MOVE_RATIO, referenced from: _analyze_all_variable_accesses in libbackend.a(tree-sra.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2 last known good bootstrap (by me on this platform) 155942. -- Summary: missing _MOVE_RATIO 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-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42842
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #15 from developer at sandoe-acoustics dot co dot uk 2010-01-22 09:38 --- successful tests on darwin8/darwin9 and no further reported issues. -- 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=41605
[Bug bootstrap/41446] in-tree GMP/MPFR requires c++ as stage 1 lang; 2 object compares fail.
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2010-01-22 09:42 --- this has been resolved without any specific action - presumably as a byproduct of fixing other issues. -- 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=41446
[Bug other/39888] TLS emutls not linked to automatically on Darwin
--- Comment #63 from developer at sandoe-acoustics dot co dot uk 2010-01-22 09:59 --- this is fixed AFAIK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #14 from developer at sandoe-acoustics dot co dot uk 2010-01-04 11:49 --- (In reply to comment #13) Is this bug now fixed? AFAICT, yes - comment #9 is not the result of this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2010-01-02
16:41 ---
(In reply to comment #1)
I was able to do a C-only bootstrap of mainline with all three libraries
in-tree on x86_64-unknown-linux-gnu. I used mpc-0.8, mpfr-2.4.2, gmp-4.3.1
and
...
1. Is this a recent regression or has it always failed?
since the introduction of mpc - prior to that I had been using in-tree mpc/mpfr
with no issues.
[however the first version of mpc I've used is 0.8.1].
2. What versions of the various libraries did you use?
gmp-4-3-1, mpfr-2-4-1 source trees.
mpc-0.8.1 source tree
3. Does it fail with all versions of the libs or just some?
I haven't built with mpc prior to 0.8.1 - but these same gmp/mpfr versions
*were* OK prior to the introduction of mpc.
4. The targets listed include darwin9 and i686-linux, do they both fail for
the same reason?
yes - configure fail for mpc.
5. Do you have other versions of gmp/mpfr installed somewhere that conflict
with the bootstrap?
no, I don't install any of these libs on darwin.
I have installed on i686-linux *since*, but the fault occurred on a fresh
ubuntu 9.10 install.
6. Is there more info or investigation you can provide?
make check (mpc part) also fails when the mpc is built in tree - even when the
gm/mpfr libs are supplied using --with-{gmp,mpfr}= ... this perhaps points at
an mpc config change between 0.8 and 0.8.1 - since 0.8 works for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #10 from developer at sandoe-acoustics dot co dot uk 2009-12-31 17:07 --- (In reply to comment #9) FAIL: gfortran.dg/gomp/recursion1.f90 -Os execution test There are two problems: 1) there is a problem with specifying -fopenmp twice on the CL gfortran.dg/gomp/gomp.exp specifies it and so does the testcase (but I guess we should be robust to this)? 2) there needs to be a -B for libgomp in the gfortran.dg/gomp section of the testsuite. === I don't think there's any problem with the actual code generated by the patch, it seems to be substituting as required. I'll look into making sure that there's only one -fopenmp on the CL ... and supplying the missing -B /path/to/libgomp gfortran.dg/gomp/recursion1.f9 is a new test - (29th of Dec) and thrown up a problem not seen before you can regress the patch if you like - but I'd prefer to fix the testsuite problems... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2009-12-23 15:04 --- http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01081.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug bootstrap/42424] New: in-tree GMP/MPFR/MPC bootstrap fails.
155320 configure: error: libgmp not found or uses a different ABI. make[2]: *** [configure-stage1-mpc] Error 1 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2 NOTE; in-tree mpc works if gmp/mpfr are installed referenced with --with-gmp/--with-mpfr. -- Summary: in-tree GMP/MPFR/MPC bootstrap fails. 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-darwin9, i686-pc-linux-gnu GCC host triplet: *-apple-darwin9, i686-pc-linux-gnu GCC target triplet: *-apple-darwin9, i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug bootstrap/42400] New: objc build fails
most likely the changes of 155302 are the cause. ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function objc_substitute_decl: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:3118:14: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function build_ivar_reference: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:6826:14: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function get_super_receiver: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:8844:10: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * cc1: warnings being treated as errors ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function build_ivar_reference: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:6827:1: error: control reaches end of non-void function make[3]: *** [objcp/objcp-act.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [bootstrap] Error 2 -- Summary: objc build fails 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: i686-pc-linux-gnu, i686-apple-darwin GCC host triplet: i686-pc-linux-gnu, i686-apple-darwin GCC target triplet: i686-pc-linux-gnu, i686-apple-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
[Bug bootstrap/42400] objc build fails
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-17 11:30 --- Created an attachment (id=19337) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19337action=view) apply the new ref_operator to objc-act.c this is a mechanical change to the file, bootstrapped and checked on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
[Bug c++/41596] handling of library-related options by g++spec.c causes a failure when generating pch.
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-17 19:51 --- Created an attachment (id=19339) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19339action=view) updated patch to allow specification of -static-libstdc++ on the CL while generating PCH -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Attachment #18715|0 |1 is obsolete|| 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 #3 from developer at sandoe-acoustics dot co dot uk 2009-12-17 19:54 --- the patch has been modified following the discussions in: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00862.html http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00855.html to re-write -static-libstdc++ onto the command line even if the target supports -BStatic/dynamic. This allows such targets the option of spec substution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2009-12-14 16:47 --- there are several problems: 1/ the target-supports tests fail if called with ObjC/ObjC++ specific flags (e.g. -fgnu-runtime). 2/ there is no specific target-supports test for OBJC2 (which is needed for 64bit Next Runtime support) 3/ The tests for the gnu-runtime library usage are failing in testsuite/lib/objc.exp and obj-c++.exp. [they only detect if -fgnu-runtime is placed in the dg-options, rather than also checking the multilib options]. to allow you guys to test and comment, I'll attach patches for all three problems here - although maybe they should be three separate PRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-12-14 16:50 --- Created an attachment (id=19290) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19290action=view) add support for ObjC/ObjC++ and an effective target OBJ2 test when -fnext-runtime, -fgnu-runtime, nostdinc++ are used the testfile suffix needs to be .m/.mm as appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2009-12-14 16:54 --- Created an attachment (id=19291) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19291action=view) changes to recognize correctly which ObjC runtime is in use this (a) tracks the -fgnu-runtime/-fnext-runtime flags to detect which is in force. The libobjc-gnu is added and also made available as a %s substitution. The gnu-includes are added when the gnu runtime is in use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-12-14 16:56 --- Created an attachment (id=19292) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19292action=view) changes to recognize correctly which ObjC runtime is in use this (a) tracks the -fgnu-runtime/-fnext-runtime flags to detect which is in force. The libobjc-gnu is added and also made available as a %s spec substitution. The gnu-includes are added when the gnu runtime is in use. %s spec substitution is also catered for for the stdc++-v3 library -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2009-12-14
16:59 ---
with the patches above;
testsuite/obj-c++.dg/const-str-9.mm should have:
/* { dg-do compile { target *-*-darwin* } } */
/* { dg-skip-if { *-*-darwin* } { -fgnu-runtime } { } } */
/* { dg-skip-if { *-*-darwin* { lp64 { ! objc2 } } } { * } { } }
*/
testsuite/obj-c++.dg/template-4.mm
/* { dg-do run } */
/* { dg-skip-if { *-*-darwin* { lp64 { ! objc2 } } } { * } {
-fgnu-runtime } } */
In fact, arguably all the ObjC/ObjC++ tests should have something along these
lines - it should reduce clutter until OBJC2 support is available in FSF gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #98 from developer at sandoe-acoustics dot co dot uk 2009-12-14 18:31 --- i686-apple-darwin9 bootstraps without dsymutil fails at 155225, thanks Jakub. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-11
13:35 ---
(In reply to comment #1)
In general you can answer what we think is best by checking the llvm-gcc
sources from llvm, and in this case, we are using:
/* { dg-options -fnext-runtime -fno-constant-cfstrings } */
delete -fno-constant-cfstrings
For template-4.mm:
/* { dg-do run { target powerpc*-*-darwin* } } */
why is this being restricted to darwin (and powerpc at that)? The testcase
appears to cater for gnu runtime too...
/* { dg-require-effective-target ilp32 } */
Having said this -- we have a global problem with using ?lp32/64 in ObjC/ObjC++
testcases along with -fgnu-runtime. This flag causes xgcc/g++ to print a
warning - which means that these target supports tests always fail for
-fgnu-runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug testsuite/42348] Syntax of dg-skip-if in two obj-c++ tests
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-12-11
14:08 ---
(In reply to comment #2)
(In reply to comment #1)
For template-4.mm:
/* { dg-do run { target powerpc*-*-darwin* } } */
why is this being restricted to darwin (and powerpc at that)? The testcase
appears to cater for gnu runtime too...
well.. it does work for -fgnu-runtime, on i686 darwin9 at least... so {
target powerpc*-*-darwin* } should probably be deleted.
However, it ONLY works if the compiler is installed -- objc/NXConstStr.h is not
found otherwise (this is a separate problem, of course).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42348
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #20 from developer at sandoe-acoustics dot co dot uk
2009-12-09 11:37 ---
(In reply to comment #17)
(In reply to comment #15)
(In reply to comment #13)
You can try filing a bug report at Apple, but I think a better route
would be
to see if we can avoid linking in the system ___divdc3 from FSF GCC.
Summary (for Dominique's test case):
working [regardless of placement of -lm]:
Darwin 9 [ppc/i686]
Apple 4.0,4.2
FSF 4.5
Darwin 10
Apple 4.0, 4.2
FSF 4.5 without -lm
FSF 4.5 fails with the placement of -lm (which causes linkage of
/usr/lib/libSystem version of ___divdc3)
the latter can be emulated using Apple's 4.2 by compiling the asm output from
FSF 4.5 for Dominique's test case.
So; Apple's two compilers that produce in-line code for ___divdc3 are
apparently 'doing the right thing' (in spite of your concern about potential
optimization issues). We might look at porting the relevant .md sections to
FSF ...
The regression is in the library version of ___divdc3 supplied in Darwin10
(i.e. nothing to do with FSF gcc); This could be radared (although as you say
there is not much motivation to fix something that is unused).
I repeat my earlier question:
Why is -lm being used for this test case?
Darwin, AFAIR, does not use -lm . { see comment in gcc/config/darwin.h #define
MATH_LIBRARY }
(of course, one could argue that it should be harmless, in an ideal world)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #22 from developer at sandoe-acoustics dot co dot uk
2009-12-09 15:21 ---
(In reply to comment #21)
As a workaround in gcc I suggest to strip -lm in the darwin specific specs
one could also suggest the following patch to unix.exp (or providing a darwin
infrastructure):
@@ -30,8 +30,8 @@
#set_board_info host_library_path [file dirname [file dirname [file dirname
[file dirname [file dirname [exec [find_gcc] --print-prog-name=cc1]]/lib
-# Do not use -lm on Cygwin
-if { [istarget *-*-cygwin*] } {
+# Do not use -lm on Cygwin or Darwin
+if { [istarget *-*-cygwin*] || [istarget *-*-darwin*] } {
set_board_info mathlib
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #24 from developer at sandoe-acoustics dot co dot uk 2009-12-09 17:36 --- (In reply to comment #21) As a workaround in gcc I suggest to strip -lm in the darwin specific specs processing. Otherwise this is not a GCC bug (again), but a darwin bug - why do they always creep into gcc bugzilla ... well, the bug here is either in the gcc testsuite or dejagnu (depending on one's pov). The compiler behaves as expected when provided with the correct linker flags. The fact that this issue reveals an underlying Darwin10 bug is incidental (that bug should never bite us). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2009-12-08 20:27 --- (In reply to comment #6) A *Very* quick look following a prompt from Jack... Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is unclear what that test should do there. Try reverting out the libgcc_ext changes from gcc trunk on darwin10 instead. removing the _ext should have no effect since -lgcc, which follows it, but precedes the -lSystem should cause the math function to be linked statically from libgcc.a (4.5 version) [the _ext will cause it to be linked dynamically from libgcc_s (4.5 version)] it seems on the face of it that there's different behavior from this function as supplied by the Darwin environment [libmath=libSystem] and as supplied by gcc. Of course, it's also possible that the code differs between the static and dynamic builds of libgcc... -- 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=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2009-12-08 20:51 --- version 125.0.0) /usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 315.0.0) [macbook] f90/bug% nm /usr/lib/libSystem.B.dylib | grep divdc3 0019fa1e S $ld$hide$os10.4$___divdc3 0019fa1f S $ld$hide$os10.5$___divdc3 001640d0 T ___divdc3 This will cause a difference in behavior: for Darwin9 ___divdc3 is provided by /usr/lib/libgcc_s.1.dylib libm.dylib = libSystem.dylib (which does not define ___divdc3) So, for darwin 10, -lm will cause the system ___divdc3 to be used instead of the gcc one. For Darwin 9 there is no system provided ___divdc3 (AFAICT) .. it is supplied from libgcc_s.1.dylib. if this is a reproducible effect with a short piece of code - one would expect if to manifest using Apple's supplied 4.2 ... and a radar could be filed. I was under the impression that -lm was not used by default for Darwin (determined in the build of the gcc driver) - is this flag being manually added by the test case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #12 from developer at sandoe-acoustics dot co dot uk 2009-12-08 23:40 --- (In reply to comment #11) I think I understand why apple gcc42 does not show the problem: it does not call ___divdc3: [macbook] f90/bug% diff -up pr42333_42.s pr42333_45.s --- pr42333_42.s2009-12-08 23:00:29.0 +0100 +++ pr42333_45.s2009-12-08 23:00:07.0 +0100 ... @@ -15,68 +15,61 @@ LCFI2: movq%rax, -16(%rbp) movabsq $9214364837600034815, %rax movq%rax, -8(%rbp) - movq-16(%rbp), %rax - movq-8(%rbp), %rdx - movq%rax, -24(%rbp) - movsd -24(%rbp), %xmm1 + movq-16(%rbp), %rdx + movq-8(%rbp), %rax movq%rdx, -24(%rbp) movsd -24(%rbp), %xmm0 - movapd %xmm0, %xmm2 - addsd %xmm1, %xmm2 - movapd %xmm0, %xmm3 - subsd %xmm1, %xmm3 - movsd LC1(%rip), %xmm0 - movapd %xmm2, %xmm1 - divsd %xmm0, %xmm1 - movsd LC1(%rip), %xmm0 - movapd %xmm3, %xmm2 - divsd %xmm0, %xmm2 - movapd %xmm2, %xmm0 - movsd %xmm1, -24(%rbp) - movq-24(%rbp), %rax + movq%rax, -24(%rbp) + movsd -24(%rbp), %xmm1 + movsd LC2(%rip), %xmm3 + movsd LC2(%rip), %xmm2 + call___divdc3 movsd %xmm0, -24(%rbp) movq-24(%rbp), %rdx ... This also explain why the test compiled with -c and 4.5, but linked with 4.2 fails. So my guess about the lazy complex division seems right in libm. Could someone write a C code forcing the use of ___divdc3? hmm.. indeed and, in fact, Apple's gcc-4.0 does not call ___divdc3 either (in fact, in a quick go at manipulation of options I couldn't find a case forcing either to call it). As far as generation of a test case is concerned - why not just use the asm generated by 4.5? I'll crank up a mini with D10 tomorrow (if possible).. if the asm gives a fault on D10 with 4.2 then that should be a file-able radar. .. seems likely that there are two things here: 1. we seem to be generating (probably) less efficient code than older versions of the compiler ... and 2. possibly the ___divdc3 in /usr/lib/libSystem is faulty? has anyone tried this on PPC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[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 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=18727action=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=18728action=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=18729action=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 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=18713action=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=18714action=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=18715action=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 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=18691action=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 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 #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=18677action=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
