From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27471 invoked by alias); 24 Sep 2004 23:24:08 -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 27457 invoked by uid 48); 24 Sep 2004 23:24:07 -0000 Date: Fri, 24 Sep 2004 23:24:00 -0000 Message-ID: <20040924232407.27456.qmail@sourceware.org> From: "mmitchel at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040923214524.17642.schnetter@aei.mpg.de> References: <20040923214524.17642.schnetter@aei.mpg.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/17642] [4.0 Regression] internal compiler error: in invert_truthvalue, at fold-const.c:2997 X-Bugzilla-Reason: CC X-SW-Source: 2004-09/txt/msg03075.txt.bz2 List-Id: ------- Additional Comments From mmitchel at gcc dot gnu dot org 2004-09-24 23:24 ------- Andrew's analysis is overly simplistic. During the initial parsing of templates, we build up trees which do not obey the GCC tying rules to represent the users input. At template-substitution time, they are converted so that they do follow those rules. Unfortunately, we sometimes call "fold" during the initial parsing phase from build_binary_op. It's not clear if this is necessary. It is clearly that constant-expressions (like "6 - 4") must be resolved at template parse time. The addition of the assert in fold is causing the compiler to crash. It is quite probable that if the compiler merely did not assert that by the time this code was ever presented to the gimplifier all the types would be correct. In the long run, we want to avoid calling "fold" at all, except on integral constant-expressions. In all other cases, we should just let the optimizers do their thing. That would make the front end both simpler and faster. However, that's not pratical for 4.0. I will experiment with turning off the call to "fold" in build_binary_op, but I suspect that we many need to remove the assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17642