--- Comment #36 from mikpe at it dot uu dot se 2010-04-13 16:51 ---
(In reply to comment #35)
I've been trying this on gcc trunk, and it doesn't have the problem.
It seems that merging is not done.
I get
...
0x8684 f2: @0x8808
Compact model 1
0xb1 0x08 pop {r3}
0x84
--- Comment #34 from mikpe at it dot uu dot se 2010-04-12 19:03 ---
Created an attachment (id=20371)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20371action=view)
eliminate use of _Unwind_GetRegionStart on ARM, take 2
The previous patch to eliminate _Unwind_GetRegionStart on ARM
--- Comment #33 from mikpe at it dot uu dot se 2010-04-08 12:14 ---
Created an attachment (id=20333)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20333action=view)
eliminate use of _Unwind_GetRegionStart on ARM, part 1
Here's a preliminary patch to eliminate the functional
--- Comment #32 from mikpe at it dot uu dot se 2010-03-31 21:43 ---
(In reply to comment #31)
There appears to be a mistaken presumption running through this thread that
there is a 1-1 mapping between unwind blocks and source language functions.
This is not the case, and any code
--- Comment #28 from mikpe at it dot uu dot se 2010-03-30 13:21 ---
I've looked at the amount of .ARM.exidx entry merging being done and its
consequences for the various unwinders in gcc. Currently only table entries
with immediate (inlined) data are merged, and for that all of gcc
--- Comment #30 from mikpe at it dot uu dot se 2010-03-30 15:09 ---
(In reply to comment #29)
Wouldn't it be better to just remove _Unwind_GetRegionStart?
This function is not part of the ARM EABI, and removing it would expose any
(already broken) users at compile time.
No.
First
--- Comment #25 from mikpe at it dot uu dot se 2010-03-20 22:10 ---
(In reply to comment #24)
This rings a bell and the comment in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206#c8
is probably related.
I don't think this is at all the same as PR29206. PR29206 is very old now
--- Comment #26 from mikpe at it dot uu dot se 2010-03-20 22:36 ---
Created an attachment (id=20147)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20147action=view)
test program to take a stack trace using _Unwind_ API
I'm attaching a test program which sets up a predictable call
--- Comment #23 from mikpe at it dot uu dot se 2010-03-19 23:20 ---
While working on another debugging patch I noticed something that I think might
explain the libjava regressions, especially the stack trace ones.
The binutils change breaks _Unwind_GetRegionStart().
Example: We have
--- Comment #21 from mikpe at it dot uu dot se 2010-03-17 21:13 ---
(In reply to comment #20)
no change in the libjava testsuite when built with these binutils
But that's still thumb not arm like in comment #16? All my results are from
plain arm (armv5tel) builds.
--
http
--- Comment #22 from mikpe at it dot uu dot se 2010-03-17 21:23 ---
I did another binutils experiment. I reverted my patch to disable general
merging of table entries, and instead disabled generating new and merging
cantunwind entries. With that binutils libjava regressed just like
--- Comment #17 from mikpe at it dot uu dot se 2010-03-16 17:29 ---
I decided to attack things from the binutils side. The problematic binutils
change rolls two distinct changes into one (add cantunwind table entries, merge
adjacent equivalent table entries). Disabling the merge part
--- Comment #19 from mikpe at it dot uu dot se 2010-03-16 23:39 ---
(In reply to comment #18)
rebuilding binutils 2.20.1 with the patch from comment #17 shows one
regression:
Running /home/doko/binutils/binutils-2.20.1/ld/testsuite/ld-arm/arm-elf.exp
...
FAIL: ld-arm/unwind-4
I
--- Comment #14 from mikpe at it dot uu dot se 2010-03-15 09:09 ---
The bug was fixed for 4.5 by r148072:
2009-06-02 Richard Earnshaw rearn...@arm.com
* arm.c (arm_get_frame_offsets): Prefer using r3 for padding a
push/pop multiple to 8-byte alignment.
That change
--- Comment #13 from mikpe at it dot uu dot se 2010-03-04 10:16 ---
With binutils-2.20.51.20100223, gcc-4.5-20090327 regresses libjava as described
here but gcc-4.5-20100225 does not.
Starting bisection on trunk (with 24+ hour build/test cycles, that's going to
take a while
--- Comment #11 from mikpe at it dot uu dot se 2010-02-22 21:49 ---
A recent 4.4 with the four unwind-related fixes I identified in CodeSourcery
G++ lite 2009q3-67 applied still regresses in libjava as before with recent
binutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #10 from mikpe at it dot uu dot se 2010-02-19 23:32 ---
The binutils patch that broke libjava came from CodeSourcery, so I decided to
test their latest G++ lite for arm-linux-gnueabi (2009q3-67). That compiler is
based on gcc-4.4.1, and it does not have the libjava
--- Comment #8 from mikpe at it dot uu dot se 2010-02-15 22:26 ---
I've identified http://sourceware.org/ml/binutils-cvs/2009-05/msg00021.html
as the source of this regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
--- You are receiving this mail because
--- Comment #6 from mikpe at it dot uu dot se 2010-02-13 20:49 ---
A bisection through the binutils weekly and daily snapshots has identified
090505 as the last good snapshot and 090506 as the first bad one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
--- You
--- Comment #5 from mikpe at it dot uu dot se 2010-02-06 15:36 ---
Same failures when bootstrapped with binutils-2.20.51.20100202. So there's no
fix on binutils trunk to be identified and backported. I'll try to identify the
point where the regression was introduced instead
--- Comment #4 from mikpe at it dot uu dot se 2010-02-05 15:40 ---
Further experiments show that the failures are triggered by using the
binutils-2.20 version of ld when bootstrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
--- You are receiving this mail because
--- Comment #3 from mikpe at it dot uu dot se 2010-02-03 14:51 ---
gcc-4.4.3 with binutils-2.20 fails StackTrace2 and Throw_3, reverting to
binutils-2.19.1 eliminated those two failures.
Bootstrapping with binutils-2.19.1 but running the test suite with
binutils-2.20 did not trigger
--- Comment #2 from mikpe at it dot uu dot se 2010-01-25 09:33 ---
I had very recently updated binutils from 2.19.1 to 2.20 + branch updates +
some fixes from trunk. Going back to binutils 2.19.1 while changing nothing
else eliminated the StackTrace2 and Throw_3 failures from gcc-4.3
--- Comment #1 from mikpe at it dot uu dot se 2010-01-24 16:04 ---
I'm now seeing failures in StackTrace2 and Throw_3 on arm-linux-gnueabi with
gcc-4.3 branch which I didn't use to see. gcc-4.4 branch doesn't fail for me on
these two, but both 4.4 and 4.3 fail (as always) on Throw_2
--- Comment #2 from mikpe at it dot uu dot se 2010-01-17 19:08 ---
Reproduced with an alpha-unknown-linux cross hosted on i686, built from
gcc-4.4-20100112.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--- Comment #4 from mikpe at it dot uu dot se 2010-01-17 19:52 ---
Created an attachment (id=19638)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19638action=view)
reduced test case
I'm attaching a really tiny test case. The trigger appears to be a 2-byte load
from the stack
--- Comment #7 from mikpe at it dot uu dot se 2010-01-17 21:36 ---
Uros' proposed patch fixes the ICE in gcc-4.5. It doesn't apply to 4.4 though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
--- You are receiving this mail because: ---
You reported the bug
--- Comment #9 from mikpe at it dot uu dot se 2010-01-17 22:32 ---
Uros' proposed fix for 4.4 and 4.3 fixes the ICE on both branches.
The original report stated that 4.3 doesn't ICE. A vanilla 4.3-20100103
definitely ICEs for me on the reduced test case.
--
http://gcc.gnu.org
--- Comment #10 from mikpe at it dot uu dot se 2009-10-16 15:16 ---
(In reply to comment #7)
I'm currently bootstrapping and testing a patch which disable section anchors
on arm. It will be interesting to see if it fixes any testsuite failures.
Done. It caused no new failures
--- Comment #7 from mikpe at it dot uu dot se 2009-10-15 14:12 ---
(In reply to comment #6)
A bisection has identified revision 139725 as the origin of this regression.
That revision added support for -fsection-anchors on arm and enabled it by
default at -O1 and above. Compiling
--- Comment #8 from mikpe at it dot uu dot se 2009-10-15 14:14 ---
Created an attachment (id=18799)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18799action=view)
kludge to disable section anchors on arm for gcc-4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41684
--- Comment #2 from mikpe at it dot uu dot se 2009-10-14 17:07 ---
A binary search through the gcc-4.4 snapshots has identified 4.4-20080822 as
the last good(*) snapshot and 4.4-20080829 as the first bad one.
(*) 4.4 snapshots around this time also cause the following failures
--- Comment #6 from mikpe at it dot uu dot se 2009-10-15 02:09 ---
A bisection has identified revision 139725 as the origin of this regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41684
--- You are receiving this mail because: ---
You are on the CC list
--- Comment #1 from mikpe at it dot uu dot se 2009-10-13 22:02 ---
Confirmed. I've built binutils-2.19.1 and binutils-2.19.92 with gcc-4.3.4 (plus
loads of well-tested fixes) and gcc-4.4.1 vanilla on an armv5tel-linux-gnueabi
machine, and for both binutils versions using gcc-4.4.1
--- Comment #1 from mikpe at it dot uu dot se 2009-07-26 12:54 ---
Looks like fallout from revision 144323. As far as I can tell the warning is
informational (ABI change from 4.3) so should be suppressed or ignored in the
test suite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #6 from mikpe at it dot uu dot se 2009-07-19 22:29 ---
This was fixed for 4.4 by revision 133117, which did a fair amount of stack
frame management changes. Applying that change to 4.3-20090712 fixes this test
case also for 4.3.
I'm not in a position to do a full regression
--- Comment #5 from mikpe at it dot uu dot se 2009-07-11 15:23 ---
The bug occurs on OABI with gcc-4.3-20090705 but not with gcc-4.4-20090707.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642
--- You are receiving this mail because: ---
You are on the CC list
--- Comment #1 from mikpe at it dot uu dot se 2009-06-17 18:51 ---
Dupe of PR40268/PR40061.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40477
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
To UNSUBSCRIBE, email
--- Comment #13 from mikpe at it dot uu dot se 2009-06-11 00:01 ---
(In reply to comment #11)
Fixed.
Not quite. I'm trying to build gcc-4.4-20090609 on powerpc64-unknown-linux-gnu,
with binutils 2.17.50.0.6-6, configured with --enable-languages=c,ada
--with-cpu=default32 --disable
--- Comment #4 from mikpe at it dot uu dot se 2009-05-28 08:40 ---
(In reply to comment #3)
I just tried this with gfortran 4.3.3 that I have on my ubuntu box. I don't
get
a failure with arm-linux-gnueabi. Can you verify that this still exists with
arm-linux configurations
--- Comment #5 from mikpe at it dot uu dot se 2009-05-22 10:07 ---
Created an attachment (id=17900)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17900action=view)
put ARM EABI atomic builtins in both shared and static libgcc
I reviewed the original ARM EABI atomic builtins code
--- Comment #7 from mikpe at it dot uu dot se 2009-05-22 11:16 ---
(In reply to comment #6)
This patch is obviously wrong - if you put things in shared libgcc you
also need to assign symbol versions to them based on the version in which
they were actually added.
Yeah, I realized
--
mikpe at it dot uu dot se changed:
What|Removed |Added
Attachment #17900|0 |1
is obsolete||
http://gcc.gnu.org
--- Comment #8 from mikpe at it dot uu dot se 2009-05-22 19:18 ---
Created an attachment (id=17902)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17902action=view)
always pass -lgcc to linker
The link error reported by Matthias Klose is caused by the following:
1. g++ links shared
--- Comment #2 from mikpe at it dot uu dot se 2008-03-16 16:49 ---
(In reply to comment #1)
This happens with 4.1, 4.2 and trunk on old ABI. Apparently it doesn't
happen with EABI.
I see the problem too, on Linux/ARM/OABI with gcc-4.1.2.
However, the problem is in the test case
45 matches
Mail list logo
