[Bug tree-optimization/82946] member pointer defeats strlen optimization involving a string literal

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82946

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 13 Nov 2017, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82946
> 
> --- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #3)
> 
> As I explained in comment #0, a_5(D)->d can safely be assumed not to point to
> itself as a result of the subsequent access to what it points to in strlen, and
> thanks to the fact that a string literal is never a valid representation of a
> pointer.

A bit too much "magic" here for my taste as in "how'd you implement that
'logic' in GCC?"

We don't have any good way to represent flow-sensitive alias info
btw (and any such representation would be fragile as you can see with
all the lurking/fixed bugs caused by maintaining flow-sensitive
range info).

To me 'strlen' operates like mem*, it accesses storage through
a character type and thus is not subject to any type-based alias
rules.  Given GCC doesn't distinguish between char * (character type)
and char * (string) I don't see how to implement that difference anyway.

This means you can very well replace memcpy with strcpy if you know
there's a '\0' in and only in the right place.

> Joseph's bare metal case of strlen (((struct A*)"123")->d) from comment #2
> could be handled either by detecting and warning about it, or accommodated
> under -ffreestanding or some new option to disable the optimization.

We certainly have to treat literal pointers encoded in any form
conservatively.  I don't see how they are against any standard.  There's
other clearly "valid" optimizations missing in GCC that look more
important to implement.