vyodaiken

But the purported massive difference of the video disappears on those versions too. So that's the big proof of the efficacy of UB driven "optimization" - one additional assembler instruction in the clang code, some movslq vs movl. Dramatic. A micro-benchmark that indicates zero.

>The point of giving that example is to show that there are studies that examine the benefit of undefined behavior,

Of course, that is exactly what Regehr's paper does not show. It shows that a modification of Clang/LVM UB operations has some good properties. I am asking for studies showing significant benefits for UB "optimizations" that are not available otherwise.

I never advocated eliminating undefined behavior from C, I advocate eliminating UB based "optimizations" from C compilers, particularly "optimizations" which rely on assuming code will never do what emitted code does!

>The reason why you don't see any studies on it is that it's obvious.

And that is the classic tell for a serious mistake in engineering. We don't need to study it, its obvious.

Your response is flat out wrong. C is not defined as a memory safe language. You are inventing a false dichotomy: if the compiler cannot assume UB never happens, it must ensure UB never happens. Nope.

-fwrapv gives you the desired C semantics.

That's correct, but I fault the Standard committee for not rejecting the peculiar interpretation that allows Compiler developers to assume e.g. overflow does not happen while emitting code that does overflow.

You are joking, right? Regehr's paper covers a proposed CHANGE to Clang/LVM UB behavior, while I was asking for studies that show advantages of UB "optimization" itself. The numbers show minor changes of performance on an artificial benchmark - some better some worse. Try better.

The absence of any actual studies showing benefits of UB "optimizations" is glaring. I don't care about motivations, which could simply be incompetance.

Do you have a single published study showing that the UB "optimizations" benefit real programs?

I typed in the example code and current Clang generates exactly the same assembly for both u and not u integers - which is correct. So the problem he is describing is an error in Clang code generation that has since been fixed. Again: I have yet to see a serious attempt to validate the utility of UB "optimizations" - this video certainly does not contain any.

Wait a second: both ARM and IA-64 have 32 bit operations.

Again: not a single study with a benchmark, just an anecdote that actually means the opposite of what is intended. The authors of Bzip had to write non-idiomatic code to prevent UB "optimization" from breaking their code, and this results in compiled code that may or may not be slower. Tip: fewer assembly instructions does not always mean faster execution in a pipelined processor. In fact, compiling with -fwrap probably would generate better code.

The rule allows both the union trick and a totally hacky char type exception (this was added because the standards authors found out that their rule was inconsistent and instead of backing it out, tried to hack it up).

7 An object shall have its stored value accessed only by an lvalue expression that has one of the following types:88)

— a type compatible with the effective type of the object,

— a qualified version of a type compatible with the effective type of the object,

— a type that is the signed or unsigned type corresponding to the effective type of the object, — a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,

— an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or

— a character type

There is no practical use for those UB "optimizations".

Just a reminder that there are ZERO published studies showing that these UB "optimizations" have significant value for any real programs. They impose a bizarre notion of C semantics that is not compatible with the language design. A good critique, for example, of the UB alias behavior can be found in Brian Kernhighans article on Pascal ( http://www.cs.virginia.edu/~evans/cs655-S00/readings/bwk-on-... ). The Standards authors have made the exact same error but in an ad hoc hacked up manner.

Just use the flags that Linux has forced on the compiler developers in order to be able to make use of C or else give up on writing correct code. http://www.yodaiken.com/2018/11/17/standard-c-is-more-fun-th...

absence of an example device is a strong strike against the Bloomberg article.

That seems entirely circular.

You're missing my point.

>Again, it seems unlikely that this was the sticking point.

Look at the proof - page after page of work showing how to encode and decode formal propositions using primitive recursive functions.

>E.g. Hilbert understood mathematics as a symbolic game, thought about this exactly question, and didn't come up with Goedel's proof. And Hilbert was definitely no dullard.

Goedel's theorem is exactly that mathematics is not a symbolic game - that Hilbert's program is not possible. The proof relies on reducing logical deduction to arithmetic.

What made the theorem hard is not the details, which are simple, it's the conceptual leap to thinking about mathematical statements as mathematical objects - something that is much easier for us than for mathematicians of Godel's time because we are familiar with programs and computers. Much of the text is taken up with proving things that were surprising to mathematicians of the era, but are now commonplace: e.g. that we can treat numbers as encoding mathematical propositions so that for every proposition P expressible in some formal logic L, there is a number #P which encodes P in some unambiguous way - as long as L is expressive enough to formalize some basic arithmetic. Then we can start making trouble by asking if we can construct a proposition Q so that Q(#P) is true iff the proposition #P encodes, P, is provable in our system. If so, we should be able to prove Q(#P) or NOT Q(#P) if L is complete, but things don't work out well because it's possible to encode paradoxical statements. In short.

no "self" in C.

There is no connection between Ayn Rand and pragmatism.

mistermann 9 hours ago [-]

>> The tech companies are _significantly_ right wing on any spectrum including countries outside the USA. >This seems like the absolute opposite of literally every single article I've ever read, I have not once heard a single person make this claim before. Am I misunderstanding something, are we not talking about the same thing?

Maybe broader reading? Tech company management is predominantly "libertarian" and right wing. You often hear Sili Valley leaders extolling Ayn Rand, never hear them extolling e.g. the economic ideas of MLK or even JFK.

Asking Twitter to enforce its rules fairly is not an attack on free speech.

I do not see how FALSE is ever a reasonable assumption for an optimizer: " a+1 > a" is not a true statement for code emitted by gcc/clang on most architectures (with or without frwapv) Can you put one of your fwrapv deoptimizations on godbolt or otherwise show it?

This is exactly why I don't propose to do away with UB but to limit what compilers can do with UB. The programmer in C cannot be prevented from writing terrible code where e.g. a loop counter is written over by an aliased pointer in the middle of the loop - the current standard doesn't prevent it either. In fact, strictly conforming C code can use char pointers to randomly write over any aliased variables if I understand it correctly. The positive thing about UB is that it makes this the programmers problem, not the compilers problem. The negative thing is that in current interpretations, the compiler is free to detect such an error and then instead of either failing to compile with a warning or just letting things happen as the programmer has specified, it can introduce global program failures because "it's impossible to have UB".

It is indeed influenced by Regehr's proposal, but is written as a concrete proposal to the WG14 committee.

Not correct. g(x){ ... if x is null panic otherwise x->v = n} can currently be optimized to x->v =n given f(){ ... y =x->v ... g(x) } because null dereferences are assumed impossible in some twisted interpretation of the standard. Imagine the effects with inlining and LTO. That's my issue, not perfectly ordinary standard value caching etc.

One of the motivating cases for this proposal is that gcc/clang, without fwrapv, will both implement wrapping on most architectures (since that is what the processor implemements) and silently remove manual overflow checks for overflow because it is "impossible" under a stupid interpretation of what UB means. Similarly, those compilers will remove manual checks for null pointers if there is a prior dereference to a pointer on the theory that dereferences of null pointers are "impossible" even when they happen.

There is nothing in what I have proposed that requires assuming a flat address space or that pointers can catch and fix invalid pointer dereferences etc.

As usual, this is pure handwaving: " certain optimizations ... "

>You expect C code to go beyond the territory of the abstract machine. The authors of the standard, quite clearly, do not.

That is 100% wrong.

>Strictly conforming programs are intended to be maximally portable among conforming implementations. Conforming programs may depend upon nonportable features of a conforming implementation.

The whole concept of "undefined behavior" is to cope with the reality that C programs routinely go beyond the bounds of the abstract machine.

This is a really common code pattern: client sends request to server; server sanity checks request. If you omit sanity checks from the server because you assume there are no errors in the client, you break a lot of systems.

I am expecting the compiler to only make optimizations based on things it knows are true - that are true. So if the source code is "check for null;check for null; do something;" the compiler should be able to delete the second check (hopefully with a warning). In fact, the Standard is very explicit about permitting optimizing compilers to delete repeated operations. However, in the case I described, the compiler does not know that the pointer is non-null, it's just easier to assume it is not null. That leads to an "optimization" that is not an optimization. I agree that requiring compilers to only use true optimizations is more of a challenge than allowing them to use false ones, but nobody said it was going to be easy. In particular, it looks like Clang loses way too much information going from source to llvm language which makes it difficult to carry information about whether, for example, a pointer dereference is safe or not - but that's a defect in the compiler, not in the source language.

Ada overflow semantics are precisely what programmers assumed were C overflow semantics on architectures that roll-over on signed arithmetic (e.g. basically every processor architetcure in current wide use). The original intent of the C "undefined behavior" category, as far as I can tell, was to in this case permit compilers on dissenting architectures to make another choice. For example, on the Itanium you might want to have a trap on overflow. Because C is comfortable with "it works differently on different processors". So it is my intention to repair the obscurity in the language by spelling out what I am 100% sure would have been obvious to C programmers and language developers at on time.