This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Fix questionable code in objects_must_conflict_p
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Tue, 8 Nov 2005 15:54:13 +0100
- Subject: [PATCH] Fix questionable code in objects_must_conflict_p
Hi,
This code has caused much trouble to the 3.x series of Ada compilers because
they were still using RTL inlining. Not sure if that's still relevant for
the 4.x series, but I thought I should submit the change anyway.
The bottom line is that objects_must_conflict_p always returns 1 if one and
only one of the type is NULL. Now the head comment reads:
/* Return 1 if any MEM object of type T1 will always conflict (using the
dependency routines in this file) with any MEM object of type T2.
This is used when allocating temporary storage. If T1 and/or T2 are
NULL_TREE, it means we know nothing about the storage. */
Note the "and/or". However, later:
/* If neither has a type specified, we don't know if they'll conflict
because we may be using them to store objects of various types, for
example the argument and local variables areas of inlined functions. */
if (t1 == 0 && t2 == 0)
return 0;
Why is that not valid in the "or" case too?
The patch has been successfully bootstrapped/regtested on x86_64-suse-linux.
2005-11-08 Eric Botcazou <ebotcazou@adacore.com>
* alias.c (objects_must_conflict_p): Do not fall back on
alias set zero when there is no type.
--
Eric Botcazou
Index: alias.c
===================================================================
--- alias.c (revision 106397)
+++ alias.c (working copy)
@@ -371,10 +371,10 @@ objects_must_conflict_p (tree t1, tree t
|| (t1 != 0 && TYPE_VOLATILE (t1) && t2 != 0 && TYPE_VOLATILE (t2)))
return 1;
- set1 = t1 ? get_alias_set (t1) : 0;
- set2 = t2 ? get_alias_set (t2) : 0;
+ set1 = t1 ? get_alias_set (t1) : -1;
+ set2 = t2 ? get_alias_set (t2) : -1;
- /* Otherwise they conflict if they have no alias set or the same. We
+ /* Otherwise they conflict if they have alias set zero or the same. We
can't simply use alias_sets_conflict_p here, because we must make
sure that every subtype of t1 will conflict with every subtype of
t2 for which a pair of subobjects of these respective subtypes