* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 17:59 ` Jeff Law
@ 2023-03-21 18:03 ` Paul Koning
2023-03-21 18:55 ` Toon Moene
2023-03-21 18:12 ` Alexander Monakov
2023-03-21 19:01 ` Qing Zhao
2 siblings, 1 reply; 32+ messages in thread
From: Paul Koning @ 2023-03-21 18:03 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches
> On Mar 21, 2023, at 1:59 PM, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 3/21/23 11:00, Qing Zhao via Gcc-patches wrote:
>>> On Mar 21, 2023, at 12:56 PM, Paul Koning <paulkoning@comcast.net> wrote:
>>>
>>>
>>>
>>>> On Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>>>
>>>> ...
>>>> Most of the compiler users are not familiar with language standards, or no access to language standards. Without clearly documenting such warnings along with the option explicitly, the users have not way to know such potential impact.
>>>
>>> With modern highly optimized languages, not knowing the standard is going to get you in trouble. There was a wonderful paper from MIT a few years ago describing all the many ways C can bite you if you don't know the rules.
>> Yes, it’s better to know the details of languages standard. -:)
>> However, I don’t think that this is a realistic expectation to the compiler users: to know all the details of a language standard.
> Umm, they really do need to know that stuff.
>
> If the developer fails to understand the language standard, then they're likely going to write code that is ultimately undefined or doesn't behave in they expect. How is the compiler supposed to guess what the developer originally intended? How should the compiler handle the case when two developers have different understandings of how a particular piece of code should work? In the end it's the language standard that defines how all this stuff should work.
>
> Failure to understand the language is a common problem and we do try to emit various diagnostics to help developers avoid writing non-conformant code. But ultimately if a developer fails to understand the language standard, then they're going to be surprised by the behavior of their code.
Conversely, of course, the problem is that C and other languages have evolved to the point that you have to be a language lawyer to write valid code. In other words, a substantial fraction of programmers are by definition writing unreliable code. This is not a good situation, and it may be part of the reason why modern software has such a high rate of defects.
paul
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 18:03 ` Paul Koning
@ 2023-03-21 18:55 ` Toon Moene
0 siblings, 0 replies; 32+ messages in thread
From: Toon Moene @ 2023-03-21 18:55 UTC (permalink / raw)
To: gcc-patches
On 3/21/23 19:03, Paul Koning via Gcc-patches wrote:
>> Failure to understand the language is a common problem and we do try to emit various diagnostics to help developers avoid writing non-conformant code. But ultimately if a developer fails to understand the language standard, then they're going to be surprised by the behavior of their code.
>
> Conversely, of course, the problem is that C and other languages have evolved to the point that you have to be a language lawyer to write valid code. In other words, a substantial fraction of programmers are by definition writing unreliable code. This is not a good situation, and it may be part of the reason why modern software has such a high rate of defects.
Fortran compilers that I use regularly (I mean, aside from gfortran)
have already given up on this battle, at least as far as floating point
issues are concerned.
So many people want to have "repeatable floating point computations"
that if someone writes:
READ*, X, Y, Z
PRINT*, X + Y + Z
END
they will get (if they know the compiler option that guarantees this -
but they will) the following code:
READ*, X, Y, Z
PRINT*, (X + Y) + Z
END
even though there's no way in hell the Fortran Language Standard (any of
them) guarantees this.
--
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 17:59 ` Jeff Law
2023-03-21 18:03 ` Paul Koning
@ 2023-03-21 18:12 ` Alexander Monakov
2023-03-21 18:18 ` Jeff Law
2023-03-21 19:01 ` Qing Zhao
2 siblings, 1 reply; 32+ messages in thread
From: Alexander Monakov @ 2023-03-21 18:12 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]
On Tue, 21 Mar 2023, Jeff Law via Gcc-patches wrote:
> On 3/21/23 11:00, Qing Zhao via Gcc-patches wrote:
> >
> >> On Mar 21, 2023, at 12:56 PM, Paul Koning <paulkoning@comcast.net> wrote:
> >>
> >>> On Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches
> >>> <gcc-patches@gcc.gnu.org> wrote:
> >>>
> >>> ...
> >>> Most of the compiler users are not familiar with language standards, or no
> >>> access to language standards. Without clearly documenting such warnings
> >>> along with the option explicitly, the users have not way to know such
> >>> potential impact.
> >>
> >> With modern highly optimized languages, not knowing the standard is going
> >> to get you in trouble. There was a wonderful paper from MIT a few years
> >> ago describing all the many ways C can bite you if you don't know the
> >> rules.
> >
> > Yes, it’s better to know the details of languages standard. -:)
> > However, I don’t think that this is a realistic expectation to the compiler
> > users: to know all the details of a language standard.
> Umm, they really do need to know that stuff.
>
> If the developer fails to understand the language standard, then they're
> likely going to write code that is ultimately undefined or doesn't behave in
> they expect. How is the compiler supposed to guess what the developer
> originally intended? How should the compiler handle the case when two
> developers have different understandings of how a particular piece of code
> should work? In the end it's the language standard that defines how all this
> stuff should work.
>
> Failure to understand the language is a common problem and we do try to emit
> various diagnostics to help developers avoid writing non-conformant code. But
> ultimately if a developer fails to understand the language standard, then
> they're going to be surprised by the behavior of their code.
W h a t.
This subthread concerns documenting the option better ("Without clearly
documenting such warnings ...").
Are you arguing against adding a brief notice to the documentation blurb for
the -ffp-contract= option?
Perplexed,
Alexander
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 18:12 ` Alexander Monakov
@ 2023-03-21 18:18 ` Jeff Law
2023-03-22 10:13 ` Richard Biener
0 siblings, 1 reply; 32+ messages in thread
From: Jeff Law @ 2023-03-21 18:18 UTC (permalink / raw)
To: Alexander Monakov; +Cc: gcc-patches
On 3/21/23 12:12, Alexander Monakov wrote:
>>> Yes, it’s better to know the details of languages standard. -:)
>>> However, I don’t think that this is a realistic expectation to the compiler
>>> users: to know all the details of a language standard.
>> Umm, they really do need to know that stuff.
>>
>> If the developer fails to understand the language standard, then they're
>> likely going to write code that is ultimately undefined or doesn't behave in
>> they expect. How is the compiler supposed to guess what the developer
>> originally intended? How should the compiler handle the case when two
>> developers have different understandings of how a particular piece of code
>> should work? In the end it's the language standard that defines how all this
>> stuff should work.
>>
>> Failure to understand the language is a common problem and we do try to emit
>> various diagnostics to help developers avoid writing non-conformant code. But
>> ultimately if a developer fails to understand the language standard, then
>> they're going to be surprised by the behavior of their code.
>
> W h a t.
>
> This subthread concerns documenting the option better ("Without clearly
> documenting such warnings ...").
>
> Are you arguing against adding a brief notice to the documentation blurb for
> the -ffp-contract= option?
I was merely chiming in on Qing's statement that it is not realistic to
expect users to know the details of the language standard.
Jeff
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 18:18 ` Jeff Law
@ 2023-03-22 10:13 ` Richard Biener
2023-03-22 12:26 ` Alexander Monakov
0 siblings, 1 reply; 32+ messages in thread
From: Richard Biener @ 2023-03-22 10:13 UTC (permalink / raw)
To: Jeff Law; +Cc: Alexander Monakov, gcc-patches
On Tue, Mar 21, 2023 at 7:18 PM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 3/21/23 12:12, Alexander Monakov wrote:
> >>> Yes, it’s better to know the details of languages standard. -:)
> >>> However, I don’t think that this is a realistic expectation to the compiler
> >>> users: to know all the details of a language standard.
> >> Umm, they really do need to know that stuff.
> >>
> >> If the developer fails to understand the language standard, then they're
> >> likely going to write code that is ultimately undefined or doesn't behave in
> >> they expect. How is the compiler supposed to guess what the developer
> >> originally intended? How should the compiler handle the case when two
> >> developers have different understandings of how a particular piece of code
> >> should work? In the end it's the language standard that defines how all this
> >> stuff should work.
> >>
> >> Failure to understand the language is a common problem and we do try to emit
> >> various diagnostics to help developers avoid writing non-conformant code. But
> >> ultimately if a developer fails to understand the language standard, then
> >> they're going to be surprised by the behavior of their code.
> >
> > W h a t.
> >
> > This subthread concerns documenting the option better ("Without clearly
> > documenting such warnings ...").
> >
> > Are you arguing against adding a brief notice to the documentation blurb for
> > the -ffp-contract= option?
> I was merely chiming in on Qing's statement that it is not realistic to
> expect users to know the details of the language standard.
I think it's even less realistic to expect users to know the details of
floating-point math. So I doubt any such sentence will be helpful
besides spreading some FUD?
>
>
> Jeff
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: Should -ffp-contract=off the default on GCC?
2023-03-22 10:13 ` Richard Biener
@ 2023-03-22 12:26 ` Alexander Monakov
2023-03-22 13:57 ` Richard Biener
0 siblings, 1 reply; 32+ messages in thread
From: Alexander Monakov @ 2023-03-22 12:26 UTC (permalink / raw)
To: Richard Biener; +Cc: Jeff Law, gcc-patches
On Wed, 22 Mar 2023, Richard Biener wrote:
> I think it's even less realistic to expect users to know the details of
> floating-point math. So I doubt any such sentence will be helpful
> besides spreading some FUD?
I think it's closer to "fundamental notions" rather than "details". For
users who bother to read the GCC manual there's a decent chance it wouldn't
be for naught.
For documentation, I was thinking
Together with -fexcess-precision=standard, -ffp-contract=off
is necessary to ensure that rounding of intermediate results to precision
implied by the source code and the FLT_EVAL_METHOD macro is not
omitted by the compiler.
Alexander
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-22 12:26 ` Alexander Monakov
@ 2023-03-22 13:57 ` Richard Biener
2023-03-22 15:52 ` Qing Zhao
0 siblings, 1 reply; 32+ messages in thread
From: Richard Biener @ 2023-03-22 13:57 UTC (permalink / raw)
To: Alexander Monakov; +Cc: Jeff Law, gcc-patches
On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov <amonakov@ispras.ru> wrote:
>
>
> On Wed, 22 Mar 2023, Richard Biener wrote:
>
> > I think it's even less realistic to expect users to know the details of
> > floating-point math. So I doubt any such sentence will be helpful
> > besides spreading some FUD?
>
> I think it's closer to "fundamental notions" rather than "details". For
> users who bother to read the GCC manual there's a decent chance it wouldn't
> be for naught.
>
> For documentation, I was thinking
>
> Together with -fexcess-precision=standard, -ffp-contract=off
> is necessary to ensure that rounding of intermediate results to precision
> implied by the source code and the FLT_EVAL_METHOD macro is not
> omitted by the compiler.
that sounds good to me
> Alexander
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-22 13:57 ` Richard Biener
@ 2023-03-22 15:52 ` Qing Zhao
2023-03-24 7:12 ` Fangrui Song
0 siblings, 1 reply; 32+ messages in thread
From: Qing Zhao @ 2023-03-22 15:52 UTC (permalink / raw)
To: Richard Biener, Alexander Monakov; +Cc: Jeff Law, gcc Patches
> On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
> On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov <amonakov@ispras.ru> wrote:
>>
>>
>> On Wed, 22 Mar 2023, Richard Biener wrote:
>>
>>> I think it's even less realistic to expect users to know the details of
>>> floating-point math. So I doubt any such sentence will be helpful
>>> besides spreading some FUD?
>>
>> I think it's closer to "fundamental notions" rather than "details". For
>> users who bother to read the GCC manual there's a decent chance it wouldn't
>> be for naught.
>>
>> For documentation, I was thinking
>>
>> Together with -fexcess-precision=standard, -ffp-contract=off
>> is necessary to ensure that rounding of intermediate results to precision
>> implied by the source code and the FLT_EVAL_METHOD macro is not
>> omitted by the compiler.
>
> that sounds good to me
Shall we add such clarification to our Gcc13 doc? That should be helpful if we keep the currently default.
Qing
>
>> Alexander
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-22 15:52 ` Qing Zhao
@ 2023-03-24 7:12 ` Fangrui Song
2023-03-24 19:42 ` Andrew Pinski
0 siblings, 1 reply; 32+ messages in thread
From: Fangrui Song @ 2023-03-24 7:12 UTC (permalink / raw)
To: Qing Zhao; +Cc: Richard Biener, Alexander Monakov, Jeff Law, gcc Patches
On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> > On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> >
> > On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov <amonakov@ispras.ru> wrote:
> >>
> >>
> >> On Wed, 22 Mar 2023, Richard Biener wrote:
> >>
> >>> I think it's even less realistic to expect users to know the details of
> >>> floating-point math. So I doubt any such sentence will be helpful
> >>> besides spreading some FUD?
> >>
> >> I think it's closer to "fundamental notions" rather than "details". For
> >> users who bother to read the GCC manual there's a decent chance it wouldn't
> >> be for naught.
> >>
> >> For documentation, I was thinking
> >>
> >> Together with -fexcess-precision=standard, -ffp-contract=off
> >> is necessary to ensure that rounding of intermediate results to precision
> >> implied by the source code and the FLT_EVAL_METHOD macro is not
> >> omitted by the compiler.
> >
> > that sounds good to me
>
> Shall we add such clarification to our Gcc13 doc? That should be helpful if we keep the currently default.
>
> Qing
> >
> >> Alexander
>
While updating the documentation, consider adding information that
#pragma STDC FP_CONTRACT OFF is ignored with -ffp-contract=fast.
This surprising behavior motivated Clang to add
-Xclang=-ffp-contract=fast-honor-pragmas
(https://discourse.llvm.org/t/fp-contract-fast-and-pragmas/58529).
--
宋方睿
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-24 7:12 ` Fangrui Song
@ 2023-03-24 19:42 ` Andrew Pinski
2023-03-31 16:31 ` Qing Zhao
0 siblings, 1 reply; 32+ messages in thread
From: Andrew Pinski @ 2023-03-24 19:42 UTC (permalink / raw)
To: Fangrui Song
Cc: Qing Zhao, Richard Biener, Alexander Monakov, Jeff Law, gcc Patches
On Fri, Mar 24, 2023 at 1:14 AM Fangrui Song via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> >
> >
> > > On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> > >
> > > On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov <amonakov@ispras.ru> wrote:
> > >>
> > >>
> > >> On Wed, 22 Mar 2023, Richard Biener wrote:
> > >>
> > >>> I think it's even less realistic to expect users to know the details of
> > >>> floating-point math. So I doubt any such sentence will be helpful
> > >>> besides spreading some FUD?
> > >>
> > >> I think it's closer to "fundamental notions" rather than "details". For
> > >> users who bother to read the GCC manual there's a decent chance it wouldn't
> > >> be for naught.
> > >>
> > >> For documentation, I was thinking
> > >>
> > >> Together with -fexcess-precision=standard, -ffp-contract=off
> > >> is necessary to ensure that rounding of intermediate results to precision
> > >> implied by the source code and the FLT_EVAL_METHOD macro is not
> > >> omitted by the compiler.
> > >
> > > that sounds good to me
> >
> > Shall we add such clarification to our Gcc13 doc? That should be helpful if we keep the currently default.
> >
> > Qing
> > >
> > >> Alexander
> >
>
> While updating the documentation, consider adding information that
> #pragma STDC FP_CONTRACT OFF is ignored with -ffp-contract=fast.
>
> This surprising behavior motivated Clang to add
> -Xclang=-ffp-contract=fast-honor-pragmas
> (https://discourse.llvm.org/t/fp-contract-fast-and-pragmas/58529).
`#pragma STDC FP_CONTRACT OFF` is not even implemented yet in GCC.
Rather we should document that :).
It does not matter what clang does here really since GCC does not even
implement the pragma.
Thanks,
Andrew Pinski
>
>
>
> --
> 宋方睿
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-24 19:42 ` Andrew Pinski
@ 2023-03-31 16:31 ` Qing Zhao
0 siblings, 0 replies; 32+ messages in thread
From: Qing Zhao @ 2023-03-31 16:31 UTC (permalink / raw)
To: Andrew Pinski
Cc: Fangrui Song, Richard Biener, Alexander Monakov, Jeff Law, gcc Patches
> On Mar 24, 2023, at 3:42 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>
> On Fri, Mar 24, 2023 at 1:14 AM Fangrui Song via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>> On Wed, Mar 22, 2023 at 8:52 AM Qing Zhao via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>>>
>>>
>>>
>>>> On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>>>
>>>> On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov <amonakov@ispras.ru> wrote:
>>>>>
>>>>>
>>>>> On Wed, 22 Mar 2023, Richard Biener wrote:
>>>>>
>>>>>> I think it's even less realistic to expect users to know the details of
>>>>>> floating-point math. So I doubt any such sentence will be helpful
>>>>>> besides spreading some FUD?
>>>>>
>>>>> I think it's closer to "fundamental notions" rather than "details". For
>>>>> users who bother to read the GCC manual there's a decent chance it wouldn't
>>>>> be for naught.
>>>>>
>>>>> For documentation, I was thinking
>>>>>
>>>>> Together with -fexcess-precision=standard, -ffp-contract=off
>>>>> is necessary to ensure that rounding of intermediate results to precision
>>>>> implied by the source code and the FLT_EVAL_METHOD macro is not
>>>>> omitted by the compiler.
>>>>
>>>> that sounds good to me
>>>
>>> Shall we add such clarification to our Gcc13 doc? That should be helpful if we keep the currently default.
>>>
>>> Qing
>>>>
>>>>> Alexander
>>>
>>
>> While updating the documentation, consider adding information that
>> #pragma STDC FP_CONTRACT OFF is ignored with -ffp-contract=fast.
>>
>> This surprising behavior motivated Clang to add
>> -Xclang=-ffp-contract=fast-honor-pragmas
>> (https://discourse.llvm.org/t/fp-contract-fast-and-pragmas/58529).
>
> `#pragma STDC FP_CONTRACT OFF` is not even implemented yet in GCC.
> Rather we should document that :).
Do we have any plan to implement this pragma?
Also, do we have any plan to implement -ffp-contract=on?
I am very curious on why -ffp-contract=on has not been implemented for so long time?
There are some documentation on Floating Point implementation of GCC on the pragma STDC FP_CONTRACT
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Floating-point-implementation.html#Floating-point-implementation
"
• Whether and how floating expressions are contracted when not disallowed by the FP_CONTRACT pragma (C99 and C11 6.5).
Expressions are currently only contracted if -ffp-contract=fast, -funsafe-math-optimizations or -ffast-math are used. This is subject to change.
• The default state for the FP_CONTRACT pragma (C99 and C11 7.12.2).
This pragma is not implemented. Expressions are currently only contracted if -ffp-contract=fast, -funsafe-math-optimizations or -ffast-math are used. This is subject to change.
“
So, looks like that we have documented this. But When the user read the documentation for —ffp-contract option, there is no such information. We might add a link in the documentation of -ffp-contract option to here to make it clear.
Qing
> It does not matter what clang does here really since GCC does not even
> implement the pragma.
>
> Thanks,
> Andrew Pinski
>
>
>>
>>
>>
>> --
>> 宋方睿
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 17:59 ` Jeff Law
2023-03-21 18:03 ` Paul Koning
2023-03-21 18:12 ` Alexander Monakov
@ 2023-03-21 19:01 ` Qing Zhao
2023-03-21 19:12 ` Jakub Jelinek
2023-03-21 19:51 ` Jeff Law
2 siblings, 2 replies; 32+ messages in thread
From: Qing Zhao @ 2023-03-21 19:01 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches
> On Mar 21, 2023, at 1:59 PM, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 3/21/23 11:00, Qing Zhao via Gcc-patches wrote:
>>> On Mar 21, 2023, at 12:56 PM, Paul Koning <paulkoning@comcast.net> wrote:
>>>
>>>
>>>
>>>> On Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>>>
>>>> ...
>>>> Most of the compiler users are not familiar with language standards, or no access to language standards. Without clearly documenting such warnings along with the option explicitly, the users have not way to know such potential impact.
>>>
>>> With modern highly optimized languages, not knowing the standard is going to get you in trouble. There was a wonderful paper from MIT a few years ago describing all the many ways C can bite you if you don't know the rules.
>> Yes, it’s better to know the details of languages standard. -:)
>> However, I don’t think that this is a realistic expectation to the compiler users: to know all the details of a language standard.
> Umm, they really do need to know that stuff.
>
> If the developer fails to understand the language standard, then they're likely going to write code that is ultimately undefined or doesn't behave in they expect. How is the compiler supposed to guess what the developer originally intended? How should the compiler handle the case when two developers have different understandings of how a particular piece of code should work? In the end it's the language standard that defines how all this stuff should work.
Theoretically, yes, I agree with you.
But in reality, many programmers don’t know all the details of the language standard and writing problematic code, that’s one of the reasons the compiler issues different warnings to the users in order to avoid those issues.
In addition to this, Standards have been changed from time to time.
The code previously worked now has some issue since we added some new stuff into standard, and the compiler added some new transformation based on this new stuff. Should the compiler issue some warnings to warn the users about such change? Then the user will go to the new standard to get more info?
Qing
>
> Failure to understand the language is a common problem and we do try to emit various diagnostics to help developers avoid writing non-conformant code. But ultimately if a developer fails to understand the language standard, then they're going to be surprised by the behavior of their code.
>
> Jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 19:01 ` Qing Zhao
@ 2023-03-21 19:12 ` Jakub Jelinek
2023-03-21 23:28 ` Jeff Law
2023-03-21 19:51 ` Jeff Law
1 sibling, 1 reply; 32+ messages in thread
From: Jakub Jelinek @ 2023-03-21 19:12 UTC (permalink / raw)
To: Qing Zhao; +Cc: Jeff Law, gcc-patches
On Tue, Mar 21, 2023 at 07:01:36PM +0000, Qing Zhao via Gcc-patches wrote:
> In addition to this, Standards have been changed from time to time.
So, the user needs to know the standard they are compiling for.
Anyway, talking again about contractions, it isn't anything new in the
standard, C99 had those too.
Jakub
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 19:12 ` Jakub Jelinek
@ 2023-03-21 23:28 ` Jeff Law
2023-03-21 23:31 ` Jakub Jelinek
0 siblings, 1 reply; 32+ messages in thread
From: Jeff Law @ 2023-03-21 23:28 UTC (permalink / raw)
To: Jakub Jelinek, Qing Zhao; +Cc: gcc-patches
On 3/21/23 13:12, Jakub Jelinek wrote:
> On Tue, Mar 21, 2023 at 07:01:36PM +0000, Qing Zhao via Gcc-patches wrote:
>> In addition to this, Standards have been changed from time to time.
>
> So, the user needs to know the standard they are compiling for.
>
> Anyway, talking again about contractions, it isn't anything new in the
> standard, C99 had those too.
And I think Qing is asking if adding a warning in the manual about how
fp contractions can cause unpredictability in FP results is appropriate
in the fp-contract section.
I think that would be a fine addition to the manual.
jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 23:28 ` Jeff Law
@ 2023-03-21 23:31 ` Jakub Jelinek
0 siblings, 0 replies; 32+ messages in thread
From: Jakub Jelinek @ 2023-03-21 23:31 UTC (permalink / raw)
To: Jeff Law; +Cc: Qing Zhao, gcc-patches
On Tue, Mar 21, 2023 at 05:28:52PM -0600, Jeff Law via Gcc-patches wrote:
> On 3/21/23 13:12, Jakub Jelinek wrote:
> > On Tue, Mar 21, 2023 at 07:01:36PM +0000, Qing Zhao via Gcc-patches wrote:
> > > In addition to this, Standards have been changed from time to time.
> >
> > So, the user needs to know the standard they are compiling for.
> >
> > Anyway, talking again about contractions, it isn't anything new in the
> > standard, C99 had those too.
> And I think Qing is asking if adding a warning in the manual about how fp
> contractions can cause unpredictability in FP results is appropriate in the
> fp-contract section.
>
> I think that would be a fine addition to the manual.
Depending on how it is worded, probably yes.
Jakub
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 19:01 ` Qing Zhao
2023-03-21 19:12 ` Jakub Jelinek
@ 2023-03-21 19:51 ` Jeff Law
2023-03-21 21:08 ` Qing Zhao
1 sibling, 1 reply; 32+ messages in thread
From: Jeff Law @ 2023-03-21 19:51 UTC (permalink / raw)
To: Qing Zhao; +Cc: gcc-patches
On 3/21/23 13:01, Qing Zhao wrote:
>
> The code previously worked now has some issue since we added some new stuff into standard, and the compiler added some new transformation based on this new stuff. Should the compiler issue some warnings to warn the users about such change? Then the user will go to the new standard to get more info?
It is not at all uncommon to have old code no longer work due to a
compiler update.
This can happen if the compiler changes the default version of the
language it's supporting (say c99 to c11) or fixes a missed-error bug
(more common in C++) or the optimizers just get smarter and code which
was always buggy, but worked by accident no longer works.
When we can reasonably give diagnostics, we try to. Improvements in
this space are appreciated :-)
Jeff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Should -ffp-contract=off the default on GCC?
2023-03-21 19:51 ` Jeff Law
@ 2023-03-21 21:08 ` Qing Zhao
0 siblings, 0 replies; 32+ messages in thread
From: Qing Zhao @ 2023-03-21 21:08 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches
> On Mar 21, 2023, at 3:51 PM, Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 3/21/23 13:01, Qing Zhao wrote:
>
>> The code previously worked now has some issue since we added some new stuff into standard, and the compiler added some new transformation based on this new stuff. Should the compiler issue some warnings to warn the users about such change? Then the user will go to the new standard to get more info?
> It is not at all uncommon to have old code no longer work due to a compiler update.
>
> This can happen if the compiler changes the default version of the language it's supporting (say c99 to c11) or fixes a missed-error bug (more common in C++) or the optimizers just get smarter and code which was always buggy, but worked by accident no longer works.
>
> When we can reasonably give diagnostics, we try to. Improvements in this space are appreciated :-)
For this specific case, the C standard (C99 and later) explicitly mentioned that the fp-contract might “undermine predictability”, “can even decrease accuracy” at the same time to allow it.
http://port70.net/%7Ensz/c/c99/n1256.html#note78
78) This license is specifically intended to allow implementations to exploit fast machine instructions that combine multiple C operators. As contractions potentially undermine predictability, and can even decrease accuracy for containing expressions, their use needs to be well-defined and clearly documented.
In GCC, the fp-contract is on by default, but the documentation of it doesn’t mention such warning at all. I think it will be helpful to add explicit warning in the -ffp-contract documentation.
If you agree on this, I can come up with a patch to add such warning for -ffp-contract.
Qing
>
> Jeff
>
^ permalink raw reply [flat|nested] 32+ messages in thread