C/C++ FEs: Do we really need three char_type_nodes?

[Andrew Thomas Pinski]

Yes char, unsigned char and signed char are three distant types.  
Unlike the other interger types in C/C++. That is they are  
incompatable types.

Thanks,
Andrew Pinski

Sent from my iPhone

On Sep 19, 2008, at 9:36 AM, "Diego Novillo" <dnovillo@google.com>  
wrote:

> When we instantiate char_type_node in tree.c:build_common_tree_nodes
> we very explicitly create a char_type_node that is signed or unsigned
> based on the value of -funsigned-char, but instead of make
> char_type_node point to signed_char_type_node or
> unsigned_char_type_node, we explicitly instantiate a different type.
>
> This is causing trouble in lto1 because when we stream out gimple,
> assignments between char and unsigned char go through without a cast.
> However, the LTO front end has no knowledge of the C/C++ FE flags, so
> it creates a signed char_type_node.  This causes a SEGV in PRE because
> the assignment between char and unsigned char confuses it.
>
> This is trivially fixable by making char_type_node be 'unsigned char',
> so that when we stream out the types for the variables the types are
> explicitly signed or unsigned, instead of taking its sign implicitly
> from an FE flag.
>
> @@ -7674,12 +7713,8 @@ build_common_tree_nodes (bool signed_cha
>   unsigned_char_type_node = make_unsigned_type (CHAR_TYPE_SIZE);
>   TYPE_STRING_FLAG (unsigned_char_type_node) = 1;
>
> -  /* Define `char', which is like either `signed char' or `unsigned  
> char'
> -     but not the same as either.  */
> -  char_type_node
> -    = (signed_char
> -       ? make_signed_type (CHAR_TYPE_SIZE)
> -       : make_unsigned_type (CHAR_TYPE_SIZE));
> +  /* Define `char', which is like either `signed char' or `unsigned  
> char'.  */
> +  char_type_node = signed_char ? signed_char_type_node :
> unsigned_char_type_node;
>   TYPE_STRING_FLAG (char_type_node) = 1;
>
>   short_integer_type_node = make_signed_type (SHORT_TYPE_SIZE);
>
> However, this has other side effects in the FE, as we now can't build
> libstdc++ (a PCH failure).  So, do we really need a third, distinct,
> char_type_node?  Is there some language or FE rule that causes us to
> do this?  The comment in build_common_tree_nodes is not very
> illuminating.
>
> I could fix this in a slower way by crawling through the whole
> callgraph and changing 'char' to 'unsigned char' everywhere once the
> whole compilation unit is in GIMPLE form, but I'd like to consider
> doing that only if it's really necessary.
>
>
> Thanks.  Diego.