Rust frontend approved for GCC

> you won't get a bad result, just less optimization.

And why would anybody want less optimization? The only reason to enable this flag would be to mask undefined behavior (UB), i.e., to allow a developer to write unsafe code that violates the aliasing invariants of rust and avoid some crashes that might result from this. There is no good reason to ever switch on this flag. If you have code that does not work without this flag, then this code is UB and has to be fixed. If your code does not have UB, then there is no need for this flag.

If rust would allow this flag for gcc than there might be developers relying on it (instead of writing correct code) and produce code that cannot be safely compiled with rustc (llvm). This should be avoided.

... of course, Rust's provenance rules are not the same as C's (and more generally nor are its aliasing rules). This has caused trouble with LLVM in the past.

Uh. Please ignore that comment, I was thinking of disabling mem alignment for some very strange reason. I need more sleep.

I don't think type-punning through transmute should cause any optimisation issues, though? Rust's main aliasing rule is that an exclusive reference (&mut T) can't coexist with any other reference (&T or another &mut T) to the same object. If you have a &u32 and a &f32 referencing the same object, they're both read-only so there's no opportunity for the optimiser to mess it up. E.g. if the compiler caches one reference's value in an integer register and the other in a float register, and doesn't realise that they're linked, that's fine because the value can't change anyway.

That contrasts with C where aliasing is based on types, not mutability, in which case you might have an int* that illegally aliases a float*, and if you write to the int* the compiler may continue to use the stale cached value of the float* (unless you use -fno-strict-aliasing to change the aliasing rules).

In Rust I think you could alias &Cell<u32> and &Cell<f32> (at least I can't see any particular reason that would be undefined behaviour?), where Cell allows mutation through a non-exclusive reference. But internally it uses raw pointers, and (if I understand correctly) Rust assumes that raw pointers can alias any object of any type. That means raw pointers are effectively -fno-strict-aliasing by default, and it will generate suboptimal code when they don't actually alias (but that's okay because you can just avoid using raw pointers in performance-critical code; you should be using normal safe references instead).

Note that transmute notionally does memcpy, and memcpy is exactly how you're allowed (without Undefined Behaviour) to write type punning in C or C++. In most cases the compiler can see what you're getting at and elide the actual memcpy but if for whatever reason the compiler can't figure out what's really going on, that memcpy prevents you getting into a place where unrelated optimisations blow up your transmute.

Transmute is hideously dangerous *anyway* but not directly because of aliasing concerns. For example you can transmute some bytes you found into a string, which Rust then assumes is UTF-8 encoded. Or you can transmute the integer 0 into a NonZeroUsize, and then hand that to APIs which explicitly took NonZeroUsize because they can't handle zeroes. Or transmute 69 into a bool which is now sometimes neither equal to true nor false. Nice. Wait, no, that's not nice at all.

I don't think this is feasible, at least not in the anything but very simple cases. Imagine for example a struct that stores some text in a string type with inline storage optimization and also holds a reference to a substring. This means that depending on the length of the string, which is probably buried deep in some unsafe code, your struct might be self-referential or not.

How do you automatically determine how to move this type? If you could track all of this, you'd be halfway towards a garbage collector.