[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue

2019-11-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264

--- Comment #7 from Jakub Jelinek  ---
Either the function guarantees that *seq will be always non-NULL (at least if
the call doesn't return negative), but then there is no point in using out &&
*out, you can as well just use *out, because out will never be NULL.  Or the
function doesn't guarantee it and if it is NULL, the code will crash.

[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue

2019-11-27 Thread zhroma at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264

--- Comment #6 from Roman Zhuykov  ---
Ok, this seems quite clear from compiler developer point of view.

But I still want to add, that for compiler user, who knows how asprintf
function works, "Line A" version is correct and warning seems unnecessary.
While "Line B" version where user forget about bail-out is compiled smoothly.

[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue

2019-11-25 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jakub Jelinek  ---
The warning started with r270574.
That said, I don't see why it wouldn't be fine to warn with line A and not warn
with line B, there is a significant difference between the two, in particular
that with line A, len is known to be in range [1, INT_MAX] in the
  if ((out - *seq) > len) return -2;
statement, and as there is out && in the condition, showing that *seq in theory
could be NULL, the compiler considers that path, and that path is broken with
line A, because the for loop will not do anything, out == *seq == NULL,
out - *seq is 0 and that is never > 1 or larger and thus *out will be
dereferenced.
Compare that to line B, where nothing is known about len value, it could be 0,
or could be negative, so it is possible that return -2; will happen in that
case and the invalid dereference will not happen.

[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue

2019-10-22 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue

2019-04-29 Thread zhroma at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264

Roman Zhuykov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2019-04-29
 Resolution|INVALID |---
Summary|[9/10 Regression]   |[9/10 Regression]
   |-Wnull-dereference false|-Wnull-dereference QoI
   |positive after r270574  |issue
 Ever confirmed|0   |1

--- Comment #4 from Roman Zhuykov  ---
Let me perhaps explain better.  Function asprintf should set *s to point
allocated memory and return non-negative amount of printed chars.  When
allocation fails it will return -1.  So, there are really no issue in the
original code, but compiler isn’t clever enough to know how asprintf works.

Gcc 8 doesn’t warn, thats why I’ve created this bugreport as false-positive. 
So, here trunk gives a warning: https://godbolt.org/z/-o6UMv

If we decide that warning is correct, we must also warn same code, when -1
bailout removed: https://godbolt.org/z/ayb9pS

Than we have a false negative and it is *not* a “9 Regression”, but we have to
fix it.

I also want to note, that when -2 bail out is removed from both examples, 8.3
and trunk give a warning.  There is a separate issue with gcc 8.3 here, it
warns two times.

: In function 'cn_sequence':
:11:8: warning: potential null pointer dereference [-Wnull-dereference]
   *out = '\0';
   ~^~
:11:8: warning: potential null pointer dereference [-Wnull-dereference]
Compiler returned: 0

But I haven’t checked recent 8-branch, maybe that was fixed and backported
after  8.3.