#21064: Enable NTL's '-march=native' more cautiously
-------------------------------------+-------------------------------------
Reporter: leif | Owner: leif
Type: defect | Status: needs_review
Priority: blocker | Milestone: sage-7.3
Component: packages: | Resolution:
standard |
Keywords: assembler shlx | Merged in:
mulx |
Authors: Leif Leonhardy | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/leif/enable_NTL_native_more_safely|
41ea5daf35f02a6e53bd62a08a423a472edbb2d4
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by leif):
Replying to [comment:5 leif]:
> Replying to [comment:4 fbissey]:
> > Anyone has contacted Victor to see if he could make a check that would
also test the assembler in a new version?
> W.r.t. upstream, thinking more about it I came to the conclusion that
it's pretty ok to assume that the parts of the toolchain fit, and for an
ordinary user manually running NTL's `configure` it's easy to just pass
`NATIVE=off` if something doesn't work.
>
> On the other hand, I actually intended to add proper feature checks (for
each "non-standard" ISA extension enabled by `-march=native`, which of
course is a moving target), probably also with some runtime checks
(actually ''executing'' instructions), because what CPUID reports isn't
always correct (and hence GCC could be "wrong" as well), be it a crippled
''and'' flawed Intel chip, or a VM bug.
Looking deeper into NTL's configure process (I haven't done for a while),
there's certainly room for improvements, i.e., changes we could submit
upstream in the long run.
While there are tests for AVX, AVX2 and `__builtin_clzl()` actually
running test code (implicitly testing the toolchain), the test program
(which gets compiled ''and'' linked, but currently not run) for
`CXXAUTOFLAGS` (which include `-march=native` if `NATIVE=on`) is the
following:
{{{
#!C
int main() { return 0; }
}}}
I think it's ''unlikely'' that GCC will generate code containing ''any''
ISA extension instructions for this, so the assembler won't complain there
(and the program -- as is -- is likely to run without errors on ''any''
machine with the same [generic] architecture, not only on those with the
specific one GCC ''thinks'' is the native).
--
Ticket URL: <https://trac.sagemath.org/ticket/21064#comment:21>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
