https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93764
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 17 Feb 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93764 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|INVALID |FIXED > > --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #7) > > r &= ((* (unsigned long *) p) == 128); > > > > this one misses the may-alias type. You can't read a char * stored value > > via a unsigned long * > > But doesn't the union contain unsigned long a[2]; unsigned char b[16]; > members? > Sure, from strict C POV it is invalid in any case, as it doesn't support > punning through unions and u.b is the last written union member. > So, for type punning through union, do we require that if the last written > member of the union is not of the type we want to read through, the access > must > be with the union in the access path? It's somewhat related to PR92152. There I wrote "Note that when I decided to make union accesses have the alias-set of the union that implicitely allows type-punning when one of the refs have the union visible as opposed to our documentation which could be read in a way that both need to have it." so yes, our docs require that to pun both accesses have to have the union visible in the access path so lzo should be fixed. Still I argue in PR92152 that the way our implementation works (assigning the alias-set of the union to component refs of it) should make such reads possible and the new path-based disambiguation code is the one "breaking" it. Note the PR92152 case is two things, a redundant store removal (based on same alias-set) and then a followup CSE based on that path-based disambiguation breaking that. I see no way to preserve redundant store removal involving unions when we not make the path based disambiguation "behave". Of course I don't want to relax our written stmt about type punning since the implementation might change (consistently) "back" to not allow it by design.
