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 Wed, 5 Nov 2003, Gabriel Dos Reis wrote:
| 
| > 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?  
| 
| I'm suggesting that changing (the value of) TREE_CONSTANT (for these
| expressions) might break code using it to approximate whether something is
| a constant expression, because of the dual use at present.

Aha, thanks.

Do you see an alternative apart from implementing the various flags
you alluded to in your earlier message?

I would think that since a TREE_LIST is a not an expression, setting
its TREE_CONSTANT would not introduce any of the problems you
identified above. 

| > | 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.
| 
| It might break uses of the undocumented extensions whereby certain things,
| that shouldn't be constant expressions, are treated as such.  Since all
| those extensions are undocumented and liable to be removed without warning
| or deprecation period, I don't consider this a problem.

I've forgotten about those :-/

-- Gaby