On Mon, Apr 20, 2020 at 11:05 PM Jeff Law via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Mon, 2020-04-20 at 15:29 -0500, Joel Sherrill wrote:
> >
> >
> > On Mon, Apr 20, 2020, 3:13 PM Jeff Law <l...@redhat.com> wrote:
> > > On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote:
> > > > Hi
> > > >
> > > > Over at RTEMS, we were discussing ports to deprecate/obsolete
> > > > and the SH seems to be on everyone's candidate list. I can't seem
> > > > to find any gcc test results sh-unknown-elf since 2009 and none
> > > > for sh-rtems. I know I posted some but when, I can't say. But the
> > > > new mailing list setup may be messing that up. I expected more
> > > > recent results.
> > > >
> > > > (1) Is my search right? Have there been no test results in 10 years?
> > > >
> > > > (2) Is the toolchain in jeopardy?
> > > >
> > > > (3) I know there was an effort to do an open implementation with
> > > > j-core.org but there is no News or download item newer than 2016.
> > > > Is this architecture effectively dead except for legacy hardware out
> > > > in the field (Sega?)
> > > >
> > > > I'm leaning to RTEMS dropping support for the SH after we branch
> > > > a release and wondering if the GCC community knows anything that
> > > > I don't.
> > > I'm not aware of the SH toolchain being in any jeopardy.
> > >
> > >
> > > I'm doing weekly bootstrap (yes, really) & regression tests for
> > > {sh4,sh4eb}-
> > > linux-gnu and daily builds of {sh3,sh3b}-linux-gnu. See
> > >
> > > http://gcc.gnu.org/jenkins
> >
> > Awesome!
> > >
> > > The Linux kernel is currently broken, but I suspect it's a transient
> > > issue as
> > > it
> > > was fine until a week ago -- my tester usually builds the kernel too, but
> > > that's
> > > been temporarily disabled for SH targets.
> >
> > Thanks Jeff! Are you using the simulator in gdb? That's what we have a BSP
> > for?
> I'm using qemu -- it's user mode emulation is strong enough that I can create
> a
> little sh4 native root filesystem and bootstrap GCC within it.
>
>
> >
> > We build the cross RTEMS tools regularly on Linux, Mac, FreeBSD, Mingw, and
> > Cygwin. All of our BSPs build including sh1 and the odd sh2e.
> >
> > Our BSP status for the gdb simulator is unknown. We replaced a lot of
> > testing
> > infrastructure scripting and the SH hasn't gotten to the top of the list.
> ACK. In general, if there's a qemu solution, that's my preference these days.
> For the *-elf targets I usually have to fall back to the old gdb-sim bits.
>
> >
> > So we both are building a lot and making sure rot hasn't set in. But in
> > practice, is this worth the trouble anymore?
> I'm not sure about that ;-) I haven't seen anyone suggest removal of the
> port or
> anything like that. The port doesn't use CC0, so there's essentially zero
> chance
> it'll be deprecated for gcc-11. I believe the port is not using LRA, so
> if/when
> we move on deprecating reload, SH might be at some degree of risk.
There's two listed maintainers as well (albeit at their anonymous
gcc.gnu.org domain).
Richard.
> jeff
> >
>
