This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Your June 7 change to expand_expr
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: Your June 7 change to expand_expr
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 30 Jun 1998 19:01:46 -0600
- cc: mark at markmitchell dot com, egcs-bugs at cygnus dot com, jfc at mit dot edu
- Reply-To: law at cygnus dot com
In message <9806302343.AA14503@vlsi1.ultra.nyu.edu>you write:
> In particular, to the bit about a dereference of a REFERENCE_TYPE be
> always considered to be in a structure. I don't know exactly *why*
> this was causing the problem, although I'm guessing it's because EGCS
> does some alias analysis that looks at MEM_IN_STRUCT_P.
>
> The fundamental problem is that there needs to be a "conservative"
> setting, one for which we can safely make things without risking
> bugs. This used to be the case when that bit is true.
? I'm not aware of any time in the recent (gcc2 era) past where the
MEM_IN_STRUCT_P bit had that meaning.
Why? Because the old alias code (as far as I know) has always used
MEM_IN_STRUCT_P to help with alias analysis.
> also seems suspicious to me. Besides the reference issue, how do we
> know whether the NOP_EXPR was the degenerate addition case mentioned?
>
> We can't. That's the whole problem with the flag.
Right. MEM_IN_STRUCT_P has fundamental flaws. No doubt about it;
particularly since some code (ie cse) will change the bit (980506-2.c
in the egcs testsuite is an example)
> Jeff, for now I recommend the following patch to EGCS.
>
> My recommendation, since EGCS is getting much better alias analysis,
> is simply to *delete* the flag since it's totally impossible to set
> it accurately and it becomes much less relevant with better alias
> analysis.
The question then becomes "has egcs's alias analysis progressed far
enough to remove the that flag?". I don't know the answer.