Re: Obsoleting c4x last minute for 4.0

[Richard Sandiford <rsandifo at redhat dot com>]

Kazu Hirata <kazu@cs.umass.edu> writes:
> I would like to propose that the c4x port be obsoleted for 4.0.
>
> c4x-*
> tic4x-*
>
>   The primary reason is that the port doesn't build.
>
>   Richard Sandiford's recent patch allows us to go further during the
>   build process, but the port still does not build.
>
>     http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01840.html
>
>   I've filed the current build problem as PR 20765.

I'd like to see us keep the port.  It's the only CVS example of
BITS_PER_UNIT != 8 and provides a canonical example of how such
a target should be handled.

I'm worried that removing the port will open the floodgates for
an across-the-board BITS_PER_UNIT == 8 assumption.  And that would
be a shame considering that the infrastructure for other settings
is there, and is more-or-less working.

Or to put it another way: the reason for deprecating most ports
is that having unmaintained, uncared-for ports doesn't help most
gcc developers and adds to the general maintenance burden.
But in this case, I think it's _useful_ to have c4x around.
It exercises functionality that isn't otherwise used, but is
supposed to be supported by the middle-end, and which is very
useful to have in theory.  And I don't really think having the
c4x port in CVS makes gcc significantly harder to maintain.

FWIW, you should be able to get a clean build by adding:

   LIB2ADDEH=

to t-c4x.  That's what I did when testing the c4x options transition.
And -- guessing wildly here -- I imagine that unwinding matters
little to the typical c4x user.  If we want c4x targets to build
from CVS, perhaps we could consider that as a workaround for your PR?

As for the failure itself: I think it exposes a deeper problem.
The build fails because unwind.h uses __attribute__((mode(DI)))
to get a 64-bit type.  But I don't think users should have to
know about, or care about, GCC's internal mode names.  It would
be much better to provide something like:

    unsigned int foo __attribute__((scalar_size(64)))

as an alternative to:

    unsigned int foo __attribute__((mode(DI)))

FWIW, I've got plans to implement something along those lines,
and hopefully fix your PR as a side-effect.  I need to finish
the .opt transition first though.

Richard