r331056 - [docs] add -ffp-cast-overflow-workaround to the release notes

[Sanjay Patel via cfe-commits]

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 at lists.llvm.org> wrote:

> On Fri, Apr 27, 2018 at 5:13 PM Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> On 27 April 2018 at 17:09, Chandler Carruth via cfe-commits <
>> cfe-commits at lists.llvm.org> wrote:
>>
>>> On Fri, Apr 27, 2018 at 4:36 PM Richard Smith via cfe-commits <
>>> cfe-commits at lists.llvm.org> wrote:
>>>
>>>> On 27 April 2018 at 16:07, Sanjay Patel via cfe-commits <
>>>> cfe-commits at 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 <richard at metafoo.co.uk>
>>>>> wrote:
>>>>>
>>>>>> On 27 April 2018 at 09:21, Sanjay Patel via cfe-commits <
>>>>>> cfe-commits at 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 at lists.llvm.org
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cfe-commits mailing list
>>>>> cfe-commits at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>>
>>>>> _______________________________________________
>>>> cfe-commits mailing list
>>>> cfe-commits at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20180429/9d724347/attachment.html>