This is the mail archive of the
mailing list for the libstdc++ project.
Re: basic-improvements merge status
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: <gcc at gcc dot gnu dot org>, <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 17 Dec 2002 03:14:25 +0000 (GMT)
- Subject: Re: basic-improvements merge status
On Mon, 16 Dec 2002, Neil Booth wrote:
> But those switches are statements about what features the compiler
> should accept, and compiler semantics. They say nothing about the
> library conformance of the target to C99, IMO.
-std=c89 says (unless -ffreestanding is used) that library function names
reserved in C90 may be presumed to have their C90 semantics, and built-in
functions may be optimised on that basis (while it also disables various
built-in functions that aren't in C90 but are accepted in gnu89 mode).
-std=c99 says (unless -ffreestanding is used) the same thing for C99.
Such presumptions may be avoided by -ffreestanding. Note that the
standards specify that the reserved function names are always reserved for
functions with external linkage, irrespective of whether any headers are
included (except for a special case in C94, where some new wide character
function names are only reserved if certain headers are included somewhere
in the program; this special case was removed in C99).
Of course it's still sensible to avoid generating calls to functions known
not to be present on the target, if calls to those functions weren't
present in the source code, just as we use TARGET_MEM_FUNCTIONS to know
whether to generate calls to the C90 mem* functions. (Though in that case
I think that we should put the mem* functions in libgcc for targets
without them in libc and then generate calls to them unconditionally;
this would need replacing TARGET_MEM_FUNCTIONS by a mechanism for
specifying, for the old targets without the functions that haven't had
support for them removed, which functions should be added to libgcc.
Much the same mechanism could be used for sinf etc., though the benefits
are less and we don't have the information readily to hand in the target
headers to work out which systems need sinf defined.)
Joseph S. Myers