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 <pola...@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
