https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|roger at nextmovesoftware dot com |unassigned at gcc dot
gnu.org
Summary|[12 Regression] gcc -O0 |gcc -O0 behaves differently
|behaves differently on |on "DBL_MAX related
|"DBL_MAX related |operations" than gcc -O1
|operations" than gcc -O1 |and above
|and above |
Target| |x86_64
--- Comment #13 from Roger Sayle <roger at nextmovesoftware dot com> ---
The Inf - Inf => 0.0 regression should now be fixed on mainline.
Hmm. As hinted by Richard Beiner's investigation, the underlying problem is
even more pervasive. It turns out that on x86/IA64 chips, floating point
addition is not commutative, i.e. x+y is not the same as y+x, as demonstrated
by the test program below:
#include <stdio.h>
const double pn = __builtin_nan("");
const double mn = -__builtin_nan("");
__attribute__ ((noinline, noclone))
double plus(double x, double y)
{
return x + y;
}
int main()
{
printf("%lf\n",plus(pn,mn));
printf("%lf\n",plus(mn,pn));
return 0;
}
Output:
nan
-nan
Unfortunately, GCC assumes almost everywhere the FP addition is commutative
and (as per comments #8 and #9) associative with negation/minus. This appears
to be target property, c.f. libgcc's _FP_CHOOSENAN, but could in theory be
resolved by a -fstrict-math mode (that implies -ftrapping-math) that disables
commutativity (swapping of operands) throughout the compiler, including
reload/fold-const etc., on affected Intel-like targets.
Perhaps this PR is a duplicate now that the regression has been fixed?
