This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Make strlen range computations more conservative
On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor <msebor@gmail.com> wrote:
>On 08/06/2018 11:40 AM, Jeff Law wrote:
>> On 08/06/2018 11:15 AM, Martin Sebor wrote:
>>>>> These examples do not aim to be valid C, they just point out
>limitations
>>>>> of the middle-end design, and a good deal of the problems are due
>>>>> to trying to do things that are not safe within the boundaries
>given
>>>>> by the middle-end design.
>>>> I really think this is important -- and as such I think we need to
>move
>>>> away from trying to describe scenarios in C because doing so keeps
>>>> bringing us back to the "C doesn't allow XYZ" kinds of arguments
>when
>>>> what we're really discussing are GIMPLE semantic issues.
>>>>
>>>> So examples should be GIMPLE. You might start with (possibly
>invalid) C
>>>> code to generate the GIMPLE, but the actual discussion needs to be
>>>> looking at GIMPLE. We might include the C code in case someone
>wants to
>>>> look at things in a debugger, but bringing the focus to GIMPLE is
>really
>>>> important here.
>>>
>>> I don't understand the goal of this exercise. Unless the GIMPLE
>>> code is the result of a valid test case (in some language GCC
>>> supports), what does it matter what it looks like? The basis of
>>> every single transformation done by a compiler is that the source
>>> code is correct. If it isn't then all bets are off. I'm no GIMPLE
>>> expert but even I can come up with any number of GIMPLE expressions
>>> that have undefined behavior. What would that prove?
>> The GIMPLE IL is less restrictive than the original source language.
>> The process of translation into GIMPLE and optimization can create
>> situations in the GIMPLE IL that can't be validly represented in the
>> original source language. Subobject crossing being one such case,
>there
>> are certainly others. We have to handle these scenarios correctly.
>
>Sure, but a valid C test case still needs to exist to show that
>such a transformation is possible. Until someone comes up with
>one it's all speculation.
Jakub showed you one wrt CSE of addresses.
Richard.
>Under normal circumstances the burden of proof that there is
>a problem is on the reporter. In this case, the requirement
>has turned into one to prove a negative. Effectively, you
>are asking for a proof that there is no bug, either in
>the assumptions behind the strlen optimization, or somewhere
>else in GCC that would lead the optimization to invalidate
>a valid piece of code. That's impossible.
>
>Martin