[Bug pch/13689] GGC PCH breaks aliasing

["steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From steven at gcc dot gnu dot org  2004-01-15 22:41 -------
dje wrote: 
>     The example in the original report ICEs (with Honza's patch) on 
> AIX due to an internal varray consistency check.  With the splay tree 
> implementation, we presumably gets zeroes for the data that was not stored 
> in PCH. 
 
That's not what happens.  If we would get zeroes, this would just result 
in pessimized code since alias set 0 is reserved for "aliasses everything" 
(iirc).  That would just be sad, but not a path to possible wrong code. 
 
What really happens is that we restore alias set numbers (from trees) but 
not the actual alias sets.  That is bad because you load things in some 
alias set, say 1, from the PCH, but alias.c does not know about that set. 
It creates its own set 1 and may put things in it that conflict with the 
set loaded from the PCH.  This can in theory lead to types ending up in 
different alias sets while they can alias (i.e. if one type comes from the 
PCH with some set number, and an aliasing type is in the code that uses 
the PCH). 
 
Now we discovered this bug because we loaded an alias set from the PCH that 
had a higher number than the number of alias sets in the compilation unit 
that used the PCH ("the unit" from here).  For the unit, 5 alias sets were 
created in alias.c.  But something from the PCH had alias set number 7. 
That was probably a valid alias set while compiling the PCH, but the unit 
doesn't know about that set because the alias sets are not stored in the PCH. 
Previously, with splay trees alias.c would just have concluded that the set 
was new, so it would insert it into the splay tree and go on without 
complaints.  But now we have a varray for the sets, and 7 was larger than 
the number of sets created (set 7 wasn't created with new_alias_set()) and 
this causes an abort in the varray bounds checking code. 
 
So the only proper solutions are: 
- Recreate the alias sets when loading the PCH. 
- Don't create alias sets when compiling a PCH, but "discover" 
  then when loading it. 
- Write the alias sets to the PCH. 
 
The latter option is IMO the worst thinkable, but I have no clue on how 
to implement the other two. 
 
I'm going to attach a patch is one I proposed to the 2 people that have 
been able to trigger this bug.  I don't know if it is correct or not and 
I have not yet had a reply from either one of them to confirm/deny that 
it fixes the bug.  But perhaps Geoff can do something with it.  Note that 
I fear it can have a compile time impact, and I'm not sure if it fixes 
the bug (but I think it should and so do others). 
 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13689