[c++-delayed-folding] fold_simple

Kai Tietz ktietz70@googlemail.com
Sat Aug 29 14:20:00 GMT 2015


2015-08-29 6:45 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 08/27/2015 05:21 AM, Kai Tietz wrote:
>>
>> 2015-08-27 4:57 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>
>>> Why does fold_simple fold so many patterns?  I thought we wanted
>>> something
>>> that would just fold conversions and negations of constant values.
>>
>>
>> Yes, initial variant was handling much less patterns.  But actually we
>> need for functions (eg. like build_vec_init in init.c) a simple
>> routine to perform basic constant-value arithmetics (sizeof * / + -
>> trunc, etc) to avoid call of maybe_constant_value.  Also for
>> overflow-diagnostics we want at least to resolve such simple patterns
>> for constant-values only.  We could change those calls to use
>> maybe_constant_value instead, but the overhead (and some of its
>> folding) leads much further then working on constant-values only (as
>> fold_simple does).
>
>
> For build_vec_init, since whether maxindex is constant has semantic meaning,
> I think we want maybe_constant_value.

So you mean that handling of constexprs within vector-init is
something we need.  Ok. I will test a replace.

> I think we also want it for overflow warnings, to get better diagnostics.

Hmm, I don't think we want to call maybe_constant_value in functions
like cp_build_binary_op. We are interested in overflow only on
constant-values anyway, I don't see that we want to have here any
constexpr-logic, nor specific address-manipulation logic.  So I see
here not much advantage in using maybe_constant_value.  Maybe I simply
not seeing the obvious here.  Do you have a specific testcase, which
shows what diagnostics could be missed?

> Jason
>

Kai



More information about the Gcc-patches mailing list