Re: C++ PATCH for c++/65398 (valid constexpr rejected)

[Marek Polacek <polacek at redhat dot com>]

On Thu, Mar 19, 2015 at 07:05:36PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 18, 2015 at 11:08:15AM +0100, Richard Biener wrote:
> > On Fri, Mar 13, 2015 at 3:40 PM, Marek Polacek <polacek@redhat.com> wrote:
> > > We started to reject this (IMHO valid) testcase with r214941 that did away with
> > > try_move_mult_to_index -- meaning that we are no longer able to fold *(&s[0] + 1)
> > > into s[1], while we are able to fold *(s + 1) into s[1].
> > >
> > > I suppose cxx_fold_indirect_ref ought to be able to handle both cases, so I added
> > > some code to that effect, it should handle now at least the simple cases...
> > > Or should that be handled in the middle end?
> > 
> > It's "correct" for constexpr folding but not correct to hand s[1] down to
> > the middle-end IL (both cases).  Well, in the particular case with
> > in-array-bound constant and a non-pointer base it's good enough at
> > least.
> 
> 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).

	Marek