Kazu Hirata <[EMAIL PROTECTED]> 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
