Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC always assumes aligned pointer accesses (2020)

trust-in-soft.com

Post reply on HN
Print view View original

101–110 of 128 posts

Re: GCC always assumes aligned pointer accesses (2020)

#101

Post by tialaramex »

zokier wrote: post #84
tedunangst wrote: post #75

Earlier quoted context omitted.

It could probably only be used with a neural link. It would read your mind, then emit code that matches your perception of what you imagine old compilers did.

You jest, but there was some real effort put in to attempt define a dialect of C that would be less UB etc. And indeed the big problem was defining the semantics: > After publishing the Friendly C Proposal, I spent some time discussing its design with people, and eventually I came to the depressing conclusion that there’s no way to get a group of C experts — even if they are knowledgable, intelligent, and otherwise r…

Right, One of the many benefits of Rust is that it provides a convenient litmus test for C and C++ programmers who complain about UB. For some of them, having a language (safe Rust) where programs don't have Undefined Behaviour is excellent - but for a whole lot of them this isn't OK.

And the reason IMO is that they didn't actually want Defined Behaviour. What they wanted is for their nonsense programs to just work anyway. They want to skip the hard part of the job of software engineer where you need to correctly express what you meant as a program. They're the current generation of the people Charles Babbage complained of, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?'.

Re: GCC always assumes aligned pointer accesses (2020)

#102

Post by saagarjha »

titzer wrote: post #51
JoeAltmaier wrote: post #27

Machine language architecture is flawed. The assumption of alignment is in the machine language. Compilers can only use the instructions that are there. They have a difficult choice: close their eyes and generate aligned-pointer moves, or use a sequence of tests and partial move instructions that is orders of magnitude less efficient. We've needed machine instructions to load or move memory efficiently regardless of…

In retrospect, too many crazy software dances are due to miserliness on the part of hardware designs. Saving a couple bits in the address lines and not needing to straddle cache lines? We're far past the point where that's a considerable cost, as all modern ISA implementations now attest.

Everyone does this, but it’s definitely not trivial. Unaligned pointers have to deal with things like straddling pages.

Re: GCC always assumes aligned pointer accesses (2020)

#103

Post by saagarjha »

Gibbon1 wrote: post #67
eklitzke wrote: post #46

Earlier quoted context omitted.

The blog post is also kind of unhinged because in the incredibly rare cases where you would want to write code like this you can literally just use the asm keyword. I think it's also worth considering WHY compilers (and the C standard) make these kinds of assumptions. For starters, not all hardware platforms allow unaligned accesses at all. Even on x86 where it's supported, you want to avoid doing unaligned reads at…

> For starters, not all hardware platforms allow unaligned accesses at all. Yeah and always everywhere a mistake. It was a mistake back in the 1970's and it's increasing bigger mistake as time goes on. Just like big endian and 'network order'

Not really. They’re quite convenient in many cases, and can actually be more efficient than carefully preparing aligned loads/stores.

Re: GCC always assumes aligned pointer accesses (2020)

#104

Post by saagarjha »

eklitzke wrote: post #46
volta87 wrote: post #2

The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…

The blog post is also kind of unhinged because in the incredibly rare cases where you would want to write code like this you can literally just use the asm keyword. I think it's also worth considering WHY compilers (and the C standard) make these kinds of assumptions. For starters, not all hardware platforms allow unaligned accesses at all. Even on x86 where it's supported, you want to avoid doing unaligned reads at…

> Even on x86 where it's supported, you want to avoid doing unaligned reads at all costs because they're up to 2x slower than aligned accesses.

This is generally not true.

Re: GCC always assumes aligned pointer accesses (2020)

#105

Post by saagarjha »

volta87 wrote: post #2

The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…

I think you (and most of the other commenters in this thread) misunderstand the perspective of the author. This is a tool meant to do static analysis of a C codebase. Their job is not to actually follow the standard, but identify what “common C” actually looks like. This is not the same as standard C.

There are a lot of things compilers do not optimize on even though they are technically illegal. As a result, people write code that relies on these kinds of manipulations. No, this is not your standard complaint about undefined behavior being the work of the devil, this is code that in certain places pushes the boundaries of what the compiler silently guarantees. The author’s job is to identify this, not what the standard says, because a tool that rejects any code that’s not entirely standards compliant is generally useless for any nontrivial codebase.

Re: GCC always assumes aligned pointer accesses (2020)

#106

Post by saagarjha »

jcranmer wrote: post #4
volta87 wrote: post #2

The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…

This line in particular really bugs me: > The present blog post brings bad, and as far as I know, previously undocumented news. Even if you really are targeting an instruction set without any memory access instruction that requires alignment, GCC still applies some sophisticated optimizations that assume aligned pointers. I could have told you this was true ~20 years ago, and the main reason I'm so conservative in ho…

What you’re saying and what the blog post is implying are different things. This is an admission that GCC optimizes on this behavior in practice. Your claim is that GCC could optimize on this, which is a much less interesting claim.

Re: GCC always assumes aligned pointer accesses (2020)

#107

Post by saagarjha »

chaboud wrote: post #65
circuit10 wrote: post #29

Earlier quoted context omitted.

For C to be portable this needs to be undefined behaviour because there are CPUs that don’t support unaligned access

That’s why, while much of the linked blog is kind of off the mark (signs of someone knowing less than they think they know), the general conclusion, using aligned pointers is recommended, is one that I typically recommend to developers new to C or C++ anyway. I’m alright with folks sticking to aligned pointer operations, largely for performance reasons. On some platforms, unaligned operations are really expensive.

I know the author. Your guess here is wrong.

Re: GCC always assumes aligned pointer accesses (2020)

#108

Post by saagarjha »

robinsonb5 wrote: post #53
tom_ wrote: post #17

Earlier quoted context omitted.

And one of the anythings permitted would be to behave in a documented manner characteristic of the target environment. The program is after all almost certainly being built to run on an actual machine; if you know what that actual machine does, it would sometimes be useful to be able to take advantage of that. We might not be able to demand this on the basis that the standard requires it, but as a quality of implemen…

The problem is that what the machine does isn't necessarily consistent. If you're using old-as-the-green-hills integer instructions then yes, the CPU supports unaligned access. If you want to benefit from the speedup afforded by the latest vector instructions, now it suddenly it doesn't. Also, to be fair, GCC does appear to back off the optimisations when dealing with, for example, a struct with the packed attribute.

That depends on which vector instructions you use.

Re: GCC always assumes aligned pointer accesses (2020)

#109

Post by saagarjha »

kmeisthax wrote: post #72
volta87 wrote: post #2

The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…

Great, except no implementation of the C abstract machine actually exists. So you can't test against it. All you have are compilers that use it to justify miscompiling your code. We need a C interpreter that intentionally implements C machine features that don't correspond to any architectural feature - i.e. pointers are (allocation provenance, offset) pairs, integer overflow panics, every pointer construction is che…

The general problem with this argument is that “do what the hardware does” is actually not easy to reason about. The end results of this typically are impossible to grok.

Re: GCC always assumes aligned pointer accesses (2020)

#110

Post by dataangel »

volta87 wrote: post #2

The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…

> When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything".

This view is alienating systems programmers. You're right that that's what the standard says, but nobody actually wants that except compiler writers trying to juice unrealistic benchmarks. In practice programmers want to alias things, they want to access unaligned memory, they want to cast objects right out of memory without constructing them, etc. And they have real reasons to do so! More narrowly defining how off the rails the compiler is allowed to go, rather than anything is a desirable objective for changing the standard.

Post reply on HN