------- 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