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

Diego Novillo dnovillo@google.com
Sun Sep 21 16:50:00 GMT 2008

On Sat, Sep 20, 2008 at 04:41, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Fri, Sep 19, 2008 at 6:56 PM, Diego Novillo <dnovillo@google.com> wrote:
>> On Fri, Sep 19, 2008 at 12:55, Jakub Jelinek <jakub@redhat.com> wrote:
>>> On Fri, Sep 19, 2008 at 12:36:12PM -0400, Diego Novillo 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.
>>> C++ e.g. requires that char (c) is mangled differently from unsigned char
>>> (h) and signed char (a), it is a distinct type.
>> Thanks, that answer my question.
> I suggest that we move these kind of "special" types creation to the
> frontends and
> stream out the declaration for LTO to pick it up (so we can LTO between
> CUs that have different -fsigned/unsigned-char flags).  Likewise we need to do
> this for sizetype if we ever LTO Ada and C CUs for example.

This is not really possible because when lto1 runs, it needs to have a
unique version of char_type_node and the multiple .o files will
potentially have different versions of it.  In essence, char_type_node
needs not exist in GIMPLE or we have to standardize it to either
signed_char_type_node or unsigned_char_type_node.

So, when we go into GIMPLE, all the instances of char_type_node need
to be converted into unsigned_char_type_node or signed_char_type_node.
 This way different CUs can have different notions of char signedness
explicitly outlined in the IL.

Ideally, we would do this very early (as soon as the whole CU is in
GIMPLE form).  In practice, mangling gets in the way and other FE
interactions are causing random build failures, so for now I will
probably push this fairly late (when GIMPLE is being streamed out).


More information about the Gcc mailing list