This is the mail archive of the
mailing list for the GCC project.
Re: [patch] config.gcc: Obsolete c4x.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ralf Corsepius <ralf dot corsepius at rtems dot org>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Kazu Hirata <kazu at cs dot umass dot edu>, GCC Patches <gcc-patches at gcc dot gnu dot org>, m dot hayes at elec dot canterbury dot ac dot nz, Joel Sherrill <joel dot sherrill at OARcorp dot com>
- Date: Tue, 3 May 2005 16:51:05 +0000 (UTC)
- Subject: Re: [patch] config.gcc: Obsolete c4x.
- References: <firstname.lastname@example.org> <42702A83.email@example.com> <firstname.lastname@example.org> <42779D95.email@example.com> <firstname.lastname@example.org>
On Tue, 3 May 2005, Ralf Corsepius wrote:
> 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").
It's a regression, but not a release-critical one. You can fix
regressions on any target or language (not just primary and secondary
targets) at any point until the release branch is frozen; indeed for minor
targets you have *more* freedom, not less, to do potentially risky patches
to the back-end files to fix what might not strictly be regressions,
simply because if you break that back end not many users will be affected.
In contrast people changing the i386 back end at a late point in the
release cycle to fix a regression need to be much more careful about any
other problems their changes might cause.
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
email@example.com (personal mail)
firstname.lastname@example.org (CodeSourcery mail)
email@example.com (Bugzilla assignments and CCs)