------- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-14 15:58 ------- > Volker, you seem to be on a quest to make gcc accept without crashing even > the most obnoxious wrong code snippets without ICEing.
I wouldn't say that they're "obnoxious" ;-) These code snippets are usually only one bug away from valid code. > How do you generate all these snippets? By sheer determination. I pick some topic like pointers-to-members or destructors for example and try to find some bugs. Over time you get a good feeling for GCC's weaknesses (templates for example). Well, okay, maybe those code snippets are "obnoxious". > (As a sidenote, even if they are technically regressions, I don't consider > such artificial codes really important to fix. There are more important > things, and we get this right for gcc 4.6.2, that'll be ok with me as well :-) Of course they are less important than wrong-code, ice-on-valid and rejects-valid bugs. OTOH, it's a matter of QoI. The sheer number of such little bugs makes them a real problem. Two examples: * If you use the compiler in education, you want a bullet-proof compiler and not a compiler that falls flat on its face when being confronted with silly mistakes. * Many people learn programming languages by throwing code at the compiler rather than checking it out first in the standard (which does make sense given the size and readability of the standard). If it doesn't compile one can still look what went wrong (given a good error message). A compiler that accepts invalid code will generate bug reports "this used to compile with gcc x.y.z!" one release later. A compiler that just crashes without sensible error messages isn't very helpful at least. In order to make GCC the best compiler around, we should get rid of these little pesky bugs. The new C++ parser has been merged over two years ago. Most of the dust should have settled by now. So to me the time seems to be right to do some clean-up. > W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253
