Strange warnings from numpy/matplotlib when sage is built with clang #22799

kiwifb · 2017-04-13T02:27:00Z

Seen with clang+OS X and freeBSD+clang

sage -t --long src/doc/en/prep/Calculus.rst  # 1 doctest failed
sage -t --long src/sage/plot/graphics.py  # 1 doctest failed
sage -t --long src/sage/plot/plot.py  # 1 doctest failed
sage -t --long src/sage/rings/polynomial/polynomial_real_mpfr_dense.pyx  # 1 doctest failed
sage -t --long src/sage/structure/coerce.pyx  # 1 doctest failed

All these doctest fail because an unexpected warning is emitted:

File "src/sage/rings/polynomial/polynomial_real_mpfr_dense.pyx", line 21, in sage.rings.polynomial.polynomial_real_mpfr_dense
Failed example:
    numpy.float32('1.5') * x
Expected:
    1.50000000000000*x
Got:
    doctest:warning
      File "/usr/home/dima/Sage/sage/src/bin/sage-runtests", line 89, in <module>
        err = DC.run()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/control.py", line 1134, in run
        self.run_doctests()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/control.py", line 858, in run_doctests
        self.dispatcher.dispatch()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1705, in dispatch
        self.parallel_dispatch()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1595, in parallel_dispatch
        w.start()  # This might take some time
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1871, in start
        super(DocTestWorker, self).start()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/multiprocessing/process.py", line 130, in start
        self._popen = Popen(self)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/multiprocessing/forking.py", line 126, in __init__
        code = process_obj._bootstrap()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
        self.run()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1844, in run
        task(self.options, self.outtmpfile, msgpipe, self.result_queue)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 2137, in __call__
        runner.run(test)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 641, in run
        return self._run(test, compileflags, out)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 503, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 866, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.rings.polynomial.polynomial_real_mpfr_dense[7]>", line 1, in <module>
        numpy.float32('1.5') * x
    :
    RuntimeWarning: invalid value encountered in multiply
    1.50000000000000*x

More specifically, the warning is emitted by the call

sage: x=polygen(RR)
sage: numpy.float32('1.5') * x

seen on freeBSD+clang, OS X+clang and linux+clang.

Similarly, the warning is emitted in

sage: numpy.float64(5)>e

or >= instead of >, or pi instead of e. Note that pi.n() and e.n() are of type RR, so again it points at the direction on mpfr.

Depends on #22582

Upstream: Fixed upstream, but not in a stable release.

CC: @dimpase @jhpalmieri

Component: porting

Author: François Bissey, Dima Pasechnik, Paul Zimmermann

Branch/Commit: fd29778

Reviewer: John Palmieri, Dima Pasechnik

Issue created by migration from https://trac.sagemath.org/ticket/22799

The text was updated successfully, but these errors were encountered:

kiwifb · 2017-04-13T05:21:50Z

comment:1

Both polynomial_real_mpfr_dense.pyx and coerce.py are the same test - more or less

        sage: import numpy
        sage: x = polygen(RR)
        sage: numpy.float32('1.5') * x
        1.50000000000000*x
        sage: x * numpy.float32('1.5')
        1.50000000000000*x

There are references to #8426 and #18076.

kiwifb · 2017-04-13T08:00:17Z

comment:2

As I suspected, both warning ultimately originate from inside numpy. The multiply warning comes from numpy/core/tests/test_datetime.py??? And greater_equal from numpy/lib/tests/test_nanfunctions.py, comparison with NaN.

jhpalmieri · 2017-04-14T19:02:00Z

comment:4

I tried to compare the build logs for numpy (on OS X) using gcc vs. clang. I found a few errors or warnings in the clang build that are not present in the gcc build. For example:

numpy/core/src/multiarray/datetime.c:781:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
    if (out_meta->base == -1) {
        ~~~~~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:1847:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
    if (out_meta->base == -1) {
        ~~~~~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:1976:20: warning: comparison of unsigned enum expression >= 0 is always true [-Wtautological-compare]
    if (meta->base >= 0 && meta->base < (NPY_FR_GENERIC + 1)) {
        ~~~~~~~~~~ ^  ~
numpy/core/src/multiarray/datetime.c:2395:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2411:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1 || meta->base == NPY_FR_GENERIC) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2424:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2463:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2495:28: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
            if (meta->base == -1) {
                ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2522:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2598:28: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
            if (meta->base == -1) {
                ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2609:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2622:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2661:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2730:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:2784:24: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
        if (meta->base == -1) {
            ~~~~~~~~~~ ^  ~~
numpy/core/src/multiarray/datetime.c:3118:26: warning: comparison of constant -1 with expression of type 'NPY_DATETIMEUNIT' is always false [-Wtautological-constant-out-of-range-compare]
    if (inout_meta->base == -1) {
        ~~~~~~~~~~~~~~~~ ^  ~~
16 warnings generated.

There are quite a few warnings in the clang build related to comparisons.

jhpalmieri · 2017-04-14T21:57:22Z

comment:5

By the way, the page https://www.scipy.org/scipylib/building/macosx.html says that we should use

export FFLAGS=-ff2c

along with the remark 'The Fortran flag “-ff2c” has been reported to be necessary.' We do not do this. Is there any reason to believe that this would help?

kiwifb · 2017-04-15T02:17:55Z

comment:6

Replying to @jhpalmieri:

By the way, the page https://www.scipy.org/scipylib/building/macosx.html says that we should use
export FFLAGS=-ff2c
along with the remark 'The Fortran flag “-ff2c” has been reported to be necessary.' We do not do this. Is there any reason to believe that this would help?

If we were using g77 for sure it would be necessary. The page itself is dated in my opinion. I'll dig a bit around the compilation warnings, there may be over-optimisation somewhere.

jhpalmieri · 2017-04-15T02:58:54Z

comment:7

It is at least interesting that we are getting compiler warnings on some of the files related to doctest failures, and furthermore on comparisons.

kiwifb · 2017-04-15T03:00:16Z

comment:8

Replying to @jhpalmieri:

It is at least interesting that we are getting compiler warnings on some of the files related to doctest failures, and furthermore on comparisons.

It is indeed.

kiwifb · 2017-04-15T03:16:19Z

comment:9

Just for those wondering: upgrading to numpy 1.12.1 doesn't change a thing.

kiwifb · 2017-04-15T20:50:54Z

comment:10

I am not sure numpy is the root cause of the problem. I recompiled numpy using x86_64-apple-darwin16.5.0-gcc which is currently installed by gfortran package. I remove gcc, but not more sophisticated names like the above. The error persists. Of course the above compiler is not bootstraped which could have an impact.

However, I am wondering if something funny happens in the coercion framework.

dimpase · 2017-04-21T08:39:09Z

comment:11

I suspect that the bug is not (only) in coersion, but in numpy's float conversion/truncation module; on FreeBSD/clang I get no warning with numpy.float or
numpy.float128, but I do get warnings with numpy.float<k> with k<128:

sage: import numpy as np
sage: x=polygen(RR)
sage: np.float32('1.5')*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float16('1.5')*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float64('1.5')*x
/usr/home/dima/Sage/sage/src/bin/sage-ipython:1: RuntimeWarning: invalid value encountered in multiply
  #!/usr/bin/env python
1.50000000000000*x
sage: np.float128('1.5')*x
1.50000000000000*x
sage: np.float('1.5')*x
1.50000000000000*x

That's of course still a mystery, and a combination of the fact that it only happens with x coming from RealField() (its precision does not matter, I tried many values, with the same effect).

kiwifb · 2017-04-21T10:55:59Z

comment:12

Good observation, I had only tried 64.

jdemeyer · 2017-04-21T12:19:25Z

Replying to @kiwifb:

All these doctest fail because an unexpected warning is emitted:
RuntimeWarning: invalid value encountered in greater_equal

Traceback please (general rule: when posting bug report, never truncate a traceback).

dimpase · 2017-04-21T14:15:04Z

comment:14

Replying to @jdemeyer:

Replying to @kiwifb:
All these doctest fail because an unexpected warning is emitted:
RuntimeWarning: invalid value encountered in greater_equal
Traceback please (general rule: when posting bug report, never truncate a traceback).

these are very uninformative (it's just a message that comes from the depths of a compiled part of numpy, not causing any interrupts). For instance:

File "src/sage/rings/polynomial/polynomial_real_mpfr_dense.pyx", line 21, in sage.rings.polynomial.polynomial_real_mpfr_dense
Failed example:
    numpy.float32('1.5') * x
Expected:
    1.50000000000000*x
Got:
    doctest:warning
      File "/usr/home/dima/Sage/sage/src/bin/sage-runtests", line 89, in <module>
        err = DC.run()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/control.py", line 1134, in run
        self.run_doctests()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/control.py", line 858, in run_doctests
        self.dispatcher.dispatch()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1705, in dispatch
        self.parallel_dispatch()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1595, in parallel_dispatch
        w.start()  # This might take some time
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1871, in start
        super(DocTestWorker, self).start()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/multiprocessing/process.py", line 130, in start
        self._popen = Popen(self)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/multiprocessing/forking.py", line 126, in __init__
        code = process_obj._bootstrap()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
        self.run()
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 1844, in run
        task(self.options, self.outtmpfile, msgpipe, self.result_queue)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 2137, in __call__
        runner.run(test)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 641, in run
        return self._run(test, compileflags, out)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 503, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/usr/home/dima/Sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 866, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.rings.polynomial.polynomial_real_mpfr_dense[7]>", line 1, in <module>
        numpy.float32('1.5') * x
    :
    RuntimeWarning: invalid value encountered in multiply
    1.50000000000000*x

It's also pretty hard to extract anything useful at the Sage prompt, I tried to set up a numpy interrupt following numpy docs, but it ends up telling me that the interrupt happends at the top level of ipython.

dimpase · 2017-04-21T14:50:30Z

comment:16

Could you run numpy tests on clang/OSX? I did so on clang/FreeBSD, with some failures in complex arithmetic/functions (mostly numerical noise, but not only)
More precisely:

untar the numpy tarball in upstream/
launch sage -sh
install nose (pip install nose)
cd upstream/numpy-1.11.1/numpy/testing
run ./setup.py install
cd ../core/tests
run python test*.py

On FreeBSD I get

Ran 3072 tests in 53.164s
FAILED (KNOWNFAIL=6, SKIP=4, failures=22)

Perhaps we should upgrade to 1.12.1 and see if this helps.

jhpalmieri · 2017-04-21T15:55:13Z

comment:17

I did ./sage -i nose to install nose, but otherwise followed your instructions. I got

Ran 3072 tests in 47.097s

OK (KNOWNFAIL=6, SKIP=4)

I also got this warning many times:

/Users/palmieri/Desktop/Sage_stuff/sage_builds/TESTING/sage-8.0.beta2/numpy-1.11.1/numpy/core/tests/test_datetime.py:1114: FutureWarning: In the future, NAT != NAT will be True rather than False.

kiwifb · 2017-04-21T20:13:39Z

comment:18

Replying to @dimpase:

Perhaps we should upgrade to 1.12.1 and see if this helps.

First thing I tried. No changes. But I will try the tests ASAP.

kiwifb · 2017-04-21T20:46:03Z

comment:19

So numpy-1.12.1

(sage-sh) fbissey@Mirage:tests$ python test*.py
.................................................................................................................................................................................................................................................................................................................................................................................................................................KKK........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S.................................................................................................................................................................................................................................................................................................................................................S.........................................................................................................................................................................................................................................................................................................K......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................K...SK.S.......S................................................................................
----------------------------------------------------------------------
Ran 3167 tests in 81.934s

OK (KNOWNFAIL=6, SKIP=5)

No warnings.

dimpase · 2017-04-22T22:27:22Z

comment:20

We're discussing this problem on sage-devel and it appears that Sage does not follow the coercion
framework prescription for the case of numpy.float32('1.5')*x, but instead does something that makes numpy unhappy on clang...

jdemeyer · 2017-04-23T07:34:50Z

comment:21

Replying to @dimpase:

it appears that Sage does not follow the coercion
framework prescription for the case of numpy.float32('1.5')*x

This has nothing to do with the coercion framework. When doing a * b, Python usually calls type(a).__mul__(a, b). If a is not a Sage object (as is the case here), then it's the __mul__ method of a which handles this multiplication. Only if this returns NotImplemented, then Python will call type(b).__mul__(a, b).

dimpase · 2017-04-23T09:03:19Z

comment:22

Replying to @jdemeyer:

Replying to @dimpase:

it appears that Sage does not follow the coercion
framework prescription for the case of numpy.float32('1.5')*x

This has nothing to do with the coercion framework. When doing a * b, Python usually calls type(a).__mul__(a, b). If a is not a Sage object (as is the case here), then it's the __mul__ method of a which handles this multiplication. Only if this returns NotImplemented, then Python will call type(b).__mul__(a, b).

Are you saying that the warning comes from
type(numpy.float32('1.5')).__mul__() ? OK, this makes sense---I tried this call on clang/FreeBSD and got the warning in question all right. So we know where to look at.

Still, this does not explain why sage.structure.element.coercion_model.explain() lies in this case (or in the case x comes as the 1st argument).

dimpase · 2017-04-23T10:08:09Z

comment:25

Replying to @kiwifb:

Replying to @dimpase:

Perhaps we should upgrade to 1.12.1 and see if this helps.

First thing I tried. No changes. But I will try the tests ASAP.

by the way, __mul__ is changing in 1.12. On 1.11 I get

sage: import numpy as np
sage: v=np.float32('1.5')
sage: v*"bla"
/home/dima/Sage/sage-dev/src/bin/sage-ipython:1: VisibleDeprecationWarning: using a non-integer number instead of an integer will result in an error in the future
  #!/usr/bin/env python
'bla'

while on 1.12

sage: v*"bla"
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-10-f57c3b7020a0> in <module>()
----> 1 v*"bla"

TypeError: 'numpy.float32' object cannot be interpreted as an index

jdemeyer · 2017-04-23T10:42:41Z

comment:26

Replying to @dimpase:

Still, this does not explain why sage.structure.element.coercion_model.explain() lies in this case

cm.explain() answers what the coercion model would do if asked to perform this multiplication. It doesn't answer what Python does when asked to perform this multiplication.

dimpase · 2017-04-23T13:05:24Z

comment:27

Replying to @jdemeyer:

Replying to @dimpase:

Still, this does not explain why sage.structure.element.coercion_model.explain() lies in this case

cm.explain() answers what the coercion model would do if asked to perform this multiplication. It doesn't answer what Python does when asked to perform this multiplication.

Do you mean that x*numpy.float32('1.5') does not use coersion, either? (Otherwise intentionally breaking the code path printed by coercion_model.explain() would make a difference---but it does not)
Documentation could be much more clear on how he coercion model is (or is not) invoked in particular cases.

kiwifb · 2017-05-18T23:29:42Z

Changed branch from u/dimpase/clangtrouble to u/fbissey/clangtrouble

kiwifb · 2017-05-18T23:29:42Z

comment:126

Ok, this now compile the workaround only when clang is used. And it is ready for review.

New commits:

`b3d23f9`	`Merge branch 'develop' into clangtrouble`
`811ba22`	`Make the work around only compile with clang`
`67fa2fa`	`bump version`

kiwifb · 2017-05-18T23:29:42Z

Changed commit from 66973af to 67fa2fa

kiwifb · 2017-05-18T23:29:42Z

Author: Dima Pasechnik, François Bissey

jhpalmieri · 2017-05-19T03:46:25Z

comment:127

With this plus #12426, all tests pass for me on OS X!

zimmermann6 · 2017-05-19T08:19:04Z

comment:128

we applied the following patch in the development version of MPFR:

--- src/set_d.c (revision 11493)
+++ src/set_d.c (working copy)
@@ -130,8 +130,16 @@
 
     d *= MP_BASE_AS_DOUBLE;
 #if GMP_NUMB_BITS >= 64
+#ifndef __clang__
     manl = d;
 #else
+    /* clang produces an invalid exception when d >= 2^63,
+       see https://bugs.llvm.org//show_bug.cgi?id=17686.
+       Since this is always the case, here, we use the following patch. */
+    MPFR_STAT_STATIC_ASSERT (GMP_NUMB_BITS == 64);
+    manl = 0x8000000000000000 + (mp_limb_t) (d - 0x8000000000000000);
+#endif /* __clang__ */
+#else
     MPFR_STAT_STATIC_ASSERT (GMP_NUMB_BITS == 32);
     manh = (mp_limb_t) d;
     manl = (mp_limb_t) ((d - manh) * MP_BASE_AS_DOUBLE);

kiwifb · 2017-05-19T08:23:27Z

comment:129

OK, I'll update the branch with this precise patch shortly. I have to think of using ifndef more.

sagetrac-git · 2017-05-19T09:24:08Z

Branch pushed to git repo; I updated commit sha1. New commits:

`fd29778`	`Rebase mpfr patch on upstream commit`

sagetrac-git · 2017-05-19T09:24:08Z

Changed commit from 67fa2fa to fd29778

kiwifb · 2017-05-19T09:25:45Z

comment:131

I followed your commit as closely as possible, but 3.1.5 doesn't seem to have MPFR_STAT_STATIC_ASSERT so I had to remove it.

zimmermann6 · 2017-05-19T11:08:44Z

comment:132

Replying to @kiwifb:

I followed your commit as closely as possible, but 3.1.5 doesn't seem to have MPFR_STAT_STATIC_ASSERT so I had to remove it.

ok, sorry for that. I also realized that 3.1.5 uses the generic case (_GMP_IEEE_FLOATS not defined)
while the development version of MPFR has _MPFR_IEEE_FLOATS defined, thus uses a different code
(which does not raise the exception).

kiwifb · 2017-05-25T02:56:37Z

comment:133

Someone to review? John?

jhpalmieri · 2017-05-25T04:57:43Z

comment:134

Yes, positive review.

jhpalmieri · 2017-05-25T04:57:43Z

Reviewer: John Palmieri

dimpase · 2017-05-25T05:10:25Z

Changed reviewer from John Palmieri to none

dimpase · 2017-05-25T05:10:25Z

comment:135

I'm running tests on FreeBSD now, but I expect it will all be good with the patch.

dimpase · 2017-05-25T05:12:30Z

Reviewer: Dima Pasechnik, John Palmieri

dimpase · 2017-05-25T05:12:30Z

Changed author from Dima Pasechnik, François Bissey to Dima Pasechnik, François Bissey, Paul Zimmermann

dimpase · 2017-05-25T07:47:05Z

Changed reviewer from Dima Pasechnik, John Palmieri to John Palmieri, Dima Pasechnik

dimpase · 2017-05-25T07:47:05Z

Changed author from Dima Pasechnik, François Bissey, Paul Zimmermann to François Bissey, Dima Pasechnik, Paul Zimmermann

dimpase · 2017-05-25T07:47:05Z

comment:137

yes, this also is good on FreeBSD

dimpase · 2017-05-25T07:47:05Z

Changed upstream from Reported upstream. Developers acknowledge bug. to Fixed upstream, but not in a stable release.

vbraun · 2017-05-27T23:42:46Z

Changed branch from u/fbissey/clangtrouble to fd29778

kiwifb added this to the sage-8.0 milestone Apr 13, 2017

kiwifb added c: porting labels Apr 13, 2017

This comment has been minimized.

Sign in to view

kiwifb added the s: needs review label May 18, 2017

jhpalmieri added s: positive review and removed s: needs review labels May 25, 2017

vbraun removed the s: positive review label May 27, 2017

vbraun closed this as completed in 367539d May 27, 2017

This was referenced Jan 7, 2019

update ECL to 20.4.24 #22191

Closed

upgrade numpy to 1.12.1 #22895

Closed

Strange warnings from numpy/matplotlib when sage is built with clang #22799

Strange warnings from numpy/matplotlib when sage is built with clang #22799

Comments

kiwifb commented Apr 13, 2017

kiwifb commented Apr 13, 2017

kiwifb commented Apr 13, 2017

jhpalmieri commented Apr 14, 2017

jhpalmieri commented Apr 14, 2017

kiwifb commented Apr 15, 2017

jhpalmieri commented Apr 15, 2017

kiwifb commented Apr 15, 2017

kiwifb commented Apr 15, 2017

kiwifb commented Apr 15, 2017

dimpase commented Apr 21, 2017

kiwifb commented Apr 21, 2017

jdemeyer commented Apr 21, 2017

dimpase commented Apr 21, 2017

This comment has been minimized.

dimpase commented Apr 21, 2017

jhpalmieri commented Apr 21, 2017

kiwifb commented Apr 21, 2017

kiwifb commented Apr 21, 2017

dimpase commented Apr 22, 2017

jdemeyer commented Apr 23, 2017

dimpase commented Apr 23, 2017

This comment has been minimized.

This comment has been minimized.

dimpase commented Apr 23, 2017

jdemeyer commented Apr 23, 2017

dimpase commented Apr 23, 2017

kiwifb commented May 18, 2017

kiwifb commented May 18, 2017

kiwifb commented May 18, 2017

kiwifb commented May 18, 2017

jhpalmieri commented May 19, 2017

zimmermann6 commented May 19, 2017

kiwifb commented May 19, 2017

sagetrac-git mannequin commented May 19, 2017

sagetrac-git mannequin commented May 19, 2017

kiwifb commented May 19, 2017

zimmermann6 commented May 19, 2017

kiwifb commented May 25, 2017

jhpalmieri commented May 25, 2017

jhpalmieri commented May 25, 2017

dimpase commented May 25, 2017

dimpase commented May 25, 2017

dimpase commented May 25, 2017

dimpase commented May 25, 2017

dimpase commented May 25, 2017

dimpase commented May 25, 2017

dimpase commented May 25, 2017

dimpase commented May 25, 2017

vbraun commented May 27, 2017