https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089
--- Comment #5 from dave.anglin at bell dot net --- On 2018-01-31 4:57 AM, aldyh at gcc dot gnu.org wrote: > I know nothing about the PA back-end, or whether E_VOIDmode is valid for > base14_operand, however... > > Before r196122, a VOIDmode would return the default value of false in > base14_operand, but when S?mode and D?mode's were collapsed with the > aforementioned patch, we started handling VOIDmode. This can trigger a > division by 0. The untested patch below fixes this problem: > > diff --git a/gcc/config/pa/predicates.md b/gcc/config/pa/predicates.md > index 4600f988c87..f7961cc7f88 100644 > --- a/gcc/config/pa/predicates.md > +++ b/gcc/config/pa/predicates.md > @@ -275,6 +275,7 @@ > case E_BLKmode: > case E_QImode: > case E_HImode: > + case E_VOIDmode: > return true; > > Again, I have no knowledge of the PA port, and I don't know if > pa_legitimate_address_p() is supposed to even handle E_VOIDmode. Thanks very much for debugging this. I believe base14_operand should return false for VOIDmode as we can't do a check on the offset value in this case. The general intent of the check is to ensure that a base14 offset is consistent with those allowed by the PA instruction set. Arbitrary offsets are only allowed for byte and half word accesses. For integer word, double word and floating point accesses both the address register and the offset must be appropriately aligned on PA. Thus, it is safest to return false for VOIDmode in this check. A patch to add a E_VOIDmode case returning false in base14_operand is okay. Dave
