------- Comment #7 from malitzke at metronets dot com 2007-06-16 13:08 -------
It is good to be challenged, as it forces clarification of the issues. It is
also good to let some grass grow instead of just charging ahead.
Putting the legal and philosophical ramifications aside and considering only
the technical issues; but, in a larger context, the following seems to apply.
The ICE issue in PR 32314 were a consequence of pursuing the decimal float
issue, but, it helps to also consider it here.
The closure is provided by the introduction of POINTER_PLUS.
While this might not be ideal forum for what follows I ask for indulgence in
order to put things into perspective.
There are really three levels to keep in mind and they are exemplified by:
1) POINTER_PLUS
2) Altivec and SSE
3) decimal float.
POINTER_PLUS is clearly an internal matter for GCC and the involved
specialists.
A user, like my self, has no right to question it or its merits.
Parenthetically, I consider it great because it makes GCC more transparent and
comprehensible. Size of the compilers, efficiency of both compiler and
generated code are clearly secondary (within even generous limits). Enough
said.
Altivec and SSE are borderline. Personally, I would love to have control over
how analysis, optimization, and code generation for a specialized instruction
set and data types, not mandated the the C standard, affect the compiler I use
for perhaps life threatening code.
However, as a practical matter, I realize that the build machinery for gcc may
make it well nigh impossible to eliminate Altivec of SSE from the areas of
analysis, optimization and code generation. I also doubt that the likes of
Altivec and SSE can be segregated into libraries with minimal impact on the
compiler proper.
As a consequence, I might have only the choice of having the compiler built for
a model CPU not having altivec or SSE, and foregoing any concomitant
architectural improvements; or, taking any penalties in compiler complexity and
quality of generated code for data types that I have no intention of using.
Decimal_float: My analysis has shown that the only readily visible difference
resulting from disable-decimal-float or enable-decimal-float is the doubling in
size of libgcc.a. Libgcc.so seems unaffected either way. I can only hope that
the impact on compiler complexity, ad-hoc code and propensity for bugs is
minimal. I hate the idea of having to use gcc versions prior to gcc-4.2.0 just
to completely avoid decimal float.
I will leave potential legal implications and inconsistencies resulting from
using COPYING.LIB and the gcc-specific disclaimer paragraph to another posting.
--
malitzke at metronets dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenther at suse dot de,
| |janis187 at us dot ibm dot
| |com
Severity|blocker |normal
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
