I'm very curious to learn more about this as I thought it was easily possible to opt out of the overly aggressive defaults of GCC, Clang, and the like.
It is possible - but not whilst maintaining standards-compliance and there are always/often another one where you least expect it.
At the root is taking a “assume the programmers know what they are doing” language and turning it into a “assume the programmers are drooling morons” language.
I think it's the opposite: compiler writers under pressure to produce fast code assume that the programmers are smart, not morons, and that they understand the rather complex rules.
For example: the compiler is assuming someone isn't ignorant and knows, for example, if they want to write a variable as one type and read it as another, they need to consider two things: they are now in implementation-dependent territory (big endian vs little endian effects, for example), and they need to use unions, not just casts, if the same data can be interpreted as two different types and neither is array of char. Failure to use unions properly triggers aliasing problems.
It was many months ago and I no longer remember the full details, plus it's proprietary code, so I can't tell them to you. But the gist was that after optimisation, some floating point arithmetic was done in different order by different compilers. This particular expression really needed to be computed in exact order and, since nothing else worked, we had to just write it in compiler-specific assembly. IIRC some language extensions are coming to better specify float semantics on a per-function basis that might help one day.
That's a compiler bug. Floating-point math shouldn't be reassociated unless you were using -ffast-math, which is indeed a poorly named option that does bad things, but one many people demand.
bombcar|4 years ago
At the root is taking a “assume the programmers know what they are doing” language and turning it into a “assume the programmers are drooling morons” language.
not2b|4 years ago
For example: the compiler is assuming someone isn't ignorant and knows, for example, if they want to write a variable as one type and read it as another, they need to consider two things: they are now in implementation-dependent territory (big endian vs little endian effects, for example), and they need to use unions, not just casts, if the same data can be interpreted as two different types and neither is array of char. Failure to use unions properly triggers aliasing problems.
Asooka|4 years ago
astrange|4 years ago