Hi Michael,
Michael Crusoe, on 2021-01-30 16:51:27 +0100:
> On Sat, 30 Jan 2021 at 14:33, Étienne Mollier <etienne.mollier@mailoo.org>
> wrote:
> > [1] https://salsa.debian.org/med-team/brian/-/tree/master
>
> https://salsa.debian.org/med-team/brian/-/blob/master/debian/patches/gsl-compiler-arg.patch#L29
>
> -march=native is not allowed as it violates the architecture baseline,
> unless there is an alternative binary or library built without it.
I would generally agree, but in this case I understood the code
was compiled (in the background) on the end user's machine[3].
I don't exclude that I could have misunderstood the mechanism,
so am triple checking at the moment. I probably should have put
the link in the patch header, by the way.
[3] https://brian2.readthedocs.io/en/stable/user/computation.html
If it is truly for local use, then -march=native is great, but not every architecture supports "-march=native", so you may need to add work arounds for archs that don't have that gcc option.
Here is the result of some reading of the gcc manual page
-march=native & -mtune=native is valid in gcc for the following Debian archs:
arm*
mips*
s390x
i386/amd64/x32
but not these
HPPA
M68k
riscv64
power*/ppc* (no -march at all, but does have -mcpu=native and -mtune=native)
alpha (no -march at all, but does have -mcpu=native and -mtune=native)
sh4 (no -march at all, no -mcpu either)
sparc64 (no -march at all, but does have -mcpu=native and -mtune=native)
ia64 (no -march, has -mtune but not -mtune=native)
In any way, I guess putting more regular compiler flags at first
should give a far safer outcome than current architecture
dependent selection.
Thanks for your review! :)
You are welcome