Re: [patch] config.gcc: Obsolete c4x.

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On Tue, 2005-05-03 at 17:32 -0700, Mark Mitchell wrote:
> Ralf Corsepius wrote:
> >>I've taken a position on obsoleting C4X, but I've not taken one on the 
> >>QImode issue.  To equate the two is unfair.
> >  
> > I disagree.
> 
> I don't know where to go from here.  I guess we just disagree.
> 
> Fundamentally, we can just give the stock answer: if you care about C4x 
> support, then you can maintain the C4x port or pay someone to do so.
No disagreement so far.

> Otherwise, it will rot.
Disagreement at this point:

My opinion:

* If the C4x stays, it will rot.

* If the C4x will be removed, you are substantially reducing
opportunities to fix it. As the C4x's QImode is different from all other
targets in GCC, this is equivalent to announcing "QImode!=8bits" dead in
GCC.

IMHO, the second alternative is worse and isn't helpful to GCC in
general.

> >>there are no other ports, then non 8-bit QImode is not a terribly 
> >>important thing to test.  Are you about to contribute and maintain a 
> >>port that uses this functionality?  If so, great.  If not, what exactly 
> >>are we worried about?
> > 
> > Code clarity in RTEMS, newlib and applications.
> 
> Code clarity in these applications is dependent on GCC having a port 
> with QImode != 8 bits? 

Yes - The vast majority of all currently existing code isn't even aware
about this problem and implications resulting from this.

>  Or a port with CHAR_BITS != 8?
Also this, plus short != 16bits and sizeof(int)=sizeof(float)=sizeof
(double)==1, ... plus conditional presence of fixed size types (int8_t,
int16_t) etc. etc.

The list of implications the C4x imposes is quite lengthy ... and has a
quite substantial impact on code, esp. on low level code, such as OS
code e.g. RTEMS's code. As RTEMS had been used on C4x's (I am not aware
of anybody currently actively using it on C4x's), we try to acknowledge
these implications.

> >>>I really don't know what broke the c4x, but I know that GCC's regression
> >>>processing policy is ignoring problems on "non-primary target" ("It's
> >>>not a regression, because it's not a primary target, therefore you are
> >>>closed out from fixing anything on during most stages of development").
> >>
> >>As Joseph has said, this statement is simply not true.
> > 
> > 
> > This does not match with my experience.
> > 
> > I have been frequently been facing situations, where PRs had been
> > postponed and ignored just because the target being affected is "not a
> > primary target" or "will not be fixed, because it is not a regression".
> 
> These issues apply to whether or not we consider a bug important for a 
> release.  It has nothing to do with whether or not you can fix the bug, 
> except that the latter criterion might prevent a bug from being fixed on 
> a release branch.

A problem is "important" to _you_ (FSF GCC leadership/maintainers) when
it is a "regression" according to _your_ definition. Your definition
doesn't necessarily match with ours nor with our (RTEMS) demands.

As a result of this, many of our problems appear not important to _you_,
so many of our problems end up being considered irrelevant and ignored
by you - We (RTEMS) are stuck in a vicious circle.

> > Just check bugzilla for my name and you'll find several PR pending
> > unfixed because of this. Some have fixes attached, some even are
> > trivially fixable ... 
> 
> Then, apparently none of the maintainers considered it worthwhile to 
> review and/or apply the fixes.
c.f. above. 

RTEMS is an "exotic" niche, our typical scenario is cross-compilation,
using newlib and one-tree style bootstrapping, we have some non-
mainstream targets in our "target portfolio". Furthermore, Joel and I
wrt. GCC are OS-maintainers and not target-maintainers.

I.e. we typically trip bugs which seem "extraterrestrial" and "corner
cases" to "mainstream maintainers".

All in all, this is a completely different situation than that of
"mainstream GCC developers".

> >> and SPARC are certainly not in the category,
> > 
> > The sparc was broken for all non-unix target throughout the whole
> > gcc-3.x series - gcc-4.0.0 is the first gcc since (IIRC) 3.2 which able
> > to build RTEMS for the sparc.
> 
> Well, "broken" is a pretty strong statement, seeing as we've built SPARC 
> Solaris compilers throughout that entire period.

Note that I said "non-unix targets". The problem with the sparc was it
having contained hard-coded assumptions on Solaris/SunOS - It might have
worked on Solaris/SunOS, but I know it did not work on most embedded
targets and even if it did, it probably was nothing but a lucky
accident. This is the reason why Joel, I and others had performed some
non-trival surgery on the sparc quite late in GCC-3.x -> 4.0
development.

Ralf