This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add LVAL argument to c_fully_fold* and propagate it through (PR c/66618, PR c/69960)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Marek Polacek <polacek at redhat dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 8 Nov 2017 17:17:50 +0000
- Subject: Re: [PATCH] Add LVAL argument to c_fully_fold* and propagate it through (PR c/66618, PR c/69960)
- Authentication-results: sourceware.org; auth=none
- References: <20171108162245.GV14653@tucnak>
On Wed, 8 Nov 2017, Jakub Jelinek wrote:
> of course only if LVAL is false. Additionally, I've added folding of
> "foo"[2] into 'o'. We have it in gimple-fold.c or so, so that one
Note that if the 2 there comes from an overflowing expression that's not
valid as an extension to constant expressions in initializers (that is,
static char c = "foo"[INT_MAX * -2];
should result in an error with -pedantic-errors because of the overflow,
just as INT_MAX * -2 by itself wouldn't be a valid initializer in that
case).
> Not sure about the COND_EXPR/VEC_COND_EXPR cases, right now I'm passing
> false as LVAL for the first operand (condition) and lval as LVAL for the
> other two (i.e. if called with lval == true on the whole *_COND_EXPR
> decl_constant_value_for_optimization etc. isn't performed on op1/op2, while
> without it it is). Can one take address of the whole COND_EXPR, or
> have it on LHS of anything in C? If not, perhaps I could just pass false
> in all the 3 calls. Though, then likely it would be called with lval == false
> anyway.
Conditional and compound expressions are never valid lvalues in C.
--
Joseph S. Myers
joseph@codesourcery.com