https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> --- > That would be an ABI change for C++ functions like: > > void func(int8_t); > > Such functions would get a different mangled name after the fix, so would no > longer link to code compiled before the fix. They would also be incompatible > with code compiled by Solaris compilers that use the un-fixincluded system > headers (I'm not sure if that matters though, is there binary compatibility > between G++ and Solaris CC?) Studio CC 12.6 by default uses -m32 -std=sun03 -library=Cstd, which means the old Sun C++ ABI supported since Studio CC 5.0. However, with -std=c++11 or -std=c++14, it implements the GNU ABI. So CC users are used to ABI issues already ;-) In the GCC testsuite, the ABI break was only observed in D code, which has its own definition of int8_t and friends, leading to d/123509. I hope that the simple patch there can be appplied in time for the GCC 16.1 release, but that wouldn't be a showstopper for this change. Besides, clang always used #define __INT8_TYPE__ signed char without anyone noticing AFAIK, although they use libstd++ themselves. That's why I mean to run LLVM bootstraps with the patched GCC 16 to see if there are any issues. > As the target maintainer it's your call whether that's acceptable, I'm just > pointing it out. Thanks for that. Overall, I guess it is given how much breakage the current int8_t setting causes. I'd seen this before in LLVM, too, each time leading to extensive discussions about the issue :-)
