On 03/23/2016 07:52 AM, Marek Polacek wrote:
On Mon, Mar 21, 2016 at 09:57:54PM +0100, Richard Biener wrote:
On March 21, 2016 6:55:28 PM GMT+01:00, Marek Polacek <pola...@redhat.com>
wrote:
This PR points out to a GC problem: when we freed a duplicate typedef,
we were
leaving its type in the variants list, with its TYPE_NAME still
pointing to the
now-freed TYPE_DECL, leading to a crash. I was lucky to discover that
the
exact same problem was fixed in November for the C++ FE, so I could
just follow
suit here. And because that change didn't add a new testcase, I'm
putting the
new test into c-c++-common/.
Bootstrapped/regtested on x86_64-linux, ok for trunk/5?
But IIRC this will drop the aligned attribute effect as that applied to the new
type?
Yes. So this metamorphosed into another issue: what to do with
typedef int T;
typedef int T __attribute__((aligned (16)));
typedef int T __attribute__((aligned (32)));
? Either we can reject this, or do what clang (and other compilers) do, that
is pick the strictest alignment - 32 in this case. The following patch does
that.
I've also checked what the C FE does for a few other attributes:
packed
visibility
- ignored on TYPE_DECLs
used
unused
deprecated
scalar_storage_order
- we seem to do the right thing
transparent_union
- typedef int T;
typedef int T __attribute__((transparent_union));
gives an error
vector_size
mode
- typedef int T;
typedef int T __attribute__((mode (SI)));
works while
typedef int T;
typedef int T __attribute__((mode (DI)));
results in "conflicts" error
similarly for vector_size
Well, here's the patch. Thoughts?
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-03-23 Marek Polacek <pola...@redhat.com>
PR c/70297
* c-decl.c (merge_decls): Also set TYPE_ALIGN and TYPE_USER_ALIGN.
* decl.c (duplicate_decls): Also set TYPE_ALIGN and TYPE_USER_ALIGN.
* c-c++-common/pr70297.c: New test.
* g++.dg/cpp0x/typedef-redecl.C: New test.
* gcc.dg/typedef-redecl2.c: New test.
OK.
jeff
