This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: "ways of accomplishing ... the basic goal"
- From: Karel Gardas <kgardas at objectsecurity dot com>
- To: lord at emf dot net
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Fri, 7 Feb 2003 15:13:00 +0100 (CET)
- Subject: Re: "ways of accomplishing ... the basic goal"
> Hold on there. Maybe (probably) I'm not reading you right.
>
> Let's suppose we wanted to make a massive test suite for a new C++
> parser using, say, the Debian source base.
>
> So, first we identify those packages that use C++.
>
> Then we pick a stable version of GCC to use as a baseline.
>
> Then try building everything. Just discard any packages that don't
> build.
>
> There's the test suite. Anything that doesn't build with the new
> parser is, until proven otherwise, a regression.
I'm afraid Tom, you don't understand. Small explanation: old parser was
more tolerant to some code which wasn't strickly ISO C++, while the new
parser correctly reports errors. So the problem will be that you'll end
with tons of regressions against new parser while the problem is in wrong
C++ code of compiled packages.
For example: I've cleanup MICO sources from warnings generated by -Wall
while using gcc2.95.4 few months ago, but since gcc3.x is _much_ more
close to ISO C++, my work don't end and I still have to fix some other
warnings which gcc2.95.4 doesn't report at all. That was situation in
gcc3.0-3.3. In gcc3.4 the new C++ parser was introduced so the cycle
repeat again...
And now imagine that some package maintainer is brave and uses -Werror as
a param for compilation...
Cheers,
Karel
--
Karel Gardas kgardas@objectsecurity.com
ObjectSecurity Ltd. http://www.objectsecurity.com