Re: Incomplete TREE_CONSTANT-propagation in build() ?

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

Ziemowit Laski <zlaski@apple.com> writes:

| On 4 Nov, 2003, at 12.46, Gabriel Dos Reis wrote:
| 
| > Ziemowit Laski <zlaski@apple.com> writes:
| >
| > | On 4 Nov, 2003, at 12.23, Gabriel Dos Reis wrote:
| > |
| > | > Ziemowit Laski <zlaski@apple.com> writes:
| > | >
| > | > | P.S.  For the morbidly curious, I'm working on Motorola-style
| > AltiVec
| > | > | support in the 3.4 tree, and I really need compound
| > expressions like
| > | > | '(1, 2, 3, 4)' to be marked TREE_CONSTANT. :-)
| > | >
| > | > Why don't you use VECTOR_CST?
| > |
| > | I am, but before they become VECTOR_CSTs, they are COMPOUND_EXPRs
| > (due
| > | to the parenthesized Motorola notation).
| >
| > OK, understood.  However, I would think that a TREE_LIST would be much
| > more appropriate: it really is a list of constant expression instead
| > of a sequence of expressions, evaluated and discarded  except the last
| > one.  It would be really helpful if the front-ends could be made much
| > more consistent in that area.
| 
| Thing is, the front-end has no way of knowing the intended use of
| something
| like '(1, 2, 3, 4)'; it all depends on what that compound expression
| is eventually
| bound to.

I hear you, but "(1, 2, 3, 4)" as a compound expression a bit
contorted and I'm really worried about tweaking the front-end into
believeing the contrary.  On the other hand, it is an
expression-list  and the front-end already has knowledge of
expression-lists used as iniatializer. 

Anyway, I believe it is too late for you to revise your design choice?
(Certainly, in the C++ front-end you can tell when it is an
expression-list and when it is a compound expresssion).

|  So I can't really decide a priori if I should use
| TREE_LISTs or not.
| >
| > | > A compound expression is NEVER a constant expression EVEN if its
| > | > operands are all constant expressions.
| > |
| > | Why not?
| >
| > I have no idea of the raionale behond "that is what the standard says".
| 
| 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.)

OK, thanks for the clarification.

| If the COUPOUND_EXPRs are not marked TREE_CONSTANT, then I have to
| selectively
| rediscover their TREE_CONSTANT-ness throughout the C and C++
| front-ends.  This
| is just horrible, error-prone engineering.  Why can't COMPOUND_EXPRs
| just
| be marked TREE_CONSTANT to begin with? :-)

given the clarification you make above, I would certainly not object
if the changed is made with appropriate clear comments.