The SPARC cc compiler has (had) a -misalign flag. Maybe the GCC guys could support the same option?
https://docs.oracle.com/cd/E19957-01/805-4952/6j4mdcegh/inde...
GCC always assumes aligned pointer accesses (2020)
91–100 of 128 posts
Re: GCC always assumes aligned pointer accesses (2020)
#92Yes, compilers take advantage of undefined behavior.
Re: GCC always assumes aligned pointer accesses (2020)
#93Earlier quoted context omitted.
I haven't gotten to use C in industry, but I was taught that undefined behavior just means that it is defined by the running system and not the compiler. Is that not the general understanding? Maybe I was just taught that way because it was old timers teaching it.
What you are talking about is implementation-defined behavior. It exists in the C standard separately from the undefined behavior.
Implementation Defined behavior means the standards authors provided a list of possible behaviors, and compiler authors must pick one and document which they picked.
Unspecified behavior is more what you're thinking of, though in that case the standard still provides a list of possibilities that compiler authors have to pick from, they just don't have to document it or always make the same choice for every program.
There's no allowed subset of behavior where compiler authors are free to pick whatever they want and document it (but must do so). IMO there should be, most "Undefined Behavior" could be specified and documented, even where that choice would be "the compiler assumes such situations are unreachable and optimizes based on that assumption" like much of current UB. At least it'd be explicit!
Re: GCC always assumes aligned pointer accesses (2020)
#94Unaligned pointer accesses are for 80386 bozos.
Period
End of story.
If you want to play in 64-bit land, live by the architectural rules. If you do not, your code will likely die. And you need to "Lurn" a lot
Re: GCC always assumes aligned pointer accesses (2020)
#95Earlier quoted context omitted.
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.
For C to be portable this needs to be undefined behaviour because there are CPUs that don’t support unaligned access
There are some other reasons, but that's one of them.
Another is that you want to guarantee objects are stored aligned in memory because that gives you some free bits in pointers you can hide stuff in. (This has less hardware support than it should.)
Re: GCC always assumes aligned pointer accesses (2020)
#96Earlier 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…
indeed, I still have ~20 years old code that picks up and rectifies unaligned memory so gcc does the right thing. To claim a compiler bugs out on unaligned memory sounds very weird, I assumed that was common knowledge.
My first 10 minutes of trying to talk to hardware, and then googling the error message. taught me.
Re: GCC always assumes aligned pointer accesses (2020)
#97As others have pointed out, GCC is completely allowed to do this because unaligned access is UB.
So the problem is not that GCC assumes your code has no UB.
The issue is that the C (and C++) specifications persist in this obnoxious and odious desire to label definable behaviour as UB, with no justification.
All of the arguments about needing UB to support different hardware fail immediately to the simple fact that the specification already has specific terms that would cover this: Implementation Defined Behavior, and Unspecified Behaviour. Using either of these instead of UB would support just as much hardware, without inflicting clearly anti-programmer optimizations on developers where the compiler is allowed to assume objectively false things about the hardware.
Undefined behaviour should be used solely for behavior that cannot be defined - for example using out of bounds, unallocated, or released memory cannot be defined because the C VM does not specify allocation, variable allocation, etc. Calling a function with a mismatched type signature is not definable as C does not specify the ABI. etc.
Re: GCC always assumes aligned pointer accesses (2020)
#98Earlier quoted context omitted.
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 f…
> Back in the 1980s, C was expected to do what hardware does. There was no "the C abstract machine". There was also a huge variety of compilers that were buggy and incomplete each in their own ways, often with mutually-incompatible extensions, not to mention prone to generating pretty awful code.
Indeed, those two statements are the same thing.
If you want a correct compiler it has to be correct according to a model, which means it can't handle things outside that model, and now you have "undefined behavior".
People want compilers to limit how much they transform UB, but that's not possible unless it gets defined. Which you can do, of course, but it's more limiting than it looks.
Re: GCC always assumes aligned pointer accesses (2020)
#99The 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…
If you really are targeting the x86_64 instruction set, you should be writing x86_64 instructions. Then you get exactly what the hardware does and don’t get any of those pesky compiler assumptions. Of course you don’t get any of those pleasant optimizations either. But those optimizations are only possible because of the assumptions.
There's some optimizing x86 assemblers actually. Of course, now you have to follow their rules.
Re: GCC always assumes aligned pointer accesses (2020)
#100Unaligned pointer accesses are for 80386 bozos. Period End of story. If you want to play in 64-bit land, live by the architectural rules. If you do not, your code will likely die. And you need to "Lurn" a lot
While illegal in C most modern 64-bit processors support unaligned accesses.