https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115761
--- Comment #5 from Antony Searle <antony at liquidinstruments dot com> --- > You can get the same size back with `-gdwarf-4` option even. Substituting -gdwarf-4 for -g only changes the file size by 1 kb of 1.3 Gb Antony-Air:bug $ ls -l bug.o* -rw-r--r-- 1 acsearle staff 1375782520 3 Jul 15:28 bug.o-g -rw-r--r-- 1 acsearle staff 1375783344 3 Jul 15:30 bug.o-gdwarf-4 > So GCC is following the best practices while clang is not. > > So invalid. I guess this is a policy choice, but again, these strings are Gb-scale and useless for any purpose. I note that the example had to be changed to be able to print them in your comment. This behavior was discovered in our production expression template code when upgrading from GCC 9 to 11 blew out our object sizes and compile times; it's not just a theoretical problem. Antony-Air:bug $ objdump -h bug.o* ... Idx Name Size VMA Type ... 66 .debug_str 52004205 0000000000000000 DEBUG ... 66 .debug_str 52004223 0000000000000000 DEBUG Antony-Air:bug $ objdump -s bug.o-g ... 9ab5560 64612829 3e203e28 663c663c 663c696e da()> >(f<f<f<in 9ab5570 743e2869 6e74293a 3a3c6c61 6d626461 t>(int)::<lambda 9ab5580 28293e20 3e28663c 696e743e 28696e74 ()> >(f<int>(int 9ab5590 293a3a3c 6c616d62 64612829 3e293a3a )::<lambda()>):: 9ab55a0 3c6c616d 62646128 293e203e 28663c66 <lambda()> >(f<f 9ab55b0 3c696e74 3e28696e 74293a3a 3c6c616d <int>(int)::<lam 9ab55c0 62646128 293e203e 28663c69 6e743e28 bda()> >(f<int>( 9ab55d0 696e7429 3a3a3c6c 616d6264 6128293e int)::<lambda()> 9ab55e0 293a3a3c 6c616d62 64612829 3e293a3a )::<lambda()>):: ...
