public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/101537] New: -Wconversion false positive in ternary
@ 2021-07-20 17:41 me at xenu dot pl
2021-08-08 15:15 ` [Bug c++/101537] " nok.raven at gmail dot com
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: me at xenu dot pl @ 2021-07-20 17:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Bug ID: 101537
Summary: -Wconversion false positive in ternary
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at xenu dot pl
Target Milestone: ---
The following code:
int foo() {
int aaa = 1;
unsigned char bbb = 0;
bbb |= aaa ? 1 : 0;
return bbb;
}
Gives this warning:
<source>: In function 'foo':
<source>:4:12: warning: conversion from 'int' to 'unsigned char' may change
value [-Wconversion]
4 | bbb |= aaa ? 1 : 0;
| ^~~
Compiler returned: 0
It happens both in C and C++ modes.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/101537] -Wconversion false positive in ternary
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
@ 2021-08-08 15:15 ` nok.raven at gmail dot com
2021-08-12 23:47 ` [Bug c/101537] -Wconversion false positive in ternary and |= pinskia at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: nok.raven at gmail dot com @ 2021-08-08 15:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Nikita Kniazev <nok.raven at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nok.raven at gmail dot com
--- Comment #1 from Nikita Kniazev <nok.raven at gmail dot com> ---
int foo(unsigned char x, bool f) {
x |= f ? 1 : 0; // warning
return x;
}
int bar(unsigned char x, bool f) {
x = x | f ? 1 : 0; // no warning
return x;
}
it also warns only for self-operators
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/101537] -Wconversion false positive in ternary and |=
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
2021-08-08 15:15 ` [Bug c++/101537] " nok.raven at gmail dot com
@ 2021-08-12 23:47 ` pinskia at gcc dot gnu.org
2021-12-31 17:25 ` thomas at habets dot se
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-12 23:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2021-08-12
Summary|-Wconversion false positive |-Wconversion false positive
|in ternary |in ternary and |=
Component|c++ |c
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. There is code to supress this if both operands of ?: are fine but
for some reason it is not triggering.
Note I was just looking at that code for another bug.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/101537] -Wconversion false positive in ternary and |=
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
2021-08-08 15:15 ` [Bug c++/101537] " nok.raven at gmail dot com
2021-08-12 23:47 ` [Bug c/101537] -Wconversion false positive in ternary and |= pinskia at gcc dot gnu.org
@ 2021-12-31 17:25 ` thomas at habets dot se
2021-12-31 22:34 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: thomas at habets dot se @ 2021-12-31 17:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
thomas at habets dot se changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thomas at habets dot se
--- Comment #3 from thomas at habets dot se ---
This may be related, as the bug I just filed seemed to be another case of the
warning not being suppressed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103881
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/101537] -Wconversion false positive in ternary and |=
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
` (2 preceding siblings ...)
2021-12-31 17:25 ` thomas at habets dot se
@ 2021-12-31 22:34 ` jakub at gcc dot gnu.org
2022-01-03 11:52 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-12-31 22:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52105
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52105&action=edit
gcc12-pr101537.patch
Untested fix. The PR101537 is fixed by this in both C and C++, PR103881 only
in C; for C++ we end up with a COMPOUND_EXPR with TARGET_EXPR and then
BIT_IOR_EXPR of something and the TARGET_EXPR_DECL. We'd need to remember when
looking through COMPOUND_EXPRs if they don't have TARGET_EXPRs on the lhs and
if so, remember for conversion_warning the mapping from their TARGET_EXPR_DECLs
to those TARGET_EXPRs, so that we could then look those up.
But it seems unsafe_conversion_p has some BIT_*_EXPR handling code, so that
would need to be copied over into conversion_warning too.
Or perhaps alternatively we could change unsafe_conversion_p to handle whatever
is missing in there (SAVE_EXPRs, TARGET_EXPRs etc.).
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/101537] -Wconversion false positive in ternary and |=
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
` (3 preceding siblings ...)
2021-12-31 22:34 ` jakub at gcc dot gnu.org
@ 2022-01-03 11:52 ` jakub at gcc dot gnu.org
2022-01-11 18:15 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-03 11:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #52105|0 |1
is obsolete| |
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52112
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52112&action=edit
gcc12-pr101537.patch
Updated patch.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/101537] -Wconversion false positive in ternary and |=
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
` (4 preceding siblings ...)
2022-01-03 11:52 ` jakub at gcc dot gnu.org
@ 2022-01-11 18:15 ` cvs-commit at gcc dot gnu.org
2022-01-24 9:21 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-01-11 18:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:20e4a5e573e76f4379b353cc736215a5f10cdb84
commit r12-6486-g20e4a5e573e76f4379b353cc736215a5f10cdb84
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Jan 11 19:11:51 2022 +0100
c-family: Fix up -W*conversion on bitwise &/|/^ [PR101537]
The following testcases emit a bogus -Wconversion warning. This is because
conversion_warning function doesn't handle BIT_*_EXPR (only
unsafe_conversion_p
that is called during the default: case, and that one doesn't handle
SAVE_EXPRs added because the unsigned char & or | operands promoted to int
have side-effects and =| or =& is used.
The patch handles BIT_IOR_EXPR/BIT_XOR_EXPR like the last 2 operands of
COND_EXPR by recursing on the two operands, if either of them doesn't fit
into the narrower type, complain. BIT_AND_EXPR too, but first it needs to
handle some special cases that unsafe_conversion_p does, namely when one
of the two operands is a constant.
This fixes completely the pr101537.c test and for C also pr103881.c
and doesn't regress anything in the testsuite, for C++ pr103881.c still
emits the bogus warnings.
This is because while the C FE emits in that case a SAVE_EXPR that
conversion_warning can handle already, C++ FE emits
TARGET_EXPR <D.whatever, ...>, something | D.whatever
etc. and conversion_warning handles COMPOUND_EXPR by "recursing" on the
rhs. To handle that case, we'd need for TARGET_EXPR on the lhs remember
in some hash map the mapping from D.whatever to the TARGET_EXPR and when
we see D.whatever, use corresponding TARGET_EXPR initializer instead.
2022-01-11 Jakub Jelinek <jakub@redhat.com>
PR c/101537
PR c/103881
gcc/c-family/
* c-warn.c (conversion_warning): Handle BIT_AND_EXPR, BIT_IOR_EXPR
and BIT_XOR_EXPR.
gcc/testsuite/
* c-c++-common/pr101537.c: New test.
* c-c++-common/pr103881.c: New test.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/101537] -Wconversion false positive in ternary and |=
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
` (5 preceding siblings ...)
2022-01-11 18:15 ` cvs-commit at gcc dot gnu.org
@ 2022-01-24 9:21 ` cvs-commit at gcc dot gnu.org
2022-05-10 8:22 ` cvs-commit at gcc dot gnu.org
2023-06-29 15:31 ` wolter.hellmundvega at tevva dot com
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-01-24 9:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:777b73e45983b11e010bd5192185ad01af444de4
commit r11-9500-g777b73e45983b11e010bd5192185ad01af444de4
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Jan 11 19:11:51 2022 +0100
c-family: Fix up -W*conversion on bitwise &/|/^ [PR101537]
The following testcases emit a bogus -Wconversion warning. This is because
conversion_warning function doesn't handle BIT_*_EXPR (only
unsafe_conversion_p
that is called during the default: case, and that one doesn't handle
SAVE_EXPRs added because the unsigned char & or | operands promoted to int
have side-effects and =| or =& is used.
The patch handles BIT_IOR_EXPR/BIT_XOR_EXPR like the last 2 operands of
COND_EXPR by recursing on the two operands, if either of them doesn't fit
into the narrower type, complain. BIT_AND_EXPR too, but first it needs to
handle some special cases that unsafe_conversion_p does, namely when one
of the two operands is a constant.
This fixes completely the pr101537.c test and for C also pr103881.c
and doesn't regress anything in the testsuite, for C++ pr103881.c still
emits the bogus warnings.
This is because while the C FE emits in that case a SAVE_EXPR that
conversion_warning can handle already, C++ FE emits
TARGET_EXPR <D.whatever, ...>, something | D.whatever
etc. and conversion_warning handles COMPOUND_EXPR by "recursing" on the
rhs. To handle that case, we'd need for TARGET_EXPR on the lhs remember
in some hash map the mapping from D.whatever to the TARGET_EXPR and when
we see D.whatever, use corresponding TARGET_EXPR initializer instead.
2022-01-11 Jakub Jelinek <jakub@redhat.com>
PR c/101537
PR c/103881
gcc/c-family/
* c-warn.c (conversion_warning): Handle BIT_AND_EXPR, BIT_IOR_EXPR
and BIT_XOR_EXPR.
gcc/testsuite/
* c-c++-common/pr101537.c: New test.
* c-c++-common/pr103881.c: New test.
(cherry picked from commit 20e4a5e573e76f4379b353cc736215a5f10cdb84)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/101537] -Wconversion false positive in ternary and |=
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
` (6 preceding siblings ...)
2022-01-24 9:21 ` cvs-commit at gcc dot gnu.org
@ 2022-05-10 8:22 ` cvs-commit at gcc dot gnu.org
2023-06-29 15:31 ` wolter.hellmundvega at tevva dot com
8 siblings, 0 replies; 10+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-10 8:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:4e8c32ecfb87e723229dc6c08df8ea602e947f1e
commit r10-10666-g4e8c32ecfb87e723229dc6c08df8ea602e947f1e
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Jan 11 19:11:51 2022 +0100
c-family: Fix up -W*conversion on bitwise &/|/^ [PR101537]
The following testcases emit a bogus -Wconversion warning. This is because
conversion_warning function doesn't handle BIT_*_EXPR (only
unsafe_conversion_p
that is called during the default: case, and that one doesn't handle
SAVE_EXPRs added because the unsigned char & or | operands promoted to int
have side-effects and =| or =& is used.
The patch handles BIT_IOR_EXPR/BIT_XOR_EXPR like the last 2 operands of
COND_EXPR by recursing on the two operands, if either of them doesn't fit
into the narrower type, complain. BIT_AND_EXPR too, but first it needs to
handle some special cases that unsafe_conversion_p does, namely when one
of the two operands is a constant.
This fixes completely the pr101537.c test and for C also pr103881.c
and doesn't regress anything in the testsuite, for C++ pr103881.c still
emits the bogus warnings.
This is because while the C FE emits in that case a SAVE_EXPR that
conversion_warning can handle already, C++ FE emits
TARGET_EXPR <D.whatever, ...>, something | D.whatever
etc. and conversion_warning handles COMPOUND_EXPR by "recursing" on the
rhs. To handle that case, we'd need for TARGET_EXPR on the lhs remember
in some hash map the mapping from D.whatever to the TARGET_EXPR and when
we see D.whatever, use corresponding TARGET_EXPR initializer instead.
2022-01-11 Jakub Jelinek <jakub@redhat.com>
PR c/101537
PR c/103881
gcc/c-family/
* c-warn.c (conversion_warning): Handle BIT_AND_EXPR, BIT_IOR_EXPR
and BIT_XOR_EXPR.
gcc/testsuite/
* c-c++-common/pr101537.c: New test.
* c-c++-common/pr103881.c: New test.
(cherry picked from commit 20e4a5e573e76f4379b353cc736215a5f10cdb84)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c/101537] -Wconversion false positive in ternary and |=
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
` (7 preceding siblings ...)
2022-05-10 8:22 ` cvs-commit at gcc dot gnu.org
@ 2023-06-29 15:31 ` wolter.hellmundvega at tevva dot com
8 siblings, 0 replies; 10+ messages in thread
From: wolter.hellmundvega at tevva dot com @ 2023-06-29 15:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
--- Comment #9 from wolter.hellmundvega at tevva dot com ---
Will the current fix be released when the C++ FE is patched as well or perhaps
before that?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-06-29 15:31 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-20 17:41 [Bug c++/101537] New: -Wconversion false positive in ternary me at xenu dot pl
2021-08-08 15:15 ` [Bug c++/101537] " nok.raven at gmail dot com
2021-08-12 23:47 ` [Bug c/101537] -Wconversion false positive in ternary and |= pinskia at gcc dot gnu.org
2021-12-31 17:25 ` thomas at habets dot se
2021-12-31 22:34 ` jakub at gcc dot gnu.org
2022-01-03 11:52 ` jakub at gcc dot gnu.org
2022-01-11 18:15 ` cvs-commit at gcc dot gnu.org
2022-01-24 9:21 ` cvs-commit at gcc dot gnu.org
2022-05-10 8:22 ` cvs-commit at gcc dot gnu.org
2023-06-29 15:31 ` wolter.hellmundvega at tevva dot com
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).