This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH for c++/65398 (valid constexpr rejected)
- From: Marek Polacek <polacek at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Jason Merrill <jason at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 19 Mar 2015 19:32:56 +0100
- Subject: Re: C++ PATCH for c++/65398 (valid constexpr rejected)
- Authentication-results: sourceware.org; auth=none
- References: <20150313144052 dot GU26802 at redhat dot com> <CAFiYyc02=2DsHrEAADcNLATjGm0BK9Dp1kUb17ZnFDMcGCWpqQ at mail dot gmail dot com> <20150319180536 dot GA1746 at tucnak dot redhat dot com> <20150319181347 dot GK31197 at redhat dot com> <20150319181723 dot GB1746 at tucnak dot redhat dot com>
On Thu, Mar 19, 2015 at 07:17:23PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 19, 2015 at 07:13:47PM +0100, Marek Polacek wrote:
> > On Thu, Mar 19, 2015 at 07:05:36PM +0100, Jakub Jelinek wrote:
> > > I believe cxx_fold_indirect_ref result is not passed through to the
> > > middle-end, unless it can be folded into a constant.
> > >
> > > Though, a question is if we do (or, if we don't and should) reject say
> > > constexpr char s[] = "abc";
> > > constexpr int j = 4;
> > > constexpr char c = *(&s[j] - 2);
> > > because there was out of bound access in there.
> >
> > That is rejected even with my patch with:
> > error: overflow in constant expression [-fpermissive]
> > and without the patch:
> > error: â*((& s[4]) + 18446744073709551614u)â is not a constant expression
> > (a valid constexpr can't have UB).
>
> But s/j = 4/j = 3/ should be valid, don't we reject even that?
> I mean, isn't the rejection because we fold the - 2 early into sizetype
> (unsigned) + -2UL?
Unfortunately we reject even that (regardless the patch), and yeah, it's
because of how POINTER_PLUS_EXPR uses sizetype as a type of the second operand.
E.g.
constexpr char s[] = "abc";
constexpr int j = 1;
constexpr char c = *(&s[j] + 3);
is correctly rejected with the patch:
error: array subscript out of bound
Marek