attribute((maybe_aliased)) in a union causes ICE
Created attachment 12040 [details] test case causing ICE compiled with: g++ -c ice.cxx
Amending the "description" attribute ((may_alias)) in a union causes ICE. I'm using the 7/15/2006 snapshot of 4.2 I realize that unions are implicitly 'aliased', but in fact this problem was encountered while I was trying to debug a more complex situation. I have a template class that tries to deposit smaller addressable units into a larger POD type. The alias analysis code in gcc3.4 thru 4.2 optimizes this code in ways that produce "wrong results". I've tried a number of workarounds, including use of volatile asm instructions to deal with that without any success - and since I'm in the realm of undefined behavior, I don't expect anything from GCC developers. But, regardless of the optimization issues, an ICE on what should be legal code is something that needs fixing...
Confirmed, 3.2.3 did not ICE, though it did just ignore may_alias after warning about it. I am going to mark this a regression as the ICE is a regression for the code.
This seems to be a C++ FE bug: debug_tree (*decl) <field_decl 0xf7bc65b0 whole type <template_type_parm 0xf7bc63f0 IT type_0 type_6 VOID align 8 symtab 0 alias set -1 index 0 level 1 orig_level 1 chain <type_decl 0xf7daeb00 IT>> VOID file a.C line 3 align 1 offset_align 1> shouldn't be passed to decl_attributes in generic code.
Even shorter testcase: ======================================= template<typename T> struct A { T t __attribute__ ((__may_alias__)); }; =======================================
When I looked at this for work, this is a hard one to fix correctly. We could ignore may_alias on template arguments but that will really fix the problem. What we need to do is to record the attribute when processing templates and then process them while instaintating them. If I get some next week I might get around to do for work and once the copyright assignment problem gets cleared up, I will post it.
Won't fix in GCC-4.0.x. Adjustine milestone.
Fixed on mainline. Probably by the fix for PR 19407. Jason, would you mind backporting your patch to the branches?
I'm reluctant to backport the changes to 4.2 now because they're fairly intrusive; I'm not sufficiently confident yet that the change in typedef handling won't introduce other problems.
Closing 4.1 branch.
Closing 4.2 branch, fixed in 4.3.