Bug 28642 - [4.2 Regression] ICE in layout_type with may_alias and templates
Summary: [4.2 Regression] ICE in layout_type with may_alias and templates
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.2.0
: P2 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, monitored
Depends on: 28834
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-07 18:26 UTC by apl
Modified: 2009-03-30 17:03 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.3.0
Known to fail: 3.4.3 4.0.4 4.2.0 3.3.3 4.2.5
Last reconfirmed: 2007-08-06 15:02:24


Attachments
test case causing ICE (172 bytes, text/plain)
2006-08-07 18:27 UTC, apl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description apl 2006-08-07 18:26:10 UTC
attribute((maybe_aliased)) in a union causes ICE
Comment 1 apl 2006-08-07 18:27:12 UTC
Created attachment 12040 [details]
test case causing ICE

compiled with: g++ -c ice.cxx
Comment 2 apl 2006-08-07 18:34:19 UTC
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...
Comment 3 Andrew Pinski 2006-08-13 16:21:01 UTC
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.
Comment 4 Jakub Jelinek 2006-08-23 20:43:27 UTC
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.
Comment 5 Volker Reichelt 2006-10-08 20:21:26 UTC
Even shorter testcase:

=======================================
template<typename T> struct A
{
  T t __attribute__ ((__may_alias__));
};
=======================================
Comment 6 Andrew Pinski 2006-10-08 20:54:36 UTC
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.
Comment 7 Gabriel Dos Reis 2007-02-03 18:43:35 UTC
Won't fix in GCC-4.0.x.  Adjustine milestone.
Comment 8 Volker Reichelt 2007-09-24 10:53:35 UTC
Fixed on mainline.
Probably by the fix for PR 19407.

Jason, would you mind backporting your patch to the branches?
Comment 9 Jason Merrill 2007-09-24 13:53:09 UTC
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.
Comment 10 Joseph S. Myers 2008-07-04 21:26:56 UTC
Closing 4.1 branch.
Comment 11 Joseph S. Myers 2009-03-30 17:03:07 UTC
Closing 4.2 branch, fixed in 4.3.