GCC always assumes aligned pointer accesses (2020) • Hacker News Board

Re: GCC always assumes aligned pointer accesses (2020)

#11

Post by shadowofneptune » Sun, Aug 20, 2023, 3:40 PM UTC

The big thing seems to be less about GCC, and more a question of, "what should a compiler be?"

He'd be better looking at smaller, less-known compilers, like the Portable C Compiler or the Intel C Compiler. If you want hyper-optimized, better-than-assembly quality, you pretty much have to give up predictability. The best optimizations that are predictable can't be written using modern compiler theory. They instead involve a lot of work, care, and attention that can't be generalized to other architectures. It can require a love for an architecture, even if's a crap one.

It's a tradeoff. Not every compiler needs to be optimized, and not every compiler needs to embody the spirit of a language.

Re: GCC always assumes aligned pointer accesses (2020)

#12

Post by j16sdiz » Sun, Aug 20, 2023, 3:44 PM UTC

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…

That's what the author meant when he said "The shift of the C language from “portable assembly” to “high-level programming language without the safety of high-level programming languages”"

Back in the 1980s, C was expected to do what hardware does. There was no "the C abstract machine".

The abstract machine idea was introduced much later.

> The arguments in this blogpost are fundamentally flawed.

The "fundamentally flawed" comment is revisionist idea.

Re: GCC always assumes aligned pointer accesses (2020)

#13

Post by j16sdiz » Sun, Aug 20, 2023, 3:47 PM UTC

Athas wrote: post #5

Dwedit wrote: post #3

We need an '__unaligned' modifier for pointers to specify that the pointer will be used for unaligned reads and writes.

Why not just use memcpy()?

Because, in some hardware, unaligned read is ok. and you want to take advantage of the hardware feature?

Re: GCC always assumes aligned pointer accesses (2020)

#14

Post by phkahler » Sun, Aug 20, 2023, 3:47 PM UTC

If you're going to read byte-level data you should be using a char pointer.

The author also speculates on how common this "bug" is. I'd say 15000 Debian packages that work properly indicates that just about nobody is relying on this undefined behavior.

Re: GCC always assumes aligned pointer accesses (2020)

#15

Post by dzaima » Sun, Aug 20, 2023, 3:50 PM UTC

j16sdiz wrote: post #13

Athas wrote: post #5

Earlier quoted context omitted.

Why not just use memcpy()?

Because, in some hardware, unaligned read is ok. and you want to take advantage of the hardware feature?

Both gcc and clang will optimize a memcpy to an unaligned load/store where possible.

Re: GCC always assumes aligned pointer accesses (2020)

#16

Post by WalterBright » Sun, Aug 20, 2023, 3:52 PM UTC

The D programming language does not allow the creation of misaligned pointers in code marked as @safe, and in @safe code assumes they are aligned. In @system code you can do whatever you like, but things need to be aligned that are provided to @safe code.

Re: GCC always assumes aligned pointer accesses (2020)

#17

Post by tom_ » Sun, Aug 20, 2023, 3:52 PM UTC

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…

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 implementation issue I think it a reasonable request.

This is such an obvious thing to do that I'm surprised the C standard doesn't include wording along those lines to accommodate it. But I suppose even if it did, people would just ignore it.

Re: GCC always assumes aligned pointer accesses (2020)

#18

Post by azakai » Sun, Aug 20, 2023, 3:57 PM UTC

An example of a recent compile target that breaks on unaligned pointer accesses was asm.js. There, a 32-bit read turns into a read from a JavaScript Int32Array like this:

HEAP32[ptr >> 2]

The k-th index in the array contains 4 bytes of data, so the pointer to an address must be divided by 4, which is what the >> 2 does. And >> 2 will "break" unaligned pointers because it discards the low bits.

In practice we did run into codebases that broke because of this, but it was fairly rare. We built some tools (SAFE_HEAP) that helped find such issues. In the end it may have added some work to a small amount of ports, but very few I think.

asm.js has been superceded by WebAssembly, which allows unaligned accesses, so this is no longer a problem there.

Re: GCC always assumes aligned pointer accesses (2020)

#19

Post by j16sdiz » Sun, Aug 20, 2023, 3:57 PM UTC

SAI_Peregrinus wrote: post #8

jcranmer wrote: post #4

Earlier quoted context omitted.

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…

It dates to the first standardization of C in 1989. The "C as portable assembly" view ended when ANSI C got standardized, and K&R's 2nd edition was published.

I would argue it's the modern understanding of C standard is flawed.

Back in 89, many of those unspecified behavior were understood as implementation/hardware dependent, not undefined. Aliasing was the norm, `restrict` was actually a keyword.

Modern C is neither safe nor low-level.

Re: GCC always assumes aligned pointer accesses (2020)

#20

Post by banthar » Sun, Aug 20, 2023, 3:57 PM UTC

This is how all undefined behavior works. It seems to be working now but breaks with new CPU, GCC version or on wrong moon phase.

"-Wcast-align=strict" will work in this but not all cases - that's why we have UBSAN:

    $ gcc -fsanitize=undefined test.c
    $ ./a.out 
    test.c:6:6: runtime error: store to misaligned address 0x55e4007adeb1 for type 'int', which requires 4 byte alignment
    0x55e4007adeb1: note: pointer points here
     00 00 00  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  51 00 00 00 00