http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622
--- Comment #4 from Domingo Alvarez <mingodad at gmail dot com> 2011-12-19 14:30:26 UTC --- Created attachment 26143 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26143 Another program to demonstrate gcc bad code generation On the previous example program my conclusions doesn't make much senes because gcc was optimizing the code and removing all code without side effects or in other words the small executables end up almost empty (good job of gcc). This new program contains the previous and add a program main2.c that when compiled without any optimization to not ending empty demonstrate the problem. Doing almost any arithmetic operations with _Decimal64 without mix with _Decimal128 or with automatic convertion to double gives an executable of 270KB. If we mix with _Decimal128 gives executable of 473KB. Now if we add a call to isnan the executable goes to 2.374KB, almost 2MB monolithic code only to isnan or even if we use ceil or floor or any other math functions, it seems too much for only a small adittion. And if I use a home made function to convert from _Decima64 to double there is now increase on executable size, but if using automatic generated conversion from gcc it grows to 2.374KB. I think that there is a problem with the way the _Decimal* library is coded, maybe all in one single code file instead of small ones with only one function, because with one function per code file adding a new function call will not link a lot of unnecessary code. gcc main2.c -o no-opt-small.exe -> 270KB gcc -DWITH_GCC_DEC2DBL main2.c -o no-opt-gcc-dec2dbl.exe -> 2.374KB gcc -DWITH_MIX128 main2.c -o no-opt-mix128.exe -> 473KB gcc -DWITH_ISNAN main2.c -o no-opt-isnan.exe -> 2.374KB gcc -DWITH_MIX128 -DWITH_ISNAN main2.c -o no-opt-isnan-mix128.exe -> 2.578KB