This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] fold more string comparison with known result (PR 90879)
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  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  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
>  array hack:
I must have dropped this from my queue by accident. I'll go find it and
give it a looksie as well.