AaronBallman wrote:
> arch/arm64/include/asm/barrier.h:164:59: note: expanded from macro
> '__smp_load_acquire'
> 164 | union { __unqual_scalar_typeof(*p) __val; char __c[1]; } __u;
> \
> | ^
Whhhhaaaa? `__unqual_scalar_typeof(*p)` seems to result in a `const`-qualified
type. I'm surprised something named `unqual` would do that. Can you confirm I'm
getting that correct?
This one:
```
In file included from net/ipv4/ip_fragment.c:42:
include/net/ip.h:478:14: warning: default initialization of an object of type
'typeof (rt->dst.expires)' (aka 'const unsigned long') leaves the object
uninitialized and is incompatible with C++ [-Wdefault-const-init-unsafe]
478 | if (mtu && time_before(jiffies, rt->dst.expires))
| ^
include/linux/jiffies.h:138:26: note: expanded from macro 'time_before'
138 | #define time_before(a,b) time_after(b,a)
| ^
include/linux/jiffies.h:128:3: note: expanded from macro 'time_after'
128 | (typecheck(unsigned long, a) && \
| ^
include/linux/typecheck.h:11:12: note: expanded from macro 'typecheck'
11 | typeof(x) __dummy2; \
| ^
2 warnings generated.
```
is unfortunate. The diagnostic is expected, but I can see why you'd want to
silence it. Does adding `= {};` to the declarations for the dummy variable work
for you?
> I also see another instance from [a recent change in the crypto
> code](https://git.kernel.org/linus/db873be6f0549597f92c72986b1939643a7f9a75):
That looks like a correct diagnostic to me, but I admit the code is dense
enough I may be missing something. Is there a reason why `addr` should not be
initialized? Or is this relying on initialization through other means like
`memcpy` into the field because the containing object is non-const?
https://github.com/llvm/llvm-project/pull/137166
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
