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

2018-04-29 Thread 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@lists.llvm.org> wrote:

> On Fri, Apr 27, 2018 at 5:13 PM Richard Smith 
> 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 
> 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=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=331055=331056=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
>>>

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

2018-04-27 Thread Chandler Carruth via cfe-commits 
On Fri, Apr 27, 2018 at 5:13 PM Richard Smith  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 
 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=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=331055=331056=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
>>>

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

2018-04-27 Thread Richard Smith via cfe-commits 
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 
>>> 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=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=331055=331056=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

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

2018-04-27 Thread Chandler Carruth via cfe-commits 
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.


>
>
>> On Fri, Apr 27, 2018 at 4:41 PM, Richard Smith 
>> 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=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=331055=331056=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

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

2018-04-27 Thread Richard Smith via cfe-commits 
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 Fri, Apr 27, 2018 at 4:41 PM, Richard Smith 
> 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=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/ReleaseNo
>>> tes.rst?rev=331056=331055=331056=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

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

2018-04-27 Thread Sanjay Patel via cfe-commits 
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.


On Fri, Apr 27, 2018 at 4:41 PM, Richard Smith 
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=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/ReleaseNo
>> tes.rst?rev=331056=331055=331056=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

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

2018-04-27 Thread Richard Smith via cfe-commits 
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=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=331055=331056=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

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

2018-04-27 Thread Sanjay Patel via cfe-commits 
Author: spatel
Date: Fri Apr 27 09:21:22 2018
New Revision: 331056

URL: http://llvm.org/viewvc/llvm-project?rev=331056=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=331055=331056=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`
+  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. 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