Testcase that crashes at -O3 -g: struct S { short x; }; typedef struct S __attribute__((__may_alias__)) test; int f() { int a=10; test *p=(test *)&a; p->x = 1; return a; } int main() { if (f() == 10) __builtin_abort(); return 0; } --------------------- mayalias-2.c:2: internal compiler error: in splice_child_die, at dwarf2out.c:5513 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
This worked in 3.4.0 so this is a regression. Note this is the testcase for 28807 which I was using for testing so the testcase might be added to the testsuite by the time someone gets around to looking into the bug.
Janis, Could you run a regression hunt on this bug?
A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=87036 r87036 | dpatel | 2004-09-03 17:10:40 +0000 (Fri, 03 Sep 2004)
Confirmed by Janis.
We now have gcc.c-torture/execute/mayalias-2.c which crashes this way on x86_64 at -O3 -g.
Also fails on PA with -O3 -g.
*** Bug 28880 has been marked as a duplicate of this bug. ***
In the duplicate I explain: The problem is that the front-end is calling the DWARF output code with two shallow copies of the same structure, 'S'. The DWARF code detects that two different structures have the same members and aborts.
Devang, Why did you remove your self, you caused this regression. Yes you might not work on GCC any more for Apple but that does not take you away from fixing the regression you caused. I am a bit upset at this behavior of going away and not going to fix a regression you caused. -- Pinski dpatel@apple.com 2006-08-29 17:46:15 CC dpatel@gcc.gnu.org
Pinski, Please do not reinsert my email address in CC list, again (and learn to not jump to conclusion based on biased views) May be it is not a good idea to ask dwarf generator to handle a case where two shallow copy of same struct refers same field ? May be equate_decl_number_to_die() should handle it properly ? May be it is appropriate to have one field be a member of multiple structures ?
Yet another problem showing problems with attributes on typedefs for structure types...
(In reply to comment #11) > Yet another problem showing problems with attributes on typedefs for structure > types... Except this is with C and not C++ unlike the other ones.
Subject: Re: [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs On 01/09/2006, at 2:53 PM, mmitchel at gcc dot gnu dot org wrote: > ------- Comment #11 from mmitchel at gcc dot gnu dot org > 2006-09-01 21:53 ------- > Yet another problem showing problems with attributes on typedefs > for structure > types... The question I asked is "why doesn't this happen for 'const'"? That turned out to be a good question, because it leads to the better question of "what debugging output did you expect for this code, anyway"? It seems to me that __noalias__ is an interesting attribute that should be somehow reflected in the DWARF. That would require a GNU extension, of course.
The mayalias-2.c failure shows up on MIPS too.
Also fails on SPARC with -O3 -g.
*** Bug 29903 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > The question I asked is "why doesn't this happen for 'const'"? That > turned out to be a good question, because it leads to the better > question of "what debugging output did you expect for this code, > anyway"? > > It seems to me that __noalias__ is an interesting attribute that > should be somehow reflected in the DWARF. That would require a GNU > extension, of course. Rather than comparing this with "const", compare it with "restrict". This deserves representation in DWARF if and only if restrict deserves it. (and that I can't answer, but my gut feeling is that such representation should be only for things that C++ would put into name mangling)
*** Bug 30661 has been marked as a duplicate of this bug. ***
won't fix in GCC-4.0.x. Adjusting milestone.
I see this for cris-elf (r121581) and mmix-knuth-mmixware (r121569) too, both mayalias-2 and -3 both at "-O3 -g" like for x86_64. As we have this PR, I intend to XFAIL it for these ports with those options; IIRC that's protocol.
*** Bug 30758 has been marked as a duplicate of this bug. ***
*** Bug 30894 has been marked as a duplicate of this bug. ***
*** Bug 30986 has been marked as a duplicate of this bug. ***
ICE's with every optimization level.
*** Bug 32426 has been marked as a duplicate of this bug. ***
*** Bug 32793 has been marked as a duplicate of this bug. ***
same failure for gcc-4.3 mainline on i686-pc-cygwin
*** Bug 34041 has been marked as a duplicate of this bug. ***
*** Bug 29436 has been marked as a duplicate of this bug. ***
Subject: Bug 28834 Author: jason Date: Mon Nov 19 22:32:30 2007 New Revision: 130298 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130298 Log: note PR 28834 Modified: trunk/gcc/ChangeLog
The crash is fixed by ignoring the attribute on the typedef. If you want to apply may_alias to a struct type, you need to specify it in the type definition, either as struct __attribute ((may_alias)) name { ... }; or struct name { ... } __attribute ((may_alias));
Jason - Should the fix for PR28834 (AKA PR29436) be backported to 4.2/4.1? I still see errors from mayalias-2.c on 4.2. (4.1 doesn't have the testcase, but I suspect it still has the bug.)
Created attachment 46717 [details] true