bit operator promotion on function return value

Question

With code:

#include <cstdint>

uint8_t a() { return 5; }

auto b() {
    uint8_t c = 6;
    c |= a();  // Warning here
    return c;
}

auto d() {
    uint8_t c = 6;
    uint8_t d = a();
    c |= d;
    return c;
}

g++ warns (using -Wconversion):

<source>:7:12: warning: conversion from 'int' to 'uint8_t' {aka 'unsigned char'} may change value [-Wconversion]

I assume the problem is related to integer promotion for bit operations, but in the second function d() I assign it to a variable first and then there is no warning.

(clang does not warn about this, only g++)

Can this be solved by casting instead of variable assignment?
Why does it behave differently when I use a function?

Compiler explorer with the above: https://godbolt.org/z/q9eMVT

That's look like a gcc bug to me - the warning is spurious. The same gcc doesn't warn when the line is rewritten to semantically equivalent `c = c | a;`. — SergeyA, Apr 11 '19 at 18:08
hmm no warning at all [here](https://wandbox.org/permlink/SR1ZHCU5ZckuqV0m) with gcc 8.3 — 463035818_is_not_an_ai, Apr 11 '19 at 18:09
In general, be wary of [integer promotion rules during bitwise operations](https://stackoverflow.com/questions/30473958/what-is-going-on-with-bitwise-operators-and-integer-promotion) — Cory Kramer, Apr 11 '19 at 18:18

Michael Kenzel · Answer 1 · 2019-04-11T23:02:43.080

I think this is a bug in GCC. Based on [expr.ass]/7, the expression

x |= y

is equivalent to

x = x | y

except that a is only evaluated once. In a bitwise inclusive OR, like other bitwise operations, as also noted in CoryKramer's comment above, the usual arithmetic conversions will first be performed on both operands [expr.or]/1. Since both our operands are of type std::uint8_t, the usual arithmetic conversions are simply the integral promotions [expr.arith.conv]/1.5. Integral promotion on std::uint8_t should mean that both operands are converted to int [conv.prom]/1. No further conversions of the operands should be required, since the converted types of both operands are the same. Finally, the int resulting from the | expression is then converted back to std::uint8_t and stored in the object referred to by x [expr.ass]/3. I would assume that this last step is what triggers the warning in some cases. However, there is no way that the result of a bitwise logical OR between two std::uint8_t could possibly not be representable in an std::uint8_t, no matter whether we convert to int (which is guaranteed to be larger) and back along the way. Thus, the warning is unnecessary here, which is probably why it is normally not produced.

The only difference I see between your first and your second version is that a() is an rvalue while d is an lvalue. The value category should have no influence on the behavior of the usual arithmetic conversions, however. Thus, the warning—unnecessary or not—should at least be produced consistently. As you have noted yourself, other compilers, such as clang, will not produce a warning here. Furthermore, the issue seems to be oddly-specific to the involvement of function calls in compound assignment. As noted by SergeyA in another comment above, GCC will not produce the warning in the equivalent form of c = c | a(). Using other kinds of rvalues in place of the function call, such as, for example, the result of casting a literal

c |= static_cast<std::uint8_t>(42);

will also not produce a warning in GCC. But as soon as there is a function call on the right-hand side of the expression, even if the result of the function call is not used at all, e.g., in

c |= (a(), static_cast<std::uint8_t>(5));

the warning appears. Thus, I would conclude that this is a bug in GCC and it would be great if you would write a bug report. …

bit operator promotion on function return value

1 Answers1