Re: [patch, mips] Fix for PR 54619, GCC aborting with -O -mips16

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Steve Ellcey " <sellcey@mips.com> writes:
> While building newlib with -O2 -mips16 I ran into a problem with GCC
> aborting due to the compiler trying to execute '0 % 0' in
> mips16_unextended_reference_p.  The problem was that the code checked
> for BLKmode and skipped the modulo operation in that case because
> GET_MODE_SIZE (BLKmode) is zero but it didn't check for VOIDmode whose
> size is also zero.  Rather then add a check for VOIDmode I changed
> the check to 'GET_MODE_SIZE (mode) != 0'.
>
> While looking at the code I also noticed that if offset was zero then
> we should return true even if mode is BLKmode or VOIDmode.  Returning
> false would not generate bad code or cause problems but returning true
> would result in better costing model in mips_address_insns so I made
> that change too.

This came in with the recent change to pass the mode to address_cost.
I hadn't realised when asking for the associated mips_address_cost change
that address_cost sometimes gets passed VOIDmode.

mips_address_insns shouldn't have to deal with VOIDmode.  The quick
hack I'd been using locally is to add:

  if (mode == VOIDmode)
    mode = SImode;

to mips_address_cost, which restores the previous behaviour for this case.
But the documentation says:

  This hook is never called with an invalid address.

Since VOIDmode MEMs aren't valid, I think that should mean it's invalid
to call this hook (and rtlanal.c:address_cost) with VOIDmode.  I never
got time to look at that though.  (The culprit in the case I saw was
tree-ssa-loop-ivopts.c.  Sandra had some improvements in this area,
so maybe they would fix this too.)

Loading or storing BLKmode doesn't map to any instruction, so I don't
think returning true for zero is any better than what we do now.

Richard