Conditional operators that result in bit-fields do not correctly preserve the width

[Halalaluyafail3]

The following program demonstrates the issue:

#include<iostream>
int main(){
    struct{unsigned u:1;}u{};
    auto a=(0?throw 0:u.u)-1;
    std::cout<<(a<0)<<'\n';//should print 1, Clang prints 0
    unsigned char b{0?throw 0:u.u};//incorrectly considered narrowing
    auto c=(1?u.u:u.u)-1;
    std::cout<<(c<0)<<'\n';//should print 1, Clang prints 0
    unsigned char d{1?u.u:u.u};//incorrectly considered narrowing
}

The two expressions (0?throw 0:u.u) and (1?u.u:u.u) should intuitively both be equivalent to u.u, but Clang appears to forget about the widths of the bit-fields in these cases and assumes that they have the full range of unsigned. #14181 also still exists and makes it impossible to use any non-constant condition here.

GCC has the same issues with propagating the bit-field with in these two expressions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122811. MSVC too, but because it fails to implement promotion and narrowing checks with bit-fields correctly. For example with MSVC +u.u has the type unsigned and unsigned char e{u.u}; is considered narrowing.

See also CWG3134. The standard doesn't clearly define the width in the cases where bit-field and non-bit-field expressions are used together, or two bit-field expressions of different widths are used together. The most reasonable behavior in these cases seems to be to take the maximum of the two widths, where the width of a non-bit-field is the width of its type. Though it may be worth waiting for the issue to be resolved before making a decision.

[llvmbot]

@llvm/issue-subscribers-c-1

Author: None (Halalaluyafail3)

The following program demonstrates the issue: ```cpp #include<iostream> int main(){ struct{unsigned u:1;}u{}; auto a=(0?throw 0:u.u)-1; std::cout<<(a<0)<<'\n';//should print 1, Clang prints 0 unsigned char b{0?throw 0:u.u};//incorrectly considered narrowing auto c=(1?u.u:u.u)-1; std::cout<<(c<0)<<'\n';//should print 1, Clang prints 0 unsigned char d{1?u.u:u.u};//incorrectly considered narrowing } ``` The two expressions `(0?throw 0:u.u)` and `(1?u.u:u.u)` should intuitively both be equivalent to `u.u`, but Clang appears to forget about the widths of the bit-fields in these cases and assumes that they have the full range of unsigned. #14181 also still exists and makes it impossible to use any non-constant condition here.

GCC has the same issues with propagating the bit-field with in these two expressions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122811. MSVC too, but because it fails to implement promotion and narrowing checks with bit-fields correctly. For example with MSVC +u.u has the type unsigned and unsigned char e{u.u}; is considered narrowing.

See also CWG3134. The standard doesn't clearly define the width in the cases where bit-field and non-bit-field expressions are used together, or two bit-field expressions of different widths are used together. The most reasonable behavior in these cases seems to be to take the maximum of the two widths, where the width of a non-bit-field is the width of its type. Though it may be worth waiting for the issue to be resolved before making a decision.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Halalaluyafail3)

The following program demonstrates the issue: ```cpp #include<iostream> int main(){ struct{unsigned u:1;}u{}; auto a=(0?throw 0:u.u)-1; std::cout<<(a<0)<<'\n';//should print 1, Clang prints 0 unsigned char b{0?throw 0:u.u};//incorrectly considered narrowing auto c=(1?u.u:u.u)-1; std::cout<<(c<0)<<'\n';//should print 1, Clang prints 0 unsigned char d{1?u.u:u.u};//incorrectly considered narrowing } ``` The two expressions `(0?throw 0:u.u)` and `(1?u.u:u.u)` should intuitively both be equivalent to `u.u`, but Clang appears to forget about the widths of the bit-fields in these cases and assumes that they have the full range of unsigned. #14181 also still exists and makes it impossible to use any non-constant condition here.

GCC has the same issues with propagating the bit-field with in these two expressions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122811. MSVC too, but because it fails to implement promotion and narrowing checks with bit-fields correctly. For example with MSVC +u.u has the type unsigned and unsigned char e{u.u}; is considered narrowing.

See also CWG3134. The standard doesn't clearly define the width in the cases where bit-field and non-bit-field expressions are used together, or two bit-field expressions of different widths are used together. The most reasonable behavior in these cases seems to be to take the maximum of the two widths, where the width of a non-bit-field is the width of its type. Though it may be worth waiting for the issue to be resolved before making a decision.

[Sirraide]

CC @AaronBallman Iirc at least in C this is very much intentional; not sure if I remember that correctly, but if it is intentional, it would seem weird to do something different in C++ (and if that’s the case, we might want to point that out on cplusplus/CWG#820).

[Halalaluyafail3]

CC @AaronBallman Iirc at least in C this is very much intentional; not sure if I remember that correctly, but if it is intentional, it would seem weird to do something different in C++ (and if that’s the case, we might want to point that out on cplusplus/CWG#820).

In C the conditional operator doesn't result in an lvalue, that difference is very intentional. Also:

#include<stdio.h>
int main(){//compile using C23+
    struct{unsigned u:1;}u={};
    auto c=(1?u.u:u.u)-1;
    printf("%i\n",c<0);
}

Clang correctly prints 1 with this program.

[zygoloid]

I believe Clang correctly tracks and computes the OK_BitField object kind in this case, but several consumers of this information (including the narrowing checks and integral promotion logic) use Expr::getSourceBitField, which both doesn't handle conditional operators and also can't handle the case where there are multiple potential bit-field results with different widths. We should probably replace that function with something that can handle the full suite of possibilities here (multiple bit-fields, and potentially non-bit-field results) or perhaps remove it and replace it with a function that returns the highest bit-width of any potential result.