Re: No way to tell when `long long' is or is not supported?
On Sun, Sep 08, 2002 at 11:50:17PM -0400, Garrett Wollman wrote: GCC used to define a macro __STRICT_ANSI__ when `-ansi' was given on the command line. The current version does not do this, It seems to work for me: $ cat foo.c #ifdef __STRICT_ANSI__ #error __STRICT_ANSI__ #endif $ /usr/bin/cc -ansi foo.c foo.c:2:2: #error __STRICT_ANSI__ The problem is it is also set for this: $ /usr/bin/cc -std=c99 foo.c foo.c:2:2: #error __STRICT_ANSI__ As you mentioned, this is now not a good test to decide if 'long long' is supported. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No way to tell when `long long' is or is not supported?
On Sun, Sep 08, 2002 at 11:50:17PM -0400, Garrett Wollman wrote:
Rather than trying to deduce whether `long long' is supported from
other macros, I simply modified the compiler driver to tell us.
Looking at GCC on other platforms, _LONGLONG seems to be the most
preferred symbol. How does this patch look? We can't get this 100%
correct as there is no way to match iso9899:1990 and iso9899:199409
as ':' is a token already. The only way to do this correctly is to add
it to c-common.c and c-opt.c looking at the value of the various
flag_iso* variables.
Index: freebsd-spec.h
===
RCS file: /home/ncvs/src/contrib/gcc/config/freebsd-spec.h,v
retrieving revision 1.3
diff -u -r1.3 freebsd-spec.h
--- freebsd-spec.h 9 Sep 2002 06:56:29 - 1.3
+++ freebsd-spec.h 9 Sep 2002 07:23:58 -
@@ -98,6 +105,7 @@
%{munderscores: -D__UNDERSCORES__} \
%{maout: %{!mno-underscores: -D__UNDERSCORES__}} \
%{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} \
+ %{!ansi:%{!std=c89:%{!std=iso9899.1990:%{!std=iso9899.199409:-D_LONGLONG\
%{posix:-D_POSIX_SOURCE}
/* Provide a STARTFILE_SPEC appropriate for FreeBSD. Here we add
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: No way to tell when `long long' is or is not supported?
On Mon, Sep 09, 2002 at 01:10:46AM -0700, David O'Brien wrote: : Rather than trying to deduce whether `long long' is supported from : other macros, I simply modified the compiler driver to tell us. What's wrong with #include limits.h #ifdef LLONG_MAX Surely we get to determine the contents of our own limits.h files? -- Christopher Vance To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No way to tell when `long long' is or is not supported?
On Mon, 9 Sep 2002, David O'Brien wrote: On Sun, Sep 08, 2002 at 11:50:17PM -0400, Garrett Wollman wrote: GCC used to define a macro __STRICT_ANSI__ when `-ansi' was given on the command line. The current version does not do this, It seems to work for me: For me too. I vaguely remember that it didn't work for all cases, but I can't find any broken case now (perhaps gcc-3.2 unbroke it). The problem is it is also set for this: $ /usr/bin/cc -std=c99 foo.c foo.c:2:2: #error __STRICT_ANSI__ As you mentioned, this is now not a good test to decide if 'long long' is supported. The __STDC_VERSION__ test in the XXX comment before the __STRICT_ANSI__ ifdef works for -std=c99. A messy ifdef to handle old compilers seems to be unavoidable until we drop support for nonstandard (non-C90) features in old compilers. BTW, I'm still waiting for the bogus LONGLONG lint markup to be removed from stdlib.h. lint should warn about long long if and only if ong long is a syntax error for the compiler that lint is checking for. Lint must see the same value for __LONG_LONG_SUPPORTED as the relevant compiler would, and then the LONGLONG markup is a no-op. The markup mainly breaks detection of broken lints and/or broken setting of __LONG_LONG_SUPPORTED. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No way to tell when `long long' is or is not supported?
On Mon, 9 Sep 2002, Christopher Vance wrote: On Mon, Sep 09, 2002 at 01:10:46AM -0700, David O'Brien wrote: : Rather than trying to deduce whether `long long' is supported from : other macros, I simply modified the compiler driver to tell us. What's wrong with #include limits.h #ifdef LLONG_MAX Surely we get to determine the contents of our own limits.h files? 1) Namespace pollution. Standard headers other than limits.h are not permitted to define LLONG_MAX. 2) A non-broken limits.h would need much the same ifdefs as sys/cdefs.h for determining whether the compiler and/or standard supports long long. limits.h is not permitted to define LLONG_MA if the standard is C90 but currently defines it unconditionally. The syntax error in the definition of LLONG_MAX doesn't cause many problems for C90 compilers because the macro is not normally used in C90 environment. A test like: #include limits.h #if LLONG_MAX 0 would have syntax errors. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No way to tell when `long long' is or is not supported?
On Mon, 9 Sep 2002 01:10:46 -0700, David O'Brien [EMAIL PROTECTED] said: Looking at GCC on other platforms, _LONGLONG seems to be the most preferred symbol. How does this patch look? Works for me. I'd still like to see `-posix' go away, if we're going to be changing freebsd-spec.h further. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No way to tell when `long long' is or is not supported?
On Mon, 9 Sep 2002 00:07:00 -0700, David O'Brien [EMAIL PROTECTED] said: It seems to work for me: $ cat foo.c #ifdef __STRICT_ANSI__ #error __STRICT_ANSI__ #endif $ /usr/bin/cc -ansi foo.c foo.c:2:2: #error __STRICT_ANSI__ OK, so this is now one of those magic defines that's not shown in the specs and just pulled out thin air by the preprocessor? One wishes that the GCC crowd would make up their minds already -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
No way to tell when `long long' is or is not supported?
GCC used to define a macro __STRICT_ANSI__ when `-ansi' was given on
the command line. The current version does not do this, which breaks
detection of whether `long long' is allowed. (For some reason this is
not hit in -current builds, but I have made some fixes to stdlib.h
which trigger it in every program which sets WARNS.)
Rather than trying to deduce whether `long long' is supported from
other macros, I simply modified the compiler driver to tell us. (BTW,
the `-posix' flag is utterly useless and should go.) If anyone has a
better way to accomplish this, I'm all ears.
(I suspect that the removal of __STRICT_ANSI__ was intentional, since
it's not clear what that should mean in the face of multiple C
language standards. The trouble is that C89 (implied by `-ansi') is
otherwise indistinguishable from C89+GCC-extensions (implied by the
absence of `-ansi'), and we need to make both cases work properly.)
-GAWollman
Index: freebsd-spec.h
===
RCS file: /home/ncvs/src/contrib/gcc/config/freebsd-spec.h,v
retrieving revision 1.2
diff -u -r1.2 freebsd-spec.h
--- freebsd-spec.h 10 May 2002 19:05:07 - 1.2
+++ freebsd-spec.h 8 Sep 2002 18:34:29 -
@@ -85,12 +85,13 @@
the final CPP_PREDEFINES value. */
#define FBSD_CPP_PREDEFINES \
- -D__FreeBSD__=5 -D__FreeBSD_cc_version=53 -Dunix -D__KPRINTF_ATTRIBUTE__
-Asystem=unix -Asystem=bsd -Asystem=FreeBSD
+ -D__FreeBSD__=5 -D__FreeBSD_cc_version=54 -Dunix -D__KPRINTF_ATTRIBUTE__
+-Asystem=unix -Asystem=bsd -Asystem=FreeBSD
#endif /* ! FREEBSD_NATIVE */
/* Provide a CPP_SPEC appropriate for FreeBSD. We just deal with the GCC
- option `-posix', and PIC issues. */
+ option `-posix', and PIC issues. Also deal with the problem of
+ detecting support for the `long long' type. */
#define FBSD_CPP_SPEC \
%(cpp_cpu) \
@@ -98,6 +99,8 @@
%{munderscores: -D__UNDERSCORES__} \
%{maout: %{!mno-underscores: -D__UNDERSCORES__}} \
%{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} \
+ %{!ansi:%{!std=*:-D__LONG_LONG_SUPPORTED}%{std=gnu*:-D__LONG_LONG_SUPPORTED}}\
+ %{std=c99:-D__LONG_LONG_SUPPORTED}\
%{posix:-D_POSIX_SOURCE}
/* Provide a STARTFILE_SPEC appropriate for FreeBSD. Here we add
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
