Hacker News Reader

Comment by m_eiman | Hacker News Reader

Is there a way to make the compiler list the applied optimizations for a specific function, in e.g. the .lst output? Would be very helpful when the compiler is doing something creative and you can't figure out how to make it do what you intended.

View on HN

With clang you can use -Rpass family of flags to get information about missed and used optimization opportunities. Although it will not print absolutely everything (trivial optimizations will be omitted). Other compilers have other options, ICC for example is able to generate optimization reports.

You can ask Clang to print the compiler IR after each optimisation, but you would need to know that you were looking for something before that was useful.

You could start by not relying on undefined behavior ;)

You mean like approximately zero percent of non-trivial C or C++ programs in actual existence?

You could of course switch to Ada.

Except Ada has UB (they used to call them bounded errors, but the semantics are basically identical), and reading the musings of ADAists[0]

> I would say, having looked at hundreds of thousands of lines of Ada, that I have had a disappointingly frequent experience in finding the UNCHECKED_CONVERSION generic used in production Ada code.

> I agree that this is often a mark of poor craftsmanship and unhesitatingly discourage its use, but it is there

[0] https://www.cs.york.ac.uk/hise/safety-critical-archive/2011/...

If finding potential UB in Ada programs is as simple as grepping for unchecked_conversion, then that's a big step forward compared to C, don't you think?

1. your claim was essentially that ADA = no UB, so that's hardly relevant

2. that's not Ada's only UB, the 2005 spec has 35 or 36, which granted is an improvement over C's circa 200, but a far cry from being UB free

The claim is that it's impossible to avoid UB in real world C, but not impossible in real world $SAFERLANGUAGE, with Ada as an example. Any language that allows you to poke around in memory (a feature you need for embedded systems) will contain unsafe constructs. The question is whether you can tell by looking whether a particular piece of code is safe or not.

Compiler writers could/should start by not treating undefined behavior as blank checks.

This is so idiotic, and no, it's not a bug in Cap'n'Proto, it is very definitely a bug in the compiler (and/or the current version of the C spec. if it actually allows this).

The C standard allows the compiler to do this, so it's definitely not a bug in the compiler.

As I wrote earlier:

I had a C compiler before there was C standard. So by your definition, this compiler could not have bugs?

As an exercise, try to express the difference between "standards-compliant" and "bug-free".

I think the main point is that if there is a standard, an implementation should comply. If there is no standard, you have to use intuition and common sense to say what's a bug.

Different people may have different expectations, so bugs become subjective.

Ideally, there is a water-tight standard. In this case every deviation from the standard is a bug and vice versa.

> if there is a standard, an implementation should comply

Yes. However, we are talking specifically about the parts where the standard is undefined. The standard most emphatically does not require a compiler to do these crazy optimizations that remove safety critical code.

So rewriting code in order to "do what I mean" makes sense, since not doing what you mean is a bug in the language itself?

Not sure that's a very productive approach. The spec is what it is, and it's of course rather deliberately done the way it is in order to make it possible for compilers to optimize and extract more performance.

Not so much "do what I mean" as "do what the underlying hardware architecture does". For example, on pretty much any machine your code is likely to run on these days, pointer arithmetic is the same as unsigned arithmetic, and so it's quite reasonable to expect C compilers to treat it that way. The spec can't mandate this because there are some obscure historic systems where pointer arithmetic is bounds-checked in hardware or has other oddities, but people not writing code for those systems shouldn't have to deal with that.

We're seeing these new security bugs because the abuse of portability wiggle-room as a corner to intentionally cut is changing the meaning that a human is trying to convey in a logical statement.

I still assert that at the very least if logical operations are eliminated they should be verbosely enumerated in the output of the compiler.

It might also be nice if there were a way of marking a section as /security/ rather than /speed/ critical, and thus transformations on the highlighted section would be far more limited.

> "do what I mean"

Well, the code is right there, there is no magic "do what I mean" needed. Just don't magically remove code that I wrote.

> spec is [..] rather deliberately done the way it is in order to make it possible for compilers to optimize and extract more performance

Yes, and it is wrong. Breaking existing programs with magic that simply removes code that is clearly there in order to eke out a bit of performance is wrong.

> Just don't magically remove code that I wrote.

Compile with O0.

> Yes, and it is wrong. Breaking existing programs with magic that simply removes code that is clearly there in order to eke out a bit of performance is wrong.

Well welcome to writing C? It's been this way for a long time and that won't change - UB is critical to performance and doesn't always lead to unsafety. If you're programming in C, don't blame the compiler when your UB leads to remote code exec, you should have known what you were getting into.

> Well welcome to writing C?

I've been writing C for 30 years.

> UB is critical to performance

Not really, no. See

"What every compiler writer should know about programmers or “Optimization” based on undefined behaviour hurts performance"

(referenced elsewhere in this thread)

http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_201...

C optimizers have and will optimize around UB. Feel free to call it a bug in C, the compiler, or the programmer, or the code - when you write C, when you use a common compiler, you're asking for vulnerabilities.

Thanks for the paper. It's very interesting but I think it has no real impact on my initial statement - these optimizations aren't going away, you can continue to expect problems like this vuln in the future for the same reasons.

Having something wrong be or become reality doesn't change it being wrong.

Ok... so what? I don't care if you blame the compiler or the spec, and no one else should either - the end result is the same, vulnerable code.

> Well, the code is right there, there is no magic "do what I mean" needed. Just don't magically remove code that I wrote.

You can already do that: use a non-optimising compiler (tcc and the like) or compile without optimisations.

Reply on news.ycombinator.com