[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-07-15 15:08 --- Subject: Bug 36369 Author: rguenth Date: Tue Jul 15 15:07:46 2008 New Revision: 137843 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137843 Log: 2008-07-15 Richard Guenther [EMAIL PROTECTED] PR middle-end/36369 * c-common.c (strict_aliasing_warning): Do not warn for TYPE_REF_CAN_ALIAS_ALL pointers. (c_common_get_alias_set): may_alias types are not special. * tree.c (build_pointer_type_for_mode): Look up the may_alias attribute and set can_ref_all accordingly. (build_reference_type_for_mode): Likewise. * doc/extend.texi (may_alias): Clarify. * gcc.dg/Wstrict-aliasing-bogus-ref-all.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-ref-all.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-07-15 15:53 --- Subject: Bug 36369 Author: rguenth Date: Tue Jul 15 15:52:35 2008 New Revision: 137844 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137844 Log: 2008-07-15 Richard Guenther [EMAIL PROTECTED] PR middle-end/36369 * c-common.c (strict_aliasing_warning): Do not warn for TYPE_REF_CAN_ALIAS_ALL pointers. (c_common_get_alias_set): may_alias types are not special. * tree.c (build_pointer_type_for_mode): Look up the may_alias attribute and set can_ref_all accordingly. (build_reference_type_for_mode): Likewise. * doc/extend.texi (may_alias): Clarify. * gcc.dg/Wstrict-aliasing-bogus-ref-all.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-ref-all.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-common.c branches/gcc-4_3-branch/gcc/doc/extend.texi branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-07-15 15:53 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.3.1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-11 14:17 --- The warning happens also with the pointer being ref-all as the alias warning code asks for the alias set of the pointed-to type. Thus it probably makes sense to give that alias-set zero as well (or rather special-case the alias check, as tree-ssa-alias.c:may_alias_p does). I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-06-11 14:29
---
Note that the documentation of may_alias is extremely confusing IMHO (and
c_common_get_alias_set is wrong).
Accesses to objects with types with this attribute are not subjected to
type-based alias analysis, but are instead assumed to be able to alias
any other type of objects, just like the @code{char} type.
the char type is not special, but instead you are allowed to access all
memory via an _lvalue_ of character type!
The above suggests that
long __attribute__((__may_alias__)) x;
*(short *)x;
is ok, but it is not.
A better wording would be to say
Accesses through pointers to types with this attribute are not subject
to type-based alias analysis, but are instead assumed to be able to alias
any other type of objects. These lvalue expressions are treated like
having a character type. ...
Note that an object of a type with this attribute does not have any
special semantics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-29 13:58 ---
I was wrong about being C++ specific as here is a testcase which fails with
both front-ends:
struct g{long a;};
unsigned long f(struct g *a) { return *(unsigned long *)a-a;}
struct A
{
void *a;
};
int f1(const struct A *x, long *y)
{
typedef long __attribute__ ((may_alias)) long_a;
*y = *(const long_a *) (x-a);
return 1;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #6 from jakub at gcc dot gnu dot org 2008-05-29 14:00 ---
Yeah, or:
void *a;
int
f0 (long *y)
{
*y = *(const long *) a;
return 1;
}
int
f1 (long *y)
{
typedef long __attribute__ ((may_alias)) long_a;
*y = *(const long_a *) a;
return 1;
}
int
f2 (long *y)
{
*y = *(const long *) a;
return 1;
}
which IMHO should warn in f0 and f2 and not in f1. Stock trunk warns in all 3
cases, with my hack surprisingly it warns only in f0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #7 from jakub at gcc dot gnu dot org 2008-05-29 14:08 --- handle_may_alias_attribute is wrong though, as it modifies the alias set of long int. Either may_alias causes creation of build_distinct_type_copy, or we are in big trouble IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-29 14:30 --- The correct fix is to build a pointer with TYPE_REF_CAN_ALIAS_ALL for pointers to types with the may_alias attribute. This is the only thing that will make sure it works properly. This can be done in build_pointer_type / build_reference_type but at the cost of a attribute lookup (I have a patch for this). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-05-29 13:43:25 |2008-05-29 14:30:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-05-29 14:41 --- Of course the cleaner design of may_alias would have put it on pointer types only, so we could have handled this in handle_may_alias_attribute ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
[Bug middle-end/36369] [4.3/4.4 Regression] may_alias broken with previous uses of non attributed type in some cases
--- Comment #10 from jakub at gcc dot gnu dot org 2008-05-29 16:28 --- Well, if it is done frequently, perhaps we should spent a bit on it. Or, make sure types with may_alias attribute get TYPE_ALIAS_SET 0 and make TYPE_REF_CAN_ALIAS_ALL all pointers that point to alias set 0 types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36369
