[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 --- Comment #11 from Matthias Kretz (Vir) --- *** Bug 93919 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:b6268016bf46dd63227dcbb73d13c30a3b4b9d2a commit r10-6863-gb6268016bf46dd63227dcbb73d13c30a3b4b9d2a Author: Richard Sandiford Date: Tue Feb 25 19:20:58 2020 + optabs: Don't use scalar conversions for vectors [PR93843] In this PR we had a conversion between two integer vectors that both had scalar integer modes. We then tried to implement the conversion using the scalar optab for those modes, instead of doing the conversion elementwise. I wondered about letting through scalar modes for single-element vectors, but I don't have any evidence that that's useful/necessary, so it seemed better to keep things simple. 2020-02-26 Richard Sandiford gcc/ PR middle-end/93843 * optabs-tree.c (supportable_convert_operation): Reject types with scalar modes. gcc/testsuite/ PR middle-end/93843 * gcc.dg/vect/pr93843-1.c: New test. * gcc.dg/vect/pr93843-2.c: Likewise.
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #8 from rsandifo at gcc dot gnu.org --- Testing a patch.
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843
--- Comment #7 from Matthias Kretz (Vir) ---
This one exhibits the issue without -ftree-vectorize (`-O1` suffices) (cf.
https://godbolt.org/z/Swx-jW):
using M [[gnu::vector_size(2)]] = char;
using MM [[gnu::vector_size(4)]] = short;
MM
cvt(M x)
{
return MM{short(x[0]), short(x[1])};
}
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843
--- Comment #6 from Andrew Pinski ---
(In reply to Matthias Kretz (Vir) from comment #5)
> Simpler variant. I couldn't come up with a better barrier to force the last
> line to load from out than inline asm.
>
> char in[2] = {2, 2};
> short out[2] = {};
>
> int
> main()
> {
> for (int i = 0; i < 2; ++i)
> out[i] = in[i];
> asm("":::"memory");
> if (out[0] != 2) __builtin_abort();
> }
__atomic_signal_fence (__ATOMIC_RELAXED) If you don't want to use inline-asm
directly (it should translate to the same thing internally though).
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843
Matthias Kretz (Vir) changed:
What|Removed |Added
CC||kretz at kde dot org
--- Comment #5 from Matthias Kretz (Vir) ---
Simpler variant. I couldn't come up with a better barrier to force the last
line to load from out than inline asm.
char in[2] = {2, 2};
short out[2] = {};
int
main()
{
for (int i = 0; i < 2; ++i)
out[i] = in[i];
asm("":::"memory");
if (out[0] != 2) __builtin_abort();
}
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 --- Comment #4 from Richard Biener --- IIRC Richard made this valid but maybe didn't expect targets to advertise support for it (how do we check this?)
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 Jakub Jelinek changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The problem is that we have a signed char -> short int cast and vectorizable_conversion on that sees vectype_in a 2xQI with HImode TYPE_MODE and vectype_out a 2xHI with SImode TYPE_MODE. As both vector types have 2 units, modifier is NONE and we create a NOP_EXPR from the 2xQI vector to 2xHI vector where we actually need to sign-extend both vector elements. The big question is whether this is something valid (I'd hope not); if yes, we'd need to tweak the expansion so that it emits something that actually does the extensions, if not, we need to punt or handle it some different way in vectorizable_conversion. Because right now, we actually emit just a scalar sign-extension, which means the first element contains both original elements and second element just 0 or -1 depending on the sign of the original second element.
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Adjusted testcase:
char a;
struct S { short b, c; } d;
__attribute__((noipa)) void
foo (int x)
{
if (x != 4)
__builtin_abort ();
}
int
main ()
{
short *g = , *h =
char e = 4 - a;
int f;
*h = *g = e;
for (f = 0; f < 2; f++)
foo (d.c);
return 0;
}
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Summary|wrong code at -O3 on|[10 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
