--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-04-25
12:32 ---
AFAICT there are a number of factors causing this and darwin8 is also affected.
A (certainly non-comprehensive) list of issues:
Darwin 8 (OSX 10.4.11)
(Objc)
There is no 64 bit NeXT runtime.
(Obj-c
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:03 ---
Created an attachment (id=17769)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17769&action=view)
patch for 4.4-branch (and 4.4.0 release)
don't forget to add the version files.
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:04 ---
Created an attachment (id=17770)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17770&action=view)
added files for the libgcc_ext patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:05 ---
Created an attachment (id=17771)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17771&action=view)
patch against 4.5 trunk
also needs the added files
--
http://gcc.gnu.org/b
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:07 ---
Sorry I got the attachments and the comment in the wrong order...
The basic issue is that TLS emulation needs to be linked just once in an
executable - but so does exception handling. Exception
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-04-27
19:15 ---
testresults:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02886.html
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02887.html
and to engage the facility you need to build your program with
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2009-08-25
12:06 ---
(In reply to comment #7)
> Use --enable-stage1-languages=c,c++
I believe that this bug also applies to powerpc-apple-darwin8 and
i686-apple-darwin9.
the suggested remedy also works.
This
--- Comment #19 from developer at sandoe-acoustics dot co dot uk
2009-09-04 08:36 ---
this also applies to powerpc-apple-darwin8 at least at 151409
--
developer at sandoe-acoustics dot co dot uk changed:
What|Removed |Added
--- Comment #21 from developer at sandoe-acoustics dot co dot uk
2009-09-04 16:27 ---
(In reply to comment #20)
> > this also applies to powerpc-apple-darwin8 at least at 151409
>
> This should be fixed now (try r151388 or newer, see pr41237).
i686-apple-darwin9 appea
--- Comment #24 from developer at sandoe-acoustics dot co dot uk
2009-09-04 17:00 ---
(In reply to comment #22 & #23)
> When you run ./config ..., you should see
>
> rm: conftest.dSYM: is a directory
> checking for default BUILD_CONFIG... conftest.o.g0.stripped
> co
--- Comment #27 from developer at sandoe-acoustics dot co dot uk
2009-09-04 19:38 ---
(In reply to comment #26)
> (In reply to comment #25)
> > Fixed with revision 151367.
this is true for powerpc-apple-darwin9 (which is the mentioned system in the
bug)
it is NOT fixed fo
t sandoe-acoustics dot co dot uk
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41296
--- Comment #1 from developer at sandoe-acoustics dot co dot uk 2009-09-07
13:32 ---
Created an attachment (id=18529)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18529&action=view)
patch allowing compare-debug to work with dwarf mach-o
this is needed to allow any mea
--- Comment #5 from developer at sandoe-acoustics dot co dot uk 2009-09-07
13:49 ---
does this help?
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00467.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
--- Comment #8 from developer at sandoe-acoustics dot co dot uk 2009-09-08
07:09 ---
(In reply to comment #6)
> I believe Mike Stump told me that it is possible that darwin's strip could
> re-order the sections. Is that possibility addressed in the current patches?
I don&#
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2009-09-08
08:54 ---
Created an attachment (id=18538)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18538&action=view)
patch allowing compare-debug to work with dwarf mach-o
this works for powerpc-apple-
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-09-08
08:49 ---
(In reply to comment #0)
> the difference appears to be the cmd LC_UUID in the stage3 object.
>
> In all probability this is harmless?
> but I've yet to find a way to strip that load
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-09-08
08:48 ---
Created an attachment (id=18537)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18537&action=view)
revised patch
adds the -no_uuid flag which is needed by powerpc darwin8 for dwarf
--- Comment #14 from developer at sandoe-acoustics dot co dot uk
2009-09-08 14:44 ---
(In reply to comment #13)
> I'm doing x86_64-apple-darwin9 now - so no need to include that tonight - I
> can
> confirm that this also needs the patch to configure with the tes
--- Comment #11 from developer at sandoe-acoustics dot co dot uk
2009-09-08 13:40 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Created an attachment (id=18538)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18538&action=view) [edit]
>
--- Comment #13 from developer at sandoe-acoustics dot co dot uk
2009-09-08 14:07 ---
(In reply to comment #12)
> I am confused then. Don't we need another patch beyond the one in
> cmpdbg-1.diff.txt to re-enable the compare-debug function on darwin?
the default BUILD_CONF
--- Comment #19 from developer at sandoe-acoustics dot co dot uk
2009-09-18 12:56 ---
(In reply to comment #18)
> Fixed or what?
Yes at 151650 (for example) on i686-apple-darwin9 (current trunk, 151837,
appears to have a different problem).
Also OK on powerpc-apple-darw
--- Comment #4 from developer at sandoe-acoustics dot co dot uk 2009-09-18
12:58 ---
FIXED as of 151837.
--
developer at sandoe-acoustics dot co dot uk changed:
What|Removed |Added
--- Comment #10 from developer at sandoe-acoustics dot co dot uk
2009-09-18 19:08 ---
on i686-apple-darwin9 bootstrap fails with a variety of different errors
depending on what --enable-checking=xx is set.
For
=yes if fails with a lot of dsymutil crashes.
=runtime it fails per the
--- Comment #15 from developer at sandoe-acoustics dot co dot uk
2009-09-19 22:45 ---
just checked; powerpc-apple-darwin9 [at 151880] this also fails.
looking through the error log there do seem to be a large number of garbage
strings in the informational messages;
e.g. ../../../gcc-4
--- Comment #11 from developer at sandoe-acoustics dot co dot uk
2009-09-20 08:00 ---
see my comment #10 on PR41395 and note that this bug also shows on
powerpc-apple-darwin9.
It DOES NOT show on powerpc-apple-darwin8 (which makes one less sure about the
likelihood of a straight
--- Comment #12 from developer at sandoe-acoustics dot co dot uk
2009-09-20 09:38 ---
(In reply to comment #11)
> see my comment #10 on PR41395 and note that this bug also shows on
> powerpc-apple-darwin9.
> It DOES NOT show on powerpc-apple-darwin8 (which makes one less sure
--- Comment #19 from developer at sandoe-acoustics dot co dot uk
2009-09-20 09:42 ---
applying
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01274.html
causes i686-apple-darwin9 to fail with the (long long) fault for all
--enable-checking=xx I've tried.
Thus, that fault seems sep
--- Comment #19 from developer at sandoe-acoustics dot co dot uk
2009-09-20 22:37 ---
(In reply to comment #16)
firstly, backing out of all mods to dwarf2out.c after 151814 both allows the
bootstrap to complete and checking the log files shows no dsymutil fails
powerpc-apple-darwin8
--- Comment #22 from developer at sandoe-acoustics dot co dot uk
2009-09-21 09:04 ---
Dominique has confirmed what I've found, that some changes beyond
151814->151815 are also significant.
test results for powerpc-apple-darwin8 and i686-apple-darwin9
http://gcc.gnu.or
--- Comment #25 from developer at sandoe-acoustics dot co dot uk
2009-09-21 12:45 ---
(In reply to comment #23)
> Created an attachment (id=18621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621&action=view) [edit]
> gcc45-pr41405.patch
thanks for the patch.
I
--- Comment #26 from developer at sandoe-acoustics dot co dot uk
2009-09-21 14:24 ---
(In reply to comment #23)
> Created an attachment (id=18621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621&action=view) [edit]
> gcc45-pr41405.patch
as pre previous c
--- Comment #28 from developer at sandoe-acoustics dot co dot uk
2009-09-21 16:46 ---
(In reply to comment #27)
> I believe I've caught all DW_OP_{implicit,stack}_value uses in dwarf2out.c, so
> likely -gstrict-dwarf wasn't used when compiling something that has been
--- Comment #31 from developer at sandoe-acoustics dot co dot uk
2009-09-21 18:50 ---
OK. this is what I've done
(a) bootstrapped with Jakub's path but modified thus
>> Common Report Var(dwarf_strict) Init(1)
- bootstrap succeeds (with the four errors mentioned in #
--- Comment #34 from developer at sandoe-acoustics dot co dot uk
2009-09-22 14:36 ---
(In reply to comment #32)
> Updated patch: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01477.html
thanks - actually I was trying this - but in the end updated to 151978...
with BOOT_CFLAGS=
--- Comment #37 from developer at sandoe-acoustics dot co dot uk
2009-09-22 16:09 ---
(In reply to comment #36)
> Remove -gdwarf-2 as well. -gdwarf-2 is the same as -g when dwarf_version
> defaults to 2 (which is true on the trunk).
> Easiest quick hack to turn -gstrict-dw
--- Comment #38 from developer at sandoe-acoustics dot co dot uk
2009-09-22 16:38 ---
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1plus-che
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-09-22
19:20 ---
(In reply to comment #6)
> I wonder if we could just trim out the symbols from libgcc that are in
> libSystem, and arrange for gcc's installed libgcc to be found first.
OK. If I understan
--- Comment #39 from developer at sandoe-acoustics dot co dot uk
2009-09-22 20:17 ---
object differences currently causing bootstrap fail - these look unrelated to
the original bug:
.. anyone throw any light on this?
stripped future.o from stage 2
07e0 63 5f 5f 5f 76 33 5f 73 72
--- Comment #43 from developer at sandoe-acoustics dot co dot uk
2009-09-22 21:42 ---
(In reply to comment #42)
> Are you building with --enable-build-with-cxx or something similar?
> libstdc++-v3 isn't normally compared. The difference you are seeing is likely
> relate
--- Comment #48 from developer at sandoe-acoustics dot co dot uk
2009-09-23 09:13 ---
(In reply to comment #43)
> (In reply to comment #42)
> > Are you building with --enable-build-with-cxx or something similar?
confirmed.
building with:
out-of-tree gmp/mpfr and --enab
t org
ReportedBy: developer at sandoe-acoustics dot co dot uk
GCC build triplet: *-apple-darwin{8,9}
GCC host triplet: *-apple-darwin{8,9}
GCC target triplet: *-apple-darwin{8,9}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41446
--- Comment #52 from developer at sandoe-acoustics dot co dot uk
2009-09-23 13:57 ---
(In reply to comment #51)
> Is there anyway to redefine or adjust gno-strict-dwarf at a target specific
> level so that for a given target that option could be set to Init(1)? Having
> to
&g
--- Comment #11 from developer at sandoe-acoustics dot co dot uk
2009-09-23 16:00 ---
(In reply to comment #10)
> What about just leveraging PIC-code libgcc.a on darwin by creating a
> libgcc_ext
> with only a dummy routine and a linkage to the FSF libgcc.a. When creating
>
--- Comment #14 from developer at sandoe-acoustics dot co dot uk
2009-09-23 16:36 ---
(In reply to comment #12)
> However your current
> approach isn't scalable (which was Mike's complaint).
anything that requires an action per added function is "non-scalable&q
--- Comment #58 from developer at sandoe-acoustics dot co dot uk
2009-09-23 19:40 ---
Created an attachment (id=18640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18640&action=view)
cause darwin to default to strict dwarf control.
Try this..
ChangeLog:
2009-09-23 Iain
--- Comment #26 from developer at sandoe-acoustics dot co dot uk
2009-09-24 07:46 ---
(In reply to comment #24)
> I am confused why libgcc_ext needs to be built as 10.4/10.5 versions. Aren't
the _ext is versioned - precisely because the symbols included in the OS
version
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-09-24
15:17 ---
(In reply to comment #2)
> Subject: Bug 41457
>
> Author: jakub
> Date: Thu Sep 24 13:08:11 2009
> New Revision: 152119
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev
--- Comment #29 from developer at sandoe-acoustics dot co dot uk
2009-09-24 20:55 ---
Created an attachment (id=18644)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18644&action=view)
updated patch for 4-5 trunk
(i) the added .ver files are (as yet) unchanged - so som
--- Comment #31 from developer at sandoe-acoustics dot co dot uk
2009-09-24 22:42 ---
(In reply to comment #30)
>I am getting the build failure on x86_64-apple-darwin10 of...
*** No rule to make target
> `../../../../gcc-4.5-20090924/libgcc/../gcc/config/i386/darwin-libgcc-e
--- Comment #65 from developer at sandoe-acoustics dot co dot uk
2009-09-25 08:11 ---
(In reply to comment #64)
> Subject: Bug 41405
>
> Author: rth
> Date: Thu Sep 24 17:02:29 2009
> New Revision: 152127
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&vi
--- Comment #36 from developer at sandoe-acoustics dot co dot uk
2009-09-25 10:07 ---
(In reply to comment #34)
> The build on i686-apple-darwin10 is going better but has a glitch. A no
> time during the different stages of the bootstrap are libgcc_s.10.4.dylib and
> libg
--- Comment #38 from developer at sandoe-acoustics dot co dot uk
2009-09-25 10:54 ---
(In reply to comment #37)
> I just noticed that I have been neglecting to pass
> --enable-version-specific-runtime-libs to configure. What should be the impact
> of that on the build (since
--- Comment #40 from developer at sandoe-acoustics dot co dot uk
2009-09-25 19:25 ---
(In reply to comment #39)
> EXLIB_64FLAG = i386
close ;) -- it should be EXLIB_64FLAG = .
(I think)
build is nearly finished on x86_64-apple-darwin9
i686-apple-darwin10 build completed and is
--- Comment #46 from developer at sandoe-acoustics dot co dot uk
2009-09-26 17:28 ---
Created an attachment (id=18657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18657&action=view)
much simplified version of the ext patch
OK. Jack made a Good Catch there...
There is
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-09-28
01:18 ---
(In reply to comment #6)
this issue was introduced by the changes in 151901.
(I can obtain a successful bootstrap by reverting the changes of 151815, the
dsymutil fail is then present, not present at
--- Comment #48 from developer at sandoe-acoustics dot co dot uk
2009-09-28 07:47 ---
(In reply to comment #47)
> (In reply to comment #46)
> It bootstraps fine here on x86_64-apple-darwin10 as well.
It does ; but there's an error message about -R not being support
--- Comment #49 from developer at sandoe-acoustics dot co dot uk
2009-09-28 09:02 ---
(In reply to comment #48)
> (In reply to comment #47)
> > (In reply to comment #46)
> > It bootstraps fine here on x86_64-apple-darwin10 as well.
> It does ; but there's an
--- Comment #50 from developer at sandoe-acoustics dot co dot uk
2009-09-30 16:58 ---
Created an attachment (id=18677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18677&action=view)
further simplified lib ext patch
after some discussion with Ian Lance Taylor, I took
--- 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
--- 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 #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 #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 #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
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 #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
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
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
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: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
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-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
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
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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 159 matches
Mail list logo
