GCC's new fortification level: The gains and costs (2022)

You could do it legally, but the results are not required to be what you want them to be.

No, it is not, and it has never been OK for as long as C has been standardized by ANSI or ISO.

C89 says that "The value of a pointer that refers to freed space is indeterminate." and that behavior is undefined "upon use ... of indeterminately-valued objects", hence a compiled program can e.g. behave as if `new_pointer == old_pointer` even though the object was relocated in memory.

> It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

Hmm, could possibly include optimization flags directly into the source code (would be clearer and less compiler mess perhaps). I could also see this causing other issues...

> It also won't be optimizing other loops that you want it to optimize. Turns out it's a tradeoff and lots of people choose C and C++ exactly because of this focus on speed..

Yeah. That's sad but there's nothing that can be done about it. If you write C you're basically guaranteed to violate strict aliasing at some point and I just cannot handle the uncertainty anymore. The Linux kernel developers are much smarter than me and as far as I know they reached the same conclusion as I did: this aliasing stuff is not even worth enabling.

I know there's a may_alias attribute you can apply to pointers to warn the compiler but I'm not confident in my ability to do it 100% correctly. I have a feeling it'd end up getting applied to a significant chunk of the code anyway, might as well just turn it off.

> char is allowed to alias other types.

I know. But can uint8_t? It's basically the same type as unsigned char but it's still a distinct type in the compiler's eyes. Never found a definitive answer to that question. What if you define your own u8 type?

I know for a fact uint16_t can't safely alias anything. Implementing a 16 bit hash function? Hoping to just treat an arbitrary buffer as an array of u16? Not gonna happen unless you turn off this aliasing nonsense.

> Other types of aliasing are rarely needed and you can always memcpy the contents if you really do need to.

I shouldn't have to copy huge buffers all over the place just to get the compiler to generate the simple instructions I want. This is on the same level as the "pointer laundering" advice I've received. Oh just pass the pointer through some inline assembly, compiler can't see into it so it assumes anything can happen and it won't screw up the code trying to optimize. This memcpy is just yet another thing the compiler can't see into. The proper solution is to kill the problematic optimizations.

> No prescribes it because otherwise it would need to load from memory on every pointer dereference after something completely different has been written to. This is obviously undesirable if you care even one bit about performance.

It doesn't have to be that way. I statically link all my code, enable link time optimization, pass flags like -fwhole-program. Surely the compiler can analyze the entire program and statically determine that certain pointers do not alias.

I have a memory allocator that works with a huge statically allocated byte buffer as its backing memory. Surely the compiler can determine that all pointers returned by my memory allocation functions are subsets of that buffer and that they do not necessarily alias each other.

> use flags to change the language semantics to your taste

That's exactly what I was advocating for in my post.

> That doesn't make the default semantics bad though.

I would argue that they are extremely bad. Compilers will straight up delete overflow and null checks from your code if the conditions are right. This can cause it to "optimize" entire functions into literally nothing. There's just no way anyone can convince me that this is not adversarial, if not malicious.

> Then C and C++ are simply not made for you.

C was made to support the development of Unix. I'm writing similar low level Linux operating system stuff. I'd say I'm closer to the target audience than all these speed obsessed folks ever were.

> There are plenty of "safe" languages for people who don't care about the perfomance impact.

I absolutely do care about performance in general.

I said I don't care about the performance impact of that one flag. Adding that flag buys me the certainty that the compiler won't screw the code up based on absolute nonsense assumptions that I don't ever want it to make. I've made the decision to not care in this case. I absolutely do want all the other optimizations the C compilers will give me.

And I don't want "safe", I want "sane".

Things like signed integer overflow not being C's particularly idiotic "can't ever happen, please delete any checks" flavor of undefined falls under my definition of "sane". I also consider overlaying a structure on top of a byte buffer to be such a basic operation there's no point in using C at all if the compiler is gonna screw this up.

> Try -O0.

No. That disables too many useful optimizations that are not problematic in any way whatsoever.

C was hardly a performance juggernaut in the 1980's, any junior Assembly coder could easily outperform the outcome of the C compilers.

It was by exploring UB to the extreme those compilers optimizers do nowadays, that such language finally got the fame it has 40 years later.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

> Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

This goal seems somewhat oxymoronic - if the "goal" is to be keenly aware of what the compiler will do and double check all assembly, then you shouldnt use C. If the goal is to ignore assembly and not pay attention to these sorts of things, then you shouldnt use C.

The only valid niche I see is where the goal is to use C, not really have to worry about the assembly, have it do the "right" thing on your platform. I.e. no undefined behavior, just underperforming (and called out as such). Then you can go in and "approve" various optimizations.

> Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

If performance is your top priority C is also the wrong choice.

I write C because I like C. That's the only reason I've got. It's what I feel comfortable writing code in. I tried learning Rust but I just couldn't get used to it.

I like C where I write the functions and the structures and the compiler just translates it to the simple processor instructions you expect it to. No complicated hidden machinery under the hood, just simple unmangled symbols pointing at simple code that conforms to simple ABIs. This simplicity is also the reason the so called "C ABI" is so ubiquitous.

Another reason I write C is it's one of very few languages with freestanding code support. I only write freestanding C targeting the Linux kernel-userspace ABI. In my opinion C is a much nicer language without the libc and its legacy. I really enjoy it.

Type punning with unions was actually forbidden by C89. You were only ever supposed to read the union member which was last written to. This may have been relaxed in C17; I can only find a draft online, but it allows for type punning in unions as long as the member being read is not longer in size than the member last written to.

The optimizations can easily be gained back by "manual" loading and storing to temporary local variables.

The classical:

  int foo(float *f, int *x) {
    *x = 2;
    *f = 3.0f;
    return *x; // oh no, without typed based aliasing I have to load x again!
  }

  int foo(float *f, int *x) {
    int z = 2;
    *x = z;
    *f = 3.0f;
    return z; // ah, thank you programmer, z has not had its address taken, it's obviously 2.
  }

> strict aliasing allows for optimizations that are actually worthwhile

I don't think there are many sensible, real world examples.

A nice explanation of the optimizations the strict-aliasing rule allows: https://stackoverflow.com/a/99010/66088

The example given is:

    typedef struct Msg {
        unsigned int a;
        unsigned int b;
    } Msg;

    void SendWord(uint32_t);

    int main(void) {
        // Get a 32-bit buffer from the system
        uint32_t* buff = malloc(sizeof(Msg));

        // Alias that buffer through message
        Msg* msg = (Msg*)(buff);

        // Send a bunch of messages
        for (int i = 0; i < 10; ++i) {
            msg->a = i;
            msg->b = i+1;
            SendWord(buff[0]);
            SendWord(buff[1]);
        }
    }

The problem I have is that when we re-write the example to use a union, the generated code is the same regardless of whether we pass -fno-strict-aliasing or not. So this isn't a working example of an optimization enabled by strict aliasing. It makes no difference whether I build it with clang or gcc, for x86-64 or arm7. I don't think I did it wrong. We still have a memory load instruction in the loop. See https://godbolt.org/z/9xzq87d1r

Knowing whether a C compiler will make an optimization or not is all but impossible. The simplest and most reliable solution in this case is to do the loop hoisting optimization manually:

        uint32_t buff0 = buff[0];
        unit32_t buff1 = buff[1];
        for (int i = 0; i < 10; ++i) {
            msg->a = i;
            msg->b = i+1;
            SendWord(buff0);
            SendWord(buff1);
        }

Note 1: The first thing that goes wrong for Stackoverflow example is that the compiler spots that malloc returns uninitialized data, so it can omit the reloading of buff in the loop anyway. In fact it removes the malloc too. Here's clang 18 doing that https://godbolt.org/z/97a8K73ss. I had to replace malloc with an undefined GetBuff() function, so the compiler couldn't assume the returned data was unintialized.

Note 2: Once we're calling GetBuff() instead of malloc(), the compiler has to assume that SendWord(buff[0]) could change buff, and therefore it has to reload it in the loop even with strict-aliasing enabled.

> but "carry" is really only useful in asm code for adding and subtracting integers larger than register size, which is not much of a thing these days

Funny you mention that. I'm studying math and algorithms to implement the arbitrary precision integer support for my programming language. The word "carry" is showing up a lot in my research so that bit does seem to be an incredibly useful feature and I have no idea why they'd remove it.

> None of the flags are accessible from C either so they just dropped them and things seem to be going well!

I know you can't directly access those flags but the fact is compilers do provide their functionality to programmers via builtins.

For example:

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

Those builtins will cause the compiler to generate optimal instructions such as conditional jumps that depend on the carry or overflow bits.

I used the __builtin_mul_overflow function to check for overflow in my memory allocation code.

This is what we really want. We want to handle these conditions, no matter how they're implemented. This is a perfectly acceptable way for the compiler to expose these processor features in a way that makes sense to us programmers. In the case of RISC-V, GCC will just emit whatever code is appropriate for checking overflows on that processor.

What's definitely not acceptable is for the compiler to just go "aw man look at this USELESS overflow checking code over here, AS WE ALL KNOW signed integer overflow is UNDEFINED and therefore CANNOT EVER HAPPEN, why the hell is this shit for brains programmer checking for a thing that can't happen, I'll just go ahead delete this nonsense code literally right now, oh wow would you look at that, looks like I just optimized the entire program into a noop, I must be the best compiler in the universe".

> In fact, I dare say: every allocation size that is neither `0` or `sizeof(T)` doesn't fundamentally care about the size

Not true? When you copy an array (common case: string) that is passed to you, you want the copy to the the same size. No more (that wastes memory) and no less (then you don't have a copy), just as with sizeof(T).

I hadn't thought about the `sizeof(T)` point before, and I can think of a handful of exceptions, but it's a great and expressive rule of thumb.

I don't think this or the sibling would be improved with a function that gave you an arbitrarily sized allocation where you also need to query the size of that allocation though? In all the cases you need to know what the size of the buffer is, even though you don't care whether it's 1kb, 4kb, or 8kb (although I imagine you'd care if you got 16b or 16gb)

I would be surprised in the general case. Realloc does have side effects and the size parameter can be known at runtime only, etc.

I tend to argue that continuing to function after a memory overrun is _unlucky_ because it's better to have it fail loudly so you know to fix it instead of it potentially not noticing subtly incorrect behavior.