Concerns regarding the -ffp-contract=fast default

Concerns regarding the -ffp-contract=fast default

[Florian Weimer]

While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
several packages had test suite failures because x86-64 suddenly gained
FMA support.  I say “rediscovered” because these issues were already
visible on other architectures with FMA.

So far, our package/architecture maintainers had just disabled test
suites or had built the package with -fp-contract=off because the
failures did not reproduce on x86-64.  I'm not sure if this is the right
course of action.

GCC contraction behavior is rather inconsistent.  It does not contract x
+ x - x without -ffast-math, for example, although I believe it would be
permissible under the rules that enable FMA contraction.  This whole
thing looks suspiciously like a quick hack to get a performance
improvement from FMA instructions (sorry).

I know that GCC 14 has -fp-contract=standard.  Would it make sense to
switch the default to that?  If it fixes those package test suites, it
probably has an observable performance impact. 8-/

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]


On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:

> While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> several packages had test suite failures because x86-64 suddenly gained
> FMA support.  I say “rediscovered” because these issues were already
> visible on other architectures with FMA.
> 
> So far, our package/architecture maintainers had just disabled test
> suites or had built the package with -fp-contract=off because the
> failures did not reproduce on x86-64.  I'm not sure if this is the right
> course of action.
> 
> GCC contraction behavior is rather inconsistent.  It does not contract x
> + x - x without -ffast-math, for example, although I believe it would be
> permissible under the rules that enable FMA contraction.  This whole
> thing looks suspiciously like a quick hack to get a performance
> improvement from FMA instructions (sorry).
> 
> I know that GCC 14 has -fp-contract=standard.  Would it make sense to
> switch the default to that?  If it fixes those package test suites, it
> probably has an observable performance impact. 8-/

Note that with =standard FMA contraction is still allowed within an
expression: the compiler will transform 'x * y + z' to 'fma(x, y, z)'.
The difference between =fast and =standard is contraction across
statement boundaries. So I'd expect some test suite failures you speak of
to remain with =standard as opposed to =off.

I think it's better to switch both C and C++ defaults to =standard,
matching Clang, but it needs a bit of leg work to avoid regressing
our own testsuite for targets that have FMA in the base ISA.

(personally I'd be on board with switching to =off even)

See https://gcc.gnu.org/PR106902 for a worked example where -ffp-contract=fast
caused a correctness issue in a widely used FOSS image processing application
that was quite hard to debug.

Obviously -Ofast and -ffast-math will still imply -ffp-contract=fast if we
make the change, so SPEC scores won't be affected.

Thanks.
Alexander

Re: Concerns regarding the -ffp-contract=fast default

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]

Hi Florian,

On Thu, 14 Sep 2023, Alexander Monakov wrote:

> 
> On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
> 
> > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> > several packages had test suite failures because x86-64 suddenly gained
> > FMA support.  I say “rediscovered” because these issues were already
> > visible on other architectures with FMA.
> > 
> > So far, our package/architecture maintainers had just disabled test
> > suites or had built the package with -fp-contract=off because the
> > failures did not reproduce on x86-64.  I'm not sure if this is the right
> > course of action.
> > 
> > GCC contraction behavior is rather inconsistent.  It does not contract x
> > + x - x without -ffast-math, for example, although I believe it would be
> > permissible under the rules that enable FMA contraction.  This whole
> > thing looks suspiciously like a quick hack to get a performance
> > improvement from FMA instructions (sorry).
> > 
> > I know that GCC 14 has -fp-contract=standard.  Would it make sense to
> > switch the default to that?  If it fixes those package test suites, it
> > probably has an observable performance impact. 8-/
> 
> Note that with =standard FMA contraction is still allowed within an
> expression: the compiler will transform 'x * y + z' to 'fma(x, y, z)'.
> The difference between =fast and =standard is contraction across
> statement boundaries. So I'd expect some test suite failures you speak of
> to remain with =standard as opposed to =off.
> 
> I think it's better to switch both C and C++ defaults to =standard,
> matching Clang, but it needs a bit of leg work to avoid regressing
> our own testsuite for targets that have FMA in the base ISA.
> 
> (personally I'd be on board with switching to =off even)
> 
> See https://gcc.gnu.org/PR106902 for a worked example where -ffp-contract=fast
> caused a correctness issue in a widely used FOSS image processing application
> that was quite hard to debug.
> 
> Obviously -Ofast and -ffast-math will still imply -ffp-contract=fast if we
> make the change, so SPEC scores won't be affected.

Is this the sort of information you were looking for?

If you're joining the Cauldron and could poll people about changing the default,
I feel that could be helpful.

One of the tricky aspects is what to do under -std=cNN, which implies
-ffp-contract=off; "upgrading" it to =standard would introduce FMAs.

Also, I'm a bit unsure what you were implying here:

> I know that GCC 14 has -fp-contract=standard.  Would it make sense to
> switch the default to that?  If it fixes those package test suites, it
> probably has an observable performance impact. 8-/

The "correctness trumps performance" principle still applies, and
-ffp-contract=fast (the current default outside of -std=cNN) is
known to cause correctness issues and violates the C language standard.
And -ffast[-and-loose]-math for is not going away.

Thanks.
Alexander

Re: Concerns regarding the -ffp-contract=fast default

[Richard Biener]

On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov <amonakov@ispras.ru> wrote:
>
> Hi Florian,
>
> On Thu, 14 Sep 2023, Alexander Monakov wrote:
>
> >
> > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
> >
> > > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> > > several packages had test suite failures because x86-64 suddenly gained
> > > FMA support.  I say “rediscovered” because these issues were already
> > > visible on other architectures with FMA.
> > >
> > > So far, our package/architecture maintainers had just disabled test
> > > suites or had built the package with -fp-contract=off because the
> > > failures did not reproduce on x86-64.  I'm not sure if this is the right
> > > course of action.
> > >
> > > GCC contraction behavior is rather inconsistent.  It does not contract x
> > > + x - x without -ffast-math, for example, although I believe it would be
> > > permissible under the rules that enable FMA contraction.  This whole

Is that really just x + x - x?  We currently gate simplifying x - x to zero
on no-signed-zeros and round-to-nearest and have no special
handling for x + x - x.

> > > thing looks suspiciously like a quick hack to get a performance
> > > improvement from FMA instructions (sorry).
> > >
> > > I know that GCC 14 has -fp-contract=standard.  Would it make sense to
> > > switch the default to that?  If it fixes those package test suites, it
> > > probably has an observable performance impact. 8-/
> >
> > Note that with =standard FMA contraction is still allowed within an
> > expression: the compiler will transform 'x * y + z' to 'fma(x, y, z)'.
> > The difference between =fast and =standard is contraction across
> > statement boundaries. So I'd expect some test suite failures you speak of
> > to remain with =standard as opposed to =off.
> >
> > I think it's better to switch both C and C++ defaults to =standard,
> > matching Clang, but it needs a bit of leg work to avoid regressing
> > our own testsuite for targets that have FMA in the base ISA.
> >
> > (personally I'd be on board with switching to =off even)
> >
> > See https://gcc.gnu.org/PR106902 for a worked example where -ffp-contract=fast
> > caused a correctness issue in a widely used FOSS image processing application
> > that was quite hard to debug.
> >
> > Obviously -Ofast and -ffast-math will still imply -ffp-contract=fast if we
> > make the change, so SPEC scores won't be affected.
>
> Is this the sort of information you were looking for?
>
> If you're joining the Cauldron and could poll people about changing the default,
> I feel that could be helpful.
>
> One of the tricky aspects is what to do under -std=cNN, which implies
> -ffp-contract=off; "upgrading" it to =standard would introduce FMAs.
>
> Also, I'm a bit unsure what you were implying here:
>
> > I know that GCC 14 has -fp-contract=standard.  Would it make sense to
> > switch the default to that?  If it fixes those package test suites, it
> > probably has an observable performance impact. 8-/
>
> The "correctness trumps performance" principle still applies, and
> -ffp-contract=fast (the current default outside of -std=cNN) is
> known to cause correctness issues and violates the C language standard.
> And -ffast[-and-loose]-math for is not going away.

I think that changing the default to =standard without -ffast-math is
reasonable.
IIRC the standard allows such default if it's indicated, so it doesn't require
=off anywhere.

Richard.

>
> Thanks.
> Alexander

Re: Concerns regarding the -ffp-contract=fast default

[Florian Weimer]

* Richard Biener:

>> > > GCC contraction behavior is rather inconsistent.  It does not contract x
>> > > + x - x without -ffast-math, for example, although I believe it would be
>> > > permissible under the rules that enable FMA contraction.  This whole
>
> Is that really just x + x - x?  We currently gate simplifying x - x to zero
> on no-signed-zeros and round-to-nearest and have no special
> handling for x + x - x.

It's just an example I made up, and checked that GCC wouldn't optimize
it by default (without -ffast-math et al.).  I believe the rule that GCC
invokes to introduce FMA under -ffp-contract=standard (and
-ffp-contract=fast) would apply to these contractions as well.

Or put differently, -ffp-contract= seems to be exclusively about FMA,
while the option name and description is more generic.

x - x is different because replacing it with 0 doesn't seem to be a
valid contraction because it's incorrect for NaNs.  x + x - x seems to
be different in this regard, but in our implementation, there might be a
quirk about sNaNs and qNaNs.

>> The "correctness trumps performance" principle still applies, and
>> -ffp-contract=fast (the current default outside of -std=cNN) is
>> known to cause correctness issues and violates the C language standard.
>> And -ffast[-and-loose]-math for is not going away.
>
> I think that changing the default to =standard without -ffast-math is
> reasonable.  IIRC the standard allows such default if it's indicated,
> so it doesn't require =off anywhere.

How much numerical code is compatible with that?  For example, David
Goldberg's What Every Computer Scientist Should Know About
Floating-Point Arithmetic (revised) contains this sentence:

| A language definition that does not require parentheses to be honored
| is useless for floating-point calculations.

<https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html>

Few people have access to the IEEE 754 standard, and Goldberg's article
is therefore widely quoted as gospel.  If I understand this correctly,
according to Goldberg, contractions make C “useless”.  But I'm not a
floating point person, and I nowadays regret that I looked down upon the
numerical methods people at university.

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Richard Biener]

On Mon, Sep 18, 2023 at 12:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Richard Biener:
>
> >> > > GCC contraction behavior is rather inconsistent.  It does not contract x
> >> > > + x - x without -ffast-math, for example, although I believe it would be
> >> > > permissible under the rules that enable FMA contraction.  This whole
> >
> > Is that really just x + x - x?  We currently gate simplifying x - x to zero
> > on no-signed-zeros and round-to-nearest and have no special
> > handling for x + x - x.
>
> It's just an example I made up, and checked that GCC wouldn't optimize
> it by default (without -ffast-math et al.).  I believe the rule that GCC
> invokes to introduce FMA under -ffp-contract=standard (and
> -ffp-contract=fast) would apply to these contractions as well.
>
> Or put differently, -ffp-contract= seems to be exclusively about FMA,
> while the option name and description is more generic.
>
> x - x is different because replacing it with 0 doesn't seem to be a
> valid contraction because it's incorrect for NaNs.  x + x - x seems to
> be different in this regard, but in our implementation, there might be a
> quirk about sNaNs and qNaNs.
>
> >> The "correctness trumps performance" principle still applies, and
> >> -ffp-contract=fast (the current default outside of -std=cNN) is
> >> known to cause correctness issues and violates the C language standard.
> >> And -ffast[-and-loose]-math for is not going away.
> >
> > I think that changing the default to =standard without -ffast-math is
> > reasonable.  IIRC the standard allows such default if it's indicated,
> > so it doesn't require =off anywhere.
>
> How much numerical code is compatible with that?  For example, David
> Goldberg's What Every Computer Scientist Should Know About
> Floating-Point Arithmetic (revised) contains this sentence:
>
> | A language definition that does not require parentheses to be honored
> | is useless for floating-point calculations.
>
> <https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html>

I suppose that applies to re-association not honoring parens.  With C
you either have no re-association (fine) or re-association but globally,
at the expense of violating the standard.  FP contraction is _not_
about honoring parens, the 'error' introduced by is subtle.

Fortran for example allows re-association by default, but honors
parens.  GCC can do this just fine.

> Few people have access to the IEEE 754 standard, and Goldberg's article
> is therefore widely quoted as gospel.  If I understand this correctly,
> according to Goldberg, contractions make C “useless”.  But I'm not a
> floating point person, and I nowadays regret that I looked down upon the
> numerical methods people at university.

No, I don't think it says that.  Fortran also allows contraction (but not
across parens).

Richard.

> Thanks,
> Florian
>

Re: Concerns regarding the -ffp-contract=fast default

[Florian Weimer]

* Richard Biener:

>> How much numerical code is compatible with that?  For example, David
>> Goldberg's What Every Computer Scientist Should Know About
>> Floating-Point Arithmetic (revised) contains this sentence:
>>
>> | A language definition that does not require parentheses to be honored
>> | is useless for floating-point calculations.
>>
>> <https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html>
>
> I suppose that applies to re-association not honoring parens.  With C
> you either have no re-association (fine) or re-association but globally,
> at the expense of violating the standard.  FP contraction is _not_
> about honoring parens, the 'error' introduced by is subtle.

But for contracted expressions, + *is* associative.  Maybe this is not
the most relevant part of the article for contractions, though.

> Fortran for example allows re-association by default, but honors
> parens.  GCC can do this just fine.

I think it's still a divergence from the model promoted by the article.
For further problems see “Pitfalls in Computations on Extended-Based
Systems”; that covers the matter of excess precision (which, as far as I
understand, is very relevant to contractions).  It quotes this code
snippet:

| if (1.0 + x .eq. 1.0) then

The C11 standard does not define what “floating expressions” are (as far
as I can see), so it's a bit unclear whether the whole thing can be
contracted (assuming x is not a NaN).

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Alexander Monakov]

On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:

> x - x is different because replacing it with 0 doesn't seem to be a
> valid contraction because it's incorrect for NaNs.  x + x - x seems to
> be different in this regard, but in our implementation, there might be a
> quirk about sNaNs and qNaNs.

Sorry, do you mean contracting 'x + x - x' to 'x'? That is not allowed
due to different result and lack of FP exception for infinities.

Contracting 'x + x - x' to fma(x, 2, -x) would be fine.

Alexander

Re: Concerns regarding the -ffp-contract=fast default

[Florian Weimer]

* Alexander Monakov:

> On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:
>
>> x - x is different because replacing it with 0 doesn't seem to be a
>> valid contraction because it's incorrect for NaNs.  x + x - x seems to
>> be different in this regard, but in our implementation, there might be a
>> quirk about sNaNs and qNaNs.
>
> Sorry, do you mean contracting 'x + x - x' to 'x'?

Yes.

> That is not allowed due to different result and lack of FP exception
> for infinities.

FP exceptions do not need to preserved in C11 (it's a recommended
practice in Annex F only, and the main text explicitly allows changes).
But you are right that inf - inf would result in a NaN, so that's a
different result that cannot be explained by infinite intermediate
precision.  Huh, so it's a bad example.  Sorry!

But the contraction would still be valid after an isfinite check
(something that ranger might catch these days), or with with
-ffinite-math-only in general.  Right?

> Contracting 'x + x - x' to fma(x, 2, -x) would be fine.

It still changes the result, doesn't it?

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Alexander Monakov]

On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:

> But the contraction would still be valid after an isfinite check
> (something that ranger might catch these days), or with with
> -ffinite-math-only in general.  Right?

Nope, still not valid for negative zero ('x + x - x' would yield
positive zero in the default rounding mode).

> > Contracting 'x + x - x' to fma(x, 2, -x) would be fine.
> 
> It still changes the result, doesn't it?

I don't follow. I doesn't change the result for infinities (produces
a NaN). It changes the result when x is so large that 'x + x' is
not representable (exponent would overflow), but that's exactly what
contraction is about?

Alexander

Re: Concerns regarding the -ffp-contract=fast default

[Florian Weimer]

* Alexander Monakov:

>> > Contracting 'x + x - x' to fma(x, 2, -x) would be fine.
>> 
>> It still changes the result, doesn't it?
>
> I don't follow. I doesn't change the result for infinities (produces
> a NaN). It changes the result when x is so large that 'x + x' is
> not representable (exponent would overflow), but that's exactly what
> contraction is about?

Okay, you meant “changing the result” as in “changing the result in a
permitted way”.  Sorry, was confused.  So this is a bad example all
around.  Are there better ones (that don't involve FMA)?

Thanks,
Florian

Re: Concerns regarding the -ffp-contract=fast default

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]


On Mon, 18 Sep 2023, Florian Weimer wrote:

> Okay, you meant “changing the result” as in “changing the result in a
> permitted way”.  Sorry, was confused.  So this is a bad example all
> around.  Are there better ones (that don't involve FMA)?

If you're looking for something similar to your original example, I can
suggest 'x + x + x + x' -> '4 * x' under -frounding-math (i.e. not assuming
default rounding mode) or 'x + x + x + x + x + x' -> '6 * x' for default
rounding.

I don't have a "somewhat practical" example off-hand, since apart from FMA
fused operations are rarely available in instruction sets.

Alexander

Re: Concerns regarding the -ffp-contract=fast default

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

On Mon, 18 Sep 2023, Alexander Monakov wrote:

> 
> On Mon, 18 Sep 2023, Florian Weimer wrote:
> 
> > Okay, you meant “changing the result” as in “changing the result in a
> > permitted way”.  Sorry, was confused.  So this is a bad example all
> > around.  Are there better ones (that don't involve FMA)?
> 
> If you're looking for something similar to your original example, I can
> suggest 'x + x + x + x' -> '4 * x' under -frounding-math (i.e. not assuming
> default rounding mode) or 'x + x + x + x + x + x' -> '6 * x' for default
> rounding.
> 
> I don't have a "somewhat practical" example off-hand, since apart from FMA
> fused operations are rarely available in instruction sets.

Apart from FMA, there are the formatOf operations such as fadd (add two 
doubles, rounding the result just once to float).  Fewer instruction sets 
have those than have FMA, however (ia64 did; newer versions of Power 
support such operations as well to some extent, though with limitations 
when underflow or overflow occur).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Concerns regarding the -ffp-contract=fast default

[Martin Uecker]

Am Montag, dem 18.09.2023 um 10:06 +0200 schrieb Richard Biener via Gcc:
> On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov <amonakov@ispras.ru> wrote:
> > 
> > Hi Florian,
> > 
> > On Thu, 14 Sep 2023, Alexander Monakov wrote:
> > 
> > > 
> > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
> > > 
> > > > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> > > > several packages had test suite failures because x86-64 suddenly gained
> > > > FMA support.  I say “rediscovered” because these issues were already
> > > > visible on other architectures with FMA.
> > > > 
> > > > So far, our package/architecture maintainers had just disabled test
> > > > suites or had built the package with -fp-contract=off because the
> > > > failures did not reproduce on x86-64.  I'm not sure if this is the right
> > > > course of action.
> > > > 
> > > > GCC contraction behavior is rather inconsistent.  It does not contract x
> > > > + x - x without -ffast-math, for example, although I believe it would be
> > > > permissible under the rules that enable FMA contraction.  This whole
> 
> Is that really just x + x - x?  We currently gate simplifying x - x to zero
> on no-signed-zeros and round-to-nearest and have no special
> handling for x + x - x.
> 
> > > > thing looks suspiciously like a quick hack to get a performance
> > > > improvement from FMA instructions (sorry).
> > > > 
> > > > I know that GCC 14 has -fp-contract=standard.  Would it make sense to
> > > > switch the default to that?  If it fixes those package test suites, it
> > > > probably has an observable performance impact. 8-/
> > > 
> > > Note that with =standard FMA contraction is still allowed within an
> > > expression: the compiler will transform 'x * y + z' to 'fma(x, y, z)'.
> > > The difference between =fast and =standard is contraction across
> > > statement boundaries. So I'd expect some test suite failures you speak of
> > > to remain with =standard as opposed to =off.
> > > 
> > > I think it's better to switch both C and C++ defaults to =standard,
> > > matching Clang, but it needs a bit of leg work to avoid regressing
> > > our own testsuite for targets that have FMA in the base ISA.
> > > 
> > > (personally I'd be on board with switching to =off even)
> > > 
> > > See https://gcc.gnu.org/PR106902 for a worked example where -ffp-contract=fast
> > > caused a correctness issue in a widely used FOSS image processing application
> > > that was quite hard to debug.
> > > 
> > > Obviously -Ofast and -ffast-math will still imply -ffp-contract=fast if we
> > > make the change, so SPEC scores won't be affected.
> > 
> > Is this the sort of information you were looking for?
> > 
> > If you're joining the Cauldron and could poll people about changing the default,
> > I feel that could be helpful.
> > 
> > One of the tricky aspects is what to do under -std=cNN, which implies
> > -ffp-contract=off; "upgrading" it to =standard would introduce FMAs.
> > 
> > Also, I'm a bit unsure what you were implying here:
> > 
> > > I know that GCC 14 has -fp-contract=standard.  Would it make sense to
> > > switch the default to that?  If it fixes those package test suites, it
> > > probably has an observable performance impact. 8-/
> > 
> > The "correctness trumps performance" principle still applies, and
> > -ffp-contract=fast (the current default outside of -std=cNN) is
> > known to cause correctness issues and violates the C language standard.
> > And -ffast[-and-loose]-math for is not going away.
> 
> I think that changing the default to =standard without -ffast-math is
> reasonable.
> IIRC the standard allows such default if it's indicated, so it doesn't require
> =off anywhere.

The C standard requires a pragma to turn control it on and off, 
which GCC does not support.  The default is then implementation
defined.

Martin

Re: Concerns regarding the -ffp-contract=fast default

[Jakub Jelinek]

On Mon, Sep 18, 2023 at 01:26:54PM +0200, Martin Uecker wrote:
> > I think that changing the default to =standard without -ffast-math is
> > reasonable.
> > IIRC the standard allows such default if it's indicated, so it doesn't require
> > =off anywhere.
> 
> The C standard requires a pragma to turn control it on and off, 
> which GCC does not support.  The default is then implementation
> defined.

Perhaps we should add some initial hammer approach for the pragma, like
if you ever use the pragma to turn it somewhere off, it is turned off
globally, or ditto per function.  Might be far easier than trying to
make it precise that contraction is allowed in this expression and not in
this subexpression of that etc.  Of course, making it precise is the
ultimate goal.

	Jakub

Re: Concerns regarding the -ffp-contract=fast default

[Alexander Monakov]

On Mon, 18 Sep 2023, Jakub Jelinek wrote:

> Perhaps we should add some initial hammer approach for the pragma, like
> if you ever use the pragma to turn it somewhere off, it is turned off
> globally, or ditto per function.  Might be far easier than trying to
> make it precise that contraction is allowed in this expression and not in
> this subexpression of that etc.  Of course, making it precise is the
> ultimate goal.

When implementing -ffp-contract=standard I looked into implementing the
pragma (in a precise manner) and I didn't get the impression it would be
hard to implement for C. But I was somewhat discouraged by the lack of
front-end maintainers reaction to the patch implementing the =standard,
so I didn't pursue that.

The hardest part would be popping the pragma state when leaving a block,
which didn't seem difficult (at least for C).

Alexander

Re: Concerns regarding the -ffp-contract=fast default

[Martin Uecker]

Am Montag, dem 18.09.2023 um 14:43 +0300 schrieb Alexander Monakov:
> On Mon, 18 Sep 2023, Jakub Jelinek wrote:
> 
> > Perhaps we should add some initial hammer approach for the pragma, like
> > if you ever use the pragma to turn it somewhere off, it is turned off
> > globally, or ditto per function.

I think the default should be off - at least for code that does
not contain the pragma anywhere. 

> > Might be far easier than trying to
> > make it precise that contraction is allowed in this expression and not in
> > this subexpression of that etc.  Of course, making it precise is the
> > ultimate goal.
> 
> When implementing -ffp-contract=standard I looked into implementing the
> pragma (in a precise manner) and I didn't get the impression it would be
> hard to implement for C. But I was somewhat discouraged by the lack of
> front-end maintainers reaction to the patch implementing the =standard,
> so I didn't pursue that.
> 
> The hardest part would be popping the pragma state when leaving a block,
> which didn't seem difficult (at least for C).

It is fairly restricted where it can appear, it essentially operates
on the level of compound statements (!= blocks). 

Martin

Re: Concerns regarding the -ffp-contract=fast default

[Alexander Monakov]

On Mon, 18 Sep 2023, Martin Uecker wrote:

> > The hardest part would be popping the pragma state when leaving a block,
> > which didn't seem difficult (at least for C).
> 
> It is fairly restricted where it can appear, it essentially operates
> on the level of compound statements (!= blocks). 

Thanks for the clarification. Let me note that the standard somehow
decided to make out-of-place pragma a (compile-time) UB rather than
a constraint violation, leaving us free to make it work for blocks
(or launch Nethack).

Alexander