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.
