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
