Bug 23064 – wrong code generated for bitfield assignment to ?:

Status
NEW
Severity
normal
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2022-04-27T22:18:00Z
Last change time
2024-12-13T19:22:27Z
Keywords
ImportC
Assigned to
No Owner
Creator
Walter Bright
Moved to GitHub: dmd#18101 →

Comments

Comment #0 by bugzilla — 2022-04-27T22:18:00Z
The generated code is as if a.x and a.y were regular fields instead of bitfields. struct A { int x: 3; int y: 5; } a; struct A test(int val, int choice, struct A a) { (choice ? a.x : a.y) = val; return a; } Affects D and ImportC.
Comment #1 by b2.temp — 2022-04-28T11:09:43Z
After a brief discussion on IRC it seems that C does not allow the conditional expression to be a lvalue, hence it could not be an assignment RHS. From http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf --- The first operand is evaluated; there is a sequence point between its evaluation and the evaluation of the second or third operand (whichever is evaluated). The second operand is evaluated only if the first compares unequal to 0; the third operand is evaluated only if the first compares equal to 0; the result is the value of the second or third operand (whichever is evaluated), converted to the type described below.110) [...] 110) A conditional expression does not yield an lvalue --- that would not affect ImportC then.
Comment #2 by b2.temp — 2022-04-28T11:10:19Z
> expression to be a lvalue, hence it could not be an assignment RHS. sorry I meant LHS obviously
Comment #3 by bugzilla — 2022-04-30T03:57:12Z
You are correct that C doesn't allow it. Currently, D accepts it and generates the wrong code. C++ accepts it, and generates the correct code. We should either make it an error or do what C++ does.
Comment #4 by robert.schadek — 2024-12-13T19:22:27Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18101 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB