This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On Sat, 14 Aug 2004, Geoffrey Keating wrote:
In practise, though, the most common thing is that the system does not provide one, because it expects the compiler to provide it. Indeed, I believe that the only library that does provide one which works for GCC is glibc, and its version is very similar to this one.
I rather had the impression that non-GNU systems were more closely coupled
to expect a particular compiler and even included various headers such as
stddef.h and stdarg.h. Even when the system compiler is GCC some BSD
systems include their own copies of the headers GCC provides (for use with
the system GCC that is; they may or may not use USER_H in FSF GCC). That
the non-glibc systems I have access to don't include tgmath.h I'd think is
them simply not yet having implemented it; I don't suppose the BSDs that
now have their own <stddef.h> etc. would want GCC's <tgmath.h>.
glibc deliberately directs calls with long double types on some platforms
where long double has the same representation as double to the double
versions of the functions. This is conforming under the "as if" rule.
What isn't conforming is that glibc in such circumstances doesn't declare
the long double versions of the functions at all in math.h and complex.h.
I am however sure that Uli has his reasons for this (which might relate to
reducing ABI breakage if future versions of those CPUs acquire a long
double type). It looks to me like this patch would instead direct to the
undeclared versions, and there is a clear choice made by the library
implementation that is being overridden here.
This header is certainly a useful contribution as a specimen to system implementors using GCC of how they could implement <tgmath.h>. Such a file could certainly go in contrib for implementor reference and use.
It's simply a question of the strategy of what headers GCC is in the business of providing (at present, de facto and as documented, those required of freestanding implementations plus some compiler intrinsic headers externally specified for particular targets).
GCC aims towards being usable as a conforming freestanding implementation, or as the compiler for a conforming hosted implementation.
It seems that this would reinforce the need to provide this header in GCC. When such future improvements are made, it would be annoying to have to change glibc and GCC simultaneously to use them, especially when required to keep backwards compatibility in glibc.
That could apply to almost any header; there are plenty of features in GCC
that can optionally be used by system headers, e.g. various built-in
functions.
The versions being cleanly decoupled seems to work fine;
and I don't think those users who are choosing to upgrade the components manually rather than upgrading to a newer whole system version are the sort to get annoyed at needing to do so (nor that many users upgrade specifically for a better <tgmath.h>).
I agree that this header is not very clean, but when compared with the existing situation of nothing, it is an improvement. In addition, it
You can also compare it to the existing situation of a working if obscure
header in glibc, the part of the GNU system that is tasked with providing
headers required only of hosted implementations, and enough features in
GCC to provide more than one way for other systems using GCC to implement
the header.
It
does, however, effect a change to the strategy of what library facilities
are provided where, without associated documentation changes.
Now, the relation of GCC to glibc and other system libraries for GCC-based
systems, what is provided where, what adaptations glibc should make for
new GCC versions, when GCC should consider overriding something in glibc,
etc., is not fixed and certainly something that can be discussed - more
generally than the matter of this particular patch and in the hope of
concluding more general principles.
I just think that in this particular
case, the question of what headers go where, we already have a working,
documented (in standards.texi and at a lower level in sourcebuild.texi)
principle for which headers are the responsibility of what part of the
system, which has the merit of simplicity (after all, both <math.h> and
<complex.h> include compiler-specific definitions, of type-generic macros,
the macro I, and others, but we leave them to the library). As this
principle is simple, working and documented, I don't feel the need for it
to change at present.
Although __builtin_classify_type needs to stay supported thanks to the
deployed glibc using it in tgmath.h, I don't think we want to introduce
new uses of that undocumented extension.
The only way to remove the extension would be to have gcc provide its own tgmath.h, which this does. So again, I think this speaks in
Or to fixinclude the existing headers, as and when there are better built-in functions.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |