vyodaiken

I'm puzzled how I could have given the impression that I am looking for safety. I just don't want the compiler to defeat programmer intentions. I don't see how your example can depend on overflow semantics. The vectorizer is free to assume there is no overflow and let the programmer suffer if she screwed up. What I don't want the optimizer to do is to prevent the programmer from checking for overflow because it can't happen in theory while it can happen in practice.That is, I am interested in prioritizing programmer control over the safety net.

I love to see code snippets. Otherwise this makes zero sense. The check for overflow is super cheap on any processor you'd run fluid dynamics code on. You'd have to be running pathologically tiny loops. I have never seen any papers on this "well known" benefit. Perhaps you can provide me a link. In any event, it's interesting that you think that compute intensive kernels are self-evidently more important uses of C than device drivers, embedded systems, middleware, etc. Perhaps you'd be better off using a language specifically designed for optimized numerical codes - FORTRAN for example.

I 100% doubt that that Ritchie would have agreed. This is the existing interpretation of the standard, which is exactly what I propose to change. I believe the standard interpretation has strayed from both the language design and the objectives of the language.

It targets the abstract machine, but the dispute here is about what should happen when the program operation goes into territory that the abstract machine does not specify. And C code is EXPECTED to go beyond the territory of the abstract machine.

is k = i+j valid C? Can it be translated sensibly to add i,j; jump on overflow to random; store k; ? How about sometimes omitting the jump to random and sometimes not?

Argument like yours seem to rely on an incorrect understanding of the design of C. Languages like Java encapsulate program execution in a runtime that, in theory, can catch and manage all sorts of programmer errors that C does not catch. That's ok. If the programmer references past the end of an array, the compiler may catch and object, it may simply compile the instructions and let the program step on its own data structures or encounter a memory fault or even a protection violation if the architecture provides some type protection. And it's bizarre to see this warning about ROP exploit, when current "optimization" based on UB is a source of ROP exploit vulnerability. One cannot reliably put protections in code against bad pointers if upstream errors are grounds for deleting the guards.

I'd love to see some examples of how -fwrapv makes real programs see an "unacceptable loss in performance". Are there any? I confess to doubt.

a) these are marginal optimizations, at best. b) because it violates C practice. My parsing library is written to distrust inputs so as to protect against buffer exploits. Your compiler "optimizes" away my security check because some buggy code dereferences a null pointer - which actually works in this implementation. Great. Now you have "optimized" to create a security hole in the program by removing a single instruction that is actually free in many pipelined architectures. Wonderful. Thanks so much.

One of the reasons for this proposal is that LTO is going to make C completely unusable otherwise. Suppose that a driver produces a structure that points to data buffers. Core code interacting with the drivers knows that drivers are of variable quality and checks that the structure is properly setup: if(x->buffer == 0)panic("bad driver" ) or something more sophisticated. Everything works beautifully until some driver is added with a dereference of x->buffer - which then defeats the guard in the core core because now the compiler " knows" that the x->buffer is not null. Separate compilation and inlining can't work reliably in this situation.

If you could actually provide some concrete basis for that argument, it would be interesting.

They exhibit a really badly mistaken idea of the role of the compiler.

C is not Java.

What is outrageous about this argument, which has been going on for far too long, is how people who don't get C or don't use it, keep dismissing critiques from expert practitioners like DJB or Torvalds and from academics like Regehr as if those people are all to damn stupid to understand the issues.

For certain types of image manipulations or other computations, it may well be that the pointers are supposed to refer to overlapping regions. This is the kind of problem that, as Dennis Ritchie pointed out, bedeviled FORTRAN for ever. I think the solution is to fix "restricted" and let programmers opt-in. If the programmer doesn't do that, or gets it wrong, too bad.

It's perfectly reasonable to argue that C is not as good as XYZ. You may even be right. But it is not reasonable to conclude from that, that it ok for C implementations to make C programming more hazardous than it needs to be. Go out and make Rust a more appealing alternative to C and good luck with it. But don't tell me C can be turned into mush because you don't much like C.

it's bizarre to me that people make this argument, given the obvious fact that those flags do not prevent optimization or inlining.

Since -fno-delete-null-pointer-checks works in both GCC and clang and, nevertheless, the compilers are able to do significant optimization, you might want to think it out again.

It's completely valid. It's just not conforming.

No the compiler is not entitled to insert a segfault. Segaults come from architectures and operating systems, not from compilers. The compiler is free to leave in the dereference of the null pointer and then, who knows what happens. But the compiler can't break the code by deleting a perfectly conforming null check on the theory that a previous dereference means that the pointer is not null.

The original Bourne shell used signal to catch memory faults so it could operate dynamic paging! If your OS/implementation permits, C is supposed to allow you do do things like that. The compiler is NOT supposed to insulate the programmer from bumps. (Disclaimer: I am not endorsing the horrible design of the Bourne shell which was also written in a macro style that made C into pseudo Algol).

>The standard doesn’t describe transformations; it describes behaviors

That is not remotely true - as you can see by looking up the example I reference.

>For C, that’s not something we can realistically do in every case. There’s no way to reasonably constrain the set of allowed behaviors after a program does some crazy pointer operation like * (int *) rand() = rand(), because any implementation of those constraints would more or less require an expensive run-time check at every pointer access.

That's such a weird response. There is nothing in the proposal that requires run-time checks. The proposal simply limits the ability of the compiler/translator to make counter-factual assumptions or otherwise violate the C semantics.

>What you could meaningfully ask is for particular situations (like negative shifts) to be considered unspecified or implementation-defined rather than undefined.

I don't want to do that: I want to clarify the meaning of "undefined behavior" to curtail its use as a license to do arbitrary code transformations. One implementation may trap on a negative shift, one may generate negative shift instructions that the architecture treats as no-ops or whatever they do, one might do sufficient static analysis to detect negative shifts and generate an error message - but the compiler is not free to assume that the shift operator has a negative value.

I'm not trying to remove undefined behavior from C. I am trying to correct a mistaken analysis of what undefined behavior should mean. C is intended to allow for non-portable operations, for example. These are "undefined" in the standard because they depend on the implementation, not because the C language should be specified so as to allow compilers to introduce hidden booby traps or counter-factual assumptions into the implementation

He didn't call anyone an asshole. His insults were reserved for the arguments and the standard itself.

The compiler and standard are both full of contradictory, useless, and counter-productive rules on aliasing. But both gcc and clang now support _may_alias_ and -fno-strict-aliasing without which they would have made the language completely unusable.

i think you should be able to make private comments on that document. Otherwise victor.yodaiken@gmail.com

Here is a start. https://docs.google.com/document/d/1xouelPcphQ-o7DmdSwz5UcL4...

So "rant" is an unnecessary pejorative. Try to make your case without yelling. And I don't get your point. You have just agreed that the compiler can optimize these loops without UB. The pessimization is minor and programmer choice. So what is the argument on the other side ? How do you justify a code transformation that, e.g. produces an infinite loop by removing a programmer check for a condition that actually can occur?

That's a false choice. Obviously Linux code is still optimized significantly despite their extensive disabling of UB based "optmizations".

Right. C is not designed to be memory safe. So certain invariants are harder to prove (or just not true). One problem with UB is that it allows compilers to assume false things.

>Invariants are useless if you can't assume them.

I would think that what we want is invariants that have been validated, not assumed - especially not assumed incorrectly.

It's an interesting talk, but, just for example: architecture dependent behavior is not something anyone really wants to prohibit in C. It's hard to believe, that DJB, who writes sophisticated C code that calls out directly to Intel vector operations thinks that should be machine independent. And his API analogy is wrong. If you have an API that responds to out-of-contract parameters by, e.g. rewriting code it is a bad API. People do fuzzing tests specifically to find badly implemented APIs that don't reject bad parameters. In particular, imagine an API that does one thing, the thing you expect, when called without optimizations, and breaks your program when "optimized"! I got to the node example and gave up. The compiler is not asked to check program correctness.

It's really irritating that people take this condescending approach. C is harder to optimize than language that e.g. do not have pointers. That is a tradeoff the language designers chose because they wanted C programmers to be able to type pun, for example. This is why C89's only limit on type punning was memory alignment. The intent of "restrict" was to enable some aliasing optimizations via opt-in. So, sure, things that are not invariant in C are not available for invariant optimization. C permits aliasing. So it calls for smarter compiler techniques. If you want a language that forbids aliasing, use one that does and then call out to C libraries. But breaking C to allow CS220 "clever optimizing tricks" to be easily used is bad engineering. Essentially, what you are saying is, "elimination of invariants is a good optimization, so pretending C has more invariants than it does is a good thing. "

So maybe come up with a real example and stop hand waving.

There is nothing to prevent the compiler from deducing that x is non-null without UB. What UB permits is for the the compiler to deduce that x is not null in the absence of information.

so : if(x)f(x) ...code ... if(x)g(x) doesn't need UB but y = x-> n ..... code if(x)g(x) - the compiler uses UB to remover the check. This will be especially horrible when LTO becomes more prevalent.