[Bug c/41172] New: C frontend botches type.name for typedef chains
gcc version 4.5.0 20090825 (experimental) (GCC)
I found this bug while working on static analysis tools for Mozilla (using the
plugin framework), where we access |tree| structures in the cfg. (For
reference, this is also filed as
https://bugzilla.mozilla.org/show_bug.cgi?id=511261.)
Consider testcase.c:
typedef struct { int i; } foo_t;
typedef const foo_t bar_t;
bar_t func() { bar_t b; return b; }
Invoked via:
cc1 testcase.c
Then the |bar_t| return type of |func()| will have a null TYPE_NAME(). I proved
this by introducing a syntax error in the body of |func()| and breaking in
lhd_print_error_function() in gcc/langhooks.c:
Breakpoint 3, lhd_print_error_function (context=0x8ac2760,
file=0xb542
"/home/dwitte/builds/gcc-dehydra/dehydra/test/test_c_typedef_bug.c",
diagnostic=0xbfffeee4)
at ../../src/gcc/langhooks.c:349
349 {
(gdb) p current_function_decl->common.type->base.code
$21 = FUNCTION_TYPE
(gdb) p current_function_decl->common.type->common.type->base.code
$22 = RECORD_TYPE
(gdb) p current_function_decl->common.type->common.type->type.name
$23 = (tree) 0x0
If the |const| is removed from the definition of bar_t, things work fine:
(gdb) p
current_function_decl->common.type->common.type->type.name->decl_minimal.name.identifier.id.str
$25 = (const unsigned char *) 0xb7d6bc00 "bar_t"
If the return type of |func()| is instead |foo_t|, things also work:
(gdb) p
current_function_decl->common.type->common.type->type.name->decl_minimal.name.identifier.id.str
$26 = (const unsigned char *) 0xb7d6bbf8 "foo_t"
In addition, it's worth noting that the variant chain of the return type (in
the testcase as written) does include |bar_t|, as well as |foo_t| (twice), but
interspersed with null-named trees. This may or may not be relevant.
(gdb) p $rt = current_function_decl->common.type->common.type
$47 = (tree) 0xb7d7d7e0
(gdb) p $variant = $rt->type.main_variant
$48 = (tree) 0xb7d7d5b0
(gdb) p $variant->type.name
$49 = (tree) 0x0
(gdb) p $variant = $variant->type.next_variant
$50 = (tree) 0xb7d7d8c0
(gdb) p $variant->type.name
$51 = (tree) 0xb7d7d850
(gdb) p $variant->type.name->decl_minimal.name.identifier.id.str
$52 = (const unsigned char *) 0xb7d6bc00 "bar_t"
(gdb) p $variant = $variant->type.next_variant
$53 = (tree) 0xb7d7d7e0
(gdb) p $variant->type.name
$54 = (tree) 0x0
(gdb) p $variant = $variant->type.next_variant
$55 = (tree) 0xb7d7d770
(gdb) p $variant->type.name
$56 = (tree) 0xb7d7d690
(gdb) p $variant->type.name->decl_minimal.name.identifier.id.str
$57 = (const unsigned char *) 0xb7d6bbf8 "foo_t"
(gdb) p $variant = $variant->type.next_variant
$58 = (tree) 0xb7d7d700
(gdb) p $variant->type.name
$59 = (tree) 0xb7d7d690
(gdb) p $variant->type.name->decl_minimal.name.identifier.id.str
$60 = (const unsigned char *) 0xb7d6bbf8 "foo_t"
(gdb) p $variant = $variant->type.next_variant
$61 = (tree) 0x0
Note that the C++ FE gets this right. I'm guessing that there's something wrong
with variant type creation involving qualifiers.
gcc -v:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../src/configure --without-libstdcxx
--prefix=/home/dwitte/builds/gcc-trunk/obj/../installed
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090825 (experimental) (GCC)
--
Summary: C frontend botches type.name for typedef chains
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwitte at mozilla dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
[Bug c/41172] C frontend botches type.name for typedef chains
--- Comment #1 from dwitte at mozilla dot com 2009-08-26 02:09 --- Created an attachment (id=18425) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18425&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
[Bug c/41172] C frontend botches type.name for typedef chains
--- Comment #2 from dwitte at mozilla dot com 2009-08-26 02:13 --- Also, this bug applies to ENUMERAL_TYPEs and UNION_TYPEs in addition to RECORD_TYPEs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
[Bug c/41172] C frontend botches type.name for typedef chains
--- Comment #4 from dwitte at mozilla dot com 2009-08-26 04:25 --- Then how does the compiler determine type equality? By looking at the variant chain? By determining the originating type somehow? If you can point me to the procedure it uses to do this, perhaps we can duplicate it in our plugin code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
[Bug c/41172] C frontend botches type.name for typedef chains
--- Comment #6 from dwitte at mozilla dot com 2009-08-26 05:52 --- Well, if it's comparing two existing types, sure. :) How does it work in the case where the parser is dealing with the declaration |bar_t func()|, and it wants to determine if it's seen the declaration of |bar_t| before? Wait, don't tell me. The parser keeps a separate mapping of names->trees? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
--- Comment #11 from dwitte at mozilla dot com 2009-11-24 21:12 --- Anthony, any chance you could pick this fix up for libffi 3.0.9? -- dwitte at mozilla dot com changed: What|Removed |Added CC||green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #1 from dwitte at mozilla dot com 2010-09-09 22:03 --- FWIW our libffi is basically libffi git head: http://github.com/atgreen/libffi Which is regularly synced to gcc libffi. -- dwitte at mozilla dot com changed: What|Removed |Added CC||dwitte at mozilla dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug target/45623] GCC 4.5.[01] breaks our ffi on Linux64. ABI break?
--- Comment #4 from dwitte at mozilla dot com 2010-09-10 00:46 --- This is on x86_64. (I can't change the field, though. Can someone else?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64
--- Comment #2 from dwitte at mozilla dot com 2010-09-15 16:17 --- I'd recommend upstreaming things directly to the maintainer, Anthony Green (that's what I do). If you'd like, close this out, and post the patch to libffi-disc...@sourceware.org and CC gr...@redhat.com? -- dwitte at mozilla dot com changed: What|Removed |Added CC| |dwitte at mozilla dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64
--- Comment #3 from dwitte at mozilla dot com 2010-09-15 16:18 --- (Oh, and please include a description of your change in ChangeLog -- makes his job easier.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64
--- Comment #5 from dwitte at mozilla dot com 2010-09-15 17:24 --- Yeah, that sounds right to me. The final alignment really wants to be the alignment of whatever comes next, right? Which happens to be cif->flags, so 8 is fine. I wonder if just assuming 8 is fragile, but since we'll only ever have integers or pointers on the stack, it should be OK? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
