This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 breaking out.

Thanks
Martin

gcc-78775.diff


PR tree-optimization/78775 - ICE in maybe_warn_alloc_args_overflow

gcc/ChangeLog:

    PR tree-optimization/78775
    * calls.c (operand_signed_p): Add overload and avoid getting into
    infinite recursion when traversing phi nodes.

gcc/testsuite/ChangeLog:

    PR tree-optimization/78775
    * gcc.dg/pr78775.c: New test.
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 was thinking more at a higher level. ie, are the warnings still useful if we don't have the anti-range handling? I suspect so, but would like to hear your opinion.



  FAIL: gcc.dg/attr-alloc_size-3.c  (test for warnings, line 448)
  FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 137)
  FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 139)
  FAIL: gcc.dg/attr-alloc_size-4.c  (test for warnings, line 175)

with the second one, for example, being:

  n = ~[-4, MAX];   (I.e., n is either negative or too big.)
  p = malloc (n);
Understood. The low level question is do we get these kinds of ranges often enough in computations leading to allocation sizes?



Passing signed integers as arguments to allocation functions is
common so I've been looking into how else to avoid the phi recursion
(which I assume is the concern here) without compromising this case.
Removing just the operand_signed_p() handling causes a number of
false positives in the test suite, such as for
Yes, passing signed integers as arguments is common. But how often do we have one of these anti-ranges that allows us to do something useful?




  m = [-3, 7];
  n = [-5, 11];
  p = calloc (m, n);

which I suspect are common in the wild as well.
I must be missing something, given those ranges I wouldn't think we have a false positive. The resulting size computation is going to have a range [-35, 88], right? ISTM that we'd really want to warn for that. I must be missing something.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]