This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
C/C++ FEs: Do we really need three char_type_nodes?
- From: "Diego Novillo" <dnovillo at google dot com>
- To: gcc at gcc dot gnu dot org
- Cc: "Jason Merrill" <jason at redhat dot com>, "Mark Mitchell" <mark at codesourcery dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Fri, 19 Sep 2008 12:36:12 -0400
- Subject: C/C++ FEs: Do we really need three char_type_nodes?
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.