[PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2016-12-12 Thread Martin Sebor
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-06 Thread Jeff Law
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-06 Thread Jeff Law
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-06 Thread Jeff Law
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-08 Thread Martin Sebor
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-08 Thread Jeff Law
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-11 Thread Christophe Lyon
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-11 Thread Andreas Schwab
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-11 Thread Martin Sebor
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,

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2016-12-13 Thread Richard Biener
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2016-12-13 Thread Marek Polacek
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); >

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2016-12-13 Thread Jeff Law
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-05 Thread Jeff Law
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-05 Thread Martin Sebor
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-05 Thread Jeff Law
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

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

2017-01-05 Thread Martin Sebor
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