https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 3 Jun 2019, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713 > > Segher Boessenkool <segher at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Last reconfirmed| |2019-06-03 > Ever confirmed|0 |1 > > --- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> --- > Confirmed. And confirmed that the testcase works fine with -maltivec. > > vect_float is the wrong selector to see if vectors of float are enabled by > current compiler options: > > # Return 1 if the target supports hardware vectors of float when > # -funsafe-math-optimizations is enabled, 0 otherwise. > # > # This won't change for different subtargets so cache the result. > > This testcase will need a test to see if there are 16 byte vector floats. > Something that just tries to create a > typedef float v4sf __attribute__((vector_size(16))); > variable should do fine. > > Oh, and the gimple front end shouldn't ICE the compiler, of course :-/ The GIMPLE FE expects valid GIMPLE - but yes, the GIMPLE verifier lacks verification of certain vector target constraints so we end up ICEing in the expander or lowering things unexpectedly. The GIMPLE FE is a unit-testing / debugging tool, not a "proper" frontend ;) I guess I'll add { dg-additional-options "-maltivec" { target powerpc*-*-* } }
