Testcase: #include <stdio.h> struct S { short x; }; typedef struct S __attribute__((__may_alias__)) test; int f() { int a=10; test *p=(test *)&a; test s={1}; *p=s; return a; } int main() { if (f() == 10) __builtin_abort() return 0; } ------- Even though the struct is not the same size as int, this should still work as the struct is marked as may_alias so we get an aliasing set of 0.
Add an alias dump so we can see what things think of all this?
Better testcase which shows the problem before SRA: 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; } ------ I will attach the aliasing dump after this.
Created attachment 12116 [details] aliasing dump aliasing dump for the newest testcase.
Subject: Re: [4.2 Regression] wrong code with may_alias and structs pinskia at gcc dot gnu dot org wrote: > ------- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-22 21:50 ------- > Created an attachment (id=12116) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12116&action=view) > aliasing dump > > aliasing dump for the newest testcase. > > My guess is now that access_can_touch_variable is returning false for the p->x store when it asks about a, so it uses the bare NMT. This is a hard nut to crack, my *guess* is that if you just check the alias set of the type of the access, we are going to end up claiming any access to a structure containing a char variable is aliased. Try it though :)
(In reply to comment #4) > This is a hard nut to crack, my *guess* is that if you just check the > alias set of the type of the access, we are going to end up claiming any > access to a structure containing a char variable is aliased. You are correct as we regress with the following testcase: struct a { char a1; }; int *aa; void g(int *a) { aa = a; *a = 2; } int t(int i, struct a *b) { g(&i); b->a1 = 1; i = 2; if (b->a1 != 1) link_failure (); } int main(void) { struct a b; t(1, &b); return 0; }
This patch fixes the problem without causing the missed optimization to happen:Index: tree-ssa-operands.c =================================================================== --- tree-ssa-operands.c (revision 116342) +++ tree-ssa-operands.c (working copy) @@ -1150,7 +1150,8 @@ access_can_touch_variable (tree ref, tre || TREE_CODE (TREE_TYPE (base)) != UNION_TYPE) && !AGGREGATE_TYPE_P (TREE_TYPE (alias)) && TREE_CODE (TREE_TYPE (alias)) != COMPLEX_TYPE - && !POINTER_TYPE_P (TREE_TYPE (alias))) + && !POINTER_TYPE_P (TREE_TYPE (alias)) + && get_alias_set (base)) { #ifdef ACCESS_DEBUGGING fprintf (stderr, "Access to ");
Mine, all mine.
Subject: Bug number PR 28807 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00878.html
Fixed.
Subject: Bug 28807 Author: pinskia Date: Fri Aug 25 07:13:48 2006 New Revision: 116393 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116393 Log: 2006-08-24 Andrew Pinski <pinskia@physics.uc.edu> PR tree-opt/28807 * tree-ssa-operands.c (access_can_touch_variable): Don't say the access through a base which has an alias set of 0 cannot touch the variable. 2006-08-24 Andrew Pinski <pinskia@physics.uc.edu> PR tree-opt/28807 * gcc.c-torture/execute/mayalias-2.c: New test. * gcc.dg/tree-ssa/alias-13.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/mayalias-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-operands.c