https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92925
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 10 Jan 2020, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92925 > > --- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > So we would probably need to add full misalignment information to MEM_ATTRS if > we want to handle this properly. So I wonder why we bother to feed 'bitpos' to set_mem_attributes_minus_bitpos when we expect the MEM_ATTRS to be created from solely 'T' (do we?) and then later apply 'bitpos' via adjust_address or friends. IIRC that set_mem_attributes_minus_bitpos adjusts the alignment gathered from 'T' with bitpos fixed some wrong-code bug at some point but somehow this really looks fragile or bogus to me. After all for the caller in question the actual MEM rtx does _not_ (yet) include 'bitpos'(?)
