#20563: Cannot compile SnapPy for sage because sage's gcc is incompatible with
system's as
----------------------------+------------------------
Reporter: mgoerner | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-7.2
Component: porting | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
----------------------------+------------------------
Comment (by mgoerner):
Replying to [comment:6 dunfield]:
> My guess is that the trigger is that the code is such that gcc decides
to optimize by issuing certain SSE instructions/operands. Which SSE
instructions/operands it generates depends on what version of "as" was
present when gcc was compiled, not what version is present at run time.
The version of "as" on 10.11 knows more SSE stuff than the one on (say)
10.9, hence the issue.
Nathan and I actually verified it by looking at the results of "gcc
SnapPy.c -S" when run under "sage -sh" which produces the intermittent
assembly code.
My guess is that the configure script of gcc follows a certain pattern to
search for "as" and, if it finds it, probes it for its capabilities. If
gcc is then compiled, the assembly produced by that gcc depends on the
"as" found during configure time.
This problem can be avoided if sage compiled its own "as" and its binary
distribution ships with it.
There are two ways of doing this:
1. Making an own sage package for binutils (which contain as) and make the
gcc sage package depend on it.
2. Making the gcc sage package obtain the binutils source code and
symlinking parts of it (see comment 1) into gcc's src directory.
I think 1. has the danger that we need to make sure gcc's configure really
picks up the "as" we compiled and doesn't fallback on the system's as.
This might require extra parameters.
And for 2., I don't know whether the sage package framework is flexible
enough to download/cache the source code from two different tarballs.
----
In detail:
The "offending instruction" is a movq instruction where an operand is an
SSE register xmm0, ...
When using the sage binary distribution, the result of the above gcc
command contains the offending instruction.
When Nathan compiled sage (and thus its gcc) himself on Mac OS 10.9, the
result of the same command does not contain the offending instruction
(though it still contained other instructions with SSE registers).
"as" on 10.11 accepts the "offending instruction" but on 10.9 it does not
(supporting of the "offending instruction" starting binutils version 2.17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43215#c7).
--
Ticket URL: <http://trac.sagemath.org/ticket/20563#comment:7>
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.
