public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/110402] New: Bogus -Waddress warning that pointer comparison is always true
@ 2023-06-25  9:58 lsof at mailbox dot org
  2023-06-25 10:31 ` [Bug c/110402] " schwab@linux-m68k.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: lsof at mailbox dot org @ 2023-06-25  9:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402

            Bug ID: 110402
           Summary: Bogus -Waddress warning that pointer comparison is
                    always true
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lsof at mailbox dot org
  Target Milestone: ---

Created attachment 55398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55398&action=edit
testcase

In the following testcase:


struct m { float *v; int t; };

_Bool chk(struct m *m, int key) {
    return (m->t = key) < 0 ? 0 : &m->v[key];
}

/* a comma expression can suppress it */
_Bool chk2(struct m *m, int key) {
    return (m->t = key, m->t < 0 ? 0 : &m->v[key]);
}

/* however, this does NOT warn */
_Bool chk3(struct m *m, int key) {
    return (m->t = key) < 0 ? &m->v[key] : &m->v[key];
}


gcc -Waddress gives this warning:

x.c: In function ‘chk’:
x.c:4:5: warning: the comparison will always evaluate as ‘true’ for the pointer
operand in ‘m->v + (sizetype)((long unsigned int)key * 4)’ must not be NULL
[-Waddress]
    4 |     return key < 0 ? 0 : &m->v[key];
      |     ^~~~~~

In particular the second function does not produce the warning (correctly), but
the third function for which the warning actually applies does not give a
warning.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
  2023-06-25  9:58 [Bug c/110402] New: Bogus -Waddress warning that pointer comparison is always true lsof at mailbox dot org
@ 2023-06-25 10:31 ` schwab@linux-m68k.org
  2023-06-25 13:06 ` pinskia at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: schwab@linux-m68k.org @ 2023-06-25 10:31 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
The error message does not match anything from the test case.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
  2023-06-25  9:58 [Bug c/110402] New: Bogus -Waddress warning that pointer comparison is always true lsof at mailbox dot org
  2023-06-25 10:31 ` [Bug c/110402] " schwab@linux-m68k.org
@ 2023-06-25 13:06 ` pinskia at gcc dot gnu.org
  2023-06-25 14:12 ` lsof at mailbox dot org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-25 13:06 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
We warn about:
```
struct m { float *v; int t; };

_Bool chk1(struct m *m, int key) {
    return &m->v[key];
}
```
```
<source>: In function 'chk1':
<source>:4:5: warning: the comparison will always evaluate as 'true' for the
pointer operand in 'm->v + (sizetype)((long unsigned int)key * 4)' must not be
NULL [-Waddress]
    4 |     return &m->v[key];
      |     ^~~~~~
```

The reason why the others in your testcase is not being warned about is more
about the shape of the ?: and/or the comma operator getting in the way of
moving the implict `!=0` into the `?:`.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
  2023-06-25  9:58 [Bug c/110402] New: Bogus -Waddress warning that pointer comparison is always true lsof at mailbox dot org
  2023-06-25 10:31 ` [Bug c/110402] " schwab@linux-m68k.org
  2023-06-25 13:06 ` pinskia at gcc dot gnu.org
@ 2023-06-25 14:12 ` lsof at mailbox dot org
  2023-06-25 14:26 ` lsof at mailbox dot org
  2024-04-05 18:04 ` pinskia at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: lsof at mailbox dot org @ 2023-06-25 14:12 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402

--- Comment #3 from lsof at mailbox dot org ---
(In reply to Andrew Pinski from comment #2)
> We warn about:
> ```
> struct m { float *v; int t; };
> 
> _Bool chk1(struct m *m, int key) {
>     return &m->v[key];
> }
> ```
> ```
> <source>: In function 'chk1':
> <source>:4:5: warning: the comparison will always evaluate as 'true' for the
> pointer operand in 'm->v + (sizetype)((long unsigned int)key * 4)' must not
> be NULL [-Waddress]
>     4 |     return &m->v[key];
>       |     ^~~~~~
> ```
> 
> The reason why the others in your testcase is not being warned about is more
> about the shape of the ?: and/or the comma operator getting in the way of
> moving the implict `!=0` into the `?:`.

I understand why it warns about `&m->v[key] != 0`; but when contained in a
larger expression like ```(key < 0 ? 0 : &m->v[key]) (!= 0)``` I don't think
the warning is useful.

(In reply to Andreas Schwab from comment #1)

> The error message does not match anything from the test case.

Now that I think about it, you're right; if `m->v` is null and `key` is 0,
`&m->v[key] != 0` can definitely evaluate to false. So I don't know why GCC is
emitting the warning here in the first place. Even the backend disagrees with
the frontend, because if it were true that `&m->v[key] != 0` always evaluates
as true as the diagnostic says, the optimizer would elide the check, but it
does not.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
  2023-06-25  9:58 [Bug c/110402] New: Bogus -Waddress warning that pointer comparison is always true lsof at mailbox dot org
                   ` (2 preceding siblings ...)
  2023-06-25 14:12 ` lsof at mailbox dot org
@ 2023-06-25 14:26 ` lsof at mailbox dot org
  2024-04-05 18:04 ` pinskia at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: lsof at mailbox dot org @ 2023-06-25 14:26 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402

--- Comment #4 from lsof at mailbox dot org ---
I retract my previous comment about `&v[key] != 0` being possibly false, since
in C it is undefined behavior to perform pointer arithmetic on the null pointer
even with an addend of zero. But I still think that it shouldn't occur in the
context of a subexpression like the one in the testcase.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
  2023-06-25  9:58 [Bug c/110402] New: Bogus -Waddress warning that pointer comparison is always true lsof at mailbox dot org
                   ` (3 preceding siblings ...)
  2023-06-25 14:26 ` lsof at mailbox dot org
@ 2024-04-05 18:04 ` pinskia at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-04-05 18:04 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Oh the location for the diagnostic is in the wrong spot. So a dup of bug
102967.

*** This bug has been marked as a duplicate of bug 102967 ***

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-04-05 18:04 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-25  9:58 [Bug c/110402] New: Bogus -Waddress warning that pointer comparison is always true lsof at mailbox dot org
2023-06-25 10:31 ` [Bug c/110402] " schwab@linux-m68k.org
2023-06-25 13:06 ` pinskia at gcc dot gnu.org
2023-06-25 14:12 ` lsof at mailbox dot org
2023-06-25 14:26 ` lsof at mailbox dot org
2024-04-05 18:04 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).