Patches to improve the language posted for review: https://reviews.llvm.org/D46236 https://reviews.llvm.org/D46237
On Fri, Apr 27, 2018 at 7:41 PM, Chandler Carruth via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On Fri, Apr 27, 2018 at 5:13 PM Richard Smith <rich...@metafoo.co.uk> > wrote: > >> On 27 April 2018 at 17:09, Chandler Carruth via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> On Fri, Apr 27, 2018 at 4:36 PM Richard Smith via cfe-commits < >>> cfe-commits@lists.llvm.org> wrote: >>> >>>> On 27 April 2018 at 16:07, Sanjay Patel via cfe-commits < >>>> cfe-commits@lists.llvm.org> wrote: >>>> >>>>> Missing dash corrected at r331057. I can improve the doc wording, but >>>>> let's settle on the flag name first, and I'll try to get it all fixed up >>>>> in >>>>> one shot. >>>>> >>>>> So far we have these candidates: >>>>> 1. -ffp-cast-overflow-workaround >>>>> 2. -fstrict-fp-trunc-semantics >>>>> 3. -fstrict-fp-cast-overflow >>>>> >>>>> I don't have a strong opinion here, but on 2nd reading, it does seem >>>>> like a 'strict' flag fits better with existing options. >>>>> >>>> >>>> The corresponding UBSan check is called -fsanitize=float-cast-overflow, >>>> so maybe -fno-strict-float-cast-overflow would be the most consistent >>>> name? >>>> >>> >>> On this topic: we were hit by this on a *lot* of code. All of that code >>> builds and passes tests with -fsanitize=float-cast-overflow. So I think >>> we've been mistaken in assuming that this sanitizer catches all of the >>> failure modes of the optimization. That at least impacts the sanitizer >>> suggestion in the release notes. And probably impacts the flag name / >>> attribuet name. >>> >> >> That's interesting, and definitely sounds like a bug (either the >> sanitizer or LLVM is presumably getting the range check wrong). Can you >> point me at an example? >> > > It appears that the code that hit this has cleverly dodged *EVERY* build > configuration we have deployed this sanitizer in... despite our best > efforts. Sorry for the noise. > > >> >> >>> On Fri, Apr 27, 2018 at 4:41 PM, Richard Smith <rich...@metafoo.co.uk> >>>>> wrote: >>>>> >>>>>> On 27 April 2018 at 09:21, Sanjay Patel via cfe-commits < >>>>>> cfe-commits@lists.llvm.org> wrote: >>>>>> >>>>>>> Author: spatel >>>>>>> Date: Fri Apr 27 09:21:22 2018 >>>>>>> New Revision: 331056 >>>>>>> >>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=331056&view=rev >>>>>>> Log: >>>>>>> [docs] add -ffp-cast-overflow-workaround to the release notes >>>>>>> >>>>>>> This option was added with: >>>>>>> D46135 >>>>>>> rL331041 >>>>>>> ...copying the text from UsersManual.rst for more exposure. >>>>>>> >>>>>>> >>>>>>> Modified: >>>>>>> cfe/trunk/docs/ReleaseNotes.rst >>>>>>> >>>>>>> Modified: cfe/trunk/docs/ReleaseNotes.rst >>>>>>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ >>>>>>> ReleaseNotes.rst?rev=331056&r1=331055&r2=331056&view=diff >>>>>>> ============================================================ >>>>>>> ================== >>>>>>> --- cfe/trunk/docs/ReleaseNotes.rst (original) >>>>>>> +++ cfe/trunk/docs/ReleaseNotes.rst Fri Apr 27 09:21:22 2018 >>>>>>> @@ -83,6 +83,15 @@ Non-comprehensive list of changes in thi >>>>>>> New Compiler Flags >>>>>>> ------------------ >>>>>>> >>>>>>> +- :option:`-ffp-cast-overflow-workaround` and >>>>>>> + :option:`-fnofp-cast-overflow-workaround` >>>>>>> >>>>>> >>>>>> Shouldn't this be -fno-fp-cast-overflow-workaround? >>>>>> >>>>>> Also, our convention for flags that define undefined behavior is >>>>>> `-fno-strict-*`, so perhaps this should be `-fno-strict-fp-cast-overflow` >>>>>> ? >>>>>> >>>>>> >>>>>>> + enable (disable) a workaround for code that casts floating-point >>>>>>> values to >>>>>>> + integers and back to floating-point. If the floating-point value >>>>>>> is not >>>>>>> + representable in the intermediate integer type, the code is >>>>>>> incorrect >>>>>>> + according to the language standard. >>>>>> >>>>>> >>>>>> I find this hard to read: I initially misread "the code is incorrect >>>>>> according to the language standard" as meaning "Clang will generate code >>>>>> that is incorrect according to the language standard". I think what you >>>>>> mean here is "the code has undefined behavior according to the language >>>>>> standard, and Clang will not guarantee any particular result. This flag >>>>>> causes the behavior to be defined to match the overflowing behavior of >>>>>> the >>>>>> target's native float-to-int conversion instructions." >>>>>> >>>>>> >>>>>>> This flag will attempt to generate code >>>>>>> + as if the result of an overflowing conversion matches the >>>>>>> overflowing behavior >>>>>>> + of a target's native float-to-int conversion instructions. >>>>>>> + >>>>>>> - ... >>>>>>> >>>>>>> Deprecated Compiler Flags >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cfe-commits mailing list >>>>>>> cfe-commits@lists.llvm.org >>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> cfe-commits mailing list >>>>> cfe-commits@lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>>>> >>>>> _______________________________________________ >>>> cfe-commits mailing list >>>> cfe-commits@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>>> >>> >>> _______________________________________________ >>> cfe-commits mailing list >>> cfe-commits@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>> >>> > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits