[Bug c++/101537] New: -Wconversion false positive in ternary

[Bug c++/101537] New: -Wconversion false positive in ternary

[me at xenu dot pl]

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.

[Bug c++/101537] -Wconversion false positive in ternary

[nok.raven at gmail dot com]

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

[Bug c/101537] -Wconversion false positive in ternary and |=

[pinskia at gcc dot gnu.org]

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.

[Bug c/101537] -Wconversion false positive in ternary and |=

[thomas at habets dot se]

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 |=

[jakub at gcc dot gnu.org]

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

[Bug c/101537] -Wconversion false positive in ternary and |=

[jakub at gcc dot gnu.org]

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.

[Bug c/101537] -Wconversion false positive in ternary and |=

[cvs-commit at gcc dot gnu.org]

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.

[Bug c/101537] -Wconversion false positive in ternary and |=

[cvs-commit at gcc dot gnu.org]

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)

[Bug c/101537] -Wconversion false positive in ternary and |=

[cvs-commit at gcc dot gnu.org]

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)

[Bug c/101537] -Wconversion false positive in ternary and |=

[wolter.hellmundvega at tevva dot com]

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?