This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: make sh-1 support in gcc obsolete?

Am Mit, 2002-05-29 um 14.13 schrieb Joern Rennecke:
> Ralf Corsepius wrote:
> [sh-1 is broken and sh-coff was broken]
> > This is sad to hear. I am inclined this qualifies to be a bug in GCC and
> > as a regression to gcc-2.95.x
> Yes.
> > No, this perspective doesn't match. The SH1/sh-coff is among the targets
> > RTEMS supports.
> Are there still people using it, apart from testing that it still works?
I don't know. Through past years, there have been several request and
apparent attempts to use it, but I don't know if they were successful
and if they are still actively used.

However, I assume the SH2-port in RTEMS (Which shares some code with the
sh1-port) to be used.

Your own (SH1) applications are frozen and have not been changed for
years, but our current policy is "if demands for changing them shall pop
up, these applications be revitalized" (They currently are in sort of a
stand-by-position. SH1 as controller on custom HW in $$$$$ mechanics)

> > RTEMS currently is in the process of switching to 3.1 (Still using
> > SH-coff, still supporting the SH1), so we probably will encounter the
> > problems you mention.
> Note that the assembler silently assembles the file as SH-2 code, and
> thus it is linked and run by the simulator as SH-2.  But tests on SH1 hardware
> can be expected to fail.

No surprize, the SH-Gnu-toolchain has repeatedly been in bad shape over
the years (And currently seems to be again. AFAIS, the SH code in
gcc-3.1 contains hard-coded references to ELF-specific code)

> If we want to continue to support SH-1, we should have the compiler pass an
> option to the assembler to limit the acceptable instruction set to the one
> being used, so that regressions are caught.  Otherwise, SH-2 instruction are
> just too likely to sneak back in. 
Sounds reasonable to me.

BTW: I have no problem if you'd like to abandon the sh1 multilib variant
from the SH default multilibs. We'd add an RTEMS-specific t-rtems to
implement RTEMS-specific multilib variants for the SH then (We already
do for some other targets).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]