From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32636 invoked by alias); 22 Apr 2002 17:06:09 -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 32563 invoked by uid 71); 22 Apr 2002 17:06:06 -0000 Date: Mon, 22 Apr 2002 10:06:00 -0000 Message-ID: <20020422170606.32557.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Neil Booth Subject: Re: c/6300: [PATCH] sparcv9-sun-solaris2.7 gcc-3.1 C testsuite failure in gcc.dg/cpp/charconst.c Reply-To: Neil Booth X-SW-Source: 2002-04/txt/msg01116.txt.bz2 List-Id: The following reply was made to PR c/6300; it has been noted by GNATS. From: Neil Booth To: Zack Weinberg 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 18:04:39 +0100 Zack Weinberg wrote:- > > 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. I meant using precision based on the target, not the host. > 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. Do you have any ideas about handling target-dependence in cpplib? Whatever we do, I hope we can contain it to a single, probably new, file. Neil.