> > > > > call fold?
> > > >
> > > > That seems like a good compromise between proper constant evaluation
> > > > and not constant evaluating at all, though I wonder how 'fold' behaves
> > > > w.r.t. to undefined behavior suc
o folds e.g. x*1 to x.
I suppose we want to be pretty conservative with the
constantness test, so I went with CONSTANT_CLASS_P && !TREE_OVERFLOW.
Makes sense.
Like so? Smoke tested so far, bootstrap and regtest on
x86_64-pc-linu-xgnu in progress.
-- >8 --
Subject: [PATCH] c++:
nk we should only return the
> result of 'fold' at this point if it is in fact constant, not if it's a
> non-constant simplification.
Sounds good, I wasn't sure if 'fold' could return a non-constant
simplification. I suppose we want to be pretty conservative with the
#x27;fold' at this point if it is in fact constant, not if
it's a non-constant simplification.
IIUC proper constant evaluation treats UB as non-constant, so it might
be potentially problematic if 'fold' instea dtakes advantage of UB. Or
maybe since we're in an unevalua
behavior such as division by zero and signed overflow?
IIUC proper constant evaluation treats UB as non-constant, so it might
be potentially problematic if 'fold' instea dtakes advantage of UB. Or
maybe since we're in an unevaluated context it doesn't matter?
-- >8 --
Su
On 2/22/23 14:45, Patrick Palka wrote:
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts. T
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts. This shouldn't make a
difference here sinc
