Fix string merging problems on mips*-linux-gnu

[Richard Sandiford]

Ian Lance Taylor <ian@wasabisystems.com> writes:
> Richard Sandiford <rsandifo@redhat.com> writes:
>> The patch makes sure that all references of the form "string_constant +
>> offset" refer to a character within the string.  Bootstrapped &
>> regression tested on mips64{,el}-linux-gnu, fixes the two test cases.
>> Also tested on mips64vrel-elf to verify the mips16 change.  Does it
>> look OK?
>
> I notice that you fixed this in backend code.  Isn't this sort of
> patch likely to be needed on other systems as well?

Probably.

> Is there something special about the MIPS target which causes it to
> generate out-of-bounds string-constant+offset references?

Not as far as I know.  On the other hand, the check I added isn't
entirely target-independent.  It's checking both for:

  (const (plus (symbol_ref ...) (const_int ...)))

(which might be useful for all targets) and:

  (lo_sum ... (const (plus (symbol_ref ...) (const_int ...))))
  (lo_sum ... (const (plus (unspec [(symbol_ref ...)] ...) (const_int ...))))

(which are somewhat mips-specific).  The problem is that different
targets have different ways of representing certain kinds of access.
It's not easy to handle this entirely in target-independent code.

That said, I guess the first form could be checked in a target-independent
way.  But there doesn't seem to be any precendent for that.  It's all
left up to GO_IF_LEGITIMATE_ADDRESS.

[ Not that that's a good reason to keep the current set-up, of course.
  But if it is changed, it might be nice to do it as part of some bigger
  revamp of the address-handling machinery.  One that aims to commonize
  the handling of simple addressing modes.

  Of course, I could well be talking rubbish here. ;) ]

I guess a compromise would be to add a target-independent
function like:

    bool symbol_offset_ok_p (rtx symbol, HOST_WIDE_INT offset);

and call it from the appropriate place in each back end.
Other ideas?

Richard