#13137: upgrade MPIR to 2.6.0
-------------------------------------------------------------------------+--
Reporter: jhpalmieri |
Owner: tbd
Type: enhancement |
Status: needs_review
Priority: major |
Milestone: sage-5.6
Component: packages |
Resolution:
Keywords: mpir spkg |
Work issues:
Report Upstream: N/A |
Reviewers: Jeroen Demeyer
Authors: John Palmieri, Jean-Pierre Flori, Karl-Dieter Crisman |
Merged in:
Dependencies: #13755 |
Stopgaps:
-------------------------------------------------------------------------+--
Comment (by jpflori):
Replying to [comment:96 leif]:
> Replying to [comment:93 jpflori]:
> > Replying to [comment:92 leif]:
> > > Replying to [comment:91 jpflori]:
> > > > Ok it failed with older MPIR as well, please have a look at build
logs here:
> > > > https://groups.google.com/d/topic/sage-
release/ngw_EiBaY0Q/discussion
> > >
> > > Well, that's a single failure, [although] in `nuss_mul()`[too] (and
on an Apple ''of course^TM^'')... ;-)
> > >
> > Hmmm, the reports on sage-release for 5.6.beta3 also point that there
is a problem with zn_poly on top of MPIR 2.4.x [on OS X], and I don't know
why but I have strong suspicion it could be in nuss_mul [as well].
>
> I didn't mean to say it was MPIR's fault. (I agree it's something with
zn_poly['s tuning], perhaps in conjunction with a specific GCC version
[and probably also the OS]. Note that the MacOSs most probably have GCC
4.6.3 [from our spkg] in common.]
>
> [[BR]]
>
> > > One would probably have to run ''the tuning'' multiple times under
heavy load to reproduce this; haven't at all looked at the code...
> > The problem is not during the tuning phase but during the quick test
one.
>
> Well, it shows up during the tests, but presumably the tuning generates
invalid code (or code triggering a compiler bug) under certain
circumstances, like perhaps heavy load.
>
From what I see after a quick look, the tuning process only chooses
thresholds, and does not generates code.
So maybe the code is genuinely buggy for certain random values, or there
is a compiler bug (but from what we gathered I wouldn't say we always use
the same GCC, bugs appear at least with FSF GCC 4.6.3 on different Os X
and with Cywgin GCC 4.5.3 (maybe with later FSF GCC don't remember) on ...
Cygwin) that generates code which fails on certain random values.
Or maybe under heavy load, the thresholds get chosen so that code is
called on value ranges it is not meant for and boom (but only on Os X and
Cygwin, if that was to be true on Linuces I guess we would have seen it
before).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13137#comment:100>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
