infinite loop in superdouble implementation with gcc 13

[emollier]

Hi,

Since introduction of gcc 13 in Debian sid, the _runtests.py script hangs at the "character: 2" message after building phyx:

cd src && python3 run_tests.py
character: 0
character: 1
character: 2

Running top reveals a pxstrec process running at 100% cpu. Attaching the hung pxstrec process with gdb reveals the process seems to be caught in an infinite loop during a superdouble calculation:

0x0000560c29677683 in Superdouble::adjustDecimal (this=<optimized out>) at ./src/superdouble.cpp:40
40          while (std::abs(mantissa) >= 10) {
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) step
41              mantissa *= 0.1;
(gdb) 
40          while (std::abs(mantissa) >= 10) {
(gdb) 
std::abs (__x=-inf) at /usr/include/c++/13/bits/std_abs.h:80
80    { return __builtin_fabsl(__x); }
(gdb) 
40          while (std::abs(mantissa) >= 10) {
(gdb) 
0x0000560c29677679 in std::abs (__x=-inf) at /usr/include/c++/13/bits/std_abs.h:80
80    { return __builtin_fabsl(__x); }
(gdb) 
41              mantissa *= 0.1;
[...]

On first sight, this looks to be related to excess precision changes documented in porting to gcc 13 guide. Adding -fexcess-precision=fast per recommendation didn't help though. Nevertheless, I managed to get rid of the issue by removing -ffast-math for information, but maybe this is hiding something else:

--- phyx.orig/src/Makefile.in
+++ phyx/src/Makefile.in
@@ -35,8 +35,6 @@
     OPT_FLAGS += -ftree-vectorize
     ifneq ($(filter @host_cpu@,i386 i486 i586 i686),)
         OPT_FLAGS += -ffloat-store
-    else
-        OPT_FLAGS += -ffast-math
     endif
 endif

This has been seen on Debian sid with phyx 1.3 with gcc 13.1.0, and phyx 1.3.1 with gcc 13.2.0. The issue is also loosely tracked in Debian Bug#1037817.

[josephwb]

Thanks for reporting this, and taking a look into the cause.

I'll look at this in the next week, although I did not write this code. I imagine your Makefile fix will be sufficient.

[josephwb]

Removing -ffast-math doesn't seem to break anything (at least from the make check standpoint). I'll do some code spelunking, but this may be a suitable solution.

[josephwb]

This has (finally) been changed. Thanks for finding the solution.