> On Mar 22, 2023, at 8:33 AM, Alexander Monakov <amona...@ispras.ru> wrote: > > > On Mon, 20 Mar 2023, Jakub Jelinek via Gcc-patches wrote: > >> On Mon, Mar 20, 2023 at 10:05:57PM +0000, Qing Zhao via Gcc-patches wrote: >>> My question: is the above section the place in C standard “explicitly >>> allows contractions”? If not, where it is in C standard? >> >> http://port70.net/%7Ensz/c/c99/n1256.html#6.5p8 >> http://port70.net/%7Ensz/c/c99/n1256.html#note78 >> http://port70.net/%7Ensz/c/c99/n1256.html#F.6 > > C only allows contractions within expressions, not across statements (i.e. > either -ffp-contract=on or -ffp-contract=off would be compliant, but not > our default -ffp-contract=fast).
Oh, thanks for the info. Just read the documentation of -fp-contract=style again: -:) " -ffp-contract=style -ffp-contract=off disables floating-point expression contraction. -ffp-contract=fast enables floating-point expression contraction such as forming of fused multiply-add operations if the target has native support for them. -ffp-contract=on enables floating-point expression contraction if allowed by the language standard. This is currently not implemented and treated equal to -ffp-contract=off. The default is -ffp-contract=fast.” I was a little confused about the difference between -ffp-contract=fast and -ffp-contract=on previously, now I understand. So, looks like that it's -ffp-contract=on that is compliant with C standard, but not -ffp-contract=fast? (However, my understanding from the above doc and also from the GCC source code is, currently, -ffp-contract=on is not implemented and is equal to -fp-contract=off). Therefore, the default value of -fp-contract=fast is NOT compliant with the language standard? Do I miss anything here? > > Unrestricted contraction across statements together with other optimizations > gives rise to difficult-to-debug issues such as PR 106902. Just read this bug’s comments, yes, I agree. Qing > > Alexander
