--- Comment #16 from irar at il dot ibm dot com 2009-12-15 13:35 ---
But in comment #5 you wrote that it passes with the print, right? So, this dump
contains correct or incorrect code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #21 from irar at il dot ibm dot com 2009-12-16 12:01 ---
Thanks.
I'll be able to look at this only on Sunday due to holidays.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #23 from irar at il dot ibm dot com 2009-12-20 12:18 ---
The code that now gets vectorized is the summation of array 'reduce':
sum(reduce). It looks like the problem is with adding the reduction result to
the correct index of 'temp' (scalar code), and not with the reduction
--- Comment #26 from irar at il dot ibm dot com 2009-12-20 13:46 ---
I think the problem is in alignment. We force alignment of temp.6 and temp.20 -
the arrays of relevant comaprison results - even though we don't vectorize
their loop. The decision whether we can force alignment is made
--- Comment #28 from irar at il dot ibm dot com 2009-12-20 13:59 ---
Hm, I don't know, but this is my best guess - we change something in the code
that goes wrong...
We also force alignment of reduce, but the reduction computation looks ok.
--
http://gcc.gnu.org/bugzilla
--- Comment #30 from irar at il dot ibm dot com 2009-12-22 11:42 ---
We can try to verify the alignment issue by applying the two hacks I am
attaching.
The first one disables alignment forcing for all the data-refs (and marks the
alignment as unknown). The loops are still vectorizable
--- Comment #31 from irar at il dot ibm dot com 2009-12-22 11:43 ---
Created an attachment (id=19370)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19370action=view)
disable alignment forcing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #32 from irar at il dot ibm dot com 2009-12-22 11:44 ---
Created an attachment (id=19371)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19371action=view)
force alignment of vectorized arrays only
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #36 from irar at il dot ibm dot com 2009-12-23 07:54 ---
Thanks!
So, it is alignment of the vectorized arrays. I'd like to do two more checks:
1. Just force alignment of the two arrays (temp and reduce) and do not
vectorize.
2. Force alignment of reduce only (and vectorize
--- Comment #37 from irar at il dot ibm dot com 2009-12-23 07:54 ---
Created an attachment (id=19377)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19377action=view)
Force alignment but don't vectorize
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #38 from irar at il dot ibm dot com 2009-12-23 07:55 ---
Created an attachment (id=19378)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19378action=view)
Force alignment of reduce only
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #40 from irar at il dot ibm dot com 2009-12-23 14:49 ---
(In reply to comment #39)
I have regtested the patch in comment #31 and I have ~75 regressions on
x86_64-apple-darwin10 in the gcc vect test suite (~100 on
powerpc-apple-darwin9). Is this expected? and do you want
--- Comment #7 from irar at il dot ibm dot com 2009-12-30 10:16 ---
The bug is in SLP load permutation analysis. I am testing a patch.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #42 from irar at il dot ibm dot com 2010-01-05 09:09 ---
So, it's enough to force alignment of reduce only (and to vectorize its loop)
to get wrong code. On the other hand, the result of the vectorized loop is
correct, and the problem is in choosing the correct index of temp
--- Comment #5 from irar at il dot ibm dot com 2010-01-10 08:22 ---
In vector_alignment_reachable_p() we check if an access is packed using
contains_packed_reference(). For packed accesses we return false, meaning
alignment is unreachable and peeling cannot be used.
In the attached
--- Comment #43 from irar at il dot ibm dot com 2010-01-10 13:43 ---
Since -O2 -ftree-vectorize doesn't cause bad code, it has to be some other
optimization on top of vectorized code that causes the problem.
Bad code is generated when the alignment of 'reduce' is forced
--- Comment #8 from irar at il dot ibm dot com 2010-01-12 08:08 ---
So, to be on the safe side, we should assume that COMPONENT_REFs are not
naturally aligned and never use peeling for them?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42652
--- Comment #10 from irar at il dot ibm dot com 2010-01-13 09:35 ---
Yes, I understand that we can't assume that an access is aligned if we can't
prove it's aligned. I don't understand how we can prove that a COMPONENT_REF is
aligned, i.e., if there is a way to check if a struct
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #19 from irar at il dot ibm dot com 2008-09-22 12:32 ---
(In reply to comment #18)
Created an attachment (id=16377)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377action=view) [edit]
patch
Actually this one vectorizes slp-perm-1.c for me on a ppc64 cross
--- Comment #20 from irar at il dot ibm dot com 2008-09-22 12:41 ---
(In reply to comment #18)
Created an attachment (id=16377)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377action=view) [edit]
patch
Actually this one vectorizes slp-perm-1.c for me on a ppc64 cross
--- Comment #5 from irar at il dot ibm dot com 2008-09-28 06:17 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from irar at il dot ibm dot com 2008-10-07 11:25 ---
This seems to be similar to the failure in PR 37385 (in set_mem_alias_set, at
emit-rtl.c:1789). There the ICE was because the lhs and the element type of rhs
did not alias.
--
irar at il dot ibm dot com changed
--- Comment #4 from irar at il dot ibm dot com 2008-11-06 08:50 ---
Maybe the complete source will be better...
I don't see any failure with r141636 on x86_64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37955
--- Comment #2 from irar at il dot ibm dot com 2008-11-11 09:24 ---
I am testing the following:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 141763)
+++ tree-vect-analyze.c (working copy)
@@ -3314,8
--- Comment #2 from irar at il dot ibm dot com 2008-11-22 15:08 ---
(In reply to comment #1)
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
--- Comment #2 from irar at il dot ibm dot com 2008-12-11 08:02 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #7 from irar at il dot ibm dot com 2008-12-30 14:57 ---
(In reply to comment #6)
t.i:3: note: Vectorization may not be profitable.
why doesn't the cost model then disallow vectorization here?
This is misleading. It only means that there exists loop bound threshold either
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35272
--- Comment #3 from irar at il dot ibm dot com 2008-03-04 13:30 ---
It fails in initialize_matrix_A() when called with chrec {0, +, {0, +, 4}_1}_2:
int_cst_value (CHREC_RIGHT (chrec)) ICEs, since CHREC_RIGHT (chrec) here is {0,
+, 4}_1.
Ira
--
irar at il dot ibm dot com changed
--- Comment #4 from irar at il dot ibm dot com 2008-03-04 15:44 ---
Isn't the same problem as in pr34635?
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--- Comment #5 from irar at il dot ibm dot com 2008-03-13 06:51 ---
(In reply to comment #4)
This still happens on mainline.
I wonder if vectorizer infrastructure can be re-used here to detect unrolled
and looped version of memset. In addition to loop that can be vectorized, we
--- Comment #4 from irar at il dot ibm dot com 2008-03-20 09:30 ---
I reproduced the failures with revision 133362 (and without
--disable-multilib). Reverting our patch (revision 133134) didn't help, I still
see the failures even without it.
Ira
--
irar at il dot ibm dot com
--- Comment #7 from irar at il dot ibm dot com 2008-04-07 07:06 ---
I am testing the following patch:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 132478)
+++ tree-vect-transform.c
--- Comment #10 from irar at il dot ibm dot com 2008-04-10 07:10 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from irar at il dot ibm dot com 2008-04-22 07:57 ---
The problem here is that we do not check the types of interleaved data-refs,
but only their steps (and since float and int are of the same size here, their
steps are equal). And then we treat all the data-refs
--- Comment #7 from irar at il dot ibm dot com 2008-04-24 07:30 ---
(In reply to comment #6)
Fixed on the 4.3 branch, but not on the trunk yet.
Yes, I'm going to do this during the next couple of hours.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35982
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36033
--- Comment #9 from irar at il dot ibm dot com 2008-04-24 09:40 ---
Fixed.
I opened pr36033 to get rid off the redundant loads.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #4 from irar at il dot ibm dot com 2008-04-24 12:24 ---
(In reply to comment #2)
the final increment for ivtmp.15_36 is wrong -- it should be 48.
Right. We are not supposed to vectorize this at all, since SLP currently
doesn't support loads with gaps.
Here
--- Comment #3 from irar at il dot ibm dot com 2008-05-04 05:54 ---
(In reply to comment #1)
SLP also doesn't handle vectorization of register operations but needs
memory source and destination operands(?).
Right.
Likewise SLP shouldn't be
confused by unvectorizable data types
--- Comment #4 from irar at il dot ibm dot com 2008-05-04 06:02 ---
(In reply to comment #2)
The vectorizer doesn't know to vectorize __builtin_cexpi or
{REAL,IMAG}PART_EXPR
either.
IMHO rather than somehow tweaking the early unroller the vectorizer should
know how to deal
--- Comment #1 from irar at il dot ibm dot com 2008-05-04 08:00 ---
I don't get the ICE: revision 134926, x86_64-linux, same flags. The loop in
line 14 gets vectorized.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
--- Comment #3 from irar at il dot ibm dot com 2008-05-04 11:13 ---
In my dump this stmt is vectorized ok:
bug.F:14: note: --vectorizing statement: D.1055_23 = ((D.1054_22))
bug.F:14: note: transform statement.
bug.F:14: note: vect_is_simple_use: operand ((D.1054_22))
bug.F:14
--- Comment #4 from irar at il dot ibm dot com 2008-05-04 11:21 ---
If it is really a try to SLP, I think this patch will fix the ICE:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 134926
--- Comment #6 from irar at il dot ibm dot com 2008-05-04 11:49 ---
(In reply to comment #5)
Created an attachment (id=15574)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574action=view) [edit]
vectorizer dump
Attached.
Thanks!
The last line indeed hints at SLP
--- Comment #8 from irar at il dot ibm dot com 2008-05-04 12:07 ---
(In reply to comment #7)
It does - and the loop is vectorized. But it looks like a hack ;)
It is not. We actually do this in all vectorizable_...() that support SLP.
SLP currently does not support multiple types (I
--- Comment #10 from irar at il dot ibm dot com 2008-05-04 12:26 ---
(In reply to comment #9)
Can you give the patch bootstrap test? I'll pre-approve
it here.
Sure, for both trunk and 4.3.1, I guess.
Ira
Thanks,
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #14 from irar at il dot ibm dot com 2008-05-12 12:17 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from irar at il dot ibm dot com 2008-05-14 07:04 ---
It's a bug in SLP analysis. I am working on a fix.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #7 from irar at il dot ibm dot com 2008-05-14 12:30 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from irar at il dot ibm dot com 2008-05-22 05:41 ---
*** This bug has been marked as a duplicate of 35642 ***
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #13 from irar at il dot ibm dot com 2008-05-22 05:41 ---
*** Bug 36295 has been marked as a duplicate of this bug. ***
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #3 from irar at il dot ibm dot com 2008-05-22 10:48 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from irar at il dot ibm dot com 2009-07-16 12:29 ---
pr40770.c:20: note: == examining statement: sincostmp.21_1 = __builtin_cexpi
(D.1625_3);
pr40770.c:20: note: get vectype for scalar type: complex double
pr40770.c:20: note: not vectorized: unsupported data-type complex
--- Comment #6 from irar at il dot ibm dot com 2009-07-16 17:31 ---
(In reply to comment #3)
make_vector_type returns NULL for this type.
Yes - there is no vector type for complex double. But the vectorizer
could query for a vector type for the complex component type (double
--- Comment #3 from irar at il dot ibm dot com 2009-07-19 09:35 ---
Testing a fix.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo
--- Comment #7 from irar at il dot ibm dot com 2009-07-20 11:18 ---
AFAIU, querying for the component type of complex type is not difficult to
implement.
I think, that loop-based vectorization is preferable here, so we should stay
with vectorization factor of 2 for doubles.
The next
--- Comment #28 from irar at il dot ibm dot com 2009-07-20 12:03 ---
I've just committed a patch that adds support of cond_expr in reductions in
nested cycles (http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01124.html).
cond_expr cannot be vectorized in reduction of inner-most loop
--- Comment #5 from irar at il dot ibm dot com 2009-07-26 07:04 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #32 from irar at il dot ibm dot com 2009-07-26 07:48 ---
(In reply to comment #30)
Regarding the just committed inline version: It would be interesting to know
whether it is vectorizable (with/without -ffinite-math-only [i.e.
-ffast-math]).
It depends on where
--- Comment #34 from irar at il dot ibm dot com 2009-07-27 08:36 ---
(In reply to comment #33)
Using the example from comment 23 with
...
gfortran shows: test.f90:12: note: not vectorized: unsupported use in stmt.
and needs 2.272s. (By comparison. 4.4 needs 3.688s
--- Comment #38 from irar at il dot ibm dot com 2009-07-27 12:44 ---
I am not sure that that kind of computation can be generated automatically,
since in general the order of caclulation of cond_expr cannot be changed.
However, the loop can be split:
for (i = 0; i end; i
--- Comment #41 from irar at il dot ibm dot com 2009-07-28 08:12 ---
That requires pattern recognition. MIN/MAX_EXPR are recognized by the first
phiopt pass, so MIN/MAXLOC should be either also recognized there or in the
vectorizer. (The phiopt pass transforms if clause to MIN/MAX_EXPR
--- Comment #10 from irar at il dot ibm dot com 2009-08-06 10:49 ---
Yes. The problem is that only a basic implementation was added. To vectorize
this code several improvements must be done: support stmt group sizes greater
than vector size, allow loads and stores to the same location
--- Comment #3 from irar at il dot ibm dot com 2009-08-09 12:15 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from irar at il dot ibm dot com 2009-08-12 12:14 ---
Looks like a problem in data-ref analysis:
Creating dr for this_6(D)-_M_x[__k_87]
...
base_address: this_6(D)
offset from base address: 0
constant offset from base address: 0
step: 8
--- Comment #10 from irar at il dot ibm dot com 2009-08-13 11:34 ---
Reduced testcase:
#include stdlib.h
#include stdio.h
#define N 4
long int a[N];
int main ()
{
int k;
for (k = 0; k N; ++k)
a[k] = a[k] != 5 ? 12 : 10;
for (k = 0; k N; ++k)
printf (%u , a[k
--- Comment #11 from irar at il dot ibm dot com 2009-08-13 11:36 ---
Created an attachment (id=18350)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18350action=view)
The assembly for the long int version (wrong code)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
--- Comment #12 from irar at il dot ibm dot com 2009-08-13 11:37 ---
Created an attachment (id=18351)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18351action=view)
The assembly for the int version (correct)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
--- Comment #9 from irar at il dot ibm dot com 2009-09-08 05:51 ---
Looks related to PR 39907.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41288
--- Comment #4 from irar at il dot ibm dot com 2009-09-27 08:06 ---
(In reply to comment #1)
The interesting thing is that data-ref analysis sees 128bit alignment but
the vectorizer still produces
vect_var_.24_59 = M*vect_p.20_57{misalignment: 0};
D.2564_12 = *D.2563_11
--- Comment #6 from irar at il dot ibm dot com 2009-09-27 09:56 ---
(In reply to comment #5)
aligned to refers to the offset misalignment and not to the misalignment
of
base.
Hmm, I believe it refers to base + offset + constant offset.
tree-data-refs.h:
/* Alignment
--- Comment #1 from irar at il dot ibm dot com 2008-06-11 08:00 ---
Reproduced on powerpc64-suse-linux.
Doesn't occur when compiled with -O2 -ftree-vectorize instead of -O3 (the
vectorizer generates the same code in both cases).
--
irar at il dot ibm dot com changed
--- Comment #5 from irar at il dot ibm dot com 2008-06-17 11:49 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from irar at il dot ibm dot com 2008-06-26 06:24 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from irar at il dot ibm dot com 2008-06-26 11:57 ---
For access function (short int) {(short unsigned int) i_44, +, 1}_1)
evolution_part_in_loop_num() returns NULL, which causes the failure.
I tried to peel NOP_EXPRs from POLYNOMIAL_CHRECs in
evolution_part_in_loop_num
--- Comment #4 from irar at il dot ibm dot com 2008-06-26 18:33 ---
(In reply to comment #3)
Can't you simply handle a NULL return
from evolution_part_in_loop_num in the vectorizer?
The problem is that this happens during the transformation (for the code
created by the vectorizer
--- Comment #5 from irar at il dot ibm dot com 2008-06-29 12:25 ---
It's a bug in calculation of number of iterations of prolog loop. I am testing
the following patch:
Index: tree-vect-transform.c
===
--- tree-vect
--- Comment #8 from irar at il dot ibm dot com 2008-07-01 06:12 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from irar at il dot ibm dot com 2008-07-06 11:54 ---
All those failures occur because vector multiplication of shorts to shorts is
not supported on power. Paolo's patch changed the order of type conversion and
multiplication, and removed type conversions.
All those
--- Comment #15 from irar at il dot ibm dot com 2008-07-06 11:55 ---
(In reply to comment #14)
Also Victor tried to reproduced the behavior that Kenny described in
comment #3
comment #1
Sorry,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
--- Comment #16 from irar at il dot ibm dot com 2008-07-06 11:57 ---
(In reply to comment #15)
(In reply to comment #14)
Also Victor tried to reproduced the behavior that Kenny described in
comment #3
comment #1
Grrr, it was in the problem description not in the comments
--
irar at il dot ibm dot com changed:
What|Removed |Added
Priority|P1 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
--- Comment #5 from irar at il dot ibm dot com 2008-07-16 06:19 ---
This seems to fix the problem:
Index: tree-chrec.c
===
--- tree-chrec.c(revision 137271)
+++ tree-chrec.c(working copy)
@@ -696,6 +696,8
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #4 from irar at il dot ibm dot com 2008-08-20 12:18 ---
I am testing the following patch:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 139225)
+++ tree-vect-analyze.c (working copy
--- Comment #1 from irar at il dot ibm dot com 2008-08-23 11:31 ---
I think it's a duplicate of pr37174.
I've just committed the fix.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37209
--- Comment #8 from irar at il dot ibm dot com 2008-08-23 11:32 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from irar at il dot ibm dot com 2008-09-03 10:43 ---
(In reply to comment #7)
I still think that handling NULL from evolution_part_in_loop_num is the
correct thing to do. Even if you need to move this check to the analysis
phase.
The interesting thing
--- Comment #19 from irar at il dot ibm dot com 2008-09-07 11:05 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #12 from irar at il dot ibm dot com 2008-09-07 11:05 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37416
--- Comment #13 from irar at il dot ibm dot com 2008-09-08 07:44 ---
(In reply to comment #9)
Subject: Re: [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
Another thing, 4.4 does not vectorize this loop anymore (and, therefore,
there
is no ICE), because
--- Comment #6 from irar at il dot ibm dot com 2008-09-09 08:24 ---
(In reply to comment #5)
This looks related to PR 37418.
The testcase in PR 37418 ICEs also with -fno-tree-vectorize.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37385
--- Comment #8 from irar at il dot ibm dot com 2008-09-10 07:48 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
201 - 300 of 361 matches
Mail list logo
