[PATCH] Make strlen range computations more conservative

Jeff Law law@redhat.com
Mon Aug 6 14:58:00 GMT 2018


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.

Jeff




More information about the Gcc-patches mailing list