From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11799 invoked by alias); 14 Feb 2005 15:59:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 11759 invoked by uid 48); 14 Feb 2005 15:58:52 -0000 Date: Mon, 14 Feb 2005 20:21:00 -0000 Message-ID: <20050214155852.11758.qmail@sourceware.org> From: "reichelt at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050104143107.19253.reichelt@gcc.gnu.org> References: <20050104143107.19253.reichelt@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/19253] [3.4/4.0 regression] bad error message / ICE for invalid template parameter X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg01467.txt.bz2 List-Id: ------- 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