This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Alias code
- To: mark at markmitchell dot com
- Subject: Re: Alias code
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 29 Jun 1998 10:26:46 -0600
- cc: egcs at cygnus dot com, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199806291545.IAA01665@smtp.earthlink.net>you write:
> Right. I thought of this problem, and had meant to do something about
> it, but forgot. I apologize profusely for wasting your time.
Don't worry about it. The mad ramblings of a sleep deprived man :-)
I was determined to pin the problem on something from the merge and it
didn't even occur to me that it could have been the alias code -- especially
since I wasn't using -fstrict-aliasing.
One more thought -- we might want to check flag_strict_aliasing in
DIFFERENT_ALIAS_SETS_P. It shouldn't matter after your patch, but
I don't think it hurts in any significant way.
> I think the only thing we can do is modify gen_rtx to special case
> MEM. BTW, configuring with --enable-checking and compiling with
> -fno-strict-aliasing might help; the type-based aliasing code will
> then abort if there's ever a MEM that is *not* in alias set zero.
Right. It probably would have caught this case (unless it changed
memory layout enough -- though it's likely we would have triggered a
fault somewhere else.
Once I had zero'd in on the alias code it was pretty trivial to find
out what had gone wrong :-)
> How about this patch?
>
> --
> Mark Mitchell mark@markmitchell.com
> Mark Mitchell Consulting http://www.markmitchell.com
>
> Mon Jun 29 08:45:08 1998 Mark Mitchell <mark@markmitchell.com>
>
> * rtl.h: Update comment about special gen_rtx variants.
> * emit-rtl.c (gen_rtx): Handle MEMs using gen_rtx_MEM.
Looks good. Presumably we've defined gen_rtx (MEM) and gen_rtx_MEM
as explicitly unable to set the alias set. That has to be done on
the return value from those functions. Right?
Jeff