Re: c/6300: [PATCH] sparcv9-sun-solaris2.7 gcc-3.1 C testsuite failure in gcc.dg/cpp/charconst.c

[Zack Weinberg <zack@codesourcery.com>]

The following reply was made to PR c/6300; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, 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