This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Fix constexpr handling of &x->y (PR c++/84463)
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 Apr 2018 22:55:34 +0000
- Subject: Re: [C++ PATCH] Fix constexpr handling of &x->y (PR c++/84463)
- References: <20180416192843.GT8577@tucnak> <20180416193107.GP5866@tucnak>
On Mon, Apr 16, 2018, 1:31 PM Jakub Jelinek <jakub@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.
>