> 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
