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.
Amusingly, unions are also defined so that operations that pun types are undefined. Gcc has private extensions that provide a way to pun types in unions, but those are not portable.
Specifically: if you have a union with members a and b, and you assign into member a, then reading from member b afterward is, by the C and C++ Standards, usually undefined. You are presumed to have some way to know that member a is live, and use that. You can then write into b, and later read that back out.
The C99 and C11 standards say that the behavior is unspecified (in standard-ese, "unspecified" and "undefined" are different), meaning that the standard doesn't say what you get. Of course that's true: the result is different on a big-endian and a little-endian machine. Packing the bytes of a double might generate a signalling NaN so you get a trap when you read it, or not, and the standards don't require that floating point representations match the IEEE standard, either.
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.
Minimum wage is closer, environmental standards are somewhat similar, and laws can be passed on a federal level. It is just as easy for workers to change states as businesses while internationally it is easier for businesses to change locations than workers.
The Cloudflare captcha is ridiculous really and makes sites completely unusable with a VPN. I even get captchas for different pages on the same domain! It used to be you only got captcha for form submissions. But somewhere along the line you started getting it for simply visiting web pages as well. Part of me wonders if I'm just getting played by these companies into labelling all their ML training sets for them.
I agree, but keep in mind that children grow up in a society, and make friends in school. You are influencing their relationships by restricting their internet access.
Sure, but the article is talking about government action. If every child in the UK grows up with age restricted internet then no ones relationships will be disadvantaged.
The only thing that would be influenced is cross national relationships, and sitting in a separate country probably affects that way more than having equal access to the same webpages.
I did a quick study on an Epson Ecotank printer 3 or 4 years ago, and I found "random" colored pixels that were added (for example a single cyan dot in a large circle of pure cyan changed to a pure magenta dot... like that is a natural mistake if it occurs multiple times on a single page with different colors, and different positions), fuzzed black lines (not really fuzz, but holding data in the "noise"), and a few horizontal lines shifted by a few pixels every once in a while. So I believe that most of the other changes are real.
Edit: If you want to check your printer then: print something to a piece of really white paper, scan it, and then use a diff tool like in Gimp after resizing it to easily spot the differences. If you are using off white paper you can scan it also before you print on it, and attempt to remove the paper's natural color variations before "diff"ing it with the digital version.
