Re: [RFC][PATCH 0/5] arch: atomic rework

From: Alec Teal
Date: Mon Feb 17 2014 - 18:25:18 EST


On 17/02/14 20:18, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 11:55 AM, Torvald Riegel<triegel@xxxxxxxxxx> wrote:
Which example do you have in mind here? Haven't we resolved all the
debated examples, or did I miss any?
Well, Paul seems to still think that the standard possibly allows
speculative writes or possibly value speculation in ways that break
the hardware-guaranteed orderings.

And personally, I can't read standards paperwork. It is invariably
Can't => Don't - evidently.
written in some basically impossible-to-understand lawyeristic mode,
You mean "unambiguous" - try reading a patent (Apple have 1000s of trivial ones, I tried reading one once thinking "how could they have phrased it so this got approved", their technique was to make the reader want to start cutting themselves to prove they wern't numb to everything)
and then it is read by people (compiler writers) that intentionally
try to mis-use the words and do language-lawyering ("that depends on
what the meaning of 'is' is"). The whole "lvalue vs rvalue expression
vs 'what is a volatile access'" thing for C++ was/is a great example
of that.
I'm not going to teach you what rvalues and lvalues, but! http://lmgtfy.com/?q=what+are+rvalues might help.

So quite frankly, as a result I refuse to have anything to do with the
process directly.
Is this goodbye?

Linus
That aside, what is the problem? If the compiler has created code that that has different program states than what would be created without optimisation please file a bug report and/or send something to the mailing list USING A CIVIL TONE, there's no need for swear-words and profanities all the time - use them when you want to emphasise something. Additionally if you are always angry, start calling that state "normal" then reserve such words for when you are outraged.

There are so many emails from you bitching about stuff, I've lost track of what you're bitching about you bitch that much about it. Like this standards stuff above (notice I said stuff, not "crap" or "shit").

What exactly is your problem, if the compiler is doing something the standard does not permit, or optimising something wrongly (read: "puts the program in a different state than if the optimisation was not applied") that is REALLY serious, you are right to report it; but whining like a n00b on Stack-overflow when a question gets closed is not helping.

I tried reading back though the emails (I dismissed them previously) but there's just so much ranting, and rants about the standard too (I would trash this if I deemed the effort required to delete was less than the storage of the bytes the message takes up) standardised behaviour is VERY important.

So start again, what is the serious problem, have you got any code that would let me replicate it, what is your version of GCC?

Oh and lastly! Optimisations are not as casual as "oh, we could do this and it'd work better" unlike kernel work or any other software that is being improved, it is very formal (and rightfully so). I seriously recommend you read the first 40 pages at least of a book called "Compiler Design, Analysis and Transformation" it's not about the parsing phases or anything, but it develops a good introduction and later a good foundation for exploring the field further. Compilers do not operate on what I call "A-level logic" and to show what I mean I use the shovel-to-the-face of real analysis, "of course 1/x tends towards 0, it's not gonna be 5!!" = A-level logic. "Let epsilon > 0 be given, then there exists an N...." - formal proof. So when one says "the compiler can prove" it's not some silly thing powered by A-level logic, it is the implementation of something that can be proven to be correct (in the sense of the program states mentioned before)

So yeah, calm down and explain - no lashing out at standards bodies, what is the problem?

Alec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/