This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Converting GCC to compilation with C++
- From: "Gabriel Dos Reis" <gdr at acm dot org>
- To: "Richard Kenner" <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: joe dot buck at synopsys dot com, gcc at gcc dot gnu dot org
- Date: Wed, 14 Jul 2004 16:23:34 +0200 (CEST)
- Subject: Re: Converting GCC to compilation with C++
- References: <10407141222.AA21448@vlsi1.ultra.nyu.edu>
- Reply-to: gdr at acm dot org
Richard Kenner:
> Patches that use MI inappropriately would be rejected.
>
> I have serious trouble being confident of that. This is similar to
> our documentation requirements, that functions need to each have
> documentation on what they do and on the parameters. However,
> somehow we have picked up at least 100 functions that are not
> properly documented.
>
> Since each patch that adds functions is supposed to be reviewed, if
> the review process were effective in enforcing coding standards, this
> couldn't have happened. I also see dozens of places in the compiler
> where line breaks around operators (usually "=") aren't done according
> to our standards either.
It is ironic you should bring that. Our commit process requires
that you should do a bootstrap followed by regression testing
before the actual commit. But you manage to commit
un-regression-tested code more often than not.
Is your point that, if you, as a GCC maintainer with global
write priv, manage to knowingly commit untested code, then
MI should be left out? That would be cynic.
That logic would imply that any useful feature of C, as we currently
practice, should be rejected. Not just use of a C++ subset.
-- Gaby