PATCH for m68k port

[Michael Sokolov]

Will Cohen <wcohen@redhat.com> wrote:

> Has anyone built gcc with "--target=m68k-elf" lately?  I tried and the
> build fails when trying to build some libraries. For the devo-based
> compiler the following error message is produced when it attempts to
> compile libgcc1-test.c:
>
> /tmp/ccYkkDFu.s:389: Error: Value of -830 too large for field of 1 bytes
> at 829
> /tmp/ccYkkDFu.s:389: Error: Value of -856 too large for field of 1 bytes
> at 855
> /tmp/ccYkkDFu.s:389: Error: Value of -882 too large for field of 1 bytes
> at 881
> /tmp/ccYkkDFu.s:389: Error: Value of -908 too large for field of 1 bytes
> at 907
> /tmp/ccYkkDFu.s:389: Error: Value of -934 too large for field of 1 bytes
> at 933

I know, I'm working on a fix.

> I have tracked this down to the jbsr statement like the following:
>
>         jbsr foo        | 8     *m68k.md:6875

Which is correct.

> The assembler is attempting to generate PC relative short versions of
> the JSR instruction with 8-bit PC relative addressing.

Which is also correct in this case, as the target of the jbsr is close enough.

The real source of the problem is elsewhere, see my recent postings on the
binutils list. The gas bug that is the real root of the problem has been there
since the start of sourceware binutils (May 1999) as far as I could tell, but
it has been brought to light and made visible on compiler-generated code with
some of my gas changes from September 2000.

> I found that gas
> has a "-S" option to force the generation of the long version of the
> instruction.

Yes, but one shouldn't use it. One should use relaxable mnemonics like jbsr and
let the assembler pick the shortest and most efficient form automatically.

> I have a patch for gcc which fixes this problem.  I have attached the
> patch to this email and the changelog entry is below:
>
> 2001-02-23  Will Cohen  <wcohen@redhat.com>
>
>         * config/m68k/m68k-none.h (ASM_SPEC): Added "-S" option.
>
> Is it okay to apply this patch?

I don't have authority to approve or reject patches, but this patch is wrong.
We need to fix the bug in gas, not paper over it in gcc.

-- 
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)