Issue 179403
Summary Clang rejects valid C11 code: invalid operands to binary _expression_ for _Atomic types returned from functions
Labels clang
Assignees
Reporter jupiter-zzp
    ### Description:
Clang fails to compile valid C11 code that compares two _Atomic objects using the != operator when one operand is a function return value. The same comparison works correctly when both operands are variables (not function returns). GCC accepts this code without errors.

### Reproducer:
[Live demo on Godbolt Compiler Explorer](https://godbolt.org/z/o6zPo3Ko5)

```
#include <stdint.h>
#include <stdatomic.h>

int test(atomic_size_t a, atomic_size_t b) {
    return a != b;
}

atomic_size_t foo(atomic_size_t a) {
 return a;
}

int test_OK(atomic_size_t a, atomic_size_t b) {
 atomic_size_t c = foo(a);
    return c != b;
}

int test_error(atomic_size_t a, atomic_size_t b) {
    return foo(a) != b;
}

```

### Output:

```
<source>:18:19: error: invalid operands to binary _expression_ ('atomic_size_t' (aka '_Atomic(size_t)') and 'atomic_size_t')
   18 |     return foo(a) != b;
      |            ~~~~~~ ^  ~
1 error generated.
Compiler returned: 1
```

### Expected Behavior:
The code should compile successfully, as atomic_size_t (aka _Atomic(size_t)) objects should be comparable using the != operator regardless of whether they are variables or function return values. This is consistent with C11 standard section 6.5.9 (Equality operators) which allows comparison of atomic types.

### Environment:

    Clang version: 21.1.0 (also reproduced on other version)
    Target: riscv32-unknown-unknown-elf (also reproduced on arm and x86)
    GCC comparison: GCC 15.2.0 accepts this code

### Additional Context:
This appears to be a semantic analysis issue where Clang fails to properly handle value categories or type decay for atomic types when they are returned from functions. The direct comparison a != b works because both are lvalues of atomic type, but foo(a) != b fails because foo(a) is an rvalue (function return), suggesting Clang is not applying the same type conversion rules for atomic types in this context.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to