🐿️Ben Gamble🦯

Okay goddamnit, we just ran into one of the most obscure and elusive bugs I've ever encountered working on our Ocarina of Time port for the Sega Dreamcast. It reared its ugly head while we were balls deep in the inline SH4 assembly, optimizing the game for DC... and I seriously CANNOT explain why the offending code caused an issue, even if we found a way to work around it... Are there any inline assembly or GCC compiler experts in the house? I know how obscure this shit is, but... hopefully there's someone I'm connected with who is well-versed in the dark arts... if so, have a seat and let me weave you a tale... What's the deal? Well, we're using my SH4 vector and math library, SH4ZAM, to accelerate a bunch of the math and hot routines in this port, going from N64 to DC, to improve performance, as we always do. What we have here is two slightly different versions of the exact same hand-optimized memcpy() variant routine, with the bare minimum code present for the routine to work and to reproduce the issue. It copies exactly 16 4-byte words from a source address to a destination address. We use this version ONLY to copy unaligned 4x4 matrices around in memory (cuz we can do much better with higher aligned matrices). ANYWAY. The one on the left? The working version of the code. Does its thing. Life is good. The one on the right? The original implementation... NOT A DAMN THING WRONG... except... owait, where's the minimap icons!? TOAST. The only difference between the two? The types of the pointers which we are using as input and output constraints to the same block of inline assembly. Since the two argument pointers are void*, we must cast them to something to give them a size as memory constraints for the inline ASM block. On the left, they are casted to 64-element byte array, which is legally allowed to alias any memory based on C/C++'s "strict aliasing" rules. On the right? We're using a pointer to a special typedef'd uint32_t which tells GCC that we're allowed to alias memory and break GCC's strict aliasing rules by referencing memory from such a pointer. So the constraints on the right take pointers to an array of 16 32-bit words which are allowed to be aliased as uint32_ts... I have searched everywhere I possibly could and cannot see any reason these two should not behave identically. Yeah, I'm breaking strict aliasing rules on the right, but so? That GCC aliasing attribute does properly get GCC to fuck off and allow me to carry on violating those rules perfectly fine from C and C++ code... so what's the problem here? Only thing I can even think of is that GCC's extended inline assembly blocks are not honoring the "may_alias" attribute on the typedef that we're using to refer to our source and destination memory addresses, and the whole block of inline ASM is getting optimized away for breaking strict aliasing rules when we pass a 4x4 float matrix to it? Anyone know if this is the case? Is that even documented anywhere? Anyway, this is the latest and greatest GCC version 15.2.1 toolchain, cross-compiling for the Sega Dreamcast's "SuperH4" CPU architecture. Yes, we are rocking -O3, -flto, -fipa-pta, and pretty much every optimization under the sun which is interacting with these blocks of inline ASM, further adding to the shitstorm... THOUGHTS? 😂