[PATCH] treat -Wxxx-larger-than=HWI_MAX special (PR 86631)
Martin Sebor
msebor@gmail.com
Thu Jul 26 14:59:00 GMT 2018
On 07/26/2018 02:38 AM, Richard Biener wrote:
> On Wed, Jul 25, 2018 at 5:54 PM Martin Sebor <msebor@gmail.com> wrote:
>>
>> On 07/25/2018 08:57 AM, Jakub Jelinek wrote:
>>> On Wed, Jul 25, 2018 at 08:54:13AM -0600, Martin Sebor wrote:
>>>> I don't mean for the special value to be used except internally
>>>> for the defaults. Otherwise, users wanting to override the default
>>>> will choose a value other than it. I'm happy to document it in
>>>> the .opt file for internal users though.
>>>>
>>>> -1 has the documented effect of disabling the warnings altogether
>>>> (-1 is SIZE_MAX) so while I agree that -1 looks better it doesn't
>>>> work. (It would need more significant changes.)
>>>
>>> The variable is signed, so -1 is not SIZE_MAX. Even if -1 disables it, you
>>> could use e.g. -2 or other negative value for the other special case.
>>
>> The -Wxxx-larger-than=N distinguish three ranges of argument
>> values (treated as unsigned):
>>
>> 1. [0, HOST_WIDE_INT_MAX)
>> 2. HOST_WIDE_INT_MAX
>> 3. [HOST_WIDE_INT_MAX + 1, Infinity)
>
> But it doesn't make sense for those to be host dependent.
It isn't when the values are handled by each warning. That's
also the point of this patch: to remove this (unintended)
dependency.
> I think numerical user input should be limited to [0, ptrdiff_max]
> and cases (1) and (2) should be simply merged, I see no value
> in distinguishing them. -Wxxx-larger-than should be aliased
> to [0, ptrdiff_max], case (3) is achieved by -Wno-xxx-larger-than.
>
> I think you are over-engineering this and the user-interface is
> awful.
Thank you.
I agree that what you describe would be the ideal solution.
As I explained in the description of the patch, I did consider
handling PTRDIFF_MAX but the target-dependent value is not
available at the time the option argument is processed. We
don't even know yet what the target data model is.
This is the best I came up with. What do you suggest instead?
Martin
More information about the Gcc-patches
mailing list