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? > 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
