That's quite an achievement, but you've got to realise that hacks which overwrite the stack return address are not maintainable and likely wouldn't work except for a narrow range of compilers (and even specific versions of those compilers with specific options). It also won't work with stack hardening.
Also it's function-level (like golang) not scope-level (like attribute cleanup). As argued elsewhere in the this thread, golang got this wrong.
Also also, overwriting the return address on the stack kills internal CPU optimizations that both Intel and AMD do for branch prediction.
Maintainable is a point of view. Works fine w/ -fstack-protector for me.
Saying it supports a narrow range of compilers is like saying US two-party system only supports a narrow range of registered voters. Libertarians and Greens absolutely deserve inclusion. They can vote but the system doesn't go out of its way to make life as exciting as possible for them. The above Gist caters to GCC/Clang. Folks who use MSVC, Watcom, etc. absolutely deserve to be supported. The Clang compiled modules can be run through something like objconv and linked into their apps.
Not convinced about scope-level. Supporting docs would help. Sounds like you just want mutex. I'm not sure if I can comment since I can't remember if I've ever written threaded code in C/C++. I would however sheepishly suggest anyone wanting that consider Java due to (a) literally has a class named Phaser come on so cool (b) postmortems I read by webmaster where I once worked.
Not concerned about microoptimizations. All I really wanted was to be able to say stuff like
const char *s = gc(xasprintf("%s%s", a, b));
Also folks who use those new return trapping security flags might see the branch predictor side-effects as a benefit. Could this really be GC for C with Retpoline for free? I don't know. You decide.
