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 15.43 schrieb Joel Sherrill:
> Ralf Corsepius wrote:
> > 
> > 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.
> > >

> > 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).
> I have a nagging feeling that this will only encourage the bitrot.
> Either the SH1 is supported or it isn't.  Hiding a broken CPU 
> in a t-rtems is just sweeping it under the rug. 
I know (Not worth mentioning the ppc :) )
> Ralf, do you remember how long it took to get all the x86 
> multilibs building because no target except i386-rtems built
> soft-float and all the p5, k6, athlon, etc variants?  I would hate
> to see the RTEMS community the only group reporting sh1 problems.
Well, though I share your view, I don't think it really matters for the
i386 nor for the SH, because the SH and the i386 already are in the
position you'd like to avoid.

The vast majority of SH/GCC-users currently probably are
SH3/SH4-linux-le endian users, which don't want to care about the SH1 or
SH2, similar as the vast majority of ix86 users don't want to care about
the i386/i486s without FPUs.

I.e. though I share your concerns and would actually be pleased not to
see this happen, Joern's proposal on the SH1 doesn't change much about
the SH1's actual situation.

However, I am very much concerned about a fact that is hiding inbetween
the lines: The GNU-toolchain in general is abandoning and letting (often
accidentially) rot more and more low-end targets in favor of focusing on
the "mass-mainstream" (Linux/desktop/workstation). As a consequence of
this, the embedded community will have to switch to commercial
toolchains. IMHO, this can't be in GCC's interest.


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