https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #9 from Matthew Fortune <matthew.fortune at imgtec dot com> --- (In reply to Eric Botcazou from comment #8) > > 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. Sure, and in this case there are no implicit extensions to larger types. The bug does require an implicit extension to occur but this only happens at runtime when on 64-bit hardware and the core is not configured to be limited to a 32-bit address space which is always true for a 64-bit kernel as it turns out. > > 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. I'm leaning heavily towards not-a-compiler-bug but may need to offer a workaround until we can solve this in the Linux kernel. The only workaround possible is to provide an option to disable register+index addressing i.e. remove [ls][wd]xc1 instructions.
