From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23862 invoked by alias); 27 Nov 2004 18:44:24 -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 23818 invoked by uid 48); 27 Nov 2004 18:44:20 -0000 Date: Sat, 27 Nov 2004 18:44:00 -0000 Message-ID: <20041127184420.23815.qmail@sourceware.org> From: "neroden at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040718223357.16621.steven@gcc.gnu.org> References: <20040718223357.16621.steven@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug preprocessor/16621] [4.0 Regression] C4x fails miserably X-Bugzilla-Reason: CC X-SW-Source: 2004-11/txt/msg03343.txt.bz2 List-Id: ------- Additional Comments From neroden at gcc dot gnu dot org 2004-11-27 18:44 ------- libcpp no longer uses HOST_WIDE_INT. The computation which leads to the error is done in c-decl.c in "target arithmetic" as follows: /* Compute the maximum valid index, that is, size - 1. Do the calculation in index_type, so that if it is a variable the computations will be done in the proper mode. */ itype = fold (build2 (MINUS_EXPR, index_type, convert (index_type, size), convert (index_type, size_one_node))); /* If that overflowed, the array is too big. ??? While a size of INT_MAX+1 technically shouldn't cause an overflow (because we subtract 1), the overflow is recorded during the conversion to index_type, before the subtraction. Handling this case seems like an unnecessary complication. */ if (TREE_OVERFLOW (itype)) { error ("size of array %qs is too large", name); type = error_mark_node; continue; } This looks OK. Steven, can you possibly check to see whether this bug still exists in mainline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16621