From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: mark@markmitchell.com Cc: egcs@cygnus.com, egcs-patches@cygnus.com Subject: Re: Alias code Date: Mon, 29 Jun 1998 22:34:00 -0000 Message-id: <13462.899137606@hurl.cygnus.com> References: <199806291545.IAA01665@smtp.earthlink.net> X-SW-Source: 1998-06/msg01085.html 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 > > * 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