After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748504 - 0.10.22: test-math fails on "powerpc" and "ppc64el"
0.10.22: test-math fails on "powerpc" and "ppc64el"
Status: RESOLVED NOTABUG
Product: libgoffice
Classification: Other
Component: General
0.10.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 751872 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-04-27 00:09 UTC by Dmitry Smirnov
Modified: 2015-07-14 16:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Expected output (28.16 KB, text/plain)
2015-05-09 14:51 UTC, Morten Welinder
Details

Comment 1 Morten Welinder 2015-04-28 12:09:48 UTC
I can see test-math failing, but I cannot see its output.

Can you get the information in the relevant log file?
Alternative, run it by hand and see what it says.
Comment 2 Dmitry Smirnov 2015-05-09 02:58:15 UTC
Here it is:
~~~~
**
ERROR:test-math.c:107:trig_tests: assertion failed: (copysign (1,r) == copysign (1,fa))
~~~~
Comment 3 Morten Welinder 2015-05-09 14:51:25 UTC
Created attachment 303129 [details]
Expected output

This is what I see.  Immediately before your failure there should be
the test it was performing.  What is that?

Also, this test uses copysign, a C99 feature.  Any compilation warnings
for the test?
Comment 4 Dmitry Smirnov 2015-05-10 09:30:39 UTC
You have access to build log -- why don't you check for warnings there?

I'm not sure what check it was performing -- too bad I did not take a note when I had access to powerpc VM... Will try again...
Comment 5 Dmitry Smirnov 2015-05-10 09:35:17 UTC
Here is tail of `test-math.log`:

~~~~
sinpi(-1) = -0  [-0]
cospi(-1) = -1  [-1]
tanpi(-1) = -0  [-0]
cotpi(-1) = -nan  [-nan]
atanpi(-1) = -0.25  [-0.25]
sinpil(-1) = -0  [-0]
cospil(-1) = -1  [-1]
tanpil(-1) = 0  [-0]
**
ERROR:test-math.c:107:trig_tests: assertion failed: (copysign (1,r) == copysign (1,fa))
~~~~
Comment 6 Morten Welinder 2015-05-10 15:58:25 UTC
Looks like a C library/compiler bug, :-/

#include <stdio.h>
#include <assert.h>
#include <math.h>

int
main (int argc, char **argv)
{
  long double l = -1.0l;
  printf ("A: %Lg\n", l);
  l = fmodl (l, 1.0l);
  printf ("B: %Lg\n", l);
  assert (l == 0.0l);
  l = copysignl (0.0l, l);
  printf ("C: %Lg\n", l);
  return 0;
}

This should print
A: -1
B: -0
C: -0
Comment 7 Morten Welinder 2015-05-10 16:11:47 UTC
And for the record, I see no relevant warnings.
Comment 8 Dmitry Smirnov 2015-05-10 16:18:32 UTC
I've checked for warnings too but did not notice anything relevant...
Comment 9 Morten Welinder 2015-05-10 18:32:58 UTC
Updated test program.  This version ensures that things happen at run-time,
not compile time.  Just in case.

Note, that the copysignl call here is utterly pointless, at least if copysignl
works according to C99.  It looks like a left-over from some editing.




#include <stdio.h>
#include <assert.h>
#include <math.h>

int
main (int argc, char **argv)
{
  long double l = (argc == 42 ? 1.0l : -1.0l);
  printf ("A: %Lg\n", l);
  l = fmodl (l, 1.0l);
  printf ("B: %Lg\n", l);
  assert (l == 0.0l);
  l = copysignl (0.0l, l);
  printf ("C: %Lg\n", l);
  return 0;
}
Comment 10 Morten Welinder 2015-05-10 18:58:22 UTC
http://en.wikipedia.org/wiki/Long_double suggests that powerpc may not
conform to ieee for long double.

If that is indeed the case, we have trouble.  You can try configuring
--without-long-double.  That will eliminate the public APIs that take
long double, but internally long double is still used in critical
places such as go_dtoa.

Or you can ignore the test and hope for the best.
Comment 11 Morten Welinder 2015-06-14 10:19:41 UTC
--> NOTABUG.

The test seems to correctly detect a system that isn't fulfilling
the resuirements.  See comment 10 for advice on moving forward.
Comment 12 Dmitry Smirnov 2015-06-14 21:56:49 UTC
How can I ignore a particular test on powerpc only?

I'm not happy with just disabling all tests (or ignoring all test results).

It appears to me that in order to build successfully on Debian/powerpc one needs to patch goffice in order to disable this particular test (or make it non-fatal) and the best place to do it is upstream i.e. here.

Any chance for such patch to be introduced to goffice? Please?
Comment 13 Dmitry Smirnov 2015-06-14 22:12:05 UTC
I tried building Goffice with "--without-long-double" on amd64 and got FTBFS:

~~~~
test-math.c: In function ‘trig_tests’: 
test-math.c:106:3: error: implicit declaration of function ‘go_sinpil’ [-Werror=implicit-function-declaration] 
   TEST1(d); 
   ^ 
~~~~

I did not try that on powerpc but it seems it might fail just as on amd64 so disabling test(s) appears to be the only option...
Comment 14 Morten Welinder 2015-06-15 19:46:56 UTC
The compilation failure of comment 13 has been fixed.

> Any chance for such patch to be introduced to goffice?

No, really.

The problem is not "The test fails because there is something wrong
with the test."

The problem is "The test fails because there is something wrong with either
the hardware or the platform's ABI."

The important difference here is that while I could tell the test to shut
up, the problem it reports is real and goffice would not work right.

Goffice depends on properly working floating-point.  There is no easy
workaround.
Comment 15 Dmitry Smirnov 2015-06-15 22:39:07 UTC
Morten, I think you misunderstood what am I saying...
I understand that the test is correct.
However we know it fails on powerpc hence my suggestion is to either make this test non-fatal on powerpc or disable this particular test on powerpc only. This is because I still want to run other tests and avoid ignoring all test results.

At the moment the only way I can build goffice on powerpc is to run no tests or ignore their failure. I want to isolate this particular test only on powerpc.
Comment 16 Morten Welinder 2015-07-14 16:48:27 UTC
*** Bug 751872 has been marked as a duplicate of this bug. ***