--- Comment #13 from steven at gcc dot gnu dot org 2008-12-01 12:24 ---
After fixing the issue mentioned in comment#2 and comment #8, gcse.c hoisting
hoists things too far up, e.g.:
{ pred ENTRY }
BB1
if (...) goto BB2 else goto BB3
{ succ BB2, BB3 }
{ pred BB1 }
BB2
...
goto BB4
--- Comment #24 from steven at gcc dot gnu dot org 2008-12-01 22:00 ---
Created an attachment (id=16803)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16803action=view)
patch to implement code hoisting in tree-ssa-pre.c
This passes bootstrap+testing on ia64-linux and amd64-linux
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-01 22:12 ---
davidxl, my latest patch to bug 23286 (tree-hoist_v3.diff) makes PRE in
tree-ssa-pre.c code-size aware. I have tested this with CSiBE on
mips-unknown-elf.
Without the patch, code size at -Os with PRE enabled is ~17
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-01 23:04 ---
With so many dups, IMHO this ought to be fixed for the releases...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from steven at gcc dot gnu dot org 2008-11-30 20:45 ---
Resurrecting regmove is not an option. Time is better spent on figuring out
what regmove does, that makes a difference, and see if IRA can be taught to do
the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #28 from steven at gcc dot gnu dot org 2008-11-30 21:18 ---
You're not explaining what regmove does. What transformation do these
alternatives with * enable regmove to do?
I'm not saying that a separate pass is not an option. Perhaps a regmove-like
pass is necessary
--- Comment #29 from steven at gcc dot gnu dot org 2008-11-30 21:32 ---
The insns 8 in comment #0 show the regmove transformation that matters here:
With regmove disabled::
(insn:HI 8 7 14 2 ../../include/mmintrin.h:300 (set (reg:V2SI 61)
(plus:V2SI (reg:V2SI 63 [ x
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from steven at gcc dot gnu dot org 2008-11-29 16:25 ---
Is this still an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26307
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-29 19:28 ---
Can an ARM maintainer please check this bug? Comment #4 suggests this bug is
fixed, but it needs re-checking now that IRA has been merged.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from steven at gcc dot gnu dot org 2008-11-29 22:23 ---
I'm not sure if this bug is fixed, though. -ftrapv is still broken afaik.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-29 22:42 ---
Looks like something alias related - so CCing Richi.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-11-28 11:23 ---
There really is obvious way to remove the argument pushes without libcall
notes. There is nothing in the RTL to make clear that the pushes are dead when
the call is removed, so they pushes stay.
There are several
--- Comment #23 from steven at gcc dot gnu dot org 2008-11-27 15:26 ---
Created an attachment (id=16784)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16784action=view)
less unpolished version of tree code hoisting
This fixes some bugs in the proof-of-concept patch:
1. Don't
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #16 from steven at gcc dot gnu dot org 2008-11-23 13:07 ---
Created an attachment (id=16751)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16751action=view)
Proof-of-concept patch
It is not terribly complicated to add hoisting to tree-ssa-pre.c. I have
attached
--- Comment #17 from steven at gcc dot gnu dot org 2008-11-23 13:11 ---
For the test case of comment #0, the proof-of-concept patch does the following
in the .084t.pre dump (relevant excerpts only):
VBEOUT[2] := { {lshift_expr,a_2(D),1} (0004) }
Inserting expression 5 into AVAIL_OUT
--- Comment #18 from steven at gcc dot gnu dot org 2008-11-23 13:22 ---
The test case of PR38204 shows one of the problems with proof-of-concept patch,
namely the don't move up too much problem. The .pre dump looks like this:
test (int a, int b, int c, int g)
{
int pretmp.11;
int
--- Comment #21 from steven at gcc dot gnu dot org 2008-11-23 14:20 ---
I'll work on something that bootstraps and passes testing. But cost-related
decisions (like the one from comment #20) are not on my TODO list right now.
The pass that should do this is called sched1
--- Comment #37 from steven at gcc dot gnu dot org 2008-11-22 09:13 ---
Re: comment #35 and comment #36
That is code hoisting, again. See Bug 23286 and some the bugs closed as a
duplicate of Bug 23286. Looks like it's time to implement tree-level hoisting
:-)
--
steven at gcc dot
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 09:51 ---
I created a t.c with both functions in it:
unsigned int f1(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return
i;}
unsigned int f2(unsigned int i, unsigned int n) {++i; i += i == n; return i
--- Comment #6 from steven at gcc dot gnu dot org 2008-11-22 10:04 ---
Ah, now I see what Pinski meant at comment #2.
Before CSE, we still have the original code for f1:
unsigned int f(unsigned int i, unsigned int n)
{
i.20 = i + 1;
if (i.20 == n) i.20 = i.20 + 1;
return i.20
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-22 10:53 ---
The last time this bug was reconfirmed, was in March 2008. PRE has been
completely rewritten since then. With today's trunk, I still see PRE take most
of the compile time, but it's only 20% (on x86 and on x86_64
--- Comment #16 from steven at gcc dot gnu dot org 2008-11-22 10:31 ---
See comment #7 and comment #13.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2008-11-22 11:17 ---
Ping?
Patch exists, tested and all, and just needs a re-test and then submit...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 11:23 ---
passes.texi *does* have documentation for the reassoc pass.
Fixed by dnovillo in r114200:
PR 26242
* doc/passes.texi: Add documentation for pass_vrp, pass_ipa_pta,
pass_fre, pass_store_ccp
--- Comment #10 from steven at gcc dot gnu dot org 2008-11-22 11:36 ---
Trunk today generates the following code (this is the final_cleanup dump):
;; Function foo (foo)
foo ()
{
static char eof_reached = 0;
int bytes;
int toread;
bb 2:
toread = 4096;
bb 3:
bytes = bar
--- Comment #8 from steven at gcc dot gnu dot org 2008-11-22 11:45 ---
I don't think anyone is interested in fixing this - WONTFIX.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 17:44 ---
Is there a mangling convention now for fixed-point types, or not?
If not, we should make this a sorry() and resolve this bug as SUSPENDED for
now.
If there is, well, you know, we should add it ;-)
--
http
--- Comment #3 from steven at gcc dot gnu dot org 2008-11-22 18:20 ---
With a trivial one-liner patch this could look a lot better:
$ ./cc1plus t.C
void foo()
t.C:6: error: no match for 'operator=' in 'a = ({...})'
t.C:1: note: candidates are: A A::operator=(const A)
Execution times
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-21 20:57 ---
This bug is shamefully incomplete. There is no way anyone willing to give this
a look can know what to look for.
For example, a few things one would have to know before he/she can even begin
to consider whether/how
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-21 21:13 ---
What does regmove change, i.e. which of the many things that regmove does, is
helpful for the test case for this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437
--- Comment #35 from steven at gcc dot gnu dot org 2008-11-21 21:29 ---
So is there a test case with current top-of-trunk that fails? This is marked
as a P1 regression, but IIUC we don't even have a test case, after Jakub's fix
for PR37316 ?
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-21 21:54 ---
The reduced test case of comment #3 does not ICE on ia64 for gcc 4.4.0 20081121
(revision 142902).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37716
--- Comment #1 from steven at gcc dot gnu dot org 2008-11-21 06:41 ---
*** This bug has been marked as a duplicate of 23286 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steven at gcc dot gnu dot org 2008-11-21 06:41 ---
*** Bug 38204 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from steven at gcc dot gnu dot org 2008-11-18 21:31 ---
Are things moving forward on the fwprop issue?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-18 21:34 ---
P1 bug with a pending patch... maybe a reviewer could take a look at this
(seemingly trivial) patch at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #9 from steven at gcc dot gnu dot org 2008-11-16 12:17 ---
Advice to folks caring about compiler stability instead of supposedly faster:
Always use double-queue instead of overeager. The overeager solver is just not
reliable enough, and I have never found any proof
--- Comment #5 from steven at gcc dot gnu dot org 2008-10-02 18:52 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from steven at gcc dot gnu dot org 2008-10-02 18:52 ---
Subject: Bug 37635
Author: steven
Date: Thu Oct 2 18:51:12 2008
New Revision: 140837
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140837
Log:
testsuite
* gfortran.fortran-torture/execute
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-28 11:57 ---
Don't know if the patch is OK, but the code is obviously doing something silly.
CC-ing ARM maintainer.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2008-09-27 14:09 ---
Created an attachment (id=16414)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16414action=view)
draft patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37635
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-24 22:28 ---
I'll see this weekend if I can take care of this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #38 from steven at gcc dot gnu dot org 2008-09-21 13:07 ---
Fixed by Honza's patch.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:13 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-21 13:13 ---
libcall notes are no more...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:14 ---
I can reproduce this on-and-off, but never with a reasonable test case.
It's unlikely that anyone is interested in fixing this, esp. given that RTL
PRE/CPROP are doing less and less these days as the tree
--- Comment #2 from steven at gcc dot gnu dot org 2008-09-21 13:19 ---
Libcall blocks are no more.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2008-09-21 13:21 ---
Andreas, could you adopt the patch of comment #4 and see if it still fixes this
bug?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2008-09-21 13:36 ---
A C equivalent test case works. Once the infamous
multiple-decls-per-function issue in gfortran is fixed, this bug probably will
disappear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
--- Comment #13 from steven at gcc dot gnu dot org 2008-09-21 13:49 ---
Re. comment #12
I don't see how PRE for globals would make a difference here. In any case,
AFAIU tree PRE for globals should now work, and we still don't produce any
better code. The output of today (4.4.0 20080921
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:52 ---
Here is the .final_cleanup dump, fwiw:
;; Function foo (foo)
foo ()
{
int a.1;
bb 2:
a.1 = a + 1;
a = a.1;
if (a.1 != 0)
goto bb 3;
else
goto bb 4;
bb 3:
a = [plus_expr] a.1 + 1;
bb 4
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:58 ---
tree PRE now *does* handle the partially redundant global variable load. This
is the .final_cleanup dump:
;; Function bar (bar)
bar ()
{
int prephitmp.13;
bb 2:
prephitmp.13 = i;
switch (prephitmp.13
--- Comment #2 from steven at gcc dot gnu dot org 2008-07-28 20:41 ---
Like Pinski said: the code before and after the patch should be identical
w.r.t. TLS addresses. Without a more specific test case I'm not even going to
look at this.
--
steven at gcc dot gnu dot org changed
--- Comment #4 from steven at gcc dot gnu dot org 2008-07-06 09:37 ---
Still doesn't work. You need to replace one line for the test case of comment
#0 though, because the tree optimizers are now smart enough to see that (i/32)
is always 0. So replace
for (i = 0; i = 10; i
--- Comment #11 from steven at gcc dot gnu dot org 2008-07-06 09:59 ---
It looks like we don't use a known number of loop iterations at all anymore
after this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
--- Comment #15 from steven at gcc dot gnu dot org 2008-07-06 08:53 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00430.html
We should re-evaluate the need for gcse.c load-PRE after Daniel's patch goes
in. The last time I looked at what loads gcse.c load-PRE would move
--- Comment #3 from steven at gcc dot gnu dot org 2008-06-11 20:19 ---
Jakub is the OpenMP guru.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2008-06-01 09:41 ---
This is now optimized by VRP, CCP, store-CCP, DOM, PRE, and TER. It's hard to
break that test case!
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27676
nThis
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36414
--- Comment #7 from steven at gcc dot gnu dot org 2008-05-24 14:31 ---
I have found a test case for the issue mentioned in comment #4. And it comes
from gcc itself:
static int *free_phinodes[10 - 2]; /* was 'tree' */
static unsigned long free_phinode_count;
void
init_phinodes (void
--- Comment #13 from steven at gcc dot gnu dot org 2008-05-24 15:37 ---
This happens again on PPC. No test case yet.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #65 from steven at gcc dot gnu dot org 2008-05-15 05:59 ---
integrated RA : 373.36 (66%) usr 0.33 ( 2%) sys 375.87 (64%) wall
12064 kB ( 2%) ggc
'nuff said.
Oh, not entirely yet: IRA should have more than one timevar.
--
steven at gcc dot gnu dot org
--- Comment #3 from steven at gcc dot gnu dot org 2008-05-08 22:16 ---
I would have thought that since this can generate an exception and it is
a call insn that it would have been declared as a non deleteable insn by
dce.c:deleteable_insn_p.
deletable_insn_p() *will* declare
--- Comment #4 from steven at gcc dot gnu dot org 2008-05-08 22:27 ---
So I was looking at an older revision of dce.c. There is this new check before
the !NONJUMP_INSN_P check now:
/* We can delete dead const or pure calls as long as they do not
infinite loop
--- Comment #6 from steven at gcc dot gnu dot org 2008-04-19 13:09 ---
Re. comment #4: If you have no idea what SCC-VN is supposed to serve, such bold
statements as made in this comment are _severely_ misguided.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35972
--- Comment #7 from steven at gcc dot gnu dot org 2008-04-16 08:59 ---
I agree with Paolo in comment #6. One purpose of the lower-subreg path was to
allow backends to *not* define insns that it doesn't have. The expanders will
generate inline code for such patterns at expand time
--- Comment #7 from steven at gcc dot gnu dot org 2008-04-16 09:07 ---
Fixed, or what?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from steven at gcc dot gnu dot org 2008-04-16 13:46 ---
Looks related to http://gcc.gnu.org/ml/fortran/2008-03/msg00119.html and the
thread surrounding it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35958
--- Comment #5 from steven at gcc dot gnu dot org 2008-04-16 21:02 ---
This will probably only be fixed once a gfortran developer gets access to
Vista...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
--- Comment #2 from steven at gcc dot gnu dot org 2008-03-10 20:04 ---
The patch makes adding log use an algorithm quadratic in the number of log
links per insn. It is probably better to:
1. build the log links.
2. filter out the duplicates as a post pass (and maybe sort them while
--- Comment #3 from steven at gcc dot gnu dot org 2008-03-10 21:48 ---
IRA does not handle this either with -fno-split-wide-types. Left is IRA as-is
with -O2 -fomit-frame-pointer. Right is same options + -fno-split-wide-types.
.file t.c .file t.c
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #11 from steven at gcc dot gnu dot org 2008-03-03 19:35 ---
Quoting your insn once more:
(insn 58 57 59 6 gnu/java/nio/natVMSelector.cc:82 (parallel [
(set (reg:DI 4 si [165])
(mult:DI (zero_extend:DI (reg:SI 0 ax
--- Comment #7 from steven at gcc dot gnu dot org 2008-03-01 10:50 ---
With trunk as of today, the test case of comment #0 does trap if optimization
is disabled. At -O, the libcall is optimized away, but the call to iaddv() from
main() is also optimized away because iaddv is found
-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35413
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||35404, 35412
Status|UNCONFIRMED |NEW
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-29 23:36 ---
PR19020 shows that -ftrapv vs. libcalls is broken even without Paolo's patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
--- Comment #4 from steven at gcc dot gnu dot org 2008-02-17 14:51 ---
Does this affect 4.2 too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35231
--- Comment #13 from steven at gcc dot gnu dot org 2008-02-16 09:33 ---
Re. comment #8
You can't terminate the DFS before a complete SCC is found, it will break the
correctness of the SCC-VN algorithm. You'd start another DFS from a
not-yet-marked SSA name that is in the SCC's DFS
--- Comment #14 from steven at gcc dot gnu dot org 2008-02-16 09:40 ---
For those who have no idea what we're talking about, check out these links.
The first link is Tarjan's algorithm, which is what the tree-ssa-sccvn.c
SCC-finder is based on. The second link is Pearce's improved
--- Comment #10 from steven at gcc dot gnu dot org 2008-02-15 16:20 ---
Re. comment #7, sure this can be P1 and block the release. SCC-VN doesn't have
to be fixed for the release. This bug can be worked around.
Not making a bug P1 because you want a release out the door is not a good
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-14 10:10 ---
At least add a comment please why REG_CROSSING would need special treatment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35190
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-14 10:12 ---
ICE on valid code should be P1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-14 23:25 ---
Should be P1.
This bug is shows an intrinsic scalability problem with SCC-VN as it is
implemented right now (and presented in the literature).
The key issue is, SCC-VN should use a non-recursive SCC finding
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
--- Comment #5 from steven at gcc dot gnu dot org 2008-02-13 22:04 ---
I also can't reproduce it (neither on native nor with a cross).
Any local patches? Maybe you can reduce it to a set of simpler configuration
options?
--
steven at gcc dot gnu dot org changed:
What
--- Comment #22 from steven at gcc dot gnu dot org 2008-02-12 07:10 ---
Zap.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-11 10:44 ---
CCing fold guru.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #23 from steven at gcc dot gnu dot org 2008-02-09 09:20 ---
Please fix the ChangeLog entries. You forgot the asterisk * before combine.c
in every commit you made.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34627
--- Comment #1 from steven at gcc dot gnu dot org 2008-02-08 17:27 ---
See PR31360. May be fixed for GCC 4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
--- Comment #6 from steven at gcc dot gnu dot org 2008-02-08 23:05 ---
Is it possible to create an equivalent C test case (e.g. from the initial
GIMPLE dumps before the ICE)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
--- Comment #23 from steven at gcc dot gnu dot org 2008-02-06 09:00 ---
The IS_STACK_MODE trick is mine, and if this affects SSE code generation, the
bug is that IS_STACK_MODE returns true for registers that will not go on the
stack.
I acknowledge the IS_STACK_MODE is a big hammer
--- Comment #5 from steven at gcc dot gnu dot org 2008-02-06 09:05 ---
There was -Wnull-dereference once. I don't know if it still exists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35092
901 - 1000 of 3017 matches
Mail list logo
