--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-23
16:50 ---
Look at gcc/libgcc/config/t-slibgcc-darwin, in particular...
SHLIB_LINK = $(CC) $(LIBGCC2_CFLAGS) -dynamiclib -nodefaultlibs \
-install_name @shlib_slibdir@/$(SHLIB_INSTALL_NAME
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-09-23
16:28 ---
Actually, the files darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver in
gcc/config/rs6000 and gcc/config/i386 must be used in that manner (with
-exported_symbols_list instead of -unexported_symbols_list
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-09-23
16:19 ---
Iain,
Rereading Nick's reply here...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
I guess using libgcc_s would work under Snow Leopard. However your current
approach
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-09-23
15:50 ---
What about just leveraging PIC-code libgcc.a on darwin by creating a libgcc_ext
with only a dummy routine and a linkage to the FSF libgcc.a. When creating
libgcc_ext, the ld option
--- Comment #57 from howarth at nitro dot med dot uc dot edu 2009-09-23
15:42 ---
Can we just add...
;; enable gstrict-dwarf as default
TargetSave
int gstrict_dwarf_explicit=1
in darwin.opt to achieve this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
--- Comment #56 from howarth at nitro dot med dot uc dot edu 2009-09-23
15:23 ---
(In reply to comment #54)
> For target masks, the target override routine checks the *_explicit flag and
> only changes it to the default if it wasn't explicit.
> For other variables, usuall
--- Comment #53 from howarth at nitro dot med dot uc dot edu 2009-09-23
14:25 ---
So then the most robust approach would be to add your patch to enable dwarf
debugging on darwin8 and then add...
gno-strict-dwarf
Common RejectNegative Var(dwarf_strict,0) Init(1)
Emit DWARF additions
--- Comment #51 from howarth at nitro dot med dot uc dot edu 2009-09-23
13:49 ---
Is there anyway to redefine or adjust gno-strict-dwarf at a target specific
level so that for a given target that option could be set to Init(1)? Having to
pass this through BOOT_CFLAGS seems suboptimal
--- Comment #50 from howarth at nitro dot med dot uc dot edu 2009-09-23
13:38 ---
(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 #2 from howarth at nitro dot med dot uc dot edu 2009-09-23
13:20 ---
Fixed with r151594.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2009-09-23
04:22 ---
The build failure appears to be at...
checking for _FILE_OFFSET_BITS value needed for large files... configure:
error: unsupported system, cannot find sizeof (omp_lock_t)
no
when passing BOOT_CFLAGS
--- Comment #46 from howarth at nitro dot med dot uc dot edu 2009-09-23
03:33 ---
Created an attachment (id=18633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18633&action=view)
failed buildlog for x86_64-apple-darwin10
Failed build log from x86_64-apple-darwin10 whe
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-09-23
03:02 ---
(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.
Mike,
Remember
--- Comment #43 from howarth at nitro dot med dot uc dot edu 2009-09-23
02:38 ---
Fixed as of r151961.Tested on x86_64-apple-darwin10.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2009-09-23
01:35 ---
Okay, using r152049 with...
--- gcc-4.5-20090922/gcc/common.opt.org 2009-09-22 20:58:14.0 -0400
+++ gcc-4.5-20090922/gcc/common.opt 2009-09-22 20:58:51.0 -0400
@@ -1473,7 +1473,7
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2009-09-23
00:11 ---
Is there a trick to getting BOOT_CFLAGS set from gcc/config/t-darwin? Simply
adding...
BOOT_CFLAGS = -gdwarf-3 -gstrict-dwarf -O2
doesn't work. it always is left as -O2 -g during the build.
--
--- Comment #40 from howarth at nitro dot med dot uc dot edu 2009-09-22
20:47 ---
Iain, that is odd. I had no problems last night at r151946
on x86_64-apple-darwin10. Why don't you try r151946 with
Jakub's patch applied from...
http://gcc.gnu.org/viewcvs?view=revision&r
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-09-21
17:07 ---
Do we even know for certain that older versions of bintuils really work
properly with the newer dwarf3/dwarf4? I wonder how much of the general
instability in the recent bootstraps might be related these
--- Comment #40 from howarth at nitro dot med dot uc dot edu 2009-09-20
18:27 ---
Is this the location of the additional epilogue notes being added in r147995?
@@ -8637,7 +8757,17 @@
+ frame.nregs * UNITS_PER_WORD
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-09-20
17:02 ---
(In reply to comment #16)
> As specified they should ignore dwarf codes they do not understand, not assert
> on them. Please if you care report this issue to apple (it's probably enough
>
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-20
16:24 ---
You might want to change the Summary here to "[4.5 Regression] Bootstrap broken
by r151815 on *-apple-darwin9"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-09-20
16:22 ---
Reverting r151815 also eliminates the bootstrap breakage on
x86_64-apple-darwin10. Nice catch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-09-19
23:37 ---
I should also point out that --save-temps produces identical conftest.s files
whether xgcc compiles from conftest.c or conftest.i. Only it errors when
starting from conftest.c but not conftest.i (which
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-09-19
23:26 ---
Created an attachment (id=18614)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18614&action=view)
assembly file for conftest.c created with --save-temps on x86_64-apple-darwin10
--
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-09-19
23:24 ---
Created an attachment (id=18613)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18613&action=view)
preprocessed source for conftest.c created on x86_64-apple-darwin10
--
http://gcc.
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-09-19
23:23 ---
Created an attachment (id=18612)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18612&action=view)
conftest.c file created on x86_64-apple-darwin10
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-09-19
23:22 ---
This seems strange to me. If I create the offending conftest.c test file and
execute...
/sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090919
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-09-19
23:14 ---
Same problem on x86_64-apple-darwin10 with current gcc trunk...
onfigure:5749: checking size of long long
configure:5754:
/sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc
-B/sw/src
--- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-09-19
22:47 ---
The patch...
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 151890)
+++ gcc/config/darwin.h (working copy)
@@ -372,7
--- Comment #38 from howarth at nitro dot med dot uc dot edu 2009-09-19
16:31 ---
The solution we want to implement is described below...
---
I dug into this. Based on the .s files in bugzilla, the latest gcc is
now adding dwarf
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-09-19
06:17 ---
Executing...
make -k check RUNTESTFLAGS="--target_board=unix/-Wl,-no_compact_unwind"
shows that all of the g++ regressions caused by 147995 are eliminated.
Unfortunately, this approach plays
NCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC targ
--- Comment #36 from howarth at nitro dot med dot uc dot edu 2009-09-19
02:18 ---
I can also confirm that adding -Wl,-no_compact_unwind to the linkage eliminates
the error when the g++.dg/torture/stackalign/eh-vararg-2.C test cases is
executed.
--
http://gcc.gnu.org/bugzilla
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2009-09-18
22:45 ---
We have two messages on llvm-dev which discuss the exact cause of the breakage
on darwin10 and possible fixes...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html
http
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2009-09-18
19:24 ---
If I understand those messages from llvm-dev properly, on Snow Leopard symbols
from libgcc_s are ignored and the unwinder is gotten from libSystem now. So
doesn't this mean we are just seein
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2009-09-18
18:02 ---
The comments in...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
also are useful in understanding the dimensions of the problem with darwin
>=10.6.
--
http://gcc.gnu.
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2009-09-18
16:57 ---
This issue could be a linkage issue as described here...
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
and it may be that the linkage for 10.6 needs to be adjusted
in config
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2009-09-18
13:15 ---
Have you opened a new PR for this new failure on i686-apple-darwin9 with
current gcc trunk? How exactly is the bootstrap failing in that case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41334
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-09-11
09:55 ---
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20090910/configure --prefix=/sw
--prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-09-11
09:54 ---
The pr39779.c test case is ICEing the compiler in gcc trunk on
x86_64-apple-darwin10 at r151625 as follows...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20090910/darwin_objdir/gcc/xgcc
-B/sw/src
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-09-10
13:19 ---
Iain,
I created this PR because PR41224 and PR41237 have already been closed.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: *-apple-darwin*
GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-09-10
03:52 ---
Attached files were generated under r151584 with the command...
/sw/src/fink.build/gcc45-4.4.999-20090909/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc45-4.4.999-20090909
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-09-10
03:51 ---
Created an attachment (id=18560)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18560&action=view)
gcda file for g++.dg/tree-prof/partition1.C compilation -g -fprofile-use
--
http://gcc.
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-09-10
03:50 ---
Created an attachment (id=18559)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18559&action=view)
assembly file for g++.dg/tree-prof/partition1.C compilation -g -fprofile-use
--
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-09-10
03:49 ---
Created an attachment (id=18558)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18558&action=view)
preprocessed source for g++.dg/tree-prof/partition1.C compilation -g
-fprofile-use
--
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-09-09
13:02 ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00569.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41288
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: *-apple-darwin*
GCC host triplet: *-apple-darwin*
GCC
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-09-09
01:59 ---
Ian,
Don't forget to post the cmpdbg-1.diff.txt patch with changelog onto
gcc-patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-08
23:13 ---
On x86_64-apple-darwin10 with the cmpdbg-1.diff.txt patch applied, I get...
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-09-08
13:51 ---
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?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-09-08
13:27 ---
(In reply to comment #9)
> Created an attachment (id=18538)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18538&action=view) [edit]
> patch allowing compare-debug to work with dwarf mac
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-09-08
13:16 ---
This should be a P1 because it involves regressions from gcc 4.4.1 on a primary
target (i686-apple-darwin10 at -m64).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-09-08
03:17 ---
Attempting to obtain a backtrace for test_struct_returning.x3 built with -O3
-fomit-frame-pointer under r147829, I can only get...
[MacPro:gcc/testsuite/gcc] root# gdb ./test_struct_returning.x3
GNU gdb
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-09-08
03:12 ---
The diff between the test_struct_returning.c test case as compiled with -O3
-fomit-frame-pointer under r147824 vs r147829 is...
--- r147824 2009-09-07 23:11:08.0 -0400
+++ r147829 2009-09
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-09-08
03:09 ---
Created an attachment (id=18536)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18536&action=view)
assembly file from gcc.target/x86_64/abi/test_struct_returning.c compilation,
-O3 -fomi
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-09-08
03:05 ---
Created an attachment (id=18535)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18535&action=view)
assembly file from gcc.target/x86_64/abi/test_struct_returning.c compilation,
-O3 -fomi
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-09-08
03:04 ---
Created an attachment (id=18534)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18534&action=view)
preprocessed source for gcc.target/x86_64/abi/test_struct_returning.c
compilation, -O3 -fomi
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-09-08
02:59 ---
A regression hunt shows that r147824 passes all of
gcc.target/x86_64/abi/test_struct_returning.c's execution tests but r147829
fails...
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-09-07
15:43 ---
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?
Current x86_64-apple-darwin10 has no problems
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-09-07
01:33 ---
Ignore the comments on the warnings. This was a glitch from running...
make -k check-gcc
RUNTESTFLAGS="abi-x86_64.exp=gcc.target/x86_64/abi/test_struct_returning.c"
in darwin_objdir which seem
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-09-07
01:24 ---
The output from 20090425 shows...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090425/darwin_objdir/gcc/
/sw/src/fink.build
n *-apple-darwin* at -m64
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build tripl
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-09-06
16:01 ---
Hopefully we can still use Apple's gdb to debug these EH issues on darwin10. If
I am reading...
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00074.html
correctly, the VTA merge may break the abili
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2009-09-06
15:07 ---
It duplicates my observations that this bug is only triggered on
*-apple-darwin10 at -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-09-06
00:29 ---
Okay, this issue also impacts the -m64 code generation of the
i686-apple-darwin10 target, I see the same set of failures as in Comment 12
with r151455. So this issue is darwin10 specific and isn't
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-09-05
22:05 ---
These failures in the g++ and libjava testsuites do not occur for
x86_64-apple-darwin9 with current gcc. These would appear an issue specific to
or only triggered on x86_64-apple-darwin10. I'll tr
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-09-05
19:34 ---
I am using the from the gcc build. The test case binary is built as...
otool -L eh-vararg-2.exe
eh-vararg-2.exe:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 124.1.1
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2009-09-05
16:23 ---
In case it matters, the eh-vararg-2.exe test case in r148013 fails with the
message...
terminate called after throwing an instance of 'A'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2009-09-05
16:11 ---
Richard,
Please let me know if there is a better test case than
g++.dg/torture/stackalign/eh-vararg-2.C, out of the regressions caused by
r147995, listed in Comment 12 or 13 and I'll provid
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-09-05
16:05 ---
Attached assembly from failing...
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O0 execution test
introduced by r147995 was produced for r147989 and r1478013 using the
commands...
/sw/src/fink.build
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-09-05
16:03 ---
Created an attachment (id=18512)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18512&action=view)
g++.dg/torture/stackalign/eh-vararg-2.C assembly on x86_64-apple-darwin10 at
r148013
--
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-09-05
16:02 ---
Created an attachment (id=18511)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18511&action=view)
g++.dg/torture/stackalign/eh-vararg-2.C assembly on x86_64-apple-darwin10 at
r147989
--
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-05
16:01 ---
Created an attachment (id=18510)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18510&action=view)
g++.dg/torture/stackalign/eh-vararg-2.C preprocessed source on
x86_64-apple-darwin10 at
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-09-05
15:58 ---
Looking at the assembly output from the testcase...
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -O0 execution test
the diff between that generated in r147989 and r1478013 is...
---
/sw/src
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-09-05
15:32 ---
We also picked up failures in the gcc testsuite between r147989 and r1478013
of...
FAIL: gcc.dg/cleanup-12.c execution test
FAIL: gcc.dg/cleanup-8.c execution test
in case these are directly related to
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-09-05
15:25 ---
In r147989, we had no regressions in x86_64-apple-darwin10 in the g++
testsuite. However, in r148013 (which is after the fix for PR 40304), we have
the following g++ testsuite failures which still exist
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-09-05
14:27 ---
I just noticed PR 40304 which fixed regressions stack unwind from r147995. Will
move testing up to that revision to try to reduce the noise when looking for
residual regressions in current gcc trunk that
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-09-05
14:02 ---
Still running make check on r147995 but that revision appears to have caused
massive regressions in testsuite which aren't present in currently in gcc
trunk. Will look for any other test cases outsi
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-09-05
13:35 ---
Created an attachment (id=18505)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18505&action=view)
testsuite results for r147989 on x86_64-apple-darwin10
--
http://gcc.gnu.org/b
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-09-05
08:58 ---
Author: rth
Date: Sat May 30 00:33:46 2009
New Revision: 147995
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147995
Log:
* cfgcleanup.c (try_crossjump_to_edge): Only s
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-09-05
08:57 ---
r147989 without regressions. The regressions start with r147995.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-09-05
08:08 ---
r147982 without regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-09-05
07:14 ---
Second round of regression hunting shows..
r147974 without regressions
r147995 with regressions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-09-05
01:24 ---
First round of regression hunting shows that r146781 (4/25/09) passes the
libjava like gcc 4.4.1 but r148013 (5/31/09) shows the additional 120+ libjava
failures.
--
http://gcc.gnu.org/bugzilla
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-09-04
19:52 ---
I would wait until none of the other major targets are reporting failures in
comparing stage2 and stage3 (hopefully later today). If it still fails, then
report it.
--
http://gcc.gnu.org/bugzilla
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2009-09-04
19:18 ---
(In reply to comment #25)
> Fixed with revision 151367.
>
Apparently, not since Iain was on r151409, however
it might be fixed after the patch from...
http://gcc.gnu.org/ml/gcc-patches/2009-09/ms
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-09-04
16:57 ---
If you follow the recent posts for Bug bootstrap/41241, you will see that there
is still some residual break even on i586 linux. I won't worry too much just
yet.
--
http://gcc.gnu.org/bug
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-09-04
12:53 ---
Dominique,
Also if you are bothering to run the test suite on i686-apple-darwin9
periodically, you might as well shoot the results over to the gcc-testresults
mailing list (since Apple has never set up
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-09-04
12:50 ---
Can you try testing x86_64-apple-darwin9 so I an focus on a regression hunt for
x86_64-apple-darwin10?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-09-03
23:16 ---
The bootstrap completes normally now on x86_64-apple-darwin10 with r151394.
Regression testing now and will post to gcc-testresults. A quick and dirty test
with himenoBMTxpa.c compiled with -O3 -g
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-09-03
17:08 ---
This breakage is likely the same issue as PR41241 which apparently is a latent
bug exposed by IRA. Watch for the fix to PR41241 and test again with that fix
applied.
--
http://gcc.gnu.org/bugzilla
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-09-03
16:32 ---
My mistake. I believe dwarfdump is showing the debug symbols and not the
sections. The stage2 build apparently doesn't generate any debug symbols.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-03
15:26 ---
Dominique,
Can you run dwarfdump on a stage2 and stage3 binary that differ from this
failed build on powerpc-apple-darwin9? Is there actual differences or is the
stage2 binary empty like on x86_64
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-09-03
15:24 ---
Can you try a x86_64-apple-darwin9 bootstrap as well? It is puzzling that on
x86_64-apple-darwin10, the corresponding dwarfdump for the stage2 binaries is
empty.
--
http://gcc.gnu.org/bugzilla
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-09-03
13:00 ---
Joesph,
Thanks for the clarifications. The origin of the patch in Comment 20 was
Mike's suggestion that we needed the change from Apple's gcc in Comment 22. It
would appear neither are really
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-09-03
00:56 ---
Mike,
Regarding passing -m32 within the x86_64 host case, I was considering the
case of trying to cross compile the i686-apple-darwin10 target on the
x86_64-apple-darwin10 host. While this sounds
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2009-09-02
23:37 ---
Mike,
I double checked and using tentative_cc doesn't results in a failure in
configure at...
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checkin
701 - 800 of 1589 matches
Mail list logo
