https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #16 from Peter Bergner <bergner at gcc dot gnu.org> --- (In reply to Bill Schmidt from comment #14) > We should definitely not be allowing the AltiVec "& ~16" flavors into these > patterns. I'm not certain whether your fix is the best way to achieve that, > but it could well be; I'll defer to Segher on that. So I _think_ the patch above is correct. Ie, we shouldn't split the insn which calls the rs6000_emit_le_vsx_* functions if the mem address isn't valid for the patterns the splitter is going to create. The question I have is, there are 2 expanders which I think we also need to guard with similar tests. They are vsx_load_<mode> and vsx_store_<mode>. Segher, I assume we want to verify we don't have an altivec style & ~16 address there too, correct? Just like we do in vector.md's mov<mode> pattern.