On Sat, 30 Jan 2021 at 17:18, Étienne Mollier <[email protected]> wrote:
> Hi Michael, > > Michael Crusoe, on 2021-01-30 16:51:27 +0100: > > On Sat, 30 Jan 2021 at 14:33, Étienne Mollier < > [email protected]> > > 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 -- Michael R. Crusoe
