--- Comment #4 from matz at gcc dot gnu dot org 2006-05-18 13:19 ---
Subject: Bug 27599
Author: matz
Date: Thu May 18 13:19:27 2006
New Revision: 113886
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113886
Log:
PR target/27599
* config.host: Make assign
--- Comment #5 from matz at gcc dot gnu dot org 2006-05-18 13:24 ---
Fixed for good.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
everywhere (when the
machine has them) but only when connected with some register as base or index.
That would ensure that a mode is available for the whole address which makes
reloading possible.
--
Summary: ICE in subst_reloads
Product: gcc
Version: 4.1.0
Status:
--- Comment #1 from matz at gcc dot gnu dot org 2006-05-18 16:07 ---
Like so perhaps. It fixes the ICE for me, but I've done no further testing:
--- s390.c.orig 2006-05-18 18:05:59.442621578 +0200
+++ config/s390/s390.c 2006-05-18 18:05:34.632630936 +0200
@@ -2731,6 +2
to do with this
special behaviour of 'subst'. Especially the copying of i2pat seems unrelated
and actually is protecting against wanted side effects of subst.
--
Summary: combine miscompiles
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
--- Comment #3 from matz at gcc dot gnu dot org 2006-05-24 18:22 ---
Created an attachment (id=11508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11508&action=view)
possible patch
I was wrong about simplify_if_then_else, it uses pc_rtx in all subst calls.
But that leave
--- Comment #4 from matz at gcc dot gnu dot org 2006-05-24 18:26 ---
Andrew, I know that this is undefined. Let us ignore this issue for this bug.
I tried some time to come up with two nicer functions which still get inlined
but are not optimized too early to hide the bug, but failed
--- Comment #3 from matz at gcc dot gnu dot org 2006-06-12 14:40 ---
Is this still a problem David? On x86_64 the libunwind-0.98.5 doesn't work
for ptrace (missing implemented functions), so I can't reproduce anything
on that platform. And on ia64-linux with a 4.1.x com
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28327
--- Comment #12 from matz at gcc dot gnu dot org 2006-07-10 08:57 ---
Mark, please apply to 4.1 branch also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
--- Comment #4 from matz at gcc dot gnu dot org 2009-01-28 12:22 ---
I'm fairly sure it's the same underlying problem. The emitted file numbers
(in the .s file for debug info) are in garbage collected memory. Hence
the directives emitted when the PCH is not yet loaded
--- Comment #8 from matz at gcc dot gnu dot org 2009-01-30 17:12 ---
But special_function_p looks at the name of the function, which is
__builtin_setjmp in case the builtin is used explicitely:
% cat x.c
#include
jmp_buf env;
int f(void){ return __builtin_setjmp(env);}
% gdb --args
--- Comment #7 from matz at gcc dot gnu dot org 2009-05-04 14:37 ---
Compile options please. I can't reproduce it with a powerpc64 compiler
with -O2, neither with -m32 nor -m64, -ffast-math or no -ffast-math.
Also 'gcc -v' can't hurt to make sure our compilers are
--- Comment #10 from matz at gcc dot gnu dot org 2009-05-04 16:10 ---
Yes, I can now, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #7 from matz at gcc dot gnu dot org 2009-05-05 15:32 ---
The problem is the expansion of this code:
:
...
D.1650_109 = D.1648_107 | 1;
if (D.1650_109 != 0)
goto ;
else
goto ;
plus the fact that we need to insert something on edge 4->6. Note how
--- Comment #8 from matz at gcc dot gnu dot org 2009-05-05 16:11 ---
Created an attachment (id=17803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17803&action=view)
fix for the problem
I'm regstrapping this patch, it fixes the problem in the testcase.
--
http:/
--- Comment #10 from matz at gcc dot gnu dot org 2009-05-06 09:01 ---
Yes, I'll clean this up before submission. Did it help?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
--- Comment #14 from matz at gcc dot gnu dot org 2009-05-06 09:48 ---
Mark, I'm certainly willing to help fixing this, but it's not a new
regression. Before my change TER _sometimes_ worked around the pre-existing
problem, but it's trivial to construct a case exposing
--- Comment #16 from matz at gcc dot gnu dot org 2009-05-06 11:20 ---
Joseph: I'd need some advise where best starting to fix this. I see some
options, when we want to deal with such construct:
struct S { T member __attribute__((packed)); };
... struct S s; ... &s->me
--- Comment #18 from matz at gcc dot gnu dot org 2009-05-06 11:57 ---
The structure in this testcase is not packed. One member is. Or are you
talking about some different case?
Let's suppose you are and you mean something like this:
struct S {T1 m1; T2 m2; ...} __attrib
--- Comment #20 from matz at gcc dot gnu dot org 2009-05-06 15:48 ---
Bootstrap on AIX was already working on April 29:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02342.html
I just left this open for the other (ARM/Mips) problem. As that now moved
somewhere else, this here is fixed
--- Comment #13 from matz at gcc dot gnu dot org 2009-05-06 16:50 ---
Subject: Bug 40021
Author: matz
Date: Wed May 6 16:49:13 2009
New Revision: 147186
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147186
Log:
PR middle-end/40021
* cfg
--- Comment #14 from matz at gcc dot gnu dot org 2009-05-06 16:54 ---
Hence, fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #19 from matz at gcc dot gnu dot org 2009-05-06 20:39 ---
Something like this implements option 1. It's probably hopelessly inefficient
(always generating a new type for each packed field), and wrong, and generally
just a bad idea, but it does fix the testcase, execut
--- Comment #23 from matz at gcc dot gnu dot org 2009-05-06 21:56 ---
No regressions on x86_64-linux. I'm baffled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40052
omponent: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40060
--- Comment #16 from matz at gcc dot gnu dot org 2009-05-07 12:39 ---
I see that in your reports only
gcc.target/powerpc/405-dlmzb-strlen-1.c scan-assembler dlmzb. (-m32)
gcc.target/powerpc/440-dlmzb-strlen-1.c scan-assembler dlmzb. (-m32)
are left (and I myself also can&#
--- Comment #3 from matz at gcc dot gnu dot org 2009-05-07 13:28 ---
How alignment is dealt with in was explained by Joseph in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954#c10
A conversion sequence implicitely maintains the largest found alignment.
Looking through casts would
--- Comment #3 from matz at gcc dot gnu dot org 2009-05-10 01:54 ---
I haven't analyzed this one, but only because I've found that particular
testcase also failing before expand from SSA, e.g:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02860.html
http://gcc.gnu.
--- Comment #13 from matz at gcc dot gnu dot org 2009-05-10 02:09 ---
Created an attachment (id=17843)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17843&action=view)
type-correct version
This is a type-corrected version of the same C testcase. Two structs are
differen
--- Comment #6 from matz at gcc dot gnu dot org 2009-05-10 18:17 ---
I haven't yet committed the patch that Ramana tested. Have you applied it
manually? Otherwise the breakage is expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031
--- Comment #8 from matz at gcc dot gnu dot org 2009-05-10 18:40 ---
Subject: Bug 40031
Author: matz
Date: Sun May 10 18:40:16 2009
New Revision: 147350
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147350
Log:
PR target/40031
* config/a
--- Comment #9 from matz at gcc dot gnu dot org 2009-05-10 18:41 ---
Now I have, hence fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from matz at gcc dot gnu dot org 2009-05-12 13:37 ---
The problem is that for PHI node expansion something has to be inserted on
the backedge of a single BB loop, splitting it into two BBs (where one just
contains one instruction). Something in the RTL passes then moves
--- Comment #4 from matz at gcc dot gnu dot org 2009-05-13 17:51 ---
flatten-2.c is the more important one. We leave the static function
doubleindirect1 in there, which we shouldn't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40095
--- Comment #14 from matz at gcc dot gnu dot org 2009-05-13 18:16 ---
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00753.html should fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #15 from matz at gcc dot gnu dot org 2009-05-13 20:14 ---
Subject: Bug 39976
Author: matz
Date: Wed May 13 20:14:44 2009
New Revision: 147494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147494
Log:
PR middle-end/39976
* tree-out
--- Comment #7 from matz at gcc dot gnu dot org 2009-06-03 09:51 ---
I'm looking at this now.
--
matz at gcc dot gnu dot org changed:
What|Removed |
--- Comment #9 from matz at gcc dot gnu dot org 2009-06-03 15:57 ---
Bah, simply not expanding those variables (whose SSA partitions were already)
by clearing TREE_USED on them fixes the problem, but makes those variables
have no debug info at all, as the DECLs then have no DECL_RTL_SET
--- Comment #10 from matz at gcc dot gnu dot org 2009-06-08 11:37 ---
Subject: Bug 40012
Author: matz
Date: Mon Jun 8 11:37:12 2009
New Revision: 148273
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148273
Log:
PR debug/40012
* cfgexpand.c (set_rtl
--- Comment #11 from matz at gcc dot gnu dot org 2009-06-08 11:38 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #26 from matz at gcc dot gnu dot org 2009-06-18 11:26 ---
Hmm, yeah, I should probably clean up my hack and formally submit it. But
I had hoped to get some advise from the frontend guys, because I was surprised
that the patch actually worked.
--
http://gcc.gnu.org
--- Comment #11 from matz at gcc dot gnu dot org 2009-07-02 15:31 ---
Subject: Bug 32131
Author: matz
Date: Thu Jul 2 15:31:28 2009
New Revision: 149178
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149178
Log:
fortran/
PR fortran/32131
* trans
--- Comment #21 from matz at gcc dot gnu dot org 2009-07-09 10:43 ---
I fear this is no expand-from-SSA problem anymore, but rather an IRA problem.
Unassigning and CCing Vlad.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2009-07-22 15:31 ---
Subject: Bug 35229
Author: matz
Date: Wed Jul 22 15:30:50 2009
New Revision: 149942
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149942
Log:
PR tree-optimization/35229
PR tree-opti
--- Comment #7 from matz at gcc dot gnu dot org 2009-07-22 15:31 ---
Subject: Bug 39300
Author: matz
Date: Wed Jul 22 15:30:50 2009
New Revision: 149942
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149942
Log:
PR tree-optimization/35229
PR tree-opti
--- Comment #8 from matz at gcc dot gnu dot org 2009-07-22 15:40 ---
So, the immediate problem is now fixed, but I'd suggest leaving this
enhancement request open, in case anybody wants to work on extending the
vectorizer to deal with these loop-carried dependencies, because in
--- Comment #1 from matz at gcc dot gnu dot org 2009-07-23 11:16 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from matz at gcc dot gnu dot org 2009-07-23 12:03 ---
Subject: Bug 40830
Author: matz
Date: Thu Jul 23 12:02:37 2009
New Revision: 14
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=14
Log:
PR middle-end/40830
* gcc.dg/vect/
--- Comment #3 from matz at gcc dot gnu dot org 2009-07-23 12:05 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from matz at gcc dot gnu dot org 2009-07-29 14:42 ---
Subject: Bug 40830
Author: matz
Date: Wed Jul 29 14:41:38 2009
New Revision: 150215
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150215
Log:
PR middle-end/40830
* gcc.dg/vect/vect-pre-interact.c: X
--- Comment #6 from matz at gcc dot gnu dot org 2009-07-29 14:43 ---
Marvelous, ia64 doesn't support alignment compensation. So, xfailing the
test on such targets seems the right way. Fixed again.
--
matz at gcc dot gnu dot org changed:
What|Re
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40964
--- Comment #9 from matz at gcc dot gnu dot org 2009-08-13 12:16 ---
It is indeed somewhat related, but currently the patchset doesn't help here.
The first issue is, that I create new types with unconflicting alias sets
only for global variables, not local ones (as I1 is in this
--- Comment #4 from matz at gcc dot gnu dot org 2009-08-13 15:36 ---
I agree with the reporters. libgcc isn't some random library, GCC should call
it correctly even in the presence of -mregparm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
le-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
--- Comment #1 from matz at gcc dot gnu dot org 2006-09-21 13:35 ---
Created an attachment (id=12303)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12303&action=view)
Breaking testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29166
--- Comment #2 from matz at gcc dot gnu dot org 2006-09-21 13:39 ---
Some more analysis of the original bugreport (
https://bugzilla.novell.com/show_bug.cgi?id=201157 ) :
For gcc version 4.1.2 20060731 (prerelease) (SUSE Linux),
r4-r7 contain before the call:
86, 87, 88, 89
and after
--- Comment #3 from matz at gcc dot gnu dot org 2006-09-21 13:40 ---
Hmpf. I wonder if there's any tool to really inspect the unwind info, like
it is possible for dwarf. But readelf doesn't help very much:
% readelf -wf a.out
% readelf -u a.out
...
<_Z4doItv>: [0x
sion: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: s390x-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
--- Comment #1 from matz at gcc dot gnu dot org 2006-10-02 11:24 ---
Created an attachment (id=12369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12369&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29319
--- Comment #2 from matz at gcc dot gnu dot org 2006-10-02 11:35 ---
Note that with this patch solves the bug for this testcase, but it still
doesn't help with the general case. With this slightly changed testcase:
% cat large-ofs2.c
static char l_info[100];
void bug1 (unsigned
--- Comment #5 from matz at gcc dot gnu dot org 2006-10-18 14:04 ---
The problem is in libcpp/files.c:open_file_failed. It deliberately only
gives a warning when producing dependencies (and under some circumstances
doesn't even give a warning) for missing files. I think it does
stack references scheduled below stack pointer
adjustment
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
Rep
--- Comment #1 from matz at gcc dot gnu dot org 2007-02-08 17:35 ---
I can't currently attach anything, somehow bugzilla is broken.
Anyway, perhaps the description of what happens is clear enough to see the
error. Btw: this patch will solve the problem on trunk per my proposal:
--- Comment #2 from matz at gcc dot gnu dot org 2007-08-09 15:50 ---
Fixed with my checkin of rev 127316.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from matz at gcc dot gnu dot org 2007-09-27 14:52 ---
Have a patch on http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01968.html .
Fixes also the reload failure on x86 -O2 -fPIC on this testcase (which hits
glibc):
/* { dg-do compile } */
/* { dg-options "-O2
--- Comment #23 from matz at gcc dot gnu dot org 2007-09-28 13:32 ---
Subject: Bug 33552
Author: matz
Date: Fri Sep 28 13:31:50 2007
New Revision: 128864
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128864
Log:
PR rtl-optimization/33552
* fu
--- Comment #24 from matz at gcc dot gnu dot org 2007-09-28 13:33 ---
Subject: Bug 33552
Author: matz
Date: Fri Sep 28 13:33:09 2007
New Revision: 128865
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128865
Log:
PR rtl-optimization/33552
* gcc.tar
--- Comment #25 from matz at gcc dot gnu dot org 2007-09-28 14:45 ---
Fixed now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from matz at gcc dot gnu dot org 2007-10-01 02:51 ---
Mine. Have a patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #2 from matz at gcc dot gnu dot org 2007-10-04 09:53 ---
Smaller testcase:
void f (volatile char *p)
{
char c = p[0];
}
This access to the volatile object p[0] must not be optimized away, but:
% ./gcc/cc1 -O1 x.c
% cat x.s
f:
pushl %ebp
movl%esp
--- Comment #3 from matz at gcc dot gnu dot org 2007-10-04 10:15 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00233.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33653
--- Comment #4 from matz at gcc dot gnu dot org 2007-10-04 13:34 ---
Subject: Bug 33653
Author: matz
Date: Thu Oct 4 13:34:09 2007
New Revision: 129006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129006
Log:
PR rtl-optimization/33653
--- Comment #5 from matz at gcc dot gnu dot org 2007-10-04 13:35 ---
Subject: Bug 33653
Author: matz
Date: Thu Oct 4 13:35:06 2007
New Revision: 129007
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129007
Log:
PR rtl-optimization/33653
* gcc.dg/pr3365
--- Comment #6 from matz at gcc dot gnu dot org 2007-10-04 13:36 ---
Fixed now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from matz at gcc dot gnu dot org 2007-10-05 14:36 ---
It's lower-subreg.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #4 from matz at gcc dot gnu dot org 2007-10-05 15:06 ---
Mine. Have patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #6 from matz at gcc dot gnu dot org 2007-10-05 15:36 ---
Subject: Bug 33600
Author: matz
Date: Fri Oct 5 15:36:16 2007
New Revision: 129035
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129035
Log:
gcc/
PR inline-asm/33600
* function.c (match_asm_const
--- Comment #7 from matz at gcc dot gnu dot org 2007-10-05 15:38 ---
Fixed now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from matz at gcc dot gnu dot org 2007-10-05 17:57 ---
Subject: Bug 33667
Author: matz
Date: Fri Oct 5 17:56:52 2007
New Revision: 129038
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129038
Log:
gcc/
PR middle-end/33667
* lower-
--- Comment #6 from matz at gcc dot gnu dot org 2007-10-05 18:03 ---
Fixed now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33714
--- Comment #1 from matz at gcc dot gnu dot org 2007-10-09 15:52 ---
Created an attachment (id=14331)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14331&action=view)
runtime testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33714
--- Comment #1 from matz at gcc dot gnu dot org 2007-10-09 16:50 ---
In 4.2.x CSE1 will already fold back the force-addr insns into the users,
i.e. the asm insn will not even see different registers in those 'm' operands
as address but simply (argp + ). trunk somehow manage
--- Comment #2 from matz at gcc dot gnu dot org 2007-10-09 17:41 ---
I think this happens because gcc 4.3.x doesn't have fold_rtx_mem() and friends
anymore since the introduction of fwprop.c. It formerly used to also lookup
the address of the given MEMs, and hence perform
--- Comment #12 from matz at gcc dot gnu dot org 2008-08-06 15:36 ---
Subject: Bug 36613
Author: matz
Date: Wed Aug 6 15:34:45 2008
New Revision: 138807
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138807
Log:
PR target/36613
* reload.c (push_reload
--- Comment #16 from matz at gcc dot gnu dot org 2008-08-11 16:22 ---
committed as r138955 into 4_3 branch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.0.2 4.1.0 |4.0.2 4.1.0 4.3.1
Target Milestone|4.2.5 |4.3.2
--- Comment #17 from matz at gcc dot gnu dot org 2008-08-11 16:23 ---
Subject: Bug 36613
Author: matz
Date: Mon Aug 11 16:22:00 2008
New Revision: 138955
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138955
Log:
PR target/36613
* reload.c (push_reload
--- Comment #4 from matz at gcc dot gnu dot org 2008-08-19 15:14 ---
HARD_REGNO_MODE_OK doesn't accept reg 328, but it should as demonstrated here.
Potential patch for this at
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01289.html .
--
http://gcc.gnu.org/bugzilla/show_bug.c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38070
--- Comment #2 from matz at gcc dot gnu dot org 2008-11-10 18:08 ---
Well, the invalid {LE,GT}_EXPRs trees are build right there in the patched
function, which is also the one that introduces the use of sizetype at all
(since the POINTER_PLUS_EXPR merge it seems, from 2007-06-15
--- Comment #3 from matz at gcc dot gnu dot org 2008-01-22 18:28 ---
The problem is, that gen_type_die() generates a DIE only for the main variant
of the given type. But lookup_type_die looks in the type itself. In the
example the type in question is "const A", for which no
--- Comment #5 from matz at gcc dot gnu dot org 2008-01-23 16:45 ---
Subject: Bug 34895
Author: matz
Date: Wed Jan 23 16:44:27 2008
New Revision: 131761
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131761
Log:
PR debug/34895
* dwarf2out.c (force_type_d
--- Comment #6 from matz at gcc dot gnu dot org 2008-01-23 16:54 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #20 from matz at gcc dot gnu dot org 2008-02-01 14:40 ---
Created an attachment (id=15074)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15074&action=view)
patch for postreload-gcse
This fixes the oversight in postreload-gcse.c and this bug.
--
http://gcc.
--- Comment #21 from matz at gcc dot gnu dot org 2008-02-01 14:45 ---
GCSE itself might or might not be safe, I haven't yet gone through all paths.
But normally it enters only pseudo regs into the hash tables. It does
remember invalidation of hard-regs, though, and that definite
1 - 100 of 411 matches
Mail list logo
