[Bug middle-end/44871] New: Invalid type mismatches while merging C and C++ sources

[Bug middle-end/44871] New: Invalid type mismatches while merging C and C++ sources

[hubicka at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

jh@evans:/abuild/jh/mozilla-central/build6/gfx/harfbuzz/src>
/abuild/jh/trunk-install/bin/gcc  -O2 -fwhopr  -r -nostdlib hb-blob.i -c
jh@evans:/abuild/jh/mozilla-central/build6/gfx/harfbuzz/src>
/abuild/jh/trunk-install/bin/g++  -O2 -fwhopr  -r -nostdlib *.ii -c
jh@evans:/abuild/jh/mozilla-central/build6/gfx/harfbuzz/src>
/abuild/jh/trunk-install/bin/g++ hb-blob.o -O2 -fwhopr  -r -nostdlib hb-font.o
../../../../gfx/harfbuzz/src/hb-blob-private.h:53:60: warning: type of
‘_hb_blob_nil’ does not match original declaration [enabled by default]
../../../../gfx/harfbuzz/src/hb-blob.c:45:11: note: previously declared here


-- 
           Summary: Invalid type mismatches while merging C and C++ sources
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hubicka at gcc dot gnu dot org
  GCC host triplet: x86_64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources

[hubicka at gcc dot gnu dot org]

------- Comment #1 from hubicka at gcc dot gnu dot org  2010-07-08 13:31 -------
Created an attachment (id=21143)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21143&action=view)
first part of testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources

[hubicka at gcc dot gnu dot org]

------- Comment #2 from hubicka at gcc dot gnu dot org  2010-07-08 13:37 -------
Created an attachment (id=21144)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21144&action=view)
second part of testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2010-07-08 14:19 -------
Created an attachment (id=21145)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21145&action=view)
reduced testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-08 14:19 -------
Created an attachment (id=21146)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21146&action=view)
reduced testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug middle-end/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-07-08 14:47 -------
The C frontend for

  typedef struct {   hb_atomic_int_t ref_count; } hb_reference_count_t;

has an unnamed (NULL TYPE_NAME) main variant of hb_reference_count_t while
the C++ frontend does not have a main variant different from the type
with the typedef name.  That causes us to hash both types differently
(once with tag NULL and once with tag hb_reference_count_t).

Now, our current behavior is to allow C-only merging of 'struct Foo *x'
vs 'Foo_t *x' or 'stuct Foo x' vs. 'Foo_t x' in a structure.  We honor
a missing name as ok for merging but still hash in stuff (mostly to avoid
excessive collisions for pointer types).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-08 14:47:48
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug lto/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-07-08 15:32 -------
Testcase to illustrate C / C++ differences:

typedef struct { } T1;
typedef T1 T2;
void foo (T1 a, T2 b)
{
}

TYPE_MAIN_VARIANT of the type of a is T1 for C++, struct {} for C.
TYPE_MAIN_VARIANT of the type of b is T1 for C++, struct {} for C.

typedef struct X { } T1;
typedef T1 T2;
void foo (T1 a, T2 b)
{
}

TYPE_MAIN_VARIANT of the type of a is struct X {} for C++, struct X {} for C.
TYPE_MAIN_VARIANT of the type of b is struct X {} for C++, struct X {} for C.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug c++/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2010-07-09 12:42 -------
The hard part with changing the C frontend to behave like the C++ frontend
is to preserve the debug info for the typedef.

The C frontend consistently uses DECL_ORIGINAL_TYPE to refer to what a
TYPE_DECL was typedeffed to, but the C++ FE again does not use this
for typedef struct { } T1; (but it does for typedef struct X { } T1;).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|lto                         |c++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug c++/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-07-09 12:52 -------
The only difference I see for typedef struct { } T1; vs typedef struct X { }
T1;
when looking at its main variant (or recursively DECL_ORIGINAL_TYPE) is

 <type_decl 0x7ffff5b2be60 X
    type <record_type 0x7ffff5b31dc8 X type_5 QI
        size <integer_cst 0x7ffff7ed24b0 constant 8>
        unit size <integer_cst 0x7ffff7ed24d8 constant 1>
        align 8 symtab 0 alias set -1 canonical type 0x7ffff5b31dc8
        fields <type_decl 0x7ffff5b2bf18 X type <record_type 0x7ffff5b31e70 X>
            nonlocal decl_4 VOID file t.i line 1 col 18
            align 1 context <record_type 0x7ffff5b31dc8 X> result <record_type
0x7ffff5b31dc8 X>
           >
        full-name "struct X"
        X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
        chain <type_decl 0x7ffff5b2be60 X>>
    public decl_2 VOID file t.i line 1 col 16
    align 8 chain <function_decl 0x7ffff5b23e00 __cxa_call_unexpected>>

 <type_decl 0x7ffff5b43000 T1
    type <record_type 0x7ffff5b31dc8 T1 type_5 QI
        size <integer_cst 0x7ffff7ed24b0 constant 8>
        unit size <integer_cst 0x7ffff7ed24d8 constant 1>
        align 8 symtab 0 alias set -1 canonical type 0x7ffff5b31dc8
        fields <type_decl 0x7ffff5b2bf18 ._0 type <record_type 0x7ffff5b31e70
T1>
            nonlocal decl_4 VOID file t.i line 1 col 16
            align 1 context <record_type 0x7ffff5b31dc8 T1> result <record_type
0x7ffff5b31dc8 T1>
           >
        full-name "struct T1"
        X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
        chain <type_decl 0x7ffff5b2be60 ._0>>
    VOID file t.i line 1 col 20
    align 1 chain <type_decl 0x7ffff5b2be60 ._0>>

which is the difference in alignment, TREE_PUBLIC and decl_lang_flag_2 set
(DECL_IMPLICIT_TYPEDEF_P).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871

[Bug c++/44871] Invalid type mismatches while merging C and C++ sources

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2010-07-09 13:01 -------
The following seems to work at least for the testcase:

Index: gcc/tree.c
===================================================================
--- gcc/tree.c  (revision 161994)
+++ gcc/tree.c  (working copy)
@@ -4298,6 +4298,18 @@ free_lang_data_in_type (tree type)
     {
       tree prev, member;

+      if (strcmp (lang_hooks.name, "GNU C++") == 0)
+       {
+         /* If this isn't an implicit typedef then this final
+            non-typedef name is not a struct tag.  Clear its name.
+            See PR44871 for the glory details.  */
+         if (TYPE_NAME (type)
+             && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
+             && !DECL_ORIGINAL_TYPE (TYPE_NAME (type))
+             /* DECL_IMPLICIT_TYPEDEF_P */
+             && !DECL_LANG_FLAG_2 (TYPE_NAME (type)))
+           TYPE_NAME (type) = NULL_TREE;
+       }
       /* Note that TYPE_FIELDS can be shared across distinct
         TREE_TYPEs.  Therefore, if the first field of TYPE_FIELDS is
         to be removed, we cannot set its TREE_CHAIN to NULL.

it will wreck debuginfo for T1 of course.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44871