This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Small update to reversed comparison code
- To: gcc at gcc dot gnu dot org
- Subject: Re: Small update to reversed comparison code
- From: Marc Espie <espie at quatramaran dot ens dot fr>
- Date: Wed, 28 Mar 2001 23:49:16 +0200
- Organization: Ecole Normale Superieure (quatramaran)
The subject of `latent bugs' in gcc caught my eyes.
Apart from the sticky subject of trying to get 3.0 out,
on which I support Mark Mitchell entirely, there is
an interesting problem being brought to light.
To put it frankly, this is dealing with gcc's robustness.
If some unrelated piece of code can trigger `latent bugs'
elsewhere, there is a large problem looming over the horizon.
The keyword `reload_cse' triggered a few reflexes as well.
>From what I've read in this mailing-list, it looks like the
reload routines are some untamed beasts that almost no-one knows
how to fathom... I recall seeing a few of the most knowledgeable
gcc developers arguing about what those functions were supposed
to be doing in a discussion a while back.
Of course, in a piece of software as large as gcc, `latent bugs'
triggered by other pieces do happen, but these should be regarded
as very valuable. Not only to fix, but also to try to find out
if something in the development process fostered that bug.
To me, these bugs are close parents of bugs that are triggered by
weird combinations of options, OR architectures that almost no-one
runs any longer, OR interesting cross-compiles combinations.
The parallel does not fully apply, but in another project, when we
find a bug and fix it, we try to generalize the bug, and find out
whether there is not a whole class of similar bugs lurking, or how
to avoid that error-prone constructs.
Another related point is that, sometimes, after a patch has been
sent to everyone and nobody has bothered to fix the bug, the last
way to force the issue is simply to commit the patch (and expose
the bug) so that suddenly, everyone becomes interested in fixing
it...
Seeing the way the interval between releases lengthens, and some
other similar indicators, I would tend to think that a `back to basics'
path of trying to increase the robustness of gcc may be a good
idea.
Of course, you should take what I say with a pinch of salt.
I don't have time to really know the internals of gcc well,
and I'm mostly speaking from my experience in other software projects.
My 2 cents...