Re: Incomplete TREE_CONSTANT-propagation in build() ?

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

| On Tue, 4 Nov 2003, Ziemowit Laski wrote:
| 
| > Well, I was thinking in terms of gcc internals rather than standards.
| > (I neither object to nor understand what the standars says in this case,
| > but that's an orthogonal matter.)
| 
| TREE_CONSTANT is used as a weird hybrid of GCC-internal-constantness and
| standard-constantness.  It is entirely inadequate for implementing the C99
| standard definition of constant expressions (for that, expressions need
| *several* flags to be kept track of for each subexpression: certain types
| of subexpressions prevent the whole containing expression from being
| constant (or a particular kind of constant) while others don't when in
| unevaluated subexpressions), but until the C front end has such several
| flags I suspect changing TREE_CONSTANT would break cases where the 
| handling of constant expressions isn't already broken.

I'm not sure he was proposing to change TREE_CONSTANT as opposed to
extending it.  My understanding is that he would like to have it cover
more cases.  Or, are you saying that his proposed extension would
break things?  

| On the separate matter of delaying folding these expressions, I suspect
| delaying all folding beyond that actually required for integer constant
| expressions, until a full expression is obtained, would be a good idea.  

Yes.  And given that COMPOUND_EXPRs ar enot constant expressions, that
won't do any harm.

However, I'm uneasy with his using of COMPOUND_EXPR.

-- Gaby