--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-30 23:40 ---
Confirmed.
For the larger structure we expand the block-copy as
(insn 8 7 9 2 t3.c:7 (parallel [
(set (reg:SI 60)
(const_int 0 [0x0]))
(set (reg:SI 58)
(plus:
--- Comment #27 from fejj at novell dot com 2010-01-30 23:34 ---
Steven: okay, thanks for the explanation.
My concern is that if I hit a similar case down the road and someone builds
with different optimization flags than I do, that I'd never figure out the
problem.
It was pure luck th
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-30 23:34 ---
See also the related PR28831
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42909
--- Comment #11 from jingyu at google dot com 2010-01-30 23:33 ---
Subject: Re: Problematic condition
simplification logic at unswitch-loops pass
> I agree that some of the checks in tree_unswitch_single_loop are badly placed
> -- it does not make sense to check them repeatedl
This is related to PR42909. When a tail-call does a trivial pass-through of a
large struct, gcc generates a redundant block copy with identical source and
destination addresses. On machines like x86 it inlines that as a rep;mov, but
on others like m68k it generates a call to libc's memcpy():
> cat
--- Comment #26 from pinskia at gcc dot gnu dot org 2010-01-30 23:20
---
Note another area which is undefined and talked a lot about with many different
issues is signed integer overflow. It has the same issue as aliasing except it
is easier to explain in most cases.
--
http://gcc
--- Comment #25 from steven at gcc dot gnu dot org 2010-01-30 23:19 ---
It should be consistent for programs that do not trigger undefined behavior.
The behavior of your program is undefined according to the C standard and
according to GCC.
The alias discussion is just one of th many wh
--- Comment #14 from steven at gcc dot gnu dot org 2010-01-30 23:15 ---
Yes, it fails with all "do ... while(...)" loops, I think.
We'll have to think of something else, then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
--- Comment #24 from fejj at novell dot com 2010-01-30 23:12 ---
Richard: it seems weird to me that gcc's interpretation of the standard differs
depending on optimization level. Shouldn't it be consistent?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-30 23:04
---
FAIL: gcc.c-torture/execute/991016-1.c execution, -O2
FAIL: gcc.c-torture/execute/loop-3.c execution, -O2
FAIL: gcc.c-torture/execute/loop-3b.c execution, -O2
FAIL: gcc.dg/doloop-2.c execution test
and other
--- Comment #23 from pinskia at gcc dot gnu dot org 2010-01-30 22:51
---
GCC and aliasing is one area which talked about a lot. The problem is what the
standard allows to do and what people think the compiler should do (not based
on anything except what they are taught) are two differe
While looking at PR42722 I noticed that gcc generates awful code for a
tail-call involving a trivial pass-through of a large struct parameter.
> cat bug1.c
struct s1 { int x[16]; };
extern void g1(struct s1);
void f1(struct s1 s1) { g1(s1); }
struct s2 { int x[17]; };
extern void g2(struct s2);
v
--- Comment #9 from shcherbakov at daad-alumni dot de 2010-01-30 22:48
---
In general 'black box' case - yes. However, here there are 2 factors:
1) It is clear from the sources that 2 similar situations (pre-decrement and
post-increment) are handled in a different way, an additional che
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-01-30 22:46
---
(In reply to comment #20)
> Richi, is restrict working now, even with -fno-strict aliasing?
Yes, it is. See PR42617 for patches still required on the RTL side, it's
a bit late to apply them for 4.5 now.
--
h
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-01-30 22:41
---
(In reply to comment #21)
> Steven:
>
> > FWIW the tri-state solution is problematic because...
>
> Fair enough. This is why you're the gcc developer and not me ;-)
>
> However, correct output should be more imp
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-30 22:34 ---
(In reply to comment #3)
> "Is this" as in, "is level two not enabled by default..."
Yes. It's even exactly documented that way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42908
--- Comment #20 from steven at gcc dot gnu dot org 2010-01-30 22:29 ---
Richi, is restrict working now, even with -fno-strict aliasing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187
--- Comment #21 from fejj at novell dot com 2010-01-30 22:25 ---
Steven:
> FWIW the tri-state solution is problematic because...
Fair enough. This is why you're the gcc developer and not me ;-)
However, correct output should be more important than optimized output.
Also, I fail to se
--- Comment #19 from dominiq at lps dot ens dot fr 2010-01-30 22:23 ---
The test fails also on powerpc-unknown-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg02790.html ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
--- Comment #20 from fejj at novell dot com 2010-01-30 22:22 ---
Just so we are all on the same page (in case I haven't been clear)
This bug ONLY manifests when using -O2+ if I don't also use
-fno-strict-aliasing.
Meaning: if I do gcc -O0 -fstrict-aliasing, things still work.
--
h
--- Comment #19 from steven at gcc dot gnu dot org 2010-01-30 22:20 ---
FWIW the tri-state solution is problematic because there are cases where type
punning doesn't lead to this kind of optimizations. For example if the casted
pointer is casted back to the correct type, or if there is n
--- Comment #18 from fejj at novell dot com 2010-01-30 22:17 ---
Steven: ok, well, it has never mis-compiled that code before 4.4 and so I never
noticed it I guess.
But now it is mis-compiling the code, so it has come to my attention with
sirens blaring.
--
fejj at novell dot com ch
--- Comment #17 from steven at gcc dot gnu dot org 2010-01-30 22:15 ---
GCC has had -fstrict-aliasing enabled since 1998.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from fejj at novell dot com 2010-01-30 22:13 ---
> You told it to use C type-based aliasing rules to optimize. And exactly this
> is what it is doing.
Richard, no, I didn't. All I asked was -O2 and -O2 never used to enable
strict-aliasing (in fact, I never even asked fo
--- Comment #15 from fejj at novell dot com 2010-01-30 22:11 ---
Since the code works just fine with -O0, -O1 and/or -fno-strict-aliasing (when
using -O2), then it seems to me that gcc is fully capable of doing what I've
asked it to do (therefor DWIM doesn't even enter into the equation,
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-30 22:06 ---
"Is this" as in, "is level two not enabled by default..."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42908
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-30 22:06 ---
Is this to avoid false positives, because there's only a hazard if the thing is
actually dereferenced later on (or if it's cast back to the "correct" type)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42908
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-30 22:03 ---
$ gcc-4.4 -S t.c -O2 -Wall -Wstrict-aliasing=2
t.c: In function main:
t.c:15: warning: dereferencing type-punned pointer might break strict-aliasing
rules
you need to enable level 2 to get warnings about this.
-
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-30 22:00
---
(In reply to comment #12)
> I'm not asking for gcc to be a DWIM compiler, I'm asking for it to do EXACTLY
> what I've told it to do.
You told it to use C type-based aliasing rules to optimize. And exactly this
is
--- Comment #8 from mikpe at it dot uu dot se 2010-01-30 21:57 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Doesn't work, an ARM gcc built with that modification ICEs while trying to
> > compile __muldi3() in libgcc2.c.
> You don't need libgcc to reproduce the problem. If
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
gcc 4.4.1 doesn't warn about strict aliasing that it encounters with -Wall -O2
See bug #42907.
That -Wall did not warn about the code that it ended up miscompiling.
It should at least warn about strict aliasing when gcc is going to break stuff.
--
Summary: gcc -O2 -Wall doesn't war
--- Comment #13 from steven at gcc dot gnu dot org 2010-01-30 21:45 ---
fejj, re-open this again and I guess we'll have to ban you.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from fejj at novell dot com 2010-01-30 21:44 ---
I'm not asking for gcc to be a DWIM compiler, I'm asking for it to do EXACTLY
what I've told it to do.
--
fejj at novell dot com changed:
What|Removed |Added
-
--- Comment #11 from steven at gcc dot gnu dot org 2010-01-30 21:41 ---
It probably does, actually, because next is the first field.
But anyway, still INVALID.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-30 21:39
---
GCC is unfortunately not a DWIM compiler but a C compiler.
And obviously tail = (Node *) ((char *) &list); doesn't make it work.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from fejj at novell dot com 2010-01-30 21:33 ---
gcc should do what I've asked it to do.
if I change the cast to:
tail = (Node *) ((char *) &list);
it works, even with -fstrict-aliasing.
In other words, if I trick gcc into not being "smart", it works. gcc shouldn't
try
--- Comment #7 from shcherbakov at daad-alumni dot de 2010-01-30 21:30
---
(In reply to comment #6)
> Doesn't work, an ARM gcc built with that modification ICEs while trying to
> compile __muldi3() in libgcc2.c.
You don't need libgcc to reproduce the problem. If gcc build has gone to th
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-01-30 21:28 ---
Well the code is totally undefined because you are access a Node* via the
struct Node.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-30 21:28 ---
You violate GCC strict-aliasing rules.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from rguenther at suse dot de 2010-01-30 21:25 ---
Subject: Re: [4.3/4.4/4.5 Regression] volatile structures
and compound literal initializers
On Sat, 30 Jan 2010, gandalf at winds dot org wrote:
> --- Comment #6 from gandalf at winds dot org 2010-01-30 20:56
--- Comment #6 from fejj at novell dot com 2010-01-30 21:25 ---
This code has been working since at least gcc 2.7 days and works fine with
other compiles (Sun's, Microsoft's, etc).
Seems like this is a very real bug to me.
--
fejj at novell dot com changed:
What|Remo
--- Comment #6 from mikpe at it dot uu dot se 2010-01-30 21:24 ---
(In reply to comment #5)
> ARM uses ACCUMULATE_OUTGOING_ARGS instead of PUSH_ARGS. To reproduce the
> problem on ARM, you need to comment out "#define ACCUMULATE_OUTGOING_ARGS 1"
> and add "#define PUSH_ARGS 1" in "gcc/co
--- Comment #5 from fejj at novell dot com 2010-01-30 21:23 ---
the way I compiled it for that gdb session is as follows:
gcc -Wall -g -O2 -o list list.c
If I use -fno-strict-aliasing or use -O0 (or -O1), it works just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-30 21:19 ---
More to the point, it is even worse than violating aliasing rules here as tail
contains a pointer which can contain only another pointer for the size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-30 21:17 ---
You get what you deserve:
$ gcc-4.5.0 -S -O2 -fstrict-aliasing -Wstrict-aliasing=2 q.c
q.c: In function 'main':
q.c:15:2: warning: dereferencing type-punned pointer might break
strict-aliasing rules
That is this li
--- Comment #14 from pault at gcc dot gnu dot org 2010-01-30 21:14 ---
Fixed on trunk and 4.4.
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pault at gcc dot gnu dot org 2010-01-30 21:13 ---
Fixed on trunk and 4.4.
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fejj at novell dot com 2010-01-30 21:13 ---
Created an attachment (id=19761)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19761&action=view)
gdb-log.txt
copy & paste of my gdb session
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907
--- Comment #6 from pault at gcc dot gnu dot org 2010-01-30 21:13 ---
Subject: Bug 41167
Author: pault
Date: Sat Jan 30 21:12:59 2010
New Revision: 156389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156389
Log:
2010-01-30 Paul Thomas
PR fortran/41044
PR fo
--- Comment #13 from pault at gcc dot gnu dot org 2010-01-30 21:13 ---
Subject: Bug 41044
Author: pault
Date: Sat Jan 30 21:12:59 2010
New Revision: 156389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156389
Log:
2010-01-30 Paul Thomas
PR fortran/41044
PR f
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-01-30 21:11
---
We seem to miscompile gen*.c. I'll check out the testsuite.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
--- Comment #1 from fejj at novell dot com 2010-01-30 21:11 ---
Created an attachment (id=19760)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19760&action=view)
list.c
this is a small test-case program to illustrate the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4290
When compiling the attached C code with gcc 4.4.1 [gcc-4_4-branch revision
150839] w/ -O2 -fstrict-aliasing, gcc outputs broken machine code.
>From what I can gather by stepping thru the generated program with gdb, gcc has
dropped a number of statements that are required for the code to properly
f
--- Comment #6 from gandalf at winds dot org 2010-01-30 20:56 ---
The patch provided fixes this issue and brings the original GCC 4.2.2 behavior
back.
Thanks so much for your quick response!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42898
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-30 20:56
---
I'll test it (but I wonder if find_control_dependence is to be corrected
instead).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2010-01-30 20:32 ---
The safe thing to do, may be to ignore self control dependence, like so:
- 8< --
Index: tree-ssa-dce.c
=
--- Comment #5 from shcherbakov at daad-alumni dot de 2010-01-30 20:08
---
Oops, missed a semicolon in the first line of "test case" (compile it with
g++).
ARM uses ACCUMULATE_OUTGOING_ARGS instead of PUSH_ARGS. To reproduce the
problem on ARM, you need to comment out "#define ACCUMULAT
--- Comment #4 from mikpe at it dot uu dot se 2010-01-30 19:54 ---
(In reply to comment #2)
> However, as shown in the patch, the discovered problem is general to GCC4
> (will
> cause problems on all targets having USE_LOAD_PRE_DECREMENT)
The "test case" is syntactically invalid and do
--- Comment #13 from dodji at gcc dot gnu dot org 2010-01-30 18:46 ---
A candidate patch was proposed at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01545.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
--- Comment #4 from pault at gcc dot gnu dot org 2010-01-30 18:22 ---
I just, at last, posted a fix on the list.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38324
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-30 18:17 ---
Created an attachment (id=19759)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19759&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42898
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-30 18:08 ---
Martin - we recently regressed here due to SRA. Even for f2 we now decompose
the assigment to *ptr, even though that will create extra volatile accesses.
I have a patch for the gimplifier bits (to be attached).
-
--- Comment #9 from steven at gcc dot gnu dot org 2010-01-30 17:30 ---
The loop is also properly eliminated if I split the (critical) edge from bb6 to
bb5 the edge that brings in the constant "0" to the "j_1 = PHI ".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-30 16:58 ---
And
int foo (int b, int j)
{
if (b)
{
int i;
for (i = 0; i<1000; ++i)
;
j = b;
}
return j;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-30 16:58 ---
Indeed it works for
void bar (void);
int foo (int b, int j)
{
if (b)
{
int i;
for (i = 0; i<1000; ++i)
;
bar ();
j = 0;
}
return j;
}
--
http://gcc.gnu.org/bugzilla/s
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-30 16:54 ---
(In reply to comment #4)
> Eh, ignore comment #3. My understanding of CD-DCE really *is* rusty :-).
>
> Being more careful now: IIRC the statement "j = 0" would have been control
> dependent on "if (b)" and marking
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-30 16:52 ---
(In reply to comment #3)
> Hack that may be worth trying:
> Index: tree-ssa-dce.c
> ===
> --- tree-ssa-dce.c (revision 156352)
> +++ tree-ssa-dce.c
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-30 16:51 ---
Eh, ignore comment #3. My understanding of CD-DCE really *is* rusty :-).
Being more careful now: IIRC the statement "j = 0" would have been control
dependent on "if (b)" and marking "j = 0" would result in marking "i
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-01-30 16:47
---
So what's the story here? Is it the case that const/pure function removal must
now be done entirely at the tree level because everything is frozen EH-wise at
the RTL level? Why isn't there the obvious early retu
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-30 16:45 ---
Hack that may be worth trying:
Index: tree-ssa-dce.c
===
--- tree-ssa-dce.c (revision 156352)
+++ tree-ssa-dce.c (working copy)
@@ -683,7 +683,
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-30 16:42 ---
Even more fun: mark_control_dependent_edges_necessary is called on basic block
6 because a PHI argument is fed to "j_1 = PHI " i.e. a
constant coming from basic block 6:
#1 0x00a16627 in propagate_necessity
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-30 16:37 ---
The loop is deemed necessary because the loop block (bb 6) is control dependent
on itself (?!):
(gdb)
mark_control_dependent_edges_necessary (bb=0x77f264e0, el=0x142c5d0) at
../../trunk/gcc/tree-ssa-dce.c:388
38
--- Comment #10 from steven at gcc dot gnu dot org 2010-01-30 16:14 ---
That "CD-DCE stuff" has by now deviated so far from the text book
implementation that I don't recognize it anymore at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42720
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-30 16:06 ---
(In reply to comment #6)
> The interesting thing is that the empty loop is not removed by
> the control-dependent DCE pass that follows the 2nd VRP.
>
> This happens because
>
>
> :
> if (obj_7(D) != 0B)
> g
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
The empty loop in the following testcase is not removed by CD-DCE but by
the empty loop removal pass in 4.4.
int foo (int b, int j)
{
if (b)
{
int i;
for (i = 0; i<1000; ++i)
;
j = 0;
}
return j;
}
--
Summary: [4.5 Regression] Empty loop not remo
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-30 16:01 ---
Patches should be sent to gcc-patc...@gcc.gu.org with a ChangeLog entry and
a note how you tested the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722
--- Comment #2 from shcherbakov at daad-alumni dot de 2010-01-30 15:37
---
(In reply to comment #1)
> What is msp430-gcc?
>
msp430-gcc is a port of GCC on TI MSP430 platform, that revealed the bug.
However, as shown in the patch, the discovered problem is general to GCC4 (will
cause p
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-30 15:33 ---
What is msp430-gcc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722
Hi, All,
I have discovered a bug in GCC related to pushing structure arguments
to stack and posted a bugreport here 2 weeks ago:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722
Since that time, I did not get any feedback on the bug. Did I post the
bugreport in the correct place?
--
Best R
--- Comment #8 from rakdver at gcc dot gnu dot org 2010-01-30 12:01 ---
(In reply to comment #7)
> Oh, and Zdenek might have an idea about the condition simplification in
> unswitching.
I agree that some of the checks in tree_unswitch_single_loop are badly placed
-- it does not make sen
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-30 11:00 ---
Oh, and Zdenek might have an idea about the condition simplification in
unswitching.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-30 10:59 ---
The interesting thing is that the empty loop is not removed by
the control-dependent DCE pass that follows the 2nd VRP.
This happens because
:
if (obj_7(D) != 0B)
goto ;
else
goto ;
:
# i_36 = PHI <
--- Comment #1 from janus at gcc dot gnu dot org 2010-01-30 10:37 ---
Related example (PR42888 comment #17):
implicit none
type t
integer :: X = -999.0
end type t
class(t), allocatable :: y(:)
allocate (t::y(1)) ! ICE
end
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-30 10:37 ---
It's optimized away before giving us a chance to warn about it. Such is life.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from janus at gcc dot gnu dot org 2010-01-30 10:31 ---
(In reply to comment #19)
> And the ICE is kind of expected right now, since CLASS arrays
> are not really supported yet (cf. PR42539, PR41600, PR41951; the second one
> contains a similar ALLOCATE statement).
Oops.
--- Comment #19 from janus at gcc dot gnu dot org 2010-01-30 10:29 ---
(In reply to comment #17)
> There is another problem left with the patch. I am not sure whether the
> code is legal, but it gives an ICE for me:
>
> implicit none
> type t
> integer :: X = -999.0 ! Real i
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-01-30
09:47 ---
Subject: Re: [4.3/4.4/4.5 regression] extra
spills due to RTL LICM
> (Looking at Zdenek:) Would something like this in a more polished and actually
> verified&tested form be a good idea?
I think t
--- Comment #11 from aoliva at gcc dot gnu dot org 2010-01-30 09:13 ---
Mine, patch posted.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #3 from aoliva at gcc dot gnu dot org 2010-01-30 09:13 ---
Mine, testing patches.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Assign
91 matches
Mail list logo
