--- Comment #21 from howarth at nitro dot med dot uc dot edu 2010-03-09
03:48 ---
Interestingly, I get...
gfortran -fgraphite-identity -O3 -Wstrict-overflow=5 -c spectop.f90
spectop.f90: In function spectop:
spectop.f90:5:0: warning: assuming signed overflow does not occur when
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-06
19:09 ---
This doesn't occur with gcc trunk on x86_64-apple-darwin10 but does for gcc
4.4.3. Perhaps backporting r151960 to avoid compact unwind code on gcc 4.4
branch for darwin10 would solve this.
--
http
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-06
20:22 ---
r151960 doesn't eliminate the problem in gcc 4.4 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-07
00:00 ---
This bug occurs in both gcc 4.4.3 and 4.4.2 on x86_64-apple-darwin10, however
it doesn't occur under x86_64-apple-darwin9. This may be a compatibility issue
with the FSF gcc unwinder code executed
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-03-07
02:01 ---
I wonder if the remaining failure on *86*-apple-darwin9 for PR41991 could also
be due to PR43099?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43277
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2010-03-06
03:45 ---
(In reply to comment #19)
I just checked in a change to mangle40.C. Did it fix the darwin failures?
No. I still get...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20100305/darwin_objdir/gcc
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2010-03-05
00:48 ---
The patch doesn't allow a bootstrap. I get...
/sw/src/fink.build/gcc45-4.4.999-20100304/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20100304/darwin_objdir/./prev-gcc/
-B/sw/lib
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-03-05
02:31 ---
Created an attachment (id=20023)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20023action=view)
revised mangle-darwin patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12909
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-03-05
02:33 ---
(In reply to comment #17)
Created an attachment (id=20023)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20023action=view) [edit]
revised mangle-darwin patch
This revised patch bootstraps
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-03-04
02:28 ---
FAIL: g++.dg/abi/mangle40.C scan-assembler weak[^\n]*_Z1fIDv4_fEvT_
FAIL: g++.dg/abi/mangle40.C scan-assembler weak[^\n]*_ZN1AIDv4_fE1tE
FAIL: g++.dg/abi/mangle41.C (test for errors, line 6)
FAIL: g++.dg
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2010-03-04
02:30 ---
/sw/src/fink.build/gcc45-4.4.999-20100303/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc45-4.4.999-20100303/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc45-4.4.999
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-03-04
02:32 ---
Created an attachment (id=20017)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20017action=view)
g++.dg/abi/mangle41.C assembly file from x86_64-apple-darwin10
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-01
01:11 ---
This also happens for i686-apple-darwin10
make[2]: Nothing to be done for `check'.
gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.5-20100228/libiberty/testsuite/../../include -o test-demangle
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-01
04:49 ---
Created an attachment (id=19992)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19992action=view)
Makefile from darwin_objdir/libiberty with commented line that eliminates the
bug
--
http
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-01
04:52 ---
I find that for i686-apple-darwin10, if I comment the line...
# Flags to pass to a recursive make.
FLAGS_TO_PASS = \
AR=$(AR) \
AR_FLAGS=$(AR_FLAGS) \
# CC=$(CC) \
CFLAGS
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
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: i686-apple
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-02-27
22:28 ---
With the patch proposed in comment 1, I now get...
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed: -D__DYNAMIC__ t.cc -fPIC -mmacosx-version-min=10.6.3
fails with Assertion failed: (class_id)
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-02-15
22:12 ---
Created an attachment (id=19883)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19883action=view)
gdb walk for PR16923 failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43086
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-02-14
23:34 ---
Posted revised patch at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00549.html
with regression test results at
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01339.html.
--
http://gcc.gnu.org
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-02-13
15:41 ---
This should probably be a P2 since it causes a regression on darwin which
breaks their weak linking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-02-13
16:04 ---
This alternative fix works as well...
--- /Users/howarth/gcc-4.5-20100211/gcc/varasm.c2010-01-20
18:46:25.0 -0500
+++ gcc/varasm.c2010-02-13 10:58:45.0 -0500
@@ -2345,7
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-02-14
02:12 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00532.html and
testsuite resuilts for proposed patch at
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg01258.html.
--
http
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-02-12
14:40 ---
Does slackware provide packaging files to show how they build their gcc?
Normally all you need to do is download
ftp://sourceware.org/pub/java/ecj-latest.jar and place it as ecj.jar in the top
of the gcc
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-02-13
05:09 ---
The weak_import attribute is described fairly well in this technote
http://developer.apple.com/mac/library/technotes/tn2002/tn2064.html#SECTION2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-02-13
06:09 ---
On darwin, it would appear that the change in r155919 is unnecessary. Using...
--- /Users/howarth/gcc-4.5-20100211/gcc/varasm.c2010-01-20
18:46:25.0 -0500
+++ gcc/varasm.c2010-02
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-02-10
21:38 ---
Even if you fix this issue, I don't believe you will be able to compile
pdftk.cc with gcc 4.3 or later...
http://gcc.gnu.org/ml/java/2008-03/msg00028.html
due to the code incorrectly mixing c++ and java
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-02-11
02:04 ---
This section in darwin.c seems a bit strange...
if (!DECL_EXTERNAL (decl)
(!TREE_PUBLIC (decl) || !DECL_WEAK (decl))
! lookup_attribute (weakref, DECL_ATTRIBUTES (decl
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 target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42982
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-02-06
03:46 ---
Could this be a side-effect of r155534...
2009-12-31 Iain Sandoe iain.san...@sandoe-acoustics.co.uk
PR target/41605
* config/darwin.h (LINK_COMMAND_SPEC): Resolve fopenmp specifically
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-02-06
03:49 ---
Is this a typo in the committed patch?
-%(link_libgcc) %o %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} \
to
+%{L*} %(link_libgcc) %o %{fprofile-arcs|fprofile-generate|coverage:-lgcov
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-02-06
05:34 ---
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 156530)
+++ gcc/config/darwin.h (working copy)
@@ -272,7 +272,7
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-02-04
23:35 ---
The new g++.dg/ext/label13.C testcase fails on *-apple-darwin*. On
x86_64-apple-darwin10, the error message is...
/sw/src/fink.build/gcc45-4.4.999-20100203/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-02-02
22:55 ---
Building gcc trunk with...
Index: configure
===
--- configure (revision 156440)
+++ configure (working copy)
@@ -7292,7 +7292,7
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-02-03
03:30 ---
Fixed for gcc 4.5 with...
Author: andreast
Date: Tue Feb 2 08:18:08 2010
New Revision: 156444
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156444
Log:
2010-02-02 Jack Howarth howa
--- Comment #42 from howarth at nitro dot med dot uc dot edu 2010-02-03
03:33 ---
Fixed on *-apple-darwin10. The gcj failures on intel darwin9 are due to a
different unwinder bug. Leaving open for darwin9.
--
howarth at nitro dot med dot uc dot edu changed:
What
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-02-02
01:55 ---
Why not remove the duplicate linkage of s-secsta.o in gnatlink and gnatmake?
There is no reason to link it in a second time since it is already in
libgnat.a.
--
http://gcc.gnu.org/bugzilla
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2010-02-01
01:47 ---
The new gcc.dg/torture/pr42898.c fails on x86_64-apple-darwin10...
FAIL: gcc.dg/torture/pr42898.c -O1 scan-tree-dump-times optimized \*ptr 1
FAIL: gcc.dg/torture/pr42898.c -O2 scan-tree-dump-times
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2010-02-01
01:50 ---
Created an attachment (id=19772)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19772action=view)
assembly for gcc.dg/torture/pr42898.c -O1 on x86_64-apple-darwin10
/sw/src/fink.build/gcc45-4.4.999
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-02-01
01:54 ---
Created an attachment (id=19773)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19773action=view)
.optimized for gcc.dg/torture/pr42898.c -O1 on x86_64-apple-darwin10
--
http://gcc.gnu.org
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-01-25
20:20 ---
Mike Stump's comment on Geoff's implementation of the attribute weak_import in
FSF gcc is...
Not earth shattering, it just sets .weak_definition or .weak_reference for
the assembler. google can find
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2010-01-05
18:27 ---
(In reply to comment #19)
pr42568 looks like a duplicate of this one.
Note that the issue seems fixed on darwin10.
This issue was radr://5613343 and has been fixed for darwin10 and later
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-01-05
19:52 ---
Might this bug be related to PR40459? Does the PR42346 test case work on gcc
pre-r148492?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42346
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-31
11:39 ---
I am now seeing...
FAIL: gfortran.dg/gomp/recursion1.f90 -Os execution test
at r155534 that wasn't present at r155526 so the proposed
fix appears to have caused a gfortran regression on x86_64-apple
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-12-30
20:50 ---
Please try an svn pull of current gcc-4_4-branch. Assuming that you have EMT64
capable hardware and want to build the native x86_64 version of the FSF gcc
compilers, the new config.guess should properly
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-29
18:25 ---
Are you building on a Core Duo (ie non-EMT64 capable) machine? If not, the
default code generation of the Apple system compiler should be to execute and
generate x86_64 code under 10.6. You can't take
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-29
18:32 ---
You might try current gcc 4.4.2 branch. It contains the latest config.guess
which determines the architecture type according to the system compiler's
default code generation for intel darwin.
--
http
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-29
18:33 ---
I meant gcc-4_4-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-29
23:37 ---
(In reply to comment #8)
--build=xxx means you're using a xxx compiler to build. Since you apparently
don't have a x86_64 compiler at hand but only a i386, you cannot do that.
You first need to build
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-30
04:14 ---
Appending -gno-strict-dwarf to the dg-options doesn't change the assembly
generated on x86_64-apple-darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-23
14:09 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00998.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42307
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-23
14:10 ---
Current behavior is correct.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-24
00:14 ---
This still appears to be broken at r155434 on x86_64-apple-darwin10 with...
gfortran -O2 -fgraphite-identity air.f90 -o air
./air
AIRFLOW IN A BOX
Version 2.0
(c) Hanley
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-12-24
00:15 ---
Still broke on x86_64-apple-darwin10.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-24
00:18 ---
Created an attachment (id=19380)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19380action=view)
assembly from 'gfortran -O2 -fgraphite-identity air.f90 --save-temps -o air' on
x86_64-apple-darwin10
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-12-24
00:20 ---
Problem doesn't exist for -O1 -fgraphite-identity on x86_64-apple-darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-12-24
01:26 ---
I still get an ICE on x86_64-apple-darwin10 at r155434 as...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-12-24
01:29 ---
This backtraces with the Apple gdb as...
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0004
0x0001004e17e8
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2009-12-24
01:35 ---
Note that gcc.dg/graphite/block-4.c also ICEs with essentially the same
backtrace...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-24
02:29 ---
On x86_64-apple-darwin10, the two new test cases are cause ICEs...
FAIL: gfortran.dg/graphite/pr42334-1.f -O (internal compiler error)
FAIL: gfortran.dg/graphite/pr42334-1.f -O (test for excess errors
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-12-24
02:34 ---
The pr42334-1.f test case fails as...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc45-4.4.999-20091223
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-24
02:37 ---
Still fails on x86_64-apple-darwin10 at r155434...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091223/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc45-4.4.999
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-12-24
03:56 ---
This can't be backtraced after the crash but the last breakpoint on
tree-ssa-loop-manip.c:425 before the crash shows...
Breakpoint 1, check_loop_closed_ssa_use (bb=0x141e793a8, use=0x141e90160
DW_AT_ranges
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 triplet
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-12-24
04:02 ---
Created an attachment (id=19382)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19382action=view)
assembly for gcc.dg/debug/dwarf2/aranges-fnsec-1.c on x86_64-apple-darwin10
Generated with...
/sw/src
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-12-22
18:29 ---
(In reply to comment #10)
I tried to build gcc on darwin to debug this but the build fails with a link
failure (sorry, don't remember exactly where). Do I need to do something
special to build
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-12-18
14:54 ---
I noticed that in libjava/sysdep/arm/backtrace.h, arm has its own definition of
_Unwind_FindEnclosingFunction. Could we use the same approach for darwin10 to
override the default
--- Comment #38 from howarth at nitro dot med dot uc dot edu 2009-12-19
00:35 ---
I've confirmed that both the WalkerTest failures and the gcj compiler crashes
on java code are eliminated on darwin10 if I duplicate the code for
_Unwind_FindEnclosingFunction
--- Comment #36 from howarth at nitro dot med dot uc dot edu 2009-12-17
23:30 ---
(In reply to comment #31)
Interestingly gcc-4.4.2 with the proposed patch,
http://gcc.gnu.org/ml/java/2009-12/msg00027.html, shows gcj crashing the same
way as gcc trunk with the same patch
(gdb
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-16
13:58 ---
Any suggestions on how we can debug this issue further on darwin? Would this
bug indicate that we are missing some section of a previous patch addressing
mangling for the darwin target?
--
http
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-16
14:32 ---
Shouldn't darwin have support for comdat? This patch, which went into FSF gcc
ages ago, suggests so...
http://gcc.gnu.org/ml/gcc/2004-01/msg02186.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-12-16
20:29 ---
What's up with the instantiation portions of the warning messages in darwin? On
Fedora 10, gcc trunk shows...
~/dist/bin/g++ mangle11.C -nostdinc++ -fmessage-length=0 -Wabi -fabi-version=1
-S -o mangle11
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-12-16
22:19 ---
So I assume darwin is the only target that uses 'a poor man's comdat group'
rather than a real one? I don't see any other targets failing these tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-15
13:53 ---
I am building with custom fink packaging for the gcc45 pre-releases. All the
important build information should be in the specs output of the compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-16
03:08 ---
Fixed on x86_64-apple-darwin10.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-15
01:56 ---
Any ideas on why we are failing this on x86_64-apple-darwin10? There we are
seeing...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091211/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: x86_64-apple-darwin*
GCC host triplet: x86_64-apple-darwin*
GCC target triplet: x86_64-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42373
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-12-15
02:06 ---
Created an attachment (id=19301)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19301action=view)
assembly from g++.dg/cpp0x/lambda/lambda-mangle.C
Created with...
/sw/src/fink.build/gcc45-4.4.999
for
errors on darwin10
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot
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=42362
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:34 ---
Created an attachment (id=19284)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19284action=view)
assembly from WalkerTest.jar in gcc trunk on x86_64-apple-darwin10
Generated with...
gcj
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:34 ---
Created an attachment (id=19285)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19285action=view)
assembly from WalkerTest.jar in gcc 4.4.2 on x86_64-apple-darwin10
Generated using...
gcj
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:36 ---
Created an attachment (id=19286)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19286action=view)
diff between assembly from gcc 4.4.2 and gcc trunk on x86_64-apple-darwin10
--
http://gcc.gnu.org
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:37 ---
Using built-in specs.
Reading specs from
/sw/lib/gcc4.5/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=gcj
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-13
22:41 ---
(In reply to comment #1)
Sounds like this should be reported to Apple really.
True except that i recall some discussion of making at least a minimal effort
to be backward compatible with older gdb's
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2009-12-10
14:32 ---
This might be a red herring but after what I observed for PR42333
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c29) I went back and looked
at how the libjava libraries and executables
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-12-09
16:47 ---
Wouldn't that be limited to a subset of darwin
@@ -30,8 +30,8 @@
#set_board_info host_library_path [file dirname [file dirname [file dirname
[file dirname [file dirname [exec [find_gcc] --print
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2009-12-09
18:40 ---
I am still a bit confused about this bug. When we leave -lm out of the linkage
of builtin-math-7.exe, where does the ___divdc3 call get resolved from?
Shouldn't it be coming libSystem since that always
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-12-09
23:06 ---
Ah, I understand now
gcc-4 -O2 builtin-math-7-reduced.c
./a.out
otool -L ./a.out
./a.out:
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
246.0.0)
/sw/lib
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-08
14:13 ---
Mike Stump says that the frame can be optimized away on darwin. However,
Apple's 4.2.1 compiler in darwin10 also appears to leave the stack frame...
[MacPro:~/bug] howarth% gcc-4.2 -O2 -fomit-frame
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-08
19:30 ---
Dominique,
It would be interesting to know what happens with a build of gcc trunk
under darwin10 if you regress out the r154282 and r154283 that introduced the
libgcc_ext feature . I suspect
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-08
19:59 ---
Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is
unclear what that test should do there. Try reverting out the libgcc_ext
changes from gcc trunk on darwin10 instead.
--
http
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-12-09
00:12 ---
(In reply to comment #13)
You can try filing a bug report at Apple, but I think a better route would be
to see if we can avoid linking in the system ___divdc3 from FSF GCC.
This may be impossible
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2009-12-09
00:19 ---
I can confirm that the gcc.dg/torture/builtin-math-7.c testcases still fail
under darwin10 if the libgcc_ext changes are regressed out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-12-09
01:11 ---
Actually, I found this file which is quite interesting in the darwin10 libgcc
open source release...
http://www.opensource.apple.com/source/libgcc/libgcc-13/stub.c
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-09
04:21 ---
(In reply to comment #6)
I have this problem of MacOSX 10.3
$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-07
14:03 ---
(In reply to comment #2)
Huh? Does plain -O2 work? Do I understand correctly that -O2 -fno-loop-block
-fno-loop-strip-mine miscompiles?
Sebastian, how can disabling graphite options but not enabling
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-07
16:54 ---
Oddly these errors don't show up on x86_64-apple-darwin9 built with mpc 0.8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
--- Comment #93 from howarth at nitro dot med dot uc dot edu 2009-12-07
18:25 ---
(In reply to comment #92)
The patches weren't reviewed/approved.
Jakub,
Could you review and approve the patches then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
--- Comment #95 from howarth at nitro dot med dot uc dot edu 2009-12-07
18:40 ---
(In reply to comment #94)
No, a quick look into MAINTAINERS could tell you that as this has nothing to
do
with OpenMP, isn't a gimplifier patch nor has anything to do with SPARC, I
can't approve
401 - 500 of 1580 matches
Mail list logo
