On 01/11/2017 02:05 AM, Christophe Lyon wrote:
Hi Martin,
On 9 January 2017 at 04:14, Jeff Law wrote:
On 01/08/2017 02:04 PM, Martin Sebor wrote:
On 01/06/2017 09:45 AM, Jeff Law wrote:
On 01/05/2017 08:52 PM, Martin Sebor wrote:
So Richi asked for removal of the VR_ANTI_RANGE handling,
On Jan 11 2017, Christophe Lyon wrote:
> The new test (gcc.dg/pr78973.c) fails on arm targets (there's no warning).
Also fails on m68k.
> In addition, I have noticed a new failure:
> gcc.dg/attr-alloc_size-4.c (test for warnings, line 140)
> on target arm-none-linux-gnueabihf --with-cpu=cort
Hi Martin,
On 9 January 2017 at 04:14, Jeff Law wrote:
> On 01/08/2017 02:04 PM, Martin Sebor wrote:
>>
>> On 01/06/2017 09:45 AM, Jeff Law wrote:
>>>
>>> On 01/05/2017 08:52 PM, Martin Sebor wrote:
>>>
>>> So Richi asked for removal of the VR_ANTI_RANGE handling, which would
>>> impl
On 01/08/2017 02:04 PM, Martin Sebor wrote:
On 01/06/2017 09:45 AM, Jeff Law wrote:
On 01/05/2017 08:52 PM, Martin Sebor wrote:
So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.
What are the implications if we do that?
I just got back to
On 01/06/2017 09:45 AM, Jeff Law wrote:
On 01/05/2017 08:52 PM, Martin Sebor wrote:
So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.
What are the implications if we do that?
I just got back to this yesterday. The implications of the rem
Another approach would be to walk the SSA_NAME list and generate a
bitmap of all the names which have a signed type or which were defined
by a conversion to an unsigned type from a signed type.
At that point what's left is just the PHIs. So we'd walk the dominator
tree in RPO order to proc
On 01/05/2017 08:52 PM, Martin Sebor wrote:
So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.
What are the implications if we do that?
I just got back to this yesterday. The implications of the removal
of the anti-range handling are a num
On 01/05/2017 08:52 PM, Martin Sebor wrote:
So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.
What are the implications if we do that?
I just got back to this yesterday. The implications of the removal
of the anti-range handling are a num
So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.
What are the implications if we do that?
I just got back to this yesterday. The implications of the removal
of the anti-range handling are a number of false negatives in the
test suite:
I
On 01/05/2017 11:49 AM, Martin Sebor wrote:
On 01/05/2017 11:03 AM, Jeff Law wrote:
On 12/12/2016 06:36 PM, Martin Sebor wrote:
The attached patch avoids infinite recursion when traversing phi
nodes in maybe_warn_alloc_args_overflow by using a bitmap to keep
track of those already visited and b
On 01/05/2017 11:03 AM, Jeff Law wrote:
On 12/12/2016 06:36 PM, Martin Sebor wrote:
The attached patch avoids infinite recursion when traversing phi
nodes in maybe_warn_alloc_args_overflow by using a bitmap to keep
track of those already visited and breaking out.
Thanks
Martin
gcc-78775.diff
On 12/12/2016 06:36 PM, Martin Sebor wrote:
The attached patch avoids infinite recursion when traversing phi
nodes in maybe_warn_alloc_args_overflow by using a bitmap to keep
track of those already visited and breaking out.
Thanks
Martin
gcc-78775.diff
PR tree-optimization/78775 - ICE in mayb
On 12/13/2016 03:52 AM, Marek Polacek wrote:
On Mon, Dec 12, 2016 at 06:36:16PM -0700, Martin Sebor wrote:
+/* Return true if the type of OP is signed, looking through any casts
+ to an unsigned type. */
+
+static bool
+operand_signed_p (tree op)
+{
+ bitmap visited = NULL;
+ bool ret = ope
On Mon, Dec 12, 2016 at 06:36:16PM -0700, Martin Sebor wrote:
> +/* Return true if the type of OP is signed, looking through any casts
> + to an unsigned type. */
> +
> +static bool
> +operand_signed_p (tree op)
> +{
> + bitmap visited = NULL;
> + bool ret = operand_signed_p (op, &visited);
>
On Tue, Dec 13, 2016 at 2:36 AM, Martin Sebor wrote:
> The attached patch avoids infinite recursion when traversing phi
> nodes in maybe_warn_alloc_args_overflow by using a bitmap to keep
> track of those already visited and breaking out.
It looks somewhat excessive (the whole PHI node walk looks
The attached patch avoids infinite recursion when traversing phi
nodes in maybe_warn_alloc_args_overflow by using a bitmap to keep
track of those already visited and breaking out.
Thanks
Martin
PR tree-optimization/78775 - ICE in maybe_warn_alloc_args_overflow
gcc/ChangeLog:
PR tree-optimizati
16 matches
Mail list logo
