Not only is the recipient of your code possibly using a different compiler version with different warnings, in which case you'll just break their build and annoy them...
Conversation
In general, compiler warnings are not actionable by non-developers or even by developers unfamiliar with your codebase.
2
27
If you break the build for them by shipping with -Werror, the likely outcome is that they start making random changes to the code the compiler warns about until the warning goes away, possibly BREAKING THE CODE IN DANGEROUS WAYS.
1
3
30
Summary: -Werror is only meaningful with a known compiler version and build target, and only to developers who can meaningfully act on the failures. Don't ship with -Werror. Ever.
2
4
44
Replying to
Since the Linux kernel doesn't follow the C memory model and disregards undefined behavior rules they don't agree with, it's fairly dangerous to use a newer compiler than what they're broadly using and testing themselves. Ideally, they'd actually list what's being tested / used.
2
Replying to
For Linux it's specific bare-metal targets so -Werror is less evil than in general, but still a bad idea. Linux uses -fno-strict-aliasing etc. so it's not subject to most C memory model issues a new compiler could break.
1
Replying to
I mean that they don't follow the C11 memory model for atomics and make extensive use of atomics. The compiler developers don't agree with their homegrown rules and don't respect them. There's a whole lot of complicated lock-free data structure stuff that's really quite fragile.
2
Replying to
Aren't they all accessed as volatiles? Assuming a C compiler with a reasonable sense of volatile, you can model your own atomics that way (other cores being async hardware modifying the volatile memory).
1
Replying to
No, they don't use volatile for that since it would hurt performance too much and the whole reason for them refusing to use C11 atomics is because they think even the acquire/release semantics are too expensive.
2
Compilers found it too difficult to safely/correctly implement consume and took conservative approach of making it work like acquire/release. Linux kernel basically uses a significantly more lax form of the acquire/consume semantics in most places WITHOUT compiler support.
1
They even formally defined their own Linux kernel memory model for atomics in C. Compilers don't implement it. That's seriously how things work right now. It's not the only example of them relying on undefined behavior but it's the most major one and a good reason to be worried.
Replying to
Based on my work with the kernel, I believe you're overstating this at least somewhat. Do you have some concrete source links showing what you mean?