Michael S <
[email protected]> writes:
On Wed, 26 Feb 2025 14:39:34 -0000 (UTC)
[email protected] wrote:
On Wed, 26 Feb 2025 14:27:21 +0200
Michael S <[email protected]> wibbled:
On Wed, 26 Feb 2025 08:16:01 -0000 (UTC)
[email protected] wrote:
I played a little on godbolt and it seems that the bug is relatively
new. clang 13 still generates correct code. clang 14 does not. I.e.
slightly less than 3 years.
I don't think they've noticed:
R8603$ cc --version
Apple clang version 16.0.0 (clang-1600.0.26.6)
More googling/stack-overflowing.
clang/LLVM people think that it is a feature rather than a bug. They
claim that the standard allows fusing. I think that they are wrong, but
I didn't read the respective part of the standard.
My reading of the C standard is that implementations are allowed to
contract floating-point expressions (aka fusing) as their default
choice of what is allowed, and because this default choice falls
into the category of implementation-defined behavior the
implementation must document what default it has chosen.
The behavior can be turned back into clang13 way by -ffp-contract=off.
Or with pragma
#pragma STDC FP_CONTRACT OFF
The C standard doesn't say anything about compiler options.
The C standard does specify what happens for the STDC FP_CONTRACT
standard #pragma, for both
#pragma STDC FP_CONTRACT OFF
and
#pragma STDC FP_CONTRACT ON
If you want to look, what these #pragma's do is defined in the
section of the C standard pertaining to <math.h>, which is 7.12 in
the N1256 document for C99.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)