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

[Christian BRUEL <christian dot bruel at st dot com>]

hello,

The sh4 relaxation is indeed broken, we are still working on it to make 
it work. We have a set of patches to apply but we still have failures 
with switch tables.

Actually we was planning to wait the full validations (on applications) 
to pass before proposing patches but we could as well propose them 
separately if you need them to repair testsuite cases ?

Regards

Christian

Andrew STUBBS wrote:
> 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