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

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

[Zack Weinberg]

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 14:43:11 -0700

 On Mon, Apr 22, 2002 at 06:04:39PM +0100, Neil Booth wrote:
 > 
 > I meant using precision based on the target, not the host.
 
 Oh, right.  We could now do the "mask to correct size" trick; I don't
 have any better ideas short of a real arbitrary-precision library
 (which we need eventually but I'm not going there just now).
 
 > 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.
 
 I believe we ought to be able to do most of it by adding entries to
 the options structure, which are set by cc1 during initialization.
 GDB needn't bother initializing them, since it only needs the macro
 expander, and it will have the target-dependent macro values right
 there in the debug information.
 
 zw
 

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

[Kaveh R. Ghazi]

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

From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: zack@codesourcery.com
Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org, neil@daikokuya.demon.co.uk
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 15:43:30 -0400 (EDT)

  > From: Zack Weinberg <zack@codesourcery.com>
  > 
  > On Sun, Apr 21, 2002 at 06:24:15PM -0700, Zack Weinberg wrote:
  > 
  > > The cure is to call convert() to the proper type from lex_charconst,
  > > instead of just smashing the type field.  I am bootstrapping the
  > > appended change now.  If you could test it on solaris, I'd appreciate
  > > it.
  > 
  > Here's testsuite results for i686-linux (3.1 branch).  I believe
  > they indicate no new regressions for this change.
  > zw
 
 
 Bootstrap with your patch and a testsuite run completed on solaris2.7,
 no regressions and the charconst.c test now passes.  Thanks Zack!
 
 		--Kaveh
 --
 Kaveh R. Ghazi			Director of Systems Architecture
 ghazi@caip.rutgers.edu		Qwest Global Services

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

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
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 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.

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

[Zack Weinberg]

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

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

[Zack Weinberg]

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

From: Zack Weinberg <zack@codesourcery.com>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org,
	neil@daikokuya.demon.co.uk
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:25:33 -0700

 On Sun, Apr 21, 2002 at 06:24:15PM -0700, Zack Weinberg wrote:
 
 > The cure is to call convert() to the proper type from lex_charconst,
 > instead of just smashing the type field.  I am bootstrapping the
 > appended change now.  If you could test it on solaris, I'd appreciate
 > it.
 
 Here's testsuite results for i686-linux (3.1 branch).  I believe
 they indicate no new regressions for this change.
 
 zw
 
                 === libstdc++-v3 tests ===
 FAIL: 26_numerics/c99_classification_macros_c.cc (test for excess errors)
                 === libstdc++-v3 Summary ===
 # of expected passes            372
 # of unexpected failures        1
 # of expected failures          25
                 === libjava tests ===
                 === libjava Summary ===
 # of expected passes            2075
 # of expected failures          18
 # of untested testcases         14
                 === gcc tests ===
 FAIL: gcc.c-torture/execute/20020307-2.c execution,  -O1 
 FAIL: gcc.c-torture/execute/20020307-2.c execution,  -O2 
 FAIL: gcc.c-torture/execute/20020307-2.c execution,  -O3 -fomit-frame-pointer 
 FAIL: gcc.c-torture/execute/20020307-2.c execution,  -O3 -fomit-frame-pointer -funroll-loops 
 FAIL: gcc.c-torture/execute/20020307-2.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
 FAIL: gcc.c-torture/execute/20020307-2.c execution,  -O3 -g 
 FAIL: gcc.c-torture/execute/20020402-1.c execution,  -Os 
                 === gcc Summary ===
 # of expected passes            18315
 # of unexpected failures        7
 # of expected failures          66
 # of unsupported tests          43
                 === g++ tests ===
                 === g++ Summary ===
 # of expected passes            7168
 # of expected failures          86
 # of untested testcases         9
 # of unsupported tests          3
                 === g77 tests ===
                 === g77 Summary ===
 # of expected passes            1468
                 === objc tests ===
                 === objc Summary ===
 # of expected passes            1036
 # of expected failures          6
 
 zw

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

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
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 07:53:19 +0100

 Zack Weinberg 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?
 
 Neil.

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

[Zack Weinberg]

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

From: Zack Weinberg <zack@codesourcery.com>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org,
	neil@daikokuya.demon.co.uk
Subject: Re: c/6300: [PATCH] sparcv9-sun-solaris2.7 gcc-3.1 C testsuite failure in gcc.dg/cpp/charconst.c
Date: Sun, 21 Apr 2002 18:24:15 -0700

 On Sun, Apr 21, 2002 at 06:11:36PM -0400, Kaveh R. Ghazi wrote:
 > Yes, however now it appears on plain sparc- targets, not sparcv9-
 > because of some config.guess hackery that was eventually reverted.
 > (See the 4/18 comment I added to the PR description field.)
 
 Thanks, I can reproduce it now.
 
 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.  No one will notice on a completely 32-bit platform,
 where sizeof(HOST_WIDE_INT) is equal to sizeof(target wchar_t) and
 therefore no truncation is necessary.  And no one will notice on a
 64-bit platform where wchar_t is equivalent to 'int', because in
 
 int c = L'yadda...';
 
 we'll think the constant is already the right width.  But
 sparc-sun-solaris2.7 has HOST_WIDE_INT == long long and WCHAR_TYPE ==
 long, which means we _do_ try to convert to int in the assignment and
 we _do_ notice that the constant doesn't fit in 32 bits.
 
 The cure is to call convert() to the proper type from lex_charconst,
 instead of just smashing the type field.  I am bootstrapping the
 appended change now.  If you could test it on solaris, I'd appreciate
 it.
 
 zw
 
 	* c-lex.c (lex_charconst): Call convert to get constant in
 	proper type; don't just smash the type field.
 
 ===================================================================
 Index: c-lex.c
 --- c-lex.c	20 Mar 2002 05:14:27 -0000	1.164.2.2
 +++ c-lex.c	22 Apr 2002 01:22:29 -0000
 @@ -1407,7 +1407,7 @@ lex_charconst (token)
       const cpp_token *token;
  {
    HOST_WIDE_INT result;
 -  tree value;
 +  tree type, value;
    unsigned int chars_seen;
   
    result = cpp_interpret_charconst (parse_in, token, warn_multichar,
 @@ -1415,7 +1415,7 @@ lex_charconst (token)
    if (token->type == CPP_WCHAR)
      {
        value = build_int_2 (result, 0);
 -      TREE_TYPE (value) = wchar_type_node;
 +      type = wchar_type_node;
      }
    else
      {
 @@ -1427,10 +1427,24 @@ lex_charconst (token)
        /* In C, a character constant has type 'int'.
   	 In C++ 'char', but multi-char charconsts have type 'int'.  */
        if (c_language == clk_cplusplus && chars_seen <= 1)
 - 	TREE_TYPE (value) = char_type_node;
 +	type = char_type_node;
        else
 - 	TREE_TYPE (value) = integer_type_node;
 +	type = integer_type_node;
      }
 - 
 +
 +  /* cpp_interpret_charconst issues a warning if the constant
 +     overflows, but if the number fits in HOST_WIDE_INT anyway, it
 +     will return it un-truncated, which may cause problems down the
 +     line.  So set the type to widest_integer_literal_type, call
 +     convert to truncate it to the proper type, then clear
 +     TREE_OVERFLOW so we don't get a second warning.
 +
 +     FIXME: cpplib's assessment of overflow may not be accurate on a
 +     platform where the final type can change at (compiler's) runtime.  */
 +
 +  TREE_TYPE (value) = widest_integer_literal_type_node;
 +  value = convert (type, value);
 +  TREE_OVERFLOW (value) = 0;
 +
    return value;
  }