Janis Johnson wrote: > Support in GCC 4.2 for decimal floating types is based on drafts of > ISO/IEC WDTR 23732, which continues to change. There are some > differences between the most recent draft N1176 and what GCC implements, > and some other things that should probably change or at least be > documented. I'd appreciate some guidance on these. > > 1. The draft TR specifies that an implementation define __STDC_DEC_FP__ > as 1 to indicate conformance to the technical report. GCC currently > defines this, but there are a couple of issues here. First is that > GCC is only one piece of the implementation and the macro shouldn't > be defined unless the C library also implements the library portion. > The other issue is that the TR continues to change, and the macro > shouldn't be defined until GCC and the relevant C library support the > final version of the TR. I'd like to remove this from GCC, if it's > OK to do that at this late stage.
That seems a good conservative change. (This same problem has arisen in past with some of the IEEE macros, in the opposite direction; GLIBC has defined them, even when the compiler doesn't provide the full guarantees.) I think the only way to get this 100% right is to provide a configure option to GCC that says whether or not to define the macro, but, even then, you have to be multilib-aware, as a uClibc multilib might not get the macro, even while a GLIBC multilib does get the macro. If the standards permit defining the macros in library headers (rather than requiring them to be pre-defined by the compiler), then an easier solution would be to have GCC define __GCC_DEC_FP__, and then have the library do: #ifdef __GCC_DEC_FP__ /* This library is DFP-capable, and GCC is DFP-capable, so... */ #define __STDC_DEC_FP__ #endif > 3. Earlier drafts specified that a new header file <decfloat.h> define > various macros for characteristics of decimal floating types. The > latest draft puts these in <float.h> instead. I'm inclined to leave > them in <decfloat.h> until the TR is approved, or at least more > stable, and document that difference. The downside to that is that some people may want us to provide <decfloat.h> forever, for source compatibility with GCC 4.2. It's frustrating that we don't really know if/when the TR will actually be final; things might move again, for all we know. I think you should document the difference, and say that we expect to remove <decfloat.h> in a future release. I think your other documentation suggestions make sense. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
