On Mon, Dec 09, 2024 at 09:40:41AM -0800, Palmer Dabbelt wrote:
> On Mon, 09 Dec 2024 09:05:10 PST (-0800), Robin Dapp wrote:
> > > +/* { dg-additional-options "-mabi=lp64d" { target { rv64 } } } */
> > > +/* { dg-additional-options "-mabi=ilp32d" { target { rv32 } } } */
> >
> > Wouldn't skipping those tests also be reasonable?
> > I.e. adding a target to the compile directive instead. I'd find that a bit
> > more intuitive than overriding the ABI.
> > The same might apply to the other cases you touched. In the end it's
> > probably
> > a question of taste but why if your test target mandates an ABI that cannot
> > compile vector tests, why compile them at all?
>
> Unless I'm missing something, these just add V (and sometimes Zvbb). Those
> should both be buildable with any ABI that's supported by the base ISA. So
> I think something else has gone off the rails here.
The way I read the specifications, ILP32E ABI is not compatible with the
V extension. See quotes and referenced documents below:
- The V vector extension depends upon the Zvl128b and Zve64d extensions [1].
- The Zve64d extension depends upon the D extension [2].
- The ILP32E calling convention is not compatible with ISAs
that have registers that require load and store alignments
of more than 32 bits. In particular, this calling convention
must not be used with the D ISA extension [3]
[1] The RISC-V Instruction Set Manual Volume I, Version 20240411
Chapter "31.18.3. V: Vector Extension for Application Processors"
[2] The RISC-V Instruction Set Manual Volume I, Version 20240411
Chapter "31.18.2. Zve*: Vector Extensions for Embedded Processors"
[3] RISC-V ABIs Specification, Version 1.0: Ratified
Chapter "2.3. ILP32E Calling Convention"
Regards,
Dimitar
>
> >
> > --
> > Regards
> > Robin
