This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question on GIMPLE semantics and EH
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: Joe dot Buck at synopsys dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 13 Aug 04 21:14:10 EDT
- Subject: Re: Question on GIMPLE semantics and EH
However, apparently in the Ada case this is not true of all temporaries.
In fact, it's not true for *most* variables it introduces. Many really
aren't *temporaries* at all, actually, but instead internal variables that
are used for various purposes (in this case for a list of objects that need
finalization). Often what happens is that a single user variable or type
produces a number of corresponding variables, which have different usage
patterns from either each other or the original variable.
So is the issue that the gimplify conversion is assuming that
DECL_ARTIFICIAL variables are SSA?
No, not SSA, but it is making an assumption that's sort of hard to pin down.
However, I'm wondering if for this particular case (a CALL), gimplification
can leave the LHS a variable if it's both DECL_ARTIFICIAL and TREE_READONLY?