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.
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.
