Re: [PATCH][SH] Ensure that offset alignments are valid

[Andrew STUBBS <andrew dot stubbs at st dot com>]

Kaz Kojima wrote:
> We should apply the above patch together with the tweaks of
> affected testcases, shouldn't we?  I'm afraid that applying
> the patch alone surprises people who run build/tests for
> multiple targets including SH.

OK, I'm working on it.

Unfortunately I've found a problem with the patch. It works fine when 
the offset is a known value, but there is a problem when it is not 
known, as in the too_large.c test.

The exact behaviour is different with and without relaxation.


Without relaxation:

The old behaviour was just "pcrel too far", so this might be OK.

$ as-new too_large.s -big -isa=sh4a
too_large.s: Assembler messages:
too_large.s:11: Error: negative offset
too_large.s:11: Error: pcrel too far
too_large.s:25: Error: negative offset
too_large.s:25: Error: pcrel too far
too_large.s:32: Error: negative offset
too_large.s:32: Error: pcrel too far
too_large.s:39: Error: negative offset
too_large.s:39: Error: pcrel too far


With relaxation:

The old behaviour was a successful operation with no diagnostics, so 
this clearly does need fixing.

$ ./as-new too_large.s -big -isa=sh4a -relax
too_large.s: Assembler messages:
too_large.s:25: Error: offset to unaligned destination
too_large.s:32: Error: offset to unaligned destination
too_large.s:39: Error: offset to unaligned destination


I'm not sure what the proper way to fix this issue should be. I'm going 
to keep looking into it, but do you have any clues?

I never saw this problem before because the compiler does not (usually?) 
produce PC-relative code with far destinations, and anyway relaxation is 
broken elsewhere, I think.

Andrew