https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 8 Jul 2019, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060 > > rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Component|middle-end |target > Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot > gnu.org > > --- Comment #11 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot > gnu.org> --- > (In reply to rguent...@suse.de from comment #10) > > On Mon, 8 Jul 2019, clyon at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91060 > > > > > > --- Comment #8 from Christophe Lyon <clyon at gcc dot gnu.org> --- > > > (In reply to Richard Biener from comment #5) > > > > Hmm, using a cross configured as > > > > > > > > trunk/configure --target=armeb-none-linux-gnueabihf --with-cpu=cortex-a9 > > > > --with-fpu=neon-fp16 --enable-languages=c > > > > > > > > and trimming the testcase to the first line I cannot reproduce the > > > > reported > > > > assembly. I get at -O3 > > > > > > > > .arm > > > > .fpu softvfp > > > > > > For some reason, you are not targeting the right FPU, I have: > > > .arm > > > .fpu neon-fp16 > > > > I noticed that - but it doesn't change even when supplying > > -mpfu=neon-fp16 -mcpu=cortex-a9 > > > > I suppose some configure-time checking disables this feature somehow > > without notifying me :/ (don't have a armeb assembler installed, > > trying a pure cc1 cross) > > > > Anyway, I can't reproduce even after spending 1+ hours on this. > > Yeah, I see the same thing building it that way. I needed to restate > the abi using -mfloat-abi=hard. Even when adding -mfloat-abi=hard I see .fpu softvfp ... > I'm pretty sure it's a target bug though. If a vector constructor > has a single nonconstant element, neon_expand_vector_init uses the > neon_vset_lane* patterns to set that index. But neon_vset_lane* > use the architecture lane numbering while neon_expand_vector_init > uses GCC lane numbering. Using the vec_set(_internal) patterns > should fix that. I'm out of here then ;)
