This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro
- To: craig at jcb-sc dot com
- Subject: Re: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 03 Jun 1999 21:42:10 -0600
- cc: donn at interix dot com, ehr at listworks dot com, mark at codesourcery dot com, egcs-patches at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <19990604020612.18180.qmail@deer>you write:
> gcc should not be considered a tool that provides drop-in replacement
> for any arbitrary target architecture's "native compiler". Heck,
> some target architectures have no real concept of a *single* native
> compiler.
Exactly. A "drop-in" replacement for system compilers has never been a goal of
gcc. However, generating code compatible with the system compilers has always
been a goal. Sometimes folks miss the difference.
-fcompat switch really isn't something we want -- from an ABI standpoint we
generally want gcc to be compatible and thus the switch would have nothing to
do.
> But, of course, someone who wants to *write* a tool (called something
> other than gcc) that provides that kind of drop-in facility can certainly
> use gcc as a component.
Yup. I've written a few myself over the years. Mostly to help with the
conversion of 4.3bsd/4.4bsd, stunos and hpux systems to use gcc as the one
true compiler to rebuild the entire system from source.
It's not hard, mostly just switch manipulation/additions. Over time the amount
of things those front-ends had to do became smaller and smaller as the
various code bases became more gcc friendly (particularly 4.3/4.4).
jeff