[Bug c/101537] -Wconversion false positive in ternary and |=
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?
[Bug c/101537] -Wconversion false positive in ternary and |=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4e8c32ecfb87e723229dc6c08df8ea602e947f1e commit r10-10666-g4e8c32ecfb87e723229dc6c08df8ea602e947f1e Author: Jakub Jelinek 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 , 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 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)
[Bug c/101537] -Wconversion false positive in ternary and |=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:777b73e45983b11e010bd5192185ad01af444de4 commit r11-9500-g777b73e45983b11e010bd5192185ad01af444de4 Author: Jakub Jelinek 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 , 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 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)
[Bug c/101537] -Wconversion false positive in ternary and |=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:20e4a5e573e76f4379b353cc736215a5f10cdb84 commit r12-6486-g20e4a5e573e76f4379b353cc736215a5f10cdb84 Author: Jakub Jelinek 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 , 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 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.
[Bug c/101537] -Wconversion false positive in ternary and |=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537 Jakub Jelinek 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 --- Created attachment 52112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52112=edit gcc12-pr101537.patch Updated patch.
[Bug c/101537] -Wconversion false positive in ternary and |=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 52105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52105=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.).
[Bug c/101537] -Wconversion false positive in ternary and |=
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
[Bug c/101537] -Wconversion false positive in ternary and |=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537 Andrew Pinski 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 --- 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.
[Bug c++/101537] -Wconversion false positive in ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment #1 from Nikita Kniazev ---
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
