https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > The expansion looks like an acceptable transformation to me i.e. it is not > introducing the overflow for the offending pointer just maintaining what is > already in the tree. Wrap around for unsigned types is OK but, if expansion does implicit extensions to larger types, then things can easily go wrong. > I'm still not sure if there is really a bug. Should reassoc not be doing > this for 'sizetype'? Should ivopts not have created the mess in the first > place? Would changing either of these actually introduce an assurance that > this situation won't occur from other optimisations? sizetype is unsigned so all the transformations looks valid.