--- 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/gc
--- 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
--- 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
--- 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
--- Comment #6 from developer at sandoe-acoustics dot co dot uk 2010-04-03
16:40 ---
(In reply to comment #4)
> These failures...
> FAIL: objc.dg-struct-layout-encoding-1/t024_main.m execution test
>
> still exist in current gcc trunk on powerpc-apple-darwin9.
these disc
--- 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=20299&action=view)
finalize emutls control vars before varpool_assemble_ending_decls()
This provides a trav
--- 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 hand
--- 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
--- 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
--- 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
--- 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|Re
--- 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|Re
--- 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
--- 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
--- 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
--- 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=20215&action=view)
warn that -fobjc-gc is ignored for -fgnu-runtime and set flag_objc_gc to 0
a warnin
--- 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 sho
--- 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
--- 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
--- 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 fault
--- 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
--- 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 t
--- 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)
>
> Propc
--- 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
--- 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
--- 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.
--- 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 #
--- 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
--- 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
--- 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=20161&action=view)
provisional fix against 157594
this is plagiarized in its entirety from apple/llvm 4
--- 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=20160&action=view)
reduced testcase
this compiles to an 7.6Mb object on current trunk.
--
http://gcc.
ReportedBy: developer at sandoe-acoustics dot co dot uk
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43481
--- 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 followi
--- 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.
--- 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 te
--- 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 tes
--- 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
--- 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://
--- 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_
--- 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
--- 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
--- 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, se
--- 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
--- 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:
--- 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 se
--- 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-re
--- 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
--- 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
--- 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 o
--- 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
--- 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 - bu
--- 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
--- 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
--- 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_
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
...
--- 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/g
--- 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
ndoe-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
--- 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-li
--- 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=19339&action=view)
updated patch to allow specification of -static-libstdc++ on the CL while
generat
--- 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=19337&action=view)
apply the new ref_operator to objc-act.c
this is a mechanical change to the file, boots
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
--- 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
--- 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" } { &q
--- 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=19292&action=view)
changes to recognize correctly which ObjC runtime is in use
this (a) tracks the -fgnu-
--- 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=19291&action=view)
changes to recognize correctly which ObjC runtime is in use
this (a) tracks the -fgnu-
--- 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=19290&action=view)
add support for ObjC/ObjC++ and an effective target OBJ2 test
when -fnext-runtime, -fgnu-
--- 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
--- 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
--- 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 "-f
--- 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 th
--- 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
infrastruct
--- 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
> > > woul
--- 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
> -
--- 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 divdc
--- 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
--- 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 cal
--- 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
--- 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/l
at sandoe-acoustics dot co dot uk
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41609
--- 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 sp
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
--- 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 alt
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: *-*-*
--- 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
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
--- 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: Ad
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
--- 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
--- 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
--- 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_6
--- 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&#
--- 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
1 - 100 of 159 matches
Mail list logo
