This is the mail archive of the gcc@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: Mistaken change in GCC (fwd)


Joe Buck <jbuck@racerx.synopsys.com> writes:

> Dropping documented features can be done, but the SC must agree.  Zack,
> it's not your call.  (That doesn't mean that you, personally, have to fix
> it, but if every flavor of Emacs out there will break and it's a simple
> fix, let's just do it, OK?).

Some context:

The decision was made to implement -traditional in cpp by using a
separate traditional-cpp program when compiling with gcc -traditional,
while using cpplib in the normal case.  So it's not simply a question
of removing functionality; it is a question of duplicating
functionality.  The cpp maintainers decided to use the cpp from gcc 1
for traditional-cpp because it is relatively simle and compact, and
seemlingly provided the needed functionality - but is does not support
#cpu.

So we have some options:
(1) Merge #cpp into the gcc-1 version of tradcpp.c.  This is probably
a lot of work.
(2) Use a gcc-2 version of cccp.c (and other files, including cexp.y)
for tradcpp.c.  That does bloat the compiler distribution a bit, and
I guess it is more work than just dropping it in.
(3) Make cpplib support -traditional, removing the need for tradcpp.c.
That presumably makes cpplib more complex, bloated and slower.  In
principle I like this better than a separate tradcpp.c program - the
problem is how "more complex, bloated and slower" the merged program
would be, and to what extend those problems can be mitigated,  There
is also the problem of actually doing the work to make cpplib
implemented -traditional - support for -traditional was presumably
removed for a reason.
(4) Make a decision that #cpu is a little-used extension, and while
we will continue to support it, we will only do so when *not* using
-traditional.

Zack is basically saying (4), and there is something to be said for
that.  However, we have to weigh the problems of applications that
use the extension.  First, can the applications reasonably be fixed
to not need the extension, and secondly we have the problem of people
compiling existing or older releases.

I don't know what the answer is.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

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