Hi Edwin,
I think just replace to:
/* { dg-options "-O2 -finstrument-functions -mabi=lp64d -march=rv64gc
-mtune=sifive-p600-series" } */
On Thu, Feb 15, 2024 at 7:43 PM Robin Dapp <rdapp....@gmail.com> wrote:
> > Ah oops I glanced over the /* { dg-do compile } */part. It should be
> > fine to add '-march=rv64gc' instead then?
>
> Hmm it's a bit tricky. So generally -mcpu=sifive-p670 includes rv64
> but it does not override a previously specified -march=rv32 (that might
> have been added by the test harness or the test target). It looks
> like it does override a (build option and thus not directly specified
> when compiling) --with-arch=rv32.
>
> For now I'd stick with something like -march=rv64gc -mtune=sifive-p670
> (but please check if the original problem does occur with this).
> While you're at it you could delete the redundant '/' in the first
> line.
>
> In general it's a bit counterintuitive a test specifying a
> particular CPU (that supports several extensions) might have
> those overridden when e.g. testing on a rv32 target not supporting
> those. We also do not support cpu names in the march string
> so there is no nice way of overriding previously specified marchs.
>
> Kito: Any idea regarding this? I read in your commit message that
> mcpu has lower precedence than march. Right now that allows us to
> somewhat silently remove architecture options that are specified
> last on the command line.
>
> aarch64 warns in case something is in conflict, maybe we should do
> that as well?
>
> At least I find it a bit annoying that we don't have a way of
> saying:
> "This test always needs to be compiled with all arch features of
> cpu = ..." and rather need to specify -march=rv64gcv_z..._z...
>
> Without having this thought through, can't mcpu be of kind of
> similar precedence to march and we'd let the one specified last
> "win" in case of conflicts? Possibly with an exception for
> the 32/64 bit. Does LLVM not have this problem?
>
> Regards
> Robin
>
>
