From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19909 invoked by alias); 1 Aug 2006 18:28:06 -0000 Received: (qmail 19836 invoked by uid 48); 1 Aug 2006 18:27:58 -0000 Date: Tue, 01 Aug 2006 18:28:00 -0000 Message-ID: <20060801182758.19835.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mmitchel at gcc dot gnu dot org" 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 X-SW-Source: 2006-08/txt/msg00024.txt.bz2 List-Id: ------- Comment #15 from mmitchel at gcc dot gnu dot org 2006-08-01 18:27 ------- DJ -- Thanks for the detailed comments. I understand that the assertion is guarding against some cases where we may silently generate wrong code (as with the situation with pointers on the m16c). However, we're now in the situation where he have a mismatch between initializer_constant_valid_p and output_constant, which is a recipe for ICEs. It is a key invariant that anything accepted by the former be something that can be output by the latter. So, we need to figure out what to do. My tentative inclination, given where we are in the development cycle, is to remove your assertion. We will generate correct code much of the time (as, for example, in this test case, where zero-extension is fine). Another choice would be to reject this case as an initializer, which will result in QoI regressions where initializers are now performed dynamically instead of statically. I agree that your strategy of simplifying valid initializers to make them obviously valid is best -- but I'm not sure we can easily implement that. What do you think? -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724