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

[Chandler Carruth via cfe-commits]

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20180428/1b703cb7/attachment-0001.html>