public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB
@ 2021-11-30 17:22 stsp at users dot sourceforge.net
  2021-11-30 21:20 ` [Bug c/103502] " pinskia at gcc dot gnu.org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: stsp at users dot sourceforge.net @ 2021-11-30 17:22 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 103502
           Summary: -Wstrict-aliasing=3 doesn't warn on what is documented
                    as UB
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
---
Similarly, access by taking the address, casting the resulting pointer and
dereferencing the result has undefined behavior, even if the cast uses a union
type, e.g.:

int f() {
  double d = 3.0;
  return ((union a_union *) &d)->i;
}
---

Here is the test-case:
---
union a_union {
  int i;
  double d;
};

static int f() {
  double d = 3.0;
  return ((union a_union *) &d)->i;
}

int main()
{
    return f();
}
---

It only warns at -Wstrict-aliasing=2 or 1,
but doesn't on 3. 3 is documented as the
most precise option. So obviously it should
warn on what the official gcc manual declares
as an UB.

Note: I very much wish such construct to
not be UB. Because of the lack of a warning
on -Wstrict-aliasing=3 I was freely using
such construct for type-punning for years...
until now I've found it invalid in gcc manual.
If it is actually valid, please fix the docs,
not gcc! :)

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

* [Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
  2021-11-30 17:22 [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB stsp at users dot sourceforge.net
@ 2021-11-30 21:20 ` pinskia at gcc dot gnu.org
  2021-11-30 21:30 ` stsp at users dot sourceforge.net
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-30 21:20 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The documentation
(https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options) for
the warning is clear here:
"Takes care of the common pun+dereference pattern in the front end:
*(int*)&some_float. "

>3 is documented as the most precise option

I think you misunderstood what precise means in this context really.
"Higher levels correspond to higher accuracy (fewer false positives). "

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

* [Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
  2021-11-30 17:22 [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB stsp at users dot sourceforge.net
  2021-11-30 21:20 ` [Bug c/103502] " pinskia at gcc dot gnu.org
@ 2021-11-30 21:30 ` stsp at users dot sourceforge.net
  2021-11-30 21:34 ` pinskia at gcc dot gnu.org
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: stsp at users dot sourceforge.net @ 2021-11-30 21:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Andrew Pinski from comment #1)
> I think you misunderstood what precise means in this context really.
> "Higher levels correspond to higher accuracy (fewer false positives). "

So was it a false-positive?

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

* [Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
  2021-11-30 17:22 [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB stsp at users dot sourceforge.net
  2021-11-30 21:20 ` [Bug c/103502] " pinskia at gcc dot gnu.org
  2021-11-30 21:30 ` stsp at users dot sourceforge.net
@ 2021-11-30 21:34 ` pinskia at gcc dot gnu.org
  2021-11-30 21:41 ` stsp at users dot sourceforge.net
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-30 21:34 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Stas Sergeev from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I think you misunderstood what precise means in this context really.
> > "Higher levels correspond to higher accuracy (fewer false positives). "
> 
> So was it a false-positive?

There are still false negatives.

You missed the first part:
"Takes care of the common pun+dereference pattern in the front end:
*(int*)&some_float. "

Because GCC can optimize that pun+dereference pattern without not breaking the
code, GCC decided it should not warn with =3.

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

* [Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
  2021-11-30 17:22 [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB stsp at users dot sourceforge.net
                   ` (2 preceding siblings ...)
  2021-11-30 21:34 ` pinskia at gcc dot gnu.org
@ 2021-11-30 21:41 ` stsp at users dot sourceforge.net
  2021-11-30 22:07 ` stsp at users dot sourceforge.net
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 8+ messages in thread
From: stsp at users dot sourceforge.net @ 2021-11-30 21:41 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Andrew Pinski from comment #3)
> Because GCC can optimize that pun+dereference pattern without _not_ breaking

Did you mean to say "without breaking the code"?
I will assume it is the case:

> the code, GCC decided it should not warn with =3.

So there is no breakage then?
Can I trust this no-warning?
Or what did the above "not" meant?

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

* [Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
  2021-11-30 17:22 [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB stsp at users dot sourceforge.net
                   ` (3 preceding siblings ...)
  2021-11-30 21:41 ` stsp at users dot sourceforge.net
@ 2021-11-30 22:07 ` stsp at users dot sourceforge.net
  2021-12-01  0:28 ` egallager at gcc dot gnu.org
  2021-12-01  1:26 ` stsp at users dot sourceforge.net
  6 siblings, 0 replies; 8+ messages in thread
From: stsp at users dot sourceforge.net @ 2021-11-30 22:07 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Stas Sergeev <stsp at users dot sourceforge.net> ---
Note that this code example
is trivial. If the warning have
disappeared as a false-negative,
then I am surprised you close this
as NOTABUG, as there is definitely
something to fix or improve here.
Not detecting such a trivial case
is a bug.

If OTOH gcc actually deduced that
this code is safe, then I am more
than happy, but this have to be
confirmed explicitly.
You inserted the seemingly redundant
"not" in your sentence, so I am not
sure what you actually meant to say.

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

* [Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
  2021-11-30 17:22 [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB stsp at users dot sourceforge.net
                   ` (4 preceding siblings ...)
  2021-11-30 22:07 ` stsp at users dot sourceforge.net
@ 2021-12-01  0:28 ` egallager at gcc dot gnu.org
  2021-12-01  1:26 ` stsp at users dot sourceforge.net
  6 siblings, 0 replies; 8+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-12-01  0:28 UTC (permalink / raw)
  To: gcc-bugs

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> The documentation
> (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options)
> for the warning is clear here:
> "Takes care of the common pun+dereference pattern in the front end:
> *(int*)&some_float. "
> 
> >3 is documented as the most precise option
> 
> I think you misunderstood what precise means in this context really.
> "Higher levels correspond to higher accuracy (fewer false positives). "

-Wstrict-aliasing is kind of confusing in this regards since it's different
from how other warnings with numerical levels work. Normally a higher numerical
value to a warning option means "print more warnings" but for -Wstrict-aliasing
it means "try harder to reduce the number of warnings". Perhaps this is an
inconsistency that should be rectified?

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

* [Bug c/103502] -Wstrict-aliasing=3 doesn't warn on what is documented as UB
  2021-11-30 17:22 [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB stsp at users dot sourceforge.net
                   ` (5 preceding siblings ...)
  2021-12-01  0:28 ` egallager at gcc dot gnu.org
@ 2021-12-01  1:26 ` stsp at users dot sourceforge.net
  6 siblings, 0 replies; 8+ messages in thread
From: stsp at users dot sourceforge.net @ 2021-12-01  1:26 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Eric Gallager from comment #6)
> -Wstrict-aliasing is kind of confusing in this regards since it's different
> from how other warnings with numerical levels work. Normally a higher
> numerical value to a warning option means "print more warnings" but for
> -Wstrict-aliasing it means "try harder to reduce the number of warnings".

Number of warnings, or number
of false-positives?
This is what is still unclear
to me. If it reduces the number
of warnings (including valid ones,
by not applying some checks for
example), then indeed what you propose
can be done (or not done - it would
be rather straight-forward anyway).

But I had the following assumptions:
1. It reduces the number of only false-positives
2. It increases the amount of warnings by avoiding false-negatives
(i.e. by not "hiding" the warnings that lower
levels could miss)
3. The warning I've seen on lower levels was a valid one

I suppose what you propose, can
be done if 2 is not true.
I still don't know which of the
above wasn't true.

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

end of thread, other threads:[~2021-12-01  1:26 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-30 17:22 [Bug c/103502] New: -Wstrict-aliasing=3 doesn't warn on what is documented as UB stsp at users dot sourceforge.net
2021-11-30 21:20 ` [Bug c/103502] " pinskia at gcc dot gnu.org
2021-11-30 21:30 ` stsp at users dot sourceforge.net
2021-11-30 21:34 ` pinskia at gcc dot gnu.org
2021-11-30 21:41 ` stsp at users dot sourceforge.net
2021-11-30 22:07 ` stsp at users dot sourceforge.net
2021-12-01  0:28 ` egallager at gcc dot gnu.org
2021-12-01  1:26 ` stsp at users dot sourceforge.net

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).