https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #23 from rguenther at suse dot de ---
On January 8, 2021 3:07:48 PM GMT+01:00, "mar...@mpa-garching.mpg.de"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
>
>--- Comment #22 from Martin Reinecke ---
>Brilliant, thank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #22 from Martin Reinecke ---
Brilliant, thank you very much for tracking this one down!
My FFT library now works correctly again with all optimizations enabled, which
is a great relief. The scipy maintainers will be happy that they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #20 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bdcde1504502719504a7a63ab10059e171694dc2
commit r11-6549-gbdcde1504502719504a7a63ab10059e171694dc2
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #19 from Martin Liška ---
> err
>
> /* { dg-do run } */
>
> double a[2], b[2], c[2], d[2];
>
> void __attribute__((noipa))
> foo()
> {
> double a0 = a[0];
> double a1 = a[1];
> double b0 = b[0];
> double b1 = b[1];
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #18 from Richard Biener ---
(In reply to Richard Biener from comment #17)
> /* { dg-do run } */
>
> double a[4], b[2];
>
> void __attribute__((noipa))
> foo ()
> {
> double a0 = a[0];
> double a1 = a[1];
> double a2 = a[2];
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #17 from Richard Biener ---
/* { dg-do run } */
double a[4], b[2];
void __attribute__((noipa))
foo ()
{
double a0 = a[0];
double a1 = a[1];
double a2 = a[2];
double a3 = a[3];
b[0] = a1 - a3;
b[1] = a0 + a2;
}
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #16 from Richard Biener ---
Interestingly trunk doesn't exhibit the issue with radb2 but radb4 and radb3
and radb5 still do ... (radb3 being the next "smallest") but a similarly
stripped down testcase doesn't exhibit problems either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #15 from Martin Reinecke ---
"Problem at length N" means that the FFT of length N is computed incorrectly.
Also, N==l1*ido*x.
For an FFT of length N, the computation is broken down into several passes.
Let's take N=15.
First the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #14 from Richard Biener ---
So that makes it sth like the following then - still not miscomparing. What's
the "problem at length N" hinting at? Does N somehow make ido/l1 different?
typedef unsigned long size_t;
template inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #13 from Martin Reinecke ---
> What kind of shape (w/o too much guessing) is the function expecting for its
> input arrays?
For radb the size of the cc and ch arrays is l1*ido*x.
Size of wa is (x-1)*ido.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #12 from Richard Biener ---
So at least the following doesn't produce any different answers for me
comparing -O -ftree-loop-vectorize -mavx to -O0
typedef unsigned long size_t;
template inline void PM(T , T , T c, T d)
{ a=c+d;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #11 from Richard Biener ---
Or massaging the C++ to produce a single-function testcase (driver still
missing,
I think we can remove the "unrelated" loops as well). What kind of shape (w/o
too much guessing) is the function expecting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #10 from Richard Biener ---
Created attachment 49912
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49912=edit
GIMPLE testcase for one of the miscompiled(?) loops
It shows similar vectorized / analysis IL as for the big
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> (In reply to Martin Liška from comment #2)
> > Confirmed, one can reduce that to a single loop vectorization:
> >
> > $ g++ bug2.cc -std=c++17 -O1 -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #8 from Richard Biener ---
(In reply to Martin Liška from comment #2)
> Confirmed, one can reduce that to a single loop vectorization:
>
> $ g++ bug2.cc -std=c++17 -O1 -mavx -ftree-loop-vectorize
> -fdbg-cnt=vect_loop:10-10 &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> (In reply to Martin Liška from comment #3)
> > For g++ bug2.cc -std=c++17 -O1 -mavx -ftree-loop-vectorize, it started with
> > r11-3917-g28290cb50c7dbf87.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #6 from Martin Liška ---
(In reply to Richard Biener from comment #5)
> (In reply to Martin Liška from comment #3)
> > For g++ bug2.cc -std=c++17 -O1 -mavx -ftree-loop-vectorize, it started with
> > r11-3917-g28290cb50c7dbf87.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
--- Comment #5 from Richard Biener ---
(In reply to Martin Liška from comment #3)
> For g++ bug2.cc -std=c++17 -O1 -mavx -ftree-loop-vectorize, it started with
> r11-3917-g28290cb50c7dbf87.
Are you sure about this bisection? Reverting this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544
Martin Liška changed:
What|Removed |Added
Summary|[11 regression] Wrong code |[11 regression] Wrong code
21 matches
Mail list logo
