--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Status|UNCONFIRMED |NEW
--- Comment #9 from steven at gcc dot gnu dot org 2009-01-04 18:45 ---
Thanks HJ for looking into this. I think revision 143027 is not the cause,
it's more likely that it uncovers a latent bug. I'm trying to reduce Joost's
code to a small test case. So far, what I'm seeing
--- Comment #6 from steven at gcc dot gnu dot org 2009-01-04 15:13 ---
Does not fail for me on i686-pc-cygwin with gcc version 4.4.0 20090103
(experimental) [trunk revision 143030]. What target are you compiling for?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38722
--- Comment #10 from steven at gcc dot gnu dot org 2009-01-04 19:51 ---
Created an attachment (id=17031)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17031action=view)
Failing test case (still needs all the .mod files)
This is as far as I can reduce it with delta.
Joost, could
--- Comment #11 from steven at gcc dot gnu dot org 2009-01-04 20:02 ---
Note that this test case ICEs in IRA, but I've checked that it ICEs on the same
insn, and in both cases we're looking at incorrect recog_data.
$ gdb --args ../f951.exe -O t.f90
GNU gdb 6.8.0.20080328-cvs (cygwin
--- Comment #12 from steven at gcc dot gnu dot org 2009-01-04 21:07 ---
This fixes it for me. However, I'm no RTL expert, and especially combine I
know nothing about :-)
I'll test/post this and see how the RTL guru's judge it.
* combine.c (try_combine): Adjust INSN_CODE after
--- Comment #13 from steven at gcc dot gnu dot org 2009-01-04 21:38 ---
My patch is wrong. The changes are reverted by undo_all() later on. However,
the bug still is in combine.c. It should not leave insns with the wrong
INSN_CODE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #14 from steven at gcc dot gnu dot org 2009-01-04 21:39 ---
Leaving this to an RTL expert.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-01-03 10:24 ---
Reviewer said: So, this is ok with or without the volatile restriction. (see
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00070.html). The committed patch
still seems to have this restriction...?
--
http
--- Comment #18 from steven at gcc dot gnu dot org 2009-01-03 15:24 ---
Closing this as a dup of bug 38582 because that bug has a test case.
*** This bug has been marked as a duplicate of 38582 ***
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-03 15:24 ---
*** Bug 15023 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-03 17:23 ---
I agree with Vlad, this is not a regression.
It'd still be nice if you can figure out a way to make this work, Vlad. It is
possible, perhaps, to split huge basic blocks up in chunks (e.g. separate basic
blocks
--- Comment #8 from steven at gcc dot gnu dot org 2009-01-04 00:15 ---
Subject: Bug 38584
Author: steven
Date: Sun Jan 4 00:15:08 2009
New Revision: 143040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143040
Log:
PR middle-end/38584
* cfgexpand.c
--- Comment #3 from steven at gcc dot gnu dot org 2009-01-04 00:16 ---
Subject: Bug 38586
Author: steven
Date: Sun Jan 4 00:15:58 2009
New Revision: 143041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143041
Log:
PR middle-end/38586
* function.c (struct
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-04 00:17 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from steven at gcc dot gnu dot org 2009-01-04 00:17 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-02 18:21 ---
Confirmed at r134530 with the following reduced test case:
typedef unsigned int USItype __attribute__ ((mode (SI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef USItype halffractype;
typedef
--- Comment #5 from steven at gcc dot gnu dot org 2009-01-02 18:25 ---
The zero_extract:DI appears for the first time in the .163r.combine dump.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36003
--- Comment #1 from steven at gcc dot gnu dot org 2009-01-03 00:36 ---
Created an attachment (id=17024)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17024action=view)
Add address - temp slot map
Instead of huge list walks, just look up the address in the hash table and use
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2009-01-03 00:48 ---
Perhaps the front end should not emit this code on the latch?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-31 14:44 ---
Unable to reproduce - INVALID.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-30 13:36 ---
Subject: Bug 38584
Author: steven
Date: Tue Dec 30 13:35:00 2008
New Revision: 142963
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142963
Log:
PR middle-end/38584
* ipa-inline.c
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-30 13:37 ---
We should not use the full bin-packing algorithm for any optimization level. A
simpler heuristic is called for. I'll see if I can come up with something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-28 12:05 ---
GCC should not generate cmov instructions if you use -march={i586,c3} and, as
far as I can tell, it does not since gcc 3.2.
Since you have not provided a test case, there is nothing we can do with this
bug report
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-28 12:20 ---
Re. comment #9
This is imho a bug, but I'd probably just fix it with a small documentation
update. Mark tends to describe the situation as it should be, but I wouldn't
want you to expect Mark, nor anyone else
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-28 12:51 ---
Undesirable. As Mark already pointed out, we'd probably end up breaking legacy
code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-28 13:15 ---
Which part of ...as I don't think people are trying to... gives you the
certainty that really people don't?
Anyway, as far as I'm concerned, this is end of discussion. There is nothing
stopping you from working
--- Comment #16 from steven at gcc dot gnu dot org 2008-12-28 13:23 ---
In fact, Mark's suggestion wouldn't actually work in all cases. With
-ffunction-sections, your function definition may end up in a section that will
be eliminated by the linker. And if the preceding section
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-26 15:38 ---
GCC inline heuristics are just that: heuristics. They are not optimal for all
targets but only for those targets that they have been tuned for.
For AVR, nobody ever tuned the heuristics, despite several suggestions
--- Comment #8 from steven at gcc dot gnu dot org 2008-12-23 18:19 ---
The problem is that phi_translate returns an expression eprime of a different
type. For the test case of comment #6, we phi_translate
(eq_expr,state,obj_1) to (bool)1.
--
http://gcc.gnu.org/bugzilla
--- Comment #9 from steven at gcc dot gnu dot org 2008-12-23 18:51 ---
Hack demonstrates the problem:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 142907)
+++ tree-ssa-pre.c (working copy)
@@ -3274,6
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-23 18:59 ---
Please don't re-open bug reports because you speculate when others have
analyzed the issue properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38608
--- Comment #35 from steven at gcc dot gnu dot org 2008-12-20 09:54 ---
Re comment #34: Good idea, but add:
5) quadratic behaviour in find_temp_slot_from_address.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #19 from steven at gcc dot gnu dot org 2008-12-20 09:56 ---
Fixing all targets is beyond my hacking skills.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-20 15:50 ---
Probably 4.5 material (alias improvement branch).
You could try --param max-aliased-vops=0 as a work-around.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-21 00:33 ---
Created an attachment (id=16951)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16951action=view)
Avoid expensive inline heuristics at O0, and speed up add_alias_set_conflicts
This problem is always going
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-18 16:55 ---
Let me try, I'm kinda sorta responsible for this bug in a way, you know...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-18 21:19 ---
Jakub's idea of comment #10 is nice conceptually, but it's a bit complicated in
practice for most cases where a libcall is emitted. Before subreg lowering we
have this:
(insn 8 7 9 2 t.c:19 (set (mem:DI (plus:SI
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-18 22:35 ---
Created an attachment (id=16939)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16939action=view)
make all functions with nonzero crtl-outgoing_args_size non-leaf
The result of this patch is that DCE of dead
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-18 22:58 ---
Created an attachment (id=16940)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16940action=view)
Make targets allocate outgoing args space if necessary
Alternative approach is to let all targets check if crtl
--- Comment #33 from steven at gcc dot gnu dot org 2008-12-17 19:40 ---
cfgexpand.c:defer_stack_allocation() has this gem:
/* Without optimization, *most* variables are allocated from the
stack, which makes the quadratic problem large exactly when we
want compilation
--- Comment #26 from steven at gcc dot gnu dot org 2008-12-16 16:26 ---
I am going to work on the -O0 problems a bit.
The operand scanner is the problem at -O3. Richi, this is one you may want to
try on the alias improvements branch, if most of the time is spent on virtual
SSA names (I
--- Comment #19 from steven at gcc dot gnu dot org 2008-12-16 12:45 ---
Re. comment #18, I'd say brilliant if it wasn't such a poor performance :-)
Did you manage to get a time report out of that run?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-16 13:45 ---
Looks like something along the lines of gcse.c:can_assign_to_reg_p() is called
for here in replace_read.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
--- Comment #22 from steven at gcc dot gnu dot org 2008-12-16 13:41 ---
We may be better off with a slightly reduced test case for the -O3 report.
It's not difficult to cut out ~8000 lines (like I did yesterday) and still have
a huge test case (and the horendous compile times to go
--- Comment #3 from steven at gcc dot gnu dot org 2008-12-16 23:03 ---
This is not fixable. When a bug is filed, messages are sent out and picked up
by archive mirrors. This is desirable for GCC the project but probably less so
for individual GCC users.
--
steven at gcc dot gnu dot
--- Comment #30 from steven at gcc dot gnu dot org 2008-12-17 07:01 ---
I think redoing this with 4.4.0 would be useful, to check if new code (like
IRA) uses this kind of non-linear algorithms. But the register renaming patch
hasn't changed between 4.3 and 4.4, so I would compile
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-15 17:38 ---
Re. comment #14: Yes, I suppose so. Why do you want to remove gcse-las from
mainline. Not that I'm against it -- ideally RTL gcse.c would not work on
memory at all anymore -- but I wouldn't remove gcse-las until
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-15 21:17 ---
One of the bottlenecks seems to be find_temp_slot_from_address.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-15 21:27 ---
OK, to elaborate: I'm playing with this test case on ia64-linux, and I reduced
the test case by some 8000 lines to make it compilable at all. With this 8000
lines less, it actually spends more time for me in expand
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-15 21:53 ---
For the inline heuristics, almost all time is also spent in stack slot related
stuff. The culprit is estimate_stack_frame_size (or actually,
add_alias_set__conflicts) in cfgexpand.c.
(What are we doing in cfgexpand
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-15 21:55 ---
From cfgexpand.c:
static void
add_alias_set_conflicts (void)
{
size_t i, j, n = stack_vars_num;
for (i = 0; i n; ++i)
{
tree type_i = TREE_TYPE (stack_vars[i].decl);
bool aggr_i
--- Comment #16 from steven at gcc dot gnu dot org 2008-12-15 21:56 ---
Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-16 06:22 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20468#c1
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #47 from steven at gcc dot gnu dot org 2008-12-10 11:42 ---
Re. comment #37:
Mark, bug 38453 has a simple test case that shows the poor optimization choice
for ARM-linux. Also, there are now 4 bugs closed as duplicates of this one, so
many users run into this and consider
--- Comment #48 from steven at gcc dot gnu dot org 2008-12-10 11:43 ---
To P3 per comment #37.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #50 from steven at gcc dot gnu dot org 2008-12-10 12:31 ---
The cost check for final value replacement was removed in revision 122896 (from
bug 33419, see http://gcc.gnu.org/viewcvs?view=revrevision=122896)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
--- Comment #46 from steven at gcc dot gnu dot org 2008-12-10 11:25 ---
*** Bug 38453 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2008-12-10 11:25 ---
*** This bug has been marked as a duplicate of 32044 ***
--
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 #3 from steven at gcc dot gnu dot org 2008-12-10 10:51 ---
Investigating.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-10 11:24 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044#c5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453
--- Comment #55 from steven at gcc dot gnu dot org 2008-12-10 21:27 ---
// This is the test case from PR38453.
// See comment #0 of that bug for further information:
// http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453#c0
typedef struct
{
int lc;
int pb;
} bar;
void foo(bar
--- Comment #56 from steven at gcc dot gnu dot org 2008-12-10 21:44 ---
Re. comment #52:
I've pasted the test case in the audit trail here as plain text -- it's pretty
small and it shows the problem nicely. The issue is that with -Os, on all
targets, the line,
propsRes-lc = prop0
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-10 23:09 ---
Seen in r141389
(http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01966.html)
Not seen anymore in r141405
(http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg02014.html)
HJ, looks fixed to me...?
--
http
--- Comment #30 from steven at gcc dot gnu dot org 2008-12-10 23:18 ---
This one is just dragged along with the Summary changes every time a new GCC is
released. I'd say WONTFIX for this bug. Eric, you would add a blurb about
that in the platform-specific installation notes (comment
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-11 00:10 ---
Created an attachment (id=16882)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16882action=view)
proposed patch
Looking for comments in this patch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
--- Comment #60 from steven at gcc dot gnu dot org 2008-12-11 00:27 ---
IMHO I the transformation to division is not fine. I would argue this is the
core issue in this problem report.
You are right that a combination of div and mod is quite common in real-world
code. Right now, GCC
--
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 #63 from steven at gcc dot gnu dot org 2008-12-11 07:03 ---
Re. comment #62:
Transforming the code and adding notes to allow the compiler to undo the
transformation is not an option with the available infrastructure in GCC.
You'd have to add some kind of note (something
--- Comment #9 from steven at gcc dot gnu dot org 2008-12-09 09:00 ---
Something as simple as this would already fix the broken link.
Index: gcc/doc/sourcebuild.texi
===
--- gcc/doc/sourcebuild.texi(revision 142582
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-09 18:53 ---
I have had no trouble bootstrapping 4.4 on ia64-unknown-linux-gnu (Debian) in
the last two weeks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-09 18:59 ---
This is what -Wshadow is for. We can't invent a new C dialect or fix the
standard.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-08 20:06 ---
What is target dependent about this, that you need a target hook for it?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-08 20:20 ---
Joseph Myers introduced this in the manual with the following patch:
http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00726.html
So this is a regression.
Ah, and Joseph also explained how to fix this, see comment #2
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-08 20:40 ---
Well, I can't even find this paragraph you want to reference.
And I was under the impression that there was a kind-of you broke it, you fix
it rule with GCC bugs. Am I wrong or does this just not apply to you
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-07 11:55 ---
Diego, in comment #7 you said you will work on this...
So? Have you worked on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-07 15:28 ---
Learn C, then try again.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2008-12-06 15:37 ---
If the code layout (see comment #2) is indeed causing the slow-down, this
problem might have been fixed along with bug 38074.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--- Comment #11 from steven at gcc dot gnu dot org 2008-12-06 20:17 ---
Created an attachment (id=16842)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16842action=view)
Remove overeager solver
Bootstrapped and tested on ia64-unknown-linux-gnu.
Time-tested by compiling cc1-i
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-06 21:25 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00409.html
Approval mail never made it through, but you can see traces of it here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00410.html
--
steven
--- Comment #11 from steven at gcc dot gnu dot org 2008-12-06 22:05 ---
What's the status of this bug? Fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37948
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-06 22:54 ---
Subject: Bug 36365
Author: steven
Date: Sat Dec 6 22:52:43 2008
New Revision: 142529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142529
Log:
PR rtl-optimization/36365
* df-core.c
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-06 22:54 ---
Fixed in GCC 4.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-05 09:15 ---
Is it possible to back-port the fix to GCC 4.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38393
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-04 16:55 ---
Hi Joost,
Thanks for all your hard work, but...
This is just the known problem that -fschedule-insns on x86* heavily constrains
the options for the register allocator. There are many bug reports about this,
most
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-04 16:58 ---
If RTL pre can catch this, then so should tree-PRE without enabling
partial-partial PRE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
--- Comment #3 from steven at gcc dot gnu dot org 2008-12-04 17:08 ---
I do not see RTL PRE catch this on ia64, with or without -fgcse-las.
Can you show, please, the RTL dumps before and after GCSE?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-04 17:27 ---
by_all was there because you made it so on purpose. From tree-ssa-pre.c:
For the partial anticipation case, we only perform insertion if it
is partially anticipated in some block, and fully available in all
--- Comment #8 from steven at gcc dot gnu dot org 2008-12-04 18:16 ---
Created an attachment (id=16828)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16828action=view)
.gcse1 dump of r142405 on ia64-linux
I still don't see why this is caught on powerpc by RTL PRE, but not on ia64
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-04 21:11 ---
*** Bug 38408 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-04 21:11 ---
*** This bug has been marked as a duplicate of 38406 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2008-12-03 18:53 ---
You can enable the aliasing warnings (-Wstrict-aliasing=2) and see if there are
warnings when compiling psim.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38387
--- Comment #7 from steven at gcc dot gnu dot org 2008-12-03 19:01 ---
But a regression at least on some targets. Confirmed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
801 - 900 of 3017 matches
Mail list logo
