Re: Incomplete TREE_CONSTANT-propagation in build() ?

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

Ziemowit Laski <zlaski@apple.com> writes:

[...]

| > I understand that.  And that is probably roughly how I would implement
| > it (except for the use of COMPOUND_EXPR).  My use of "contorted" here
| > refers to the fact that a TREE_LIST is not being used for that job.
| 
| I guess I'm still not clear on how you'd want me to use TREE_LISTs in
| this
| particular context.  At present, both the C and C++ front-ends will turn
| '(1, 2, 3, 4)' into COMPOUND_EXPRs.

Not in the context you described.  
The C++ front-end does build a TREE_LIST for an initializers of the
for

   initializer:
     = initializer-clause
       ( expression-list )      // <- a TREE_LIST for this
  
   initializer-clause:
     assignment-expression
     { initializer-list , [opt] }
     { }

You said in a previous message that you're not using the
iniatilizer-clause production that uses the {}-enclosed syntax, so
you're left with the TREE_LIST you get from either
cp_parser_initializer or cp_parser_initializer_list. 

|  The essence of my approach is that
| the folding of these COMPOUND_EXPRs has to be deferred only long enough
| to determine if they should be VECTOR_CSTs instead.  (In C++, it turns
| out that the COMPOUND_EXPRs survive long enough already, so no further
| deferrals are needed.)
| 
| Where does your TREE_LIST idea fit in?  Are you suggesting that the C
| and
| C++ parsers turn comma expressions into TREE_LISTs _instead of_
| COMPOUND_EXPRs, and then turn said TREE_LISTs into either COMPOUND_EXPRs
| or VECTOR_CSTs later on?  This is the only interpretation of your
| TREE_LIST
| suggestion that I could come up with.  I suppose it is doable, but I
| fail
| to see what it buys you aside from an increased memory footprint and
| compile time. :-(

I not telling you to change a COMPOUND_EXPR into a TREE_LIST.
I'm saying that a TREE_LIST is a "more natural" representation and the
C++ parser already represents those things as a TREE_LIST.  Have a
look at cp_parser_initializer.

[...]

| > | > | 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.
| > |
| > | Ok, thanks.  Do you think I should offer a one-line patch for tree.c
| > | (assuming all tests pass, of course)?
| >
| > Given that this will have an interaction with the C++ front-end
| > (meaning that the C++ front-end will have to support it) I would
| > really encourage you to give another try to expression-list as a
| > TREE_LIST.
| 
| I don't follow you here; the C++ front-end also uses COMPOUND_EXPR for
| comma
| expressions; look at build_x_compound_expr().

You're looking at the wrong place, I suppose.

-- Gaby