[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-19 14:59:44 UTC ---
Seems to me that you don't seem to understand what it means that the dfp
support bits from libgcc.a are statically linked into your application.  There
is no bad code generation, the only problem is that libbid has lots of small
*.o files, then about 7 mid size *.o files (~ 16KB to ~ 64KB of code, almost no
.rodata) and then a single huge one - bid_binarydecimal.o - which, while it
contains a tiny bit above 64KB of code, contains additionally 2MB of read-only
data in various tables, and unfortunately this huge 6MB of source file is used
by many of the routines.  The reason why the decimal stuff isn't in libgcc_s
(i.e. shared library) is because _Decimal* support is huge amount of code for
something used extremely rarely.  It could be either built into a separate
shared library and ask people to add that library in, or perhaps this single
huge source file could be split into several smaller ones, so you get only the
code you really need to handle the operations you are using, or it could be
built with -ffunction-sections -fdata-sections and allow people to use
-Wl,--gc-sections to garbage collect it.

OT, your comments about using _Decimal64 as an interesting option to double are
very weird, the two types are completely different, have different purpose,
_Decimal* is (except for some PowerPC and S390* chips) completely software
emulated type and thus very slow, double has on the other side usually very
fast operations on it implemented in hw.