--- Comment #18 from uweigand at gcc dot gnu dot org 2010-09-07 19:18
---
(In reply to comment #17)
I am thinking in the same direction. merge_assign_reloads is dated by 1993.
Since then it was not practically changed. I guess postreload can remove
unecessary loads
--- Comment #16 from uweigand at gcc dot gnu dot org 2010-09-06 16:57
---
(In reply to comment #15)
Ulrih, I've just wanted to post the following when I found that you already
posted analogous conclusion. I should have been on CC to see your comment
right away. The problem
--- Comment #14 from uweigand at gcc dot gnu dot org 2010-09-03 18:30
---
(In reply to comment #12)
Yes, it would but I think the reload should still generate the right code in
this particular order of insns. IMHO, fixing the order of insn is not the
right thing to do because
--- Comment #18 from uweigand at gcc dot gnu dot org 2010-08-02 19:25
---
(In reply to comment #17)
Someone might want to try this again after the fix for PR 38582.
It's a lot better, but still not real good. I'm now seeing on a QS22 (ppu -
spu cross compiler):
-O0: 0m9.983s
-O1
--- Comment #4 from uweigand at gcc dot gnu dot org 2010-07-31 15:46
---
Subject: Bug 45112
Author: uweigand
Date: Sat Jul 31 15:46:15 2010
New Revision: 162783
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162783
Log:
gcc/
PR c++/45112
* cp/decl.c
--- Comment #5 from uweigand at gcc dot gnu dot org 2010-07-31 15:48
---
Fixed in 4.5 branch (for 4.5.2) as well.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from uweigand at gcc dot gnu dot org 2010-07-31 17:43
---
Subject: Bug 45112
Author: uweigand
Date: Sat Jul 31 17:42:48 2010
New Revision: 162785
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162785
Log:
Move PR c++/45112 ChangeLog entry to correct location
--- Comment #7 from uweigand at gcc dot gnu dot org 2010-07-31 17:44
---
Subject: Bug 45112
Author: uweigand
Date: Sat Jul 31 17:43:59 2010
New Revision: 162786
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162786
Log:
Move PR c++/45112 ChangeLog entry to correct location
--- Comment #2 from uweigand at gcc dot gnu dot org 2010-07-30 15:50
---
Subject: Bug 45112
Author: uweigand
Date: Fri Jul 30 15:49:34 2010
New Revision: 162716
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162716
Log:
gcc/
PR c++/45112
* cp/decl.c
--- Comment #3 from uweigand at gcc dot gnu dot org 2010-07-30 16:19
---
Fixed in mainline. Will check in to 4.5 after 4.5.1 release.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from uweigand at gcc dot gnu dot org 2010-07-28 18:00
---
Subject: Bug 42509
Author: uweigand
Date: Wed Jul 28 18:00:08 2010
New Revision: 162650
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162650
Log:
Backport from mainline:
2010-04-03
--- Comment #30 from uweigand at gcc dot gnu dot org 2010-07-28 18:01
---
Backported fix to 4.4 branch as well. The bug should now be fixed everywhere.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45112
--- Comment #1 from uweigand at gcc dot gnu dot org 2010-07-28 21:47
---
Proposed fix posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02223.html
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from uweigand at gcc dot gnu dot org 2010-07-15 12:38
---
Subject: Bug 44877
Author: uweigand
Date: Thu Jul 15 12:37:03 2010
New Revision: 162220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162220
Log:
PR target/44877
* config/spu/spu.c
--- Comment #3 from uweigand at gcc dot gnu dot org 2010-07-13 15:15
---
Also fails on spu-elf.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from uweigand at gcc dot gnu dot org 2010-07-13 16:35
---
Also fails on spu-elf.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from uweigand at gcc dot gnu dot org 2010-07-02 11:48
---
Subject: Bug 44707
Author: uweigand
Date: Fri Jul 2 11:48:30 2010
New Revision: 161703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161703
Log:
ChangeLog:
PR target/44707
* config/rs6000
--- Comment #5 from uweigand at gcc dot gnu dot org 2010-07-02 11:50
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot
|dot org
--- Comment #3 from uweigand at gcc dot gnu dot org 2010-07-01 19:14
---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00082.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707
--- Comment #1 from uweigand at gcc dot gnu dot org 2010-06-29 16:56
---
I agree, this looks like a longstanding bug in
rs6000_legitimize_reload_address.
What happens here is that find_reloads is called on this insn:
(insn 15 8 18 2 pr44707.c:13 (asm_operands/v (/* %0 %1 %2 %3 %4
--- Comment #2 from uweigand at gcc dot gnu dot org 2010-06-29 17:03
---
Created an attachment (id=21041)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21041action=view)
Recognize (lo_sum (high ...) ...) in rs6000_legitimize_reload_address
It seems to me that simply extending
--- Comment #8 from uweigand at gcc dot gnu dot org 2010-05-11 13:57
---
(In reply to comment #7)
Not sure what's the state here. Is 4.4 broken now?
Here's the status as far as I know. I had checked in a patch:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00254.html
to fix
--- Comment #1 from uweigand at gcc dot gnu dot org 2010-03-08 16:11
---
Why doesn't this make sense? The address space is a property of the pointed-to
type, not the pointer type itself (just like const/volatile-ness) ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43292
--- Comment #11 from uweigand at gcc dot gnu dot org 2010-03-02 19:56
---
(In reply to comment #10)
I don't see where reload is creating the whole instruction; maybe I am
misunderstanding that statement.
Well, after reload you have insn 624, which presumably didn't exist before
--- Comment #4 from uweigand at gcc dot gnu dot org 2009-12-07 22:20
---
Subject: Bug 31499
Author: uweigand
Date: Mon Dec 7 22:20:06 2009
New Revision: 155055
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155055
Log:
2008-12-07 Ulrich Weigand ulrich.weig...@de.ibm.com
--- Comment #5 from uweigand at gcc dot gnu dot org 2009-12-05 00:12
---
Subject: Bug 41857
Author: uweigand
Date: Sat Dec 5 00:11:29 2009
New Revision: 155003
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155003
Log:
2008-12-04 Ulrich Weigand ulrich.weig...@de.ibm.com
--- Comment #7 from uweigand at gcc dot gnu dot org 2009-12-05 00:12
---
Subject: Bug 42224
Author: uweigand
Date: Sat Dec 5 00:11:29 2009
New Revision: 155003
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155003
Log:
2008-12-04 Ulrich Weigand ulrich.weig...@de.ibm.com
--- Comment #5 from uweigand at gcc dot gnu dot org 2009-12-02 13:51
---
Subject: Bug 42224
Author: uweigand
Date: Wed Dec 2 13:50:52 2009
New Revision: 154908
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154908
Log:
gcc/
PR middle-end/42224
* tree.h
--- Comment #6 from uweigand at gcc dot gnu dot org 2009-12-02 13:52
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from uweigand at gcc dot gnu dot org 2009-11-30 15:17
---
OK, I've reproduced the problem. It seems int_or_pointer_precision
is fundamentally wrong for pointers using a non-standard size
(i.e. pointer variables defined using a mode attribute).
The history
--- Comment #4 from uweigand at gcc dot gnu dot org 2009-11-17 16:22
---
Subject: Bug 41857
Author: uweigand
Date: Tue Nov 17 16:21:56 2009
New Revision: 154255
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154255
Log:
PR tree-optimization/41857
* tree-ssa
--- Comment #2 from uweigand at gcc dot gnu dot org 2009-11-02 14:30
---
Subject: Bug 41857
Author: uweigand
Date: Mon Nov 2 14:30:39 2009
New Revision: 153810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153810
Log:
gcc/
PR tree-optimization/41857
* tree
--- Comment #3 from uweigand at gcc dot gnu dot org 2009-11-02 14:35
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from uweigand at gcc dot gnu dot org 2009-10-29 18:49
---
Proposed fix: http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01757.html
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
: normal
Priority: P3
Component: tree-optimization
AssignedTo: uweigand at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: spu-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41857
--- Comment #9 from uweigand at gcc dot gnu dot org 2009-10-08 18:39
---
(In reply to comment #8)
This is on (set (reg:DF X) (mem:DF ((plus:DI (reg:DI Y) (const_int 3.
When X is still a pseudo, this is considered valid, as lfd accept any offset,
but when RA chooses to assign X
--- Comment #19 from uweigand at gcc dot gnu dot org 2009-08-10 15:34
---
Subject: Bug 37053
Author: uweigand
Date: Mon Aug 10 15:34:09 2009
New Revision: 150626
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150626
Log:
PR target/37053
* reload1.c
front-end
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: spu
--- Comment #2 from uweigand at gcc dot gnu dot org 2009-03-12 14:00
---
Subject: Bug 39181
Author: uweigand
Date: Thu Mar 12 14:00:21 2009
New Revision: 144811
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144811
Log:
PR target/39181
* config/spu/spu.c
--- Comment #3 from uweigand at gcc dot gnu dot org 2009-03-12 14:01
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from uweigand at gcc dot gnu dot org 2009-03-12 14:02
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
Summary: [4.4 regression] Failing SPU vectorizer testcases
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand
--- Comment #1 from uweigand at gcc dot gnu dot org 2009-03-07 16:02
---
Subject: Bug 38028
Author: uweigand
Date: Sat Mar 7 16:02:30 2009
New Revision: 144696
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144696
Log:
PR middle-end/38028
* function.c
--- Comment #1 from uweigand at gcc dot gnu dot org 2008-11-05 18:04
---
The test case tests for expected failures. It seems there is now an additional
message being output:
/home/meissner/fsf-src/trunk/gcc/testsuite/gcc.target/spu/intrinsics-1.c:13:
warning: passing argument 2
--- Comment #1 from uweigand at gcc dot gnu dot org 2008-08-12 14:37
---
Subject: Bug 37097
Author: uweigand
Date: Tue Aug 12 14:35:54 2008
New Revision: 139019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139019
Log:
PR bootstrap/37097
* builtins.c
--- Comment #2 from uweigand at gcc dot gnu dot org 2008-08-12 14:45
---
Should be fixed now ...
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from uweigand at gcc dot gnu dot org 2008-08-11 15:12
---
(In reply to comment #14)
Ulrich asked for some time on the trunk (we have built all of our
packages against a patched 4.3 tree now with no appearant problems as
well).
OK, in that case I have no further
--- Comment #11 from uweigand at gcc dot gnu dot org 2008-07-31 19:31
---
I'll have a look tomorrow ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
SPU local
store size with -O0
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot
--- Comment #1 from uweigand at gcc dot gnu dot org 2008-07-02 15:57
---
Subject: Bug 36698
Author: uweigand
Date: Wed Jul 2 15:56:31 2008
New Revision: 137367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137367
Log:
PR target/36698
* gcc.c-torture/compile
--- Comment #2 from uweigand at gcc dot gnu dot org 2008-07-02 15:59
---
Subject: Bug 36698
Author: uweigand
Date: Wed Jul 2 15:58:09 2008
New Revision: 137368
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137368
Log:
PR target/36698
* gcc.c-torture/compile
--- Comment #28 from uweigand at gcc dot gnu dot org 2008-06-28 10:48
---
Subject: Bug 34856
Author: uweigand
Date: Sat Jun 28 10:47:36 2008
New Revision: 137218
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137218
Log:
PR target/34856
* config/spu/spu.c
--- Comment #29 from uweigand at gcc dot gnu dot org 2008-06-28 10:49
---
Subject: Bug 34856
Author: uweigand
Date: Sat Jun 28 10:48:33 2008
New Revision: 137219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137219
Log:
PR target/34856
* config/spu/spu.c
--- Comment #8 from uweigand at gcc dot gnu dot org 2008-05-18 15:58
---
That special case in find_reloads is really about a different situation.
We do not have a simple move here.
The problem also is not really related to vector instruction in particular;
reload doesn't at all care
--- Comment #16 from uweigand at gcc dot gnu dot org 2008-03-04 14:51
---
Hi Jakub,
we need the same changes in both .eh_frame and .dwarf_frame;
does the gas .cfi_ support both sections?
I'm wondering how save restore should work across two
different FDEs -- in the new FDE, we'd
--- Comment #4 from uweigand at gcc dot gnu dot org 2008-02-25 22:15
---
(In reply to comment #3)
This problem has already been fixed for GCC 4.3 (#34641). The testcase from
that PR didn't fail for GCC 4.2 so I didn't apply the patch on 4.2 as well.
But
now the patch should
--- Comment #11 from uweigand at gcc dot gnu dot org 2008-01-21 18:54
---
The secondary reload hook does not need to make the decision whether or
not indexed addresses are allowed; that decision has already been taken.
The purpose of the secondary reload hook is simply to do whatever
--- Comment #8 from uweigand at gcc dot gnu dot org 2008-01-09 19:23
---
This is a long-standing problem in gen_reload. This routine fundamentally
assumes that every PLUS expression that describes a legitimate address can
be reloaded into a register without requiring any additional
--- Comment #3 from uweigand at gcc dot gnu dot org 2007-11-28 13:36
---
Hi Michael,
the problem is that there is an implicit assumption throughout the code
that you can have at most one pool constant per instruction. For example,
the pool size / splitting heuristics assume that. I
--- Comment #7 from uweigand at gcc dot gnu dot org 2007-11-28 17:11
---
(In reply to comment #4)
For reference, our hacky approach to enforce liveness of arguments is by
using them as operands of an inline asm, which we insert as first instruction
in every function. When those
--- Comment #6 from uweigand at gcc dot gnu dot org 2007-08-12 23:35
---
Changing component to middle-end as the problem is not actually in the C++
front-end.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from uweigand at gcc dot gnu dot org 2007-08-12 23:43
---
Sa's patch isn't quite correct as it ignores the result of
the build_qualified_type call. The following patch should
fix that:
diff -urNp toolchain/gcc.orig/gcc/tree.c toolchain/gcc/gcc/tree.c
--- toolchain
--- Comment #10 from uweigand at gcc dot gnu dot org 2007-04-27 14:59
---
Subject: Bug 30761
Author: uweigand
Date: Fri Apr 27 14:59:21 2007
New Revision: 124219
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124219
Log:
PR middle-end/30761
* reload1.c
--- Comment #11 from uweigand at gcc dot gnu dot org 2007-04-27 15:03
---
(In reply to comment #8)
Ulrich, in response to your question in Comment #6, yes, this bug appears in
4.1 and 4.2, not just in 4.3. So, if you think it's safe to backport the
reload patch, it would be nice
--- Comment #9 from uweigand at gcc dot gnu dot org 2007-04-26 22:10
---
Subject: Bug 30761
Author: uweigand
Date: Thu Apr 26 22:10:09 2007
New Revision: 124199
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124199
Log:
PR middle-end/30761
* reload1.c
--- Comment #3 from uweigand at gcc dot gnu dot org 2007-04-23 14:51
---
I don't think the patch is correct; according to the C standard,
the third argument of memset is of type size_t, which must be
an *unsigned* type, so it cannot in fact be negative.
What apparently happens
--- Comment #12 from uweigand at gcc dot gnu dot org 2007-03-14 15:26
---
This does fix my testcase on mainline. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
--- Comment #6 from uweigand at gcc dot gnu dot org 2007-03-12 19:34
---
I haven't verified that this problem is fixed -- the patch was originally
intended to fix another bug uncovered by Peter Bergner, and I just added
this PR number to the check-in due to Andrew's comment #3
--- Comment #4 from uweigand at gcc dot gnu dot org 2007-02-21 15:05
---
Subject: Bug 30761
Author: uweigand
Date: Wed Feb 21 15:05:01 2007
New Revision: 122199
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122199
Log:
PR middle-end/30761
* reload1.c
: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-10-24 19:03
---
Sorry for missing that bug. The proposed patch is OK -- thanks for
catching this.
As to the general problem, I think you're right that we need to further
constrain the range of accepted offsets. However
--- Comment #6 from uweigand at gcc dot gnu dot org 2006-09-05 12:41
---
(In reply to comment #4)
Anyways I am going to test the obvious fix unless you (Ulrich) want to do it.
Please go ahead, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-09-05 12:47
---
(In reply to comment #5)
Is this also supposed to fix the problem I posted in comment #2? I applied
that
patch to my gcc but it didn't fix the generated code for me. It's just weird
because the bug only
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28862
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-07-14 19:27
---
Yes, looks like this is long fixed. Closing bug now.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from uweigand at gcc dot gnu dot org 2006-06-06 17:01
---
Subject: Bug 27842
Author: uweigand
Date: Tue Jun 6 17:01:27 2006
New Revision: 114438
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114438
Log:
PR target/27842
* config/rs6000/altivec.md
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-06-06 17:05
---
Subject: Bug 27842
Author: uweigand
Date: Tue Jun 6 17:04:56 2006
New Revision: 114439
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114439
Log:
PR target/27842
* config/rs6000/altivec.md
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-06-06 17:10
---
Fixed on 4.1 branch and mainline.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-06-01 21:30
---
Yes, that makes sense -- in fact, it looks like altivec_vslw_v4sf can then be
removed as well. I'm currenly testing a patch to that effect ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-31 16:59
---
I'm not sure (subreg:SF (const_int)) is canonical RTL, I haven't seen
subregs of anything but REG or MEM.
In any case, I don't really see what this would buy us over an UNSPEC -- will
the generic simplifier
--- Comment #2 from uweigand at gcc dot gnu dot org 2006-05-26 12:58
---
This looks like a source-code problem. The assembler instruction
union {DItype __ll; struct {USItype __h, __l;} __i; } __x;
__asm__ (lr %N0,%1\n\tmr %0,%2 : =r (__x.__ll)
: r
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-05-26 20:22
---
Subject: Bug 27661
Author: uweigand
Date: Fri May 26 20:21:53 2006
New Revision: 114141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114141
Log:
PR rtl-optimization/27661
* reload.c
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-05-22 13:27
---
Looking somewhat more into this problem, there are other places where
reload decides to reload an CONST_INT as address. Where this happens,
it usually uses Pmode as the mode to do the reload in (which makes
sense
--- Comment #6 from uweigand at gcc dot gnu dot org 2006-04-13 11:47
---
I've now tested and submitted the patch, thanks.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-04-13 20:27
---
Subject: Bug 27006
Author: uweigand
Date: Thu Apr 13 20:26:59 2006
New Revision: 112923
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112923
Log:
2006-04-13 Paolo Bonzini [EMAIL PROTECTED
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-04-13 20:33
---
Subject: Bug 27006
Author: uweigand
Date: Thu Apr 13 20:33:51 2006
New Revision: 112924
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112924
Log:
2006-04-13 Paolo Bonzini [EMAIL PROTECTED
--- Comment #10 from uweigand at gcc dot gnu dot org 2006-04-13 20:35
---
Fixed for 4.1 and mainline.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-04-06 14:03
---
(In reply to comment #3)
Ulrich, can you prepare a patch or should I do so?
It would be great if you could do that, I don't yet
have a proper setup for ppc testing ...
--
http://gcc.gnu.org/bugzilla
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: powerpc-*-linux
--- Comment #18 from uweigand at gcc dot gnu dot org 2006-02-22 09:57
---
(In reply to comment #17)
(e.g. s390/linux-unwind.h was doing that, although just for 2 selected
signals, which wasn't good enough, as e.g. all async signals need to be
handled the same).
We've actually
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-02-10 20:00
---
Yup. See how this is handled in config/s390/linux-unwind.c:
/* If we got a SIGSEGV or a SIGBUS, the PSW address points *to*
the faulting instruction, not after it. This causes the logic
in unwind
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-10 20:34
---
(In reply to comment #4)
Not all the targets have the luxury of spare register slots.
I guess we were lucky here ;-)
So the current proposal is to add a new CIE augmentation that will signify
a signal frame
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-08 16:10
---
FYI -- this also breaks bootstrap on s390-ibm-linux and s390x-ibm-linux:
../../../gcc-head/libgfortran/io/unit.c: In function 'find_unit_1':
../../../gcc-head/libgfortran/io/unit.c:269: internal compiler error
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-02-08 21:44
---
The spurious failures are always in different test cases for me as well ...
In fact, I now did a re-test and only see the four well-understood failures:
FAIL: c32001e
FAIL: c64105b
FAIL: c95086b
FAIL
--- Comment #10 from uweigand at gcc dot gnu dot org 2006-02-08 22:36
---
(In reply to comment #9)
The first 3 are so well-understood as to be fixed on my machine. :-) We are
working on the 4th.
Excellent!
Will you be committing the patch, or is this not the proper fix?
It's
--- Comment #3 from uweigand at gcc dot gnu dot org 2006-02-04 19:11
---
(In reply to comment #2)
Could you try the following fix?
Yes, this fixes the problem. Bootstrap and regression test passes
on s390x-ibm-linux (and s390-ibm-linux) with this fix.
The following test case
--- Comment #5 from uweigand at gcc dot gnu dot org 2006-02-04 20:16
---
(In reply to comment #4)
Thanks. ce3107b is new to me but all the others are fully understood.
It looks like ce3107b is one of those spurious failures I'm getting from
time to time -- I've never quite
1 - 100 of 196 matches
Mail list logo
