On Tue, May 31, 2016 at 1:18 PM, Martin Sebor wrote:
> On 03/31/2016 11:54 AM, Jason Merrill wrote:
>>
>> OK, thanks.
>
> This bug was fixed in 6.1 but it is also a GCC 5 regression and
> the patch hasn't been applied there yet. Should I go ahead and
> backport it to the 5.x branch?
It seems saf
On 03/31/2016 11:54 AM, Jason Merrill wrote:
OK, thanks.
This bug was fixed in 6.1 but it is also a GCC 5 regression and
the patch hasn't been applied there yet. Should I go ahead and
backport it to the 5.x branch?
Martin
OK, thanks.
Jason
+ /* Avoid folding references to struct members at offset
0 to
+ prevent tests like '&ptr->firstmember == 0' from getting
+ eliminated. When ptr is null, although the -> expression
+ is strictly speaking invalid, GCC retains it as a matter
+ of QoI.
On 03/30/2016 01:25 PM, Jason Merrill wrote:
On 03/30/2016 12:32 PM, Martin Sebor wrote:
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as
POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be gi
On 03/30/2016 06:50 PM, Martin Sebor wrote:
On 03/30/2016 01:25 PM, Jason Merrill wrote:
On 03/30/2016 12:32 PM, Martin Sebor wrote:
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as
POINTER_PLUS_EXPR or
On 03/30/2016 01:25 PM, Jason Merrill wrote:
On 03/30/2016 12:32 PM, Martin Sebor wrote:
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as
POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be gi
On 03/30/2016 12:32 PM, Martin Sebor wrote:
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be given that this is my first time
working in this
On 03/30/2016 09:30 AM, Jason Merrill wrote:
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be given that this is my first time
working in this area. Which piece of code or what assumptio
On 03/29/2016 11:57 PM, Martin Sebor wrote:
Are we confident that arr[0] won't make it here as POINTER_PLUS_EXPR or
some such?
I'm as confident as I can be given that this is my first time
working in this area. Which piece of code or what assumption
in particular are you concerned about?
I w
On 03/29/2016 12:54 PM, Jason Merrill wrote:
On 03/28/2016 06:04 PM, Martin Sebor wrote:
+ && compare_tree_int (arg1, 0) == 0)
This can be integer_zerop.
Sure.
+case GE_EXPR:
+case EQ_EXPR:
+case LE_EXPR:
+ return boolean_false_node;
+ca
On 03/28/2016 06:04 PM, Martin Sebor wrote:
+ && compare_tree_int (arg1, 0) == 0)
This can be integer_zerop.
+ case GE_EXPR:
+ case EQ_EXPR:
+ case LE_EXPR:
+ return boolean_false_node;
+ case GT_EXPR:
+ case LT_EXPR:
I think let's defer the fix for c++/60760 (i.e. the nullptr_p bits)
until stage 1, when it can be combined with the POINTER_PLUS_EXPR fix,
and put the rest of this patch in now.
I can split up the patch into two and post the subset without
the fix for c++/60760, though I don't expect to be done
On 03/22/2016 04:01 PM, Martin Sebor wrote:
On 03/22/2016 12:52 PM, Jason Merrill wrote:
On 03/21/2016 06:09 PM, Jeff Law wrote:
On 03/21/2016 11:54 AM, Jason Merrill wrote:
Both b0 and b1 are invalid and should be diagnosed, but only b1
is. b1 isn't because because by the time we see its ini
On 03/22/2016 12:52 PM, Jason Merrill wrote:
On 03/21/2016 06:09 PM, Jeff Law wrote:
On 03/21/2016 11:54 AM, Jason Merrill wrote:
Both b0 and b1 are invalid and should be diagnosed, but only b1
is. b1 isn't because because by the time we see its initializer
in constexpr.c it's been transformed
On 03/21/2016 06:09 PM, Jeff Law wrote:
On 03/21/2016 11:54 AM, Jason Merrill wrote:
Both b0 and b1 are invalid and should be diagnosed, but only b1
is. b1 isn't because because by the time we see its initializer
in constexpr.c it's been transformed into the equivalent of "b1
= (int*)ps" (thoug
On 03/21/2016 11:54 AM, Jason Merrill wrote:
Both b0 and b1 are invalid and should be diagnosed, but only b1
is. b1 isn't because because by the time we see its initializer
in constexpr.c it's been transformed into the equivalent of "b1
= (int*)ps" (though we don't see the cast which would also
On 03/18/2016 01:04 PM, Jeff Law wrote:
On 03/17/2016 03:16 PM, Martin Sebor wrote:
The difficulty I've run into with detecting these problems in later
phases is that some invalid expressions have already been simplified
by the front end. The example that applies here (even though this
is still
On 03/14/2016 03:25 PM, Martin Sebor wrote:
The attached patch fixes the outstanding cases mentioned in comment
10 on bug c++/67376. While testing the fix I uncovered a number of
other related problems without which the test would have been
incomplete. They include:
PR c++/70170 - [6 regressio
static tree cxx_eval_constant_expression (const constexpr_ctx *, tree,
- bool, bool *, bool *, tree * = NULL);
+ bool, bool *, bool *, bool * = NULL,
+ tree * = NULL);
I didn't look deeply, but do you end up fixi
On 03/14/2016 04:13 PM, Jakub Jelinek wrote:
On Mon, Mar 14, 2016 at 03:25:07PM -0600, Martin Sebor wrote:
PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
of array fails inside constant expression
PR c++/70170 - [6 regression] bogus not a constant expression error
On 03/17/2016 03:16 PM, Martin Sebor wrote:
gcc-67376.patch
PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
of array fails inside constant expression
PR c++/70170 - [6 regression] bogus not a constant expression error comparing
pointer to array to null
On 03/17/2016 03:16 PM, Martin Sebor wrote:
static tree cxx_eval_constant_expression (const constexpr_ctx *, tree,
- bool, bool *, bool *, tree * = NULL);
+ bool, bool *, bool *, bool * = NULL,
+ tree * = NULL);
On Wed, Mar 16, 2016 at 01:38:21PM -0600, Jeff Law wrote:
> On 03/14/2016 04:13 PM, Jakub Jelinek wrote:
> >On Mon, Mar 14, 2016 at 03:25:07PM -0600, Martin Sebor wrote:
> >>PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
> >>of array fails inside constant expression
> >
On Mon, Mar 14, 2016 at 03:25:07PM -0600, Martin Sebor wrote:
> PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
> of array fails inside constant expression
> PR c++/70170 - [6 regression] bogus not a constant expression error comparing
> pointer to array to null
The attached patch fixes the outstanding cases mentioned in comment
10 on bug c++/67376. While testing the fix I uncovered a number of
other related problems without which the test would have been
incomplete. They include:
PR c++/70170 - [6 regression] bogus not a constant expression error
26 matches
Mail list logo
