pcc seeks contributions to reach 1.0 milestone

More aggressive optimizations will rely on this wiggle room and sometimes break things. That's a headache for kernel developers. Sure, GCC may get fixed, but breaking to begin with was an annoyance. If the break causes subtle problems, diagnosing the issue could be very difficult.

This is where a simpler compiler can be more effective. If it provides very simple semantics (rather than the extraordinary wiggle room the standard provides), it becomes easier to reason about the correctness of the program. Yes, it's less portable to other compilers, but as long as the compiler itself is portable, what's the issue?

After all, you don't see many Linux builds that don't use GCC (although there are a few...).

No, I was and am still talking of "volatile".
The problem is that the C++ standard treats all attributes the same way, and gives examples with "const".
I do understand that to overwrite the "const" attribute, I need to do a dirty cast to non-const, but the basic use of volatile is to copy them into standard variables, at a controled place of the software:

volatile unsigned ethernet_status;
/* -> address of ethernet_status defined in the linker file */
int fct(void) {
unsigned status = ethernet_status; // single read of "ethernet_status"
return ((status & 1) || ((status & 2) ^ (status & 4)));
}

Now tell me how to put ethernet_status and fct() into a class and compile without warning and without casting ethernet_status to non-volatile...

But the worst for me is still considering a volatile structure of bitfields as a structure of volatile bitfields, even if I see no problem to consider a constant structure of bitfields as a structure of constant bitfields...
For instance:
volatile struct color_s { char red, green, blue, transparent; } volcolor;
int fct (void) {
struct color_s color = volcolor;
return color.red == color.blue;
}
Because volcolor is considered as a structure of volatile fields, volcolor is read twice (two byte access) when optimising.