build regression

Alexandre Oliva aoliva@redhat.com
Mon Jun 16 20:22:00 GMT 2003


On Jun 16, 2003, Neil Booth <neil@daikokuya.co.uk> wrote:

> I disagree.  You might have a point if there were, say, one or two
> dozen switches where this was the case.  However, it appears that
> there are just these two, and the difference is not even user-visible.

No.  There are just these two in the front ends that are part of the
GCC CVS tree.  There are a few front-ends, however, that are not part
of this CVS tree, that are drop-in, and those command line options I
have no knowledge about.

> Allowing front ends to specify options that are different in bahaviour
> to other front ends is, IMO, a bad idea.

I agree, but there's no coordination here: we don't (and can't)
require external front-ends to register with us their intentions of
using certain options in certain ways.  Independent concurrent
developments might choose to use the same switch in different ways.
Why should we privilege one over another.

> However, what I like least about your proposal is that it would prevent
> me from achieving what is probably the main goal of my option rewrite.

I like very much the goal of your rewrite, but I don't like the
disregard to front ends that may be outside our CVS tree.  Maybe my
attitude is too extreme in that I tend to prefer coping with a
potential problem than trying to figure out whether it is an actual
problem and whether forcing the problem situations to adapt would be a
big deal.  I tend to take a more conservative approach, of assuming
that there will be cases in which the conflict cannot be easily
overcome.  The conflict between C/C++ and Java and the IMHO hackish
solution to it may be just the first of a sequence of such hacks, that
will end up giving us a more solid core with a mess just above it.
I'm not sure that's the best way to go.

Ideally, I'd like to enable each language to have a say on whether a
flag takes arguments or not.  You seem to claim this shouldn't happen,
but the fact that it has already happened, and in the very core of GCC
(our CVS repository), is an indication to me that it will happen
again, and we should step back and try to engineer a solution that
will handle such conflicts gracefully.  Coming up with a design that
has very nice properties indeed, but that fails to model the world
we're in, then beating the world into fit the design, is not the way I
like to do it, which is why I brought up my personal opinion.  Since
you're the official maintainer of this piece of code, you're entitled
to take it into account or not.  Or maybe you've already taken it into
account and decided it was not worth trying to handle.  Your surprise
at the encounter of different behaviors for -MD seems to indicate you
didn't even know about it, though, so maybe there wasn't enough
research put into the problem before a design was come up with.  If it
turns out that this is the only case of conflict, considering GCC as
in CVS in addition to all front-ends that are not here, proceeding
with the current approach is probably best.  Otherwise, I think we
should step back and consider (just consider) some alternative design
that would enable us to address conflicts between front-ends more
gracefully.

> I want to be able to *decode* all switches before *handling* any of
> them, and to do this switch decoding has to be language and target
> independent

I don't understand why decoding has to be language and
target-independent in order to be able to decode before handling.
Could you please explain it to me?  Please start by describing whether
you're talking about option handling in the compiler driver, in
front end actual compilers, or both.

> I have re-engineered it

You mean, after your initial design, or after encountering the -MD
conflict?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer



More information about the Gcc mailing list