This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro



  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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]