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)


I'd like to add my 2 cents, as I've done a fair share of work on cpp.

Per Bothner wrote:-

> So we have some options:
> (1) Merge #cpp into the gcc-1 version of tradcpp.c.  This is probably
> a lot of work.

This is the direction I prefer.

> (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.

I don't think any of us really wants this.

> (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.

I cannot stress how strongly I feel that this is the worst option.  On
a scale of 0 to 10 I would rate it minus 10.  We are moving towards a
fully integrated preprocessor / C compiler combination, based on
*tokens* not text, with the beginnings of precompiled headers on the
horizon.  This would practically put us back to square 1.

> (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.

This doesn't look popular.

> 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.

So.  I'm prepared to do the work to introduce assertions to tradcpp to
either match the current implementation in cpp0 or the one in 2.95.2.
I cannot believe it would be too hard.

However, I will only commit my time to do this if we agree now on
doing absolutely *nothing* to cpp0.  cpp0 works on tokens, not text.
It lexes tokens the C way.  It does not preserve the form of
whitespace.  Double dots with a space between them is the least of
your problems trying to put Makefiles through it or languages other
than C derivatives and assembler.  I am extremely against anything
done to cpp0 that encourages such abuse.

Also, I do not have access to my machine for about 3 wks over
Christmas, though if given the go ahead I would hope to have this
finished by then.

Neil.


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