Testcase (at -O2 and above): typedef long atype[]; typedef long atype1[]; int NumSift (atype *a, atype1 *a1) { (*a)[0] = 0; (*a1)[0] = 1; return (*a)[0]; } int main(void) { long a[2]; if (!NumSift(&a, &a)) __builtin_abort (); return 0; } ------ Orginally reported here: http://gcc.gnu.org/ml/gcc/2006-03/msg00638.html
Just to add some information from the conversation on this topic: > > Shouldn't the aliasing set for the type atype be the same as atype1? > > Im not entirely sure, but the C99 standard does at least not suggest > otherwise, instead it says (6.7.7/3) "A typedef declaration does not introduce > a new type, only a synonym for the type so specified." atype and atype1 are compatible bacsue of 6.7.5.2, Array declarators: 6 For two array types to be compatible, both shall have compatible element types, and if both size specifiers are present, and are integer constant expressions, then both size specifiers shall have the same constant value. If the two array types are used in a context which requires them to be compatible, it is undefined behavior if the two size specifiers evaluate to unequal values. I assume that compatible types should be in the same alias set.
And this only fails for array types without their size specified. Confirmed. Btw. inside NumShift the two array types are <array_type 0xb7d86398 atype type <integer_type 0xb7d1733c long int sizes-gimplified public SI size <integer_cst 0xb7d07408 constant invariant 32> unit size <integer_cst 0xb7d07198 constant invariant 4> align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0xb7d07498 -2147483648> max <integer_cst 0xb7d074b0 2147483647> pointer_to_this <pointer_type 0xb7d1f114>> BLK align 32 symtab 0 alias set -1 pointer_to_this <pointer_type 0xb7d864ac>> <array_type 0xb7d86450 atype1 type <integer_type 0xb7d1733c long int sizes-gimplified public SI size <integer_cst 0xb7d07408 constant invariant 32> unit size <integer_cst 0xb7d07198 constant invariant 4> align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0xb7d07498 -2147483648> max <integer_cst 0xb7d074b0 2147483647> pointer_to_this <pointer_type 0xb7d1f114>> BLK align 32 symtab 0 alias set -1 pointer_to_this <pointer_type 0xb7d86508>> still we create Variable: aD.1278, UID 1278, long intD.2[<unknown>] *, type memory tag: TMT.5D.1303, default def: aD.1278_1 Variable: a1D.1279, UID 1279, long intD.2[<unknown>] *, type memory tag: TMT.6D.1304, default def: a1D.1279_2 # TMT.5D.1303_6 = V_MAY_DEF <TMT.5D.1303_5>; (*aD.1278_1)[0] = 0; # TMT.6D.1304_8 = V_MAY_DEF <TMT.6D.1304_7>; (*a1D.1279_2)[0] = 1; # VUSE <TMT.5D.1303_6>; D.1282_3 = (*aD.1278_1)[0];
Mine
Created attachment 11526 [details] Patch that appears to fix the problem Here's a patch I'm trying to fix the problem. Hopefully I've caught all cases of modifying array ranges in place, which would break under the sharing of types I've introduced.
Created attachment 11533 [details] Patch that fixes the problem and does not introduce regressions The previous patch had a few regressions in vlas, all fixed in this newer revision of the patch, just submitted to gcc-patches.
Subject: Bug number PR c/27184 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-05/msg01507.html
I am rebootstrapping this patch right now and will commit tommorow.
Ping!
I have been having problems with my work machine to be able to test this patch (before applying it) but hopefuly it will finish this time. If it does not work, I am going to test it using my home machine.
Subject: Bug 27184 Author: pinskia Date: Sun Aug 13 21:16:46 2006 New Revision: 116116 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116116 Log: 2006-08-13 Alexandre Oliva <aoliva@redhat.com> Andrew Pinski <pinskia@physics.uc.edu> PR c/27184 * tree.c (build_array_type): Unify array types with unspecified index_type. * c-decl.c (grokdeclarator): Make sure we do not modify a unified incomplete array type. * c-typeck.c (store_init_value): Create distinct type before filling in the index type in an initializer from a compound literal. * c-decl.c (grokdeclarator): Remove code where we copy the array type over. 2006-08-13 Alexandre Oliva <aoliva@redhat.com> PR c/27184 * gcc.dg/torture/pr27184.c: New test Added: trunk/gcc/testsuite/gcc.dg/torture/pr27184.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
Fixed on the mainline, will apply to the branches after a week or so.
(In reply to comment #11) > Fixed on the mainline, will apply to the branches after a week or so. > So, how's this going for 4.1?
(In reply to comment #12) > So, how's this going for 4.1? Well a regression was found in 4.2 caused by this patch so I am going to fix that first.
The patch does not apply cleanly to the 4.1 branch so I am going to fix this.
I'll take care of this. (Bootstrap running)
Subject: Bug 27184 Author: rguenth Date: Mon Oct 16 11:18:28 2006 New Revision: 117782 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117782 Log: 2006-10-16 Richard Guenther <rguenther@suse.de> Backport from mainline: 2006-08-13 Alexandre Oliva <aoliva@redhat.com> Andrew Pinski <pinskia@physics.uc.edu> PR c/27184 * tree.c (build_array_type): Unify array types with unspecified index_type. * c-decl.c (grokdeclarator): Make sure we do not modify a unified incomplete array type. * c-typeck.c (store_init_value): Create distinct type before filling in the index type in an initializer from a compound literal. * c-decl.c (grokdeclarator): Remove code where we copy the array type over. 2006-08-13 Alexandre Oliva <aoliva@redhat.com> PR c/27184 * gcc.dg/torture/pr27184.c: New test Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr27184.c - copied unchanged from r116116, trunk/gcc/testsuite/gcc.dg/torture/pr27184.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-decl.c branches/gcc-4_1-branch/gcc/c-typeck.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree.c
Fixed on the 4.1 branch.
Fixed in GCC-4.1.2 and higher.