This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Make strlen range computations more conservative

On 08/03/2018 01:48 AM, Jakub Jelinek wrote:
> On Fri, Aug 03, 2018 at 01:19:14AM -0600, Jeff Law wrote:
>> I'm leaning towards a similar conclusion, namely that we can only rely
>> on type information for the pointer that actually gets passed to strlen,
>> which 99.9% of the time is (char *), potentially with const qualifiers.
> You can't derive anything from the pointer type of the strlen argument,
> because pointer conversions are useless in the middle-end, so if there was
> some conversion at some point, it might be gone, or you might get there a
> completely different pointer type of something that happened to have the
> same value.  That is why the information, if it matters, needs to be stored
> elsewhere, on the memory access (MEM_REF has such info, TARGET_MEM_REF too,
> handled_component_p do too).
So ISTM that you, Richi and I are in broad agreement that we can't walk
backwards through casts to refine the potential range for string lengths
because of GIMPLE semantics.  That also matches which Bernd wants to see
happen.  With that in mind I propose we either revert that aspect of
Martin's patch or move forward with Bernd's patch for that issue,
whichever makes the most sense.

However, I want to give Martin a chance to chime in explicitly on the
subject of looking through casts before making that change.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]