This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Our release cycles are getting longer
- From: Marcin Dalecki <martin at dalecki dot de>
- To: Michael Veksler <mveksler at tx dot technion dot ac dot il>
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, David Carlton <david dot carlton at sun dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 24 Jan 2007 11:08:30 +0100
- Subject: Re: [RFC] Our release cycles are getting longer
- References: <200701240416.l0O4GlDJ001172@localhost.localdomain> <45B722F8.2010308@tx.technion.ac.il>
WiadomoÅÄ napisana w dniu 2007-01-24, o godz10:12, przez Michael
Veksler:
Andrew, you are both correct and incorrect. Certainly,
deterministic unit testing
is not very useful. However, random unit testing is priceless. I
have been doing
pseudo-random unit tests for years, believe me it makes your code
practically
bug free.
However the problem with applying this kind of methods to GCC would
actually be finding
the units inside the spaghetti. Even a curious look at for example
how -ffast-math works
did give me recently a run from the compiler 'driver' down to the c4x
back-end.
An trivial attempt at doing something about it resulted in a request
for a "full
bootstrap without regressions" for a platform:
1. which can't be bootstrapped at all
2. can't by nature run the test-suite
3. isn't in good shape overall.
Thus the small bolt against a layering violation will remain simply
unplugged.
The intention was of course to look at how move stuff, which simply
doesn't belong to the scope of a compilation unit a bit more in the
direction
of the #pragma level. There is after all enough of stuff sitting
inside bugzilla, that
actually pertains to a request for a #pragma STDC_C99 implementation.
That was a code path example. I'm not going to start about the data.
The polymorphism by preprocessor macro/GTY fun of some(all?) crucial
data types
makes me think that the whole MFC stuff looks sleek and elegant...
â Marcin Dalecki â