porting status (bad news)

Richard B. Kreckel kreckel at ThEP.Physik.Uni-Mainz.DE
Thu Dec 23 03:44:31 CET 1999


Ok, here is a little update on what's happening when you dare to use GCC
2.96.  Actually, I'm talking about the current CVS-snapshot, which claims
to be 2.96 according to __GNUC__ and __GNUC_MINOR__.  (And, yes, I have
tried the last two *official* snapshots too.)

First of all, CLN has to be recompiled because otherwise it aborts at each
exception thrown.  (This is business as usual, I don't know why this is so
and have asked B. Haible for a hint.)  If one tries, one runs into
problems because the new compiler complains:
  `void () ()' cannot be `const'-, `volatile'-, or `restrict'-qualified
I have made a quick hack around this problem in cl_macros.h but then
one runs into trouble again with internal compiler errors, always in
`scan_region', at except.c:2710 on different CLN-modules.  (Bugreport for
gcc-bugs is already submitted.)  One can get around this problem by
fiddling with optimization options but this does not seem to built a
useful library then, since it sometimes fails at some of the random
checks. :-(

If one insists and builts GiNaC, ginsh and whatnot against this library it
fails at every test once optimization is switched on.  Omitting
optimization results in the follwing fiasco:

checking several ex-bugs just out of pure paranoia... failed (NaNs)
checking output of numeric types... passed (0.03s)
checking consistency of numeric types... passed (0.04s)
checking power laws... passed (NaNs)
checking commutative expansion and substitution... passed (NaNs)
checking consistency of symbolic functions... failed (NaNs)
checking symbolic differentiation... passed (NaNs)
checking polynomial GCD computation... passed (NaNs)
checking rational function normalization... passed (NaNs)
checking symbolic matrix manipulations... passed (NaNs)
checking linear solve... passed (NaNs)
checking series expansion... passed (NaNs)
error: something went wrong. (2 individual failures)
please check result.out against result.ref for more details.
happy debugging!
Comparing output...
result.ref result.out differ: char 53, line 2
FAIL: run_checks
===================
1 of 1 tests failed
===================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/home/kreckel/projects/GiNaC/check'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/home/kreckel/projects/GiNaC/check'
make: *** [check-recursive] Error 1
higgsino:~/projects/GiNaC$ diff check/result.out check/result.ref 
2c2
< e = x*y*z; f = y*z; expand(e/f) erroneously returned x
---
> (no output)
16c16
< sin(n*Pi) with integer n does not always return exact 0
---
> (no output)

Both error-reports are *logically* wrong (the first one is obvious).
Also, the NaN seconds are quite funny, they go away as soon as one tries
to trace down their origin.

Holy shit, GCC seems to be rather broken at present.

The good news is that the more restrictive preprocessor didn't find any
mistakes in GiNaC itself.

Happy hacking
          -rbk.

PS: No, my system's clock is fine.   :-(
-- 
Richard Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>





More information about the GiNaC-devel mailing list