OK, thanks.
Jason
Turned out that my earlier fix for this PR didn't handle cases where we aren't
dealing with an INDIRECT_REF expression, which means we fail to compile valid
code. Fixed by moving the folding to cxx_eval_constant_expression, where we
ought to be able to reduce all POINTER_PLUS_EXPRs in a constexpr
On 03/20/2015 05:03 PM, Jakub Jelinek wrote:
Hi!
Just for completeness:
On Fri, Mar 20, 2015 at 09:56:52PM +0100, Marek Polacek wrote:
+constexpr char d1 = *(&s[4] - 0); // { dg-error "array subscript out of bound"
}
+constexpr char d2 = *(&s[4] - 1);
+constexpr char d3 = *(&s[4] - 2);
+const
Hi!
Just for completeness:
On Fri, Mar 20, 2015 at 09:56:52PM +0100, Marek Polacek wrote:
> +constexpr char d1 = *(&s[4] - 0); // { dg-error "array subscript out of
> bound" }
> +constexpr char d2 = *(&s[4] - 1);
> +constexpr char d3 = *(&s[4] - 2);
> +constexpr char d4 = *(&s[4] - 3);
> +conste
On Fri, Mar 20, 2015 at 10:53:50AM -0400, Jason Merrill wrote:
> On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
> >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
On Fri, Mar 20, 2015 at 11:15:30AM -0400, Jason Merrill wrote:
> On 03/20/2015 11:11 AM, Jakub Jelinek wrote:
> >>&s[3] is the address of the terminal \0.
> >
> >Yeah, sure. But the above testcase does &s[4], which is out of bounds
> >arithmetics
>
> But since &s[3] is the address of an element o
On 03/20/2015 11:11 AM, Jakub Jelinek wrote:
&s[3] is the address of the terminal \0.
Yeah, sure. But the above testcase does &s[4], which is out of bounds
arithmetics
But since &s[3] is the address of an element of the array (the NUL),
&s[4] is one-past-the-end, which is fine. &s[5] would
On Fri, Mar 20, 2015 at 11:02:59AM -0400, Jason Merrill wrote:
> On 03/20/2015 10:59 AM, Jakub Jelinek wrote:
> >On Fri, Mar 20, 2015 at 10:53:50AM -0400, Jason Merrill wrote:
> >>On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
> >>>Though, a question is if we do (or, if we don't and should) reject sa
On 03/20/2015 10:59 AM, Jakub Jelinek wrote:
On Fri, Mar 20, 2015 at 10:53:50AM -0400, Jason Merrill wrote:
On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
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 = *(&
On Fri, Mar 20, 2015 at 10:53:50AM -0400, Jason Merrill wrote:
> On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
> >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
On 03/19/2015 02:05 PM, Jakub Jelinek wrote:
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.
I don't see an out-of-bound access in this exampl
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 ca
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 (o
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 wrote:
> > > We started to reject this (IMHO valid) testcase with r214941 that did
> > > away with
> > > try_move_mul
On Wed, Mar 18, 2015 at 11:08:15AM +0100, Richard Biener wrote:
> On Fri, Mar 13, 2015 at 3:40 PM, Marek Polacek 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
On Fri, Mar 13, 2015 at 3:40 PM, Marek Polacek 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
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
a
17 matches
Mail list logo
