On Mon, Apr 16, 2018, 1:31 PM Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, Apr 16, 2018 at 09:28:43PM +0200, Jakub Jelinek wrote: > > On the following new testcase we emit 2 different constexpr errors > > because of premature folding, where the PR44100 hack which is supposed > > to fold expressions like &((S *)0)->f or > > &((S *)24)->f folds all the &x->y expressions if x is TREE_CONSTANT > > into (some type)(x + cst) where what we were actually trying to access > > is lost. > > > > The following patch limits the offsetof-like expression hack to > expressions > > where maybe_constant_value of val's operand is INTEGER_CST, or e.g. > > a cast of INTEGER_CST to some pointer type. This way we don't regress > > e.g. init/struct2.C, but don't mess up with x is e.g. some constexpr > > variable initialized to address of something. Or should it avoid > > maybe_constant_value and just handle the literal INTEGER_CST and cast > > thereof? We wouldn't handle &((S *)(24 + 8))->f that way though... > > Or shall we move this folding to cp_fold instead of cp_build_addr_expr_1 > (while keeping it limited to INTEGER_CST pointers)? Yes, I think that would be better. >