cado-nfs config tests forcibly add some architecture flags, which might be undesirable
It is fairly common that some processor features (avx2, pclmul, whatnot) need specific flags to be activated. In most cases, this is a rather good idea to test for that.
However, there's a case where it's totally unnecessary: if the user supplied -march=native
, this of course encompasses all the feature flags that might be needed on the current machine.
Going further, there's even a situation where this behavior is outright buggy, in fact. If the user tries to compile for an older-generation architecture (e.g. by specifying -march=ivybridge
on a skylake machine), then it's clearly NOT right to attempt -march=ivybridge -mavx2
; we really don't care if this happens to work on the machine that does the compilation, all we need is that the feature set sticks to exactly what we've requested.
I'm therefore going for a special case that catches the presence of a -march
of some sort, and omits this automatic flag behavior in these cases.
Ideally, we should also detect the ways that the user could supply architecture specifications for other compilers as well.