Re: [PATCH] fold more string comparison with known result (PR 90879)

[Jeff Law <law@redhat.com>]

On 8/12/19 4:17 PM, Martin Sebor wrote:
> On 8/12/19 2:04 PM, Jeff Law wrote:
>> On 8/9/19 4:14 PM, Martin Sebor wrote:
>>> On 8/9/19 10:58 AM, Jakub Jelinek wrote:
>>>> On Fri, Aug 09, 2019 at 10:51:09AM -0600, Martin Sebor wrote:
>>>>> That said, we should change this code one way or the other.
>>>>> There is even less of a guarantee that other compilers support
>>>>> writing past the end of arrays that have non-zero size than
>>>>> that they recognize the documented zero-length extension.
>>>>
>>>> We use that everywhere forever, so no.
>>>
>>> Just because some invalid code has been in place "forever" doesn't
>>> mean it cannot be changed.  Relying on undocumented "extensions"
>>> because they just happen to work with the compilers they have been
>>> exposed to is exactly how naive users get in trouble.  Our answer
>>> to reports of "bugs" when the behavior changes is typically: fix
>>> your code.  There's little reason to expect other compiler writers
>>> to be any more accommodating.
>>>
>>>> See e.g. rtx u.fld and u.hwint arrays, tree_exp operands array,
>>>> gimple_statement_with_ops op array just to name a few that are
>>>> everywhere.  Coverity is indeed unhappy about
>>>> that, but it would be with [0] certainly too.  Another option is
>>>> to use maximum possible size where we know it (which is the case of
>>>> rtxes and most tree expressions and gimple stmts, but not e.g.
>>>> CALL_EXPR or GIMPLE_CALL where there is no easy upper bound.
>>>
>>> The solution introduced in C99 is a flexible array.  C++
>>> compilers usually support it as well.  Those that don't are
>>> likely to support the zero-length array (even Visual C++ does).
>>> If there's a chance that some don't support either do you really
>>> think it's safe to assume they will do something sane with
>>> the [1] hack?  If you're concerned that the flexible array syntax
>>> or the zero length array won't compile, add a configure test to
>>> see if it does and use whatever alternative is most appropriate.
>> Given that we require a C++03 compiler to build GCC, I think we can
>> revisit how we represent the trailing array.  But that seems independent
>> of the bulk of this patch.
>>
>> Can we separate this issue from the rest of the patch?
> 
> The updated patch I posted is independent of the trailing
> [1] array hack:
> 
>   https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html
I must have dropped this from my queue by accident.  I'll go find it and
give it a looksie as well.

jeff