--- 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.
--- 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 d
--- 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):
-O
--- 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=gcc&view=rev&rev=162786
Log:
Move PR c++/45112 ChangeLog entry to correct
--- 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=gcc&view=rev&rev=162785
Log:
Move PR c++/45112 ChangeLog entry to correct
--- 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 #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=gcc&view=rev&rev=162783
Log:
gcc/
PR c++/45112
* 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 #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=gcc&view=rev&rev=162716
Log:
gcc/
PR c++/45112
* c
--- 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
ity: 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 #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
--- 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=gcc&view=rev&rev=162650
Log:
Backport from mainline:
20
--- 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=gcc&view=rev&rev=162220
Log:
PR target/44877
* config/s
--- 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 #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 #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
--- 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=gcc&view=rev&rev=161703
Log:
ChangeLog:
PR target/44707
--- 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
--
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 #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=21041&action=view)
Recognize (lo_sum (high ...) ...) in rs6000_legitimize_reload_address
> It seems to me that simply
--- 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
--- 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.ht
--- 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
--- 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=gcc&view=rev&rev=155055
Log:
2008-12-07 Ulrich Weigand
Backp
--- 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=gcc&view=rev&rev=155003
Log:
2008-12-04 Ulrich Weigand
Backp
--- 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=gcc&view=rev&rev=155003
Log:
2008-12-04 Ulrich Weigand
Backp
--- 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 #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=gcc&view=rev&rev=154908
Log:
gcc/
PR middle-end/42224
--- 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 of th
--- 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=gcc&view=rev&rev=154255
Log:
PR tree-optimization/41857
*
--- 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 #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=gcc&view=rev&rev=153810
Log:
gcc/
PR tree-optimization/41857
--- 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
ords: ice-on-valid-code
Severity: 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
--- 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=gcc&view=rev&rev=150626
Log:
PR target/37053
* r
--- Comment #18 from uweigand at gcc dot gnu dot org 2009-08-05 14:59
---
(In reply to comment #16)
> Uli, can you please have a look at Richard's and Paolo's patches and does one
> or the other seem like a "better" fix?
I've yet another suggestio
o in Fortran 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
--- 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
--- 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:00
---
Subject: Bug 39181
Author: uweigand
Date: Thu Mar 12 14:00:21 2009
New Revision: 144811
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144811
Log:
PR target/39181
* config/s
g
ReportedBy: uweigand at gcc dot gnu dot org
GCC target triplet: spu-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39422
--- 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=gcc&view=rev&rev=144696
Log:
PR middle-end/38028
* fu
--- 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 of
--- 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 #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=gcc&view=rev&rev=139019
Log:
PR bootstrap/37097
* bu
--- 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 n
--- 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
--- 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=gcc&view=rev&rev=137368
Log:
PR target/36698
* gcc.c-torture
--- 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=gcc&view=rev&rev=137367
Log:
PR target/36698
* gcc.c-torture
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 #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=gcc&view=rev&rev=137219
Log:
PR target/34856
* config/s
--- 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=gcc&view=rev&rev=137218
Log:
PR target/34856
* config/s
--- 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
--- 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 -- i
--- 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
> n
--- 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 #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. W
--- 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-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
---
--- 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 #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
--- 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=gcc&view=rev&rev=124219
Log:
PR middle-end/30761
* r
--- 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=gcc&view=rev&rev=124199
Log:
PR middle-end/30761
* r
--- 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 is
--- 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
--- 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=gcc&view=rev&rev=122199
Log:
PR middle-end/30761
* r
s: 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/show_bug.cgi?id=30590
--- 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. Ho
--- 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
>
--- 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
ute ((aligned)) ignored on vector variables
Product: gcc
Version: 4.2.0
Status: 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 #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 #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=gcc&view=rev&rev=114439
Log:
PR target/27842
* confi
--- 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=gcc&view=rev&rev=114438
Log:
PR target/27842
* confi
--- 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
--- 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 generi
= gen_reg_rtx (V4SFmode);
+})
However, the underlying abuse of RTL semantics when describing the
vspltisw instruction in V4SFmode apparently pre-dates this patch.
The easiest way to fix this would appear to use an UNSPEC to
describe the insn semantics. Any better idea?
--
Summary: Miscompile o
--- 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=gcc&view=rev&rev=114141
Log:
PR rtl-optimization/27661
*
--- 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" : "
--- 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 #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 #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=gcc&view=rev&rev=112924
Log:
2006-04-13 Paolo Bonzini <[EMAI
--- 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=gcc&view=rev&rev=112923
Log:
2006-04-13 Paolo Bonzini <[EMAI
--- 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 |
--- 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/
on?
--
Summary: Invalid altivec constant loading code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc
--- 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).
--- 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 sig
--- 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 #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 th
--- 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 #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 comp
--- 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'v
1 - 100 of 198 matches
Mail list logo
