Alias sets

Mark Mitchell
Sat Jun 3 22:39:00 GMT 2000

Folks --

  Two things went wrong with mail in the last few days that have made
me less useful than I should have been with respect to the aliasing

   - Somehow, I was unsubscribed to gcc-patches around the beginning
     of last week.  That's where a lot of the interesting traffic was.
     I am now resubscribed.

   - I sent mail to Kenner about his patch, but accidentally failed
     to copy the lists.

Just to recap, and so that we're all on the same page, Kenner agreed
to restore the conservative behavior for alias sets that we had in the
past.  Namely, that no language that didn't use alias sets in the past
would be forced to use them now.  And that FIELD_DECLs would by
default be addressable.  And that finish_record_layout wouldn't
automatically call get_alias_set, so that the whole
record_component_aliases thing wouldn't be triggered by a language
that didn't want that behavior.  (Including C++, since TYPE_FIELDs
doesn't accurately represent all the fields of a C++ object at the

  It looks like Richard Henderson, and others, were having somewhat
parallel conversations with Kenner at the same time.  Again, I
apologize for not being more participatory.

  RTH, I think we should back out this patch:

        2000-06-02  Richard Henderson  <>

	* alias.c (lang_get_alias_set): Remove.
	(get_alias_set): Call it directly, not indirectly.
	* c-common.c (lang_get_alias_set): Rename from c_get_alias_set.
	* c-common.h (c_get_alias_set): Don't declare.
	* c-decl.c (init_decl_processing): Don't set lang_get_alias_set.
	* expr.h (lang_get_alias_set): Declare as function, not pointer.

and the accompanying front-end patches.  I don't think language
implementors should be saddled with alias sets at all if they don't
want to deal.  It should be possible to right a correct front-end
without providing this function; you just won't get as good
optimization.  Do you agree?

Mark Mitchell         
CodeSourcery, LLC     

More information about the Gcc mailing list