This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]