--- 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 #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 #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 #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 #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 #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
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 #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
--- 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 #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
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 #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
--- 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 #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 #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
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 #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
--- 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 #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-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
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 #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.
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 159 matches
Mail list logo
