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

GCC always assumes aligned pointer accesses

trust-in-soft.com

Post reply on HN
Print view View original

11–20 of 93 posts

Re: GCC always assumes aligned pointer accesses

#11

Post by ajross »

Spivak wrote: post #4
ajross wrote: post #2

The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory. I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.

Isn’t that in practice the same as an alignment problem? Can you have two ints overlap without a misaligned access?

No, but you can have two otherwise-perfectly-legal aligned accesses that overlap (consider two long longs on a 32 bit platform), and that's disallowed by the standard.

Re: GCC always assumes aligned pointer accesses

#12

Post by eqvinox »

ajross wrote: post #11
Spivak wrote: post #4

Earlier quoted context omitted.

Isn’t that in practice the same as an alignment problem? Can you have two ints overlap without a misaligned access?

No, but you can have two otherwise-perfectly-legal aligned accesses that overlap (consider two long longs on a 32 bit platform), and that's disallowed by the standard.

The compiler would know that the alignment is smaller than the type itself, which would disable the optimization mentioned in the post.

Re: GCC always assumes aligned pointer accesses

#13

Post by dooglius »

eqvinox wrote: post #8

No. [as in: this isn't about GCC.] The C standard requires that pointers generally be created from referencing a valid, existing object. A misaligned integer is not a valid "object", thus the compiler may assume that all pointers to ints are aligned (to 4 bytes.) https://en.cppreference.com/w/cpp/language/pointer Every value of pointer type is one of the following: - a pointer to an object or function (in which case…

Why "no", you're agreeing with the conclusion

Re: GCC always assumes aligned pointer accesses

#14

Post by eqvinox »

dooglius wrote: post #13
eqvinox wrote: post #8

No. [as in: this isn't about GCC.] The C standard requires that pointers generally be created from referencing a valid, existing object. A misaligned integer is not a valid "object", thus the compiler may assume that all pointers to ints are aligned (to 4 bytes.) https://en.cppreference.com/w/cpp/language/pointer Every value of pointer type is one of the following: - a pointer to an object or function (in which case…

Why "no", you're agreeing with the conclusion

"No, it's not GCC's fault / doing something weird." :)

But, yes. Edited to clarify.

FWIW this isn't a new problem either. If you wrote some C code in the 90ies using misaligned pointers, and then tried porting it to, say, a DEC Alpha, you'd get a SIGBUS in your face on first dereferencing such a pointer.

Re: GCC always assumes aligned pointer accesses

#15

Post by ajross »

eqvinox wrote: post #12
ajross wrote: post #11

Earlier quoted context omitted.

No, but you can have two otherwise-perfectly-legal aligned accesses that overlap (consider two long longs on a 32 bit platform), and that's disallowed by the standard.

The compiler would know that the alignment is smaller than the type itself, which would disable the optimization mentioned in the post.

It literally cannot. The function in the linked article, that takes two pointers, must be compiled in isolation. If it needs to depend on alignment or overlapping, it needs to emit code to check it. And the standard does not require it to, nor do typical users want that.

It's true that fancy tricks like LTO can make that kind of behavior visible to the optimizer, but the standard predates that kind of magic by several decades.

Re: GCC always assumes aligned pointer accesses

#17

Post by hedora »

eqvinox wrote: post #9
__s wrote: post #5

Earlier quoted context omitted.

-fno-strict-aliasing: https://stackoverflow.com/questions/98650/what-is-the-strict... Torvalds rant: https://www.yodaiken.com/2018/06/07/torvalds-on-aliasing edit: I misread the parent as wondering about a compiler flag

Irrelevant to the post, even without strict aliasing the compiler will assume pointers/objects are properly aligned.

Do you have an example where the compiler generates bad code that doesn’t involve misaligned aliases?

Many programs rely on misaligned access, and features like pragma packed do too. I doubt they’ll be able to break all of that legacy code.

Re: GCC always assumes aligned pointer accesses

#19

Post by eqvinox »

hedora wrote: post #16

The example of bad gcc behavior was essentially type punning, which is well-known to cause trouble. Is there an example where things break on misaligned access to non-overlapping objects?

Misaligned accesses, in general, without any qualification, can earn you a SIGSEGV or SIGBUS. It's mostly x86 that's being very tolerant here; other architectures are much less forgiving to varying degrees.

That's also why this rule is in the C standard to begin with. Misaligned accesses need different / multiple instructions on some of these architectures, making them significantly more expensive. So the decision was made in favor of assuming things are aligned.

Re: GCC always assumes aligned pointer accesses

#20

Post by not2b »

loeg wrote: post #3
ajross wrote: post #2

The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory. I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.

Yes, this is the compiler optimizing UB due to aliasing , not due to alignment.

Yes, the optimization assumes that given two pointers to int, either they point to the same int, or they point to distinct, non-overlapping ints. Under that restriction the result is guaranteed to be 1. It's allowed to do so by the standard because those are the rules.

C was portable assembly back in the early 1980s. The result was that it was crushed in performance by Fortran for scientific codes, and most of the difference had to do with assumptions the compiler could make about aliasing (or the lack of it). This was fixed by the first ANSI C standard (finalized in 1989).

Yet I still see people who weren't even born then, or were young children then, talk as if C is supposed to be "portable assembly". It isn't.

Post reply on HN