From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 527 invoked by alias); 22 Apr 2002 07:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 513 invoked by uid 71); 22 Apr 2002 07:36:01 -0000 Date: Mon, 22 Apr 2002 00:36:00 -0000 Message-ID: <20020422073601.512.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Zack Weinberg Subject: Re: c/6300: [PATCH] sparcv9-sun-solaris2.7 gcc-3.1 C testsuite failure in gcc.dg/cpp/charconst.c Reply-To: Zack Weinberg X-SW-Source: 2002-04/txt/msg01101.txt.bz2 List-Id: The following reply was made to PR c/6300; it has been noted by GNATS. From: Zack Weinberg To: Neil Booth Cc: "Kaveh R. Ghazi" , gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: c/6300: [PATCH] sparcv9-sun-solaris2.7 gcc-3.1 C testsuite failure in gcc.dg/cpp/charconst.c Date: Mon, 22 Apr 2002 00:33:05 -0700 On Mon, Apr 22, 2002 at 07:53:19AM +0100, Neil Booth wrote: > > The problem is that cpp_interpret_charconst will happily pass back a > > value wider than the mode we actually want, as long as it fits in > > HOST_WIDE_INT. > > Thanks for figuring this out, Zack. However, this makes it sound > like the correct fix is in cpp_interpret_charconst, no? Is this > something that will get magically fixed when CPP arithmetic is done > properly? I'm not sure what you mean by "done properly". I see two latent bugs, both of which are straightforward to fix on the mainline, but neither is necessarily what you're thinking of. One is that we really need to get cpplib using accurate definitions for __WCHAR_TYPE__ etc. Currently the "character constant too long" warning issues based on MAX_WCHAR_TYPE_SIZE, which is incorrect if WCHAR_TYPE_SIZE happens not to be that big in the current run. This is not practical to fix on the branch, but easy on the mainline as long as we take care not to make it harder to separate the library so GDB can use it. The other is that truncation isn't happening as required when these constants are used in #if expressions. This could be fixed for the branch but I don't think it's worth it. Uses of multi-character character constants are rare, and programs that depend on their being truncated "properly" in #if expressions... well, I can't think of one that isn't a contrived example. zw