This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Aliasing violation generated by fold_builtin_memcmp?
- From: Richard Henderson <rth at redhat dot com>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, gcc at gcc dot gnu dot org, Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Fri, 30 Sep 2005 17:11:08 -0700
- Subject: Re: Aliasing violation generated by fold_builtin_memcmp?
- References: <200509300008.j8U08IT3029381@53v30g15.boeblingen.de.ibm.com> <1128040347.9435.33.camel@IBM-82ZWS052TEN> <d459440f02d12d0e37f25bbec7d2ccf1@physics.uc.edu>
On Fri, Sep 30, 2005 at 01:49:59PM -0400, Andrew Pinski wrote:
> Something like this will fix the issue with TYPE_REF_CAN_ALIAS_ALL
> by removing the use. Maybe we could move may_alias to a bit in the
> types and move TYPE_REF_CAN_ALIAS_ALL from the pointer type to the
> type which is being accessed instead of this mess.
Close.
> + build_type_attribute_variant (ttype,
> + merge_attributes
> + (TYPE_ATTRIBUTES (to_type),
> + tree_cons (get_identifier ("may_alias"),
> + NULL_TREE, NULL_TREE)));
If ALIAS_SET had been computed on ttype, this will leave it set.
You'd need to force set it to zero here. You can also avoid
creating a new type for C for the case in question by checking
that the original type has alias set zero.
> return build_pointer_type_for_mode (build_type_no_quals (TREE_TYPE (t)),
> TYPE_MODE (t),
> - TYPE_REF_CAN_ALIAS_ALL (t));
> + false);
You'd also want to delete all traces of TYPE_REF_CAN_ALIAS_ALL.
r~