Re: Allow clang++ to work on OpenBSD
On Wed, 14 Dec 2011 20:54:05 +0100, Pascal Stumpf wrote: So ... Any oks for this diff? Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h 26 May 2010 11:23:06 - 1.2 +++ os_defines.h 14 Dec 2011 19:53:49 - @@ -35,11 +35,8 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 #define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 #define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !def ined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 #define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE typedef __builtin_va_list __gnuc_va_list; And followup converting restrict - __restrict (I hope I caught them all). ok? Index: std_cstdio.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/include/c_std/std_cstdio.h,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 std_cstdio.h --- std_cstdio.h15 Oct 2009 17:11:32 - 1.1.1.1 +++ std_cstdio.h15 Dec 2011 10:04:36 - @@ -156,14 +156,14 @@ _GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx) #if _GLIBCXX_USE_C99_CHECK || _GLIBCXX_USE_C99_DYNAMIC extern C int - (snprintf)(char * restrict, size_t, const char * restrict, ...); + (snprintf)(char * __restrict, size_t, const char * __restrict, ...); extern C int - (vfscanf)(FILE * restrict, const char * restrict, __gnuc_va_list); - extern C int (vscanf)(const char * restrict, __gnuc_va_list); + (vfscanf)(FILE * __restrict, const char * __restrict, __gnuc_va_list); + extern C int (vscanf)(const char * __restrict, __gnuc_va_list); extern C int - (vsnprintf)(char * restrict, size_t, const char * restrict, __gnuc_va_list); + (vsnprintf)(char * __restrict, size_t, const char * __restrict, __gnuc_va_list); extern C int - (vsscanf)(const char * restrict, const char * restrict, __gnuc_va_list); + (vsscanf)(const char * __restrict, const char * __restrict, __gnuc_va_list); #endif #if !_GLIBCXX_USE_C99_DYNAMIC Index: std_cstdlib.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/include/c_std/std_cstdlib.h,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 std_cstdlib.h --- std_cstdlib.h 15 Oct 2009 17:11:32 - 1.1.1.1 +++ std_cstdlib.h 15 Dec 2011 10:04:36 - @@ -186,9 +186,9 @@ _GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx) #if _GLIBCXX_USE_C99_LONG_LONG_CHECK || _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC extern C long long int (atoll)(const char *); extern C long long int -(strtoll)(const char * restrict, char ** restrict, int); +(strtoll)(const char * __restrict, char ** __restrict, int); extern C unsigned long long int -(strtoull)(const char * restrict, char ** restrict, int); +(strtoull)(const char * __restrict, char ** __restrict, int); #endif #if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC using ::atoll; Index: std_cwchar.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/include/c_std/std_cwchar.h,v retrieving revision 1.6 diff -u -p -r1.6 std_cwchar.h --- std_cwchar.h17 Oct 2011 08:47:49 - 1.6 +++ std_cwchar.h15 Dec 2011 10:04:36 - @@ -247,16 +247,16 @@ _GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx) #if _GLIBCXX_USE_C99_CHECK || _GLIBCXX_USE_C99_DYNAMIC extern C long double -(wcstold)(const wchar_t * restrict, wchar_t ** restrict); +(wcstold)(const wchar_t * __restrict, wchar_t ** __restrict); #endif #if !_GLIBCXX_USE_C99_DYNAMIC using ::wcstold; #endif #if _GLIBCXX_USE_C99_LONG_LONG_CHECK || _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC extern C long long int -(wcstoll)(const wchar_t * restrict, wchar_t ** restrict, int); +(wcstoll)(const wchar_t * __restrict, wchar_t ** __restrict, int); extern C unsigned long long int -(wcstoull)(const wchar_t * restrict, wchar_t ** restrict, int); +(wcstoull)(const wchar_t * __restrict, wchar_t ** __restrict, int); #endif #if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC using ::wcstoll;
Re: Allow clang++ to work on OpenBSD
On Mon, 12 Dec 2011 17:06:19 +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 16:55:04 +0100 (CET), Mark Kettenis wrote: Date: Mon, 12 Dec 2011 16:51:48 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote: On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: The s/restrict/__restrict/g in cstdio shouldn't be necessary. Apparently, clang++ interprets restrict as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern C int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern C int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. I'm not that surprised. restrict is C99. It's not part of C++98. Googling for restrict and C++ show various bug-reports explicitly stati ng tha t library headers should probably adapt. I don't have access to C++ 2011 yet, but from n3242, it seems that it d oe s now refer to C99 instead of C89, so restrict is probably leggit in C++2 01 1. So it looks to me like clang in C++98 mode is totally right to not reco gn ize restrict as a keyword! Yes, you're right. And clang++ -std=c++0x does recognise restrict as a keyword. cstdio should be adapted (and gcc 4.6 does indeed have __restrict over restrict). Still worth checking if only removing the XXX_CHECK defines and leaving the XXX_DYNAMIC defines helps. Yes, it does. :) Thanks! So ... Any oks for this diff? Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h26 May 2010 11:23:06 - 1.2 +++ os_defines.h14 Dec 2011 19:53:49 - @@ -35,11 +35,8 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 #define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 #define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 #define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE typedef __builtin_va_list __gnuc_va_list;
Re: Allow clang++ to work on OpenBSD
Date: Wed, 14 Dec 2011 20:54:05 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 17:06:19 +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 16:55:04 +0100 (CET), Mark Kettenis wrote: Date: Mon, 12 Dec 2011 16:51:48 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote: On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: The s/restrict/__restrict/g in cstdio shouldn't be necessary. Apparently, clang++ interprets restrict as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern C int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern C int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. I'm not that surprised. restrict is C99. It's not part of C++98. Googling for restrict and C++ show various bug-reports explicitly stati ng tha t library headers should probably adapt. I don't have access to C++ 2011 yet, but from n3242, it seems that it d oe s now refer to C99 instead of C89, so restrict is probably leggit in C++2 01 1. So it looks to me like clang in C++98 mode is totally right to not reco gn ize restrict as a keyword! Yes, you're right. And clang++ -std=c++0x does recognise restrict as a keyword. cstdio should be adapted (and gcc 4.6 does indeed have __restrict over restrict). Still worth checking if only removing the XXX_CHECK defines and leaving the XXX_DYNAMIC defines helps. Yes, it does. :) Thanks! So ... Any oks for this diff? ok kettenis@ Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h 26 May 2010 11:23:06 - 1.2 +++ os_defines.h 14 Dec 2011 19:53:49 - @@ -35,11 +35,8 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 #define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 #define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 #define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE typedef __builtin_va_list __gnuc_va_list;
Re: Allow clang++ to work on OpenBSD
Date: Sun, 11 Dec 2011 19:18:40 +0100
From: Pascal Stumpf pascal.stu...@cubes.de
I still think this should be investigated deeper. Matthew did a bit
of digging jusdging from:
http://marc.info/?l=openbsd-portsm=129783295016631w=2
That raises the question what difference between the prototypes makes
clang++ barf. If it is only thye missing restrict qualifiers, we
should add those to our prototypes.
As far as I can tell, the #defines that get removed by the diff do
serve a purpose. Without them, compiling
#include cstdio
with
g++ -D_POSIX_C_SOURCE=199309
will fail.
Hmm, okay. Adding __restrict to the prototypes in stdio.h and
s/restrict/__restrict/g in cstdio gets rid of some errors, but not all
of them. So there still seems to be some difference it doesn't like,
but apparently, I'm totally blind as to which one.
The s/restrict/__restrict/g in cstdio shouldn't be necessary.
The remaining conflict could be due to the __attribute__ stuff.
That'd be unfortunate, and I'd say that'd be a bug in clang++. It'd
be nice if you could check that. Easiest way would probably be to compile
a simple bit of test code like:
extern C int foo(const char *, ...) __attribute__((__format__(printf, 1, 2));
extern C int (foo)(const char *, ...);
namespace bar {
using ::foo;
}
and see if clang++ warns about that.
If clang++ really is stumbling over the __attribute__ stuff, perhaps
the right thing to do would be to remove the XXX_CHECK defines, but
leave the XXX_DYNAMIC defines. That'd still prevent the g++ failure I
mentioned above.
Re: Allow clang++ to work on OpenBSD
On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote:
Date: Sun, 11 Dec 2011 19:18:40 +0100
From: Pascal Stumpf pascal.stu...@cubes.de
I still think this should be investigated deeper. Matthew did a bit
of digging jusdging from:
http://marc.info/?l=openbsd-portsm=129783295016631w=2
That raises the question what difference between the prototypes makes
clang++ barf. If it is only thye missing restrict qualifiers, we
should add those to our prototypes.
As far as I can tell, the #defines that get removed by the diff do
serve a purpose. Without them, compiling
#include cstdio
with
g++ -D_POSIX_C_SOURCE=199309
will fail.
Hmm, okay. Adding __restrict to the prototypes in stdio.h and
s/restrict/__restrict/g in cstdio gets rid of some errors, but not all
of them. So there still seems to be some difference it doesn't like,
but apparently, I'm totally blind as to which one.
The s/restrict/__restrict/g in cstdio shouldn't be necessary.
Apparently, clang++ interprets restrict as parameter name, i.e.:
attr.cc:1:50: error: redefinition of parameter 'restrict'
extern C int foo(const char * restrict, char * restrict, ...)
^
attr.cc:1:33: note: previous declaration is here
extern C int foo(const char * restrict, char * restrict, ...)
^
This might indeed be a bug, but I'd have to read the C++ standard to be
sure. In pure C, clang doesn't complain.
The remaining conflict could be due to the __attribute__ stuff.
That'd be unfortunate, and I'd say that'd be a bug in clang++. It'd
be nice if you could check that. Easiest way would probably be to compile
a simple bit of test code like:
extern C int foo(const char *, ...) __attribute__((__format__(printf, 1, 2)
);
extern C int (foo)(const char *, ...);
namespace bar {
using ::foo;
}
and see if clang++ warns about that.
Nope, it doesn't.
If clang++ really is stumbling over the __attribute__ stuff, perhaps
the right thing to do would be to remove the XXX_CHECK defines, but
leave the XXX_DYNAMIC defines. That'd still prevent the g++ failure I
mentioned above.
Re: Allow clang++ to work on OpenBSD
oups include the list this time sorry for the noise Pascal. On 12 December 2011 16:00, Pascal Stumpf pascal.stu...@cubes.de wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: Date: Sun, 11 Dec 2011 19:18:40 +0100 From: Pascal Stumpf pascal.stu...@cubes.de I still think this should be investigated deeper. Matthew did a bit of digging jusdging from: http://marc.info/?l=openbsd-portsm=129783295016631w=2 That raises the question what difference between the prototypes makes clang++ barf. If it is only thye missing restrict qualifiers, we should add those to our prototypes. As far as I can tell, the #defines that get removed by the diff do serve a purpose. Without them, compiling #include cstdio with g++ -D_POSIX_C_SOURCE=199309 will fail. Hmm, okay. Adding __restrict to the prototypes in stdio.h and s/restrict/__restrict/g in cstdio gets rid of some errors, but not all of them. So there still seems to be some difference it doesn't like, but apparently, I'm totally blind as to which one. The s/restrict/__restrict/g in cstdio shouldn't be necessary. Apparently, clang++ interprets restrict as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern C int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern C int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. restrict is a C99 keyword and has no meaning (ie doesn't exist) in the C++ standard.
Re: Allow clang++ to work on OpenBSD
On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: The s/restrict/__restrict/g in cstdio shouldn't be necessary. Apparently, clang++ interprets restrict as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern C int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern C int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. I'm not that surprised. restrict is C99. It's not part of C++98. Googling for restrict and C++ show various bug-reports explicitly stating that library headers should probably adapt. I don't have access to C++ 2011 yet, but from n3242, it seems that it does now refer to C99 instead of C89, so restrict is probably leggit in C++2011. So it looks to me like clang in C++98 mode is totally right to not recognize restrict as a keyword!
Re: Allow clang++ to work on OpenBSD
On Mon, Dec 12, 2011 at 04:15:23PM +0100, Mathieu - wrote: restrict is a C99 keyword and has no meaning (ie doesn't exist) in the C++ standard. Wrong answer. What's the C++ standard ? C++98 or C++2011 ? A lot of things that are valid C++ don't exist in any C++ standard, since they're included from the corresponding C standard...
Re: Allow clang++ to work on OpenBSD
On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote: On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: The s/restrict/__restrict/g in cstdio shouldn't be necessary. Apparently, clang++ interprets restrict as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern C int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern C int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. I'm not that surprised. restrict is C99. It's not part of C++98. Googling for restrict and C++ show various bug-reports explicitly stating tha t library headers should probably adapt. I don't have access to C++ 2011 yet, but from n3242, it seems that it does now refer to C99 instead of C89, so restrict is probably leggit in C++2011. So it looks to me like clang in C++98 mode is totally right to not recognize restrict as a keyword! Yes, you're right. And clang++ -std=c++0x does recognise restrict as a keyword. cstdio should be adapted (and gcc 4.6 does indeed have __restrict over restrict).
Re: Allow clang++ to work on OpenBSD
Date: Mon, 12 Dec 2011 16:51:48 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote: On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: The s/restrict/__restrict/g in cstdio shouldn't be necessary. Apparently, clang++ interprets restrict as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern C int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern C int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. I'm not that surprised. restrict is C99. It's not part of C++98. Googling for restrict and C++ show various bug-reports explicitly stating tha t library headers should probably adapt. I don't have access to C++ 2011 yet, but from n3242, it seems that it does now refer to C99 instead of C89, so restrict is probably leggit in C++2011. So it looks to me like clang in C++98 mode is totally right to not recognize restrict as a keyword! Yes, you're right. And clang++ -std=c++0x does recognise restrict as a keyword. cstdio should be adapted (and gcc 4.6 does indeed have __restrict over restrict). Still worth checking if only removing the XXX_CHECK defines and leaving the XXX_DYNAMIC defines helps.
Re: Allow clang++ to work on OpenBSD
On Mon, 12 Dec 2011 16:55:04 +0100 (CET), Mark Kettenis wrote: Date: Mon, 12 Dec 2011 16:51:48 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote: On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: The s/restrict/__restrict/g in cstdio shouldn't be necessary. Apparently, clang++ interprets restrict as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern C int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern C int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. I'm not that surprised. restrict is C99. It's not part of C++98. Googling for restrict and C++ show various bug-reports explicitly stating tha t library headers should probably adapt. I don't have access to C++ 2011 yet, but from n3242, it seems that it doe s now refer to C99 instead of C89, so restrict is probably leggit in C++201 1. So it looks to me like clang in C++98 mode is totally right to not recogn ize restrict as a keyword! Yes, you're right. And clang++ -std=c++0x does recognise restrict as a keyword. cstdio should be adapted (and gcc 4.6 does indeed have __restrict over restrict). Still worth checking if only removing the XXX_CHECK defines and leaving the XXX_DYNAMIC defines helps. Yes, it does. :) Thanks!
Re: Allow clang++ to work on OpenBSD
On Mon, Dec 12, 2011 at 10:06 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: On Mon, 12 Dec 2011 16:55:04 +0100 (CET), Mark Kettenis wrote: Date: Mon, 12 Dec 2011 16:51:48 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, 12 Dec 2011 16:26:42 +0100, Marc Espie wrote: On Mon, Dec 12, 2011 at 04:00:44PM +0100, Pascal Stumpf wrote: On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: The s/restrict/__restrict/g in cstdio shouldn't be necessary. Apparently, clang++ interprets restrict as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern C int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern C int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. I'm not that surprised. restrict is C99. It's not part of C++98. Googling for restrict and C++ show various bug-reports explicitly stating tha t library headers should probably adapt. I don't have access to C++ 2011 yet, but from n3242, it seems that it doe s now refer to C99 instead of C89, so restrict is probably leggit in C++201 1. So it looks to me like clang in C++98 mode is totally right to not recogn ize restrict as a keyword! Yes, you're right. And clang++ -std=c++0x does recognise restrict as a keyword. cstdio should be adapted (and gcc 4.6 does indeed have __restrict over restrict). Still worth checking if only removing the XXX_CHECK defines and leaving the XXX_DYNAMIC defines helps. Yes, it does. :) Thanks! pascal, thanks for the persistent follow-up. all, please get this in. finally clang++ is usable, and can be used without any problems in ports! thanks
Re: Allow clang++ to work on OpenBSD
On Thu, 17 Nov 2011 19:06:24 +0100, Pascal Stumpf wrote: Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see: http://marc.info/?l=openbsd-techm=130229126704450w=2 I don't expect any fallout, but just to be sure, can this go through a bulk build on affected platforms (gcc4)? Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h 26 May 2010 11:23:06 - 1.2 +++ os_defines.h 17 Nov 2011 18:04:55 - @@ -35,12 +35,6 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 -#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 -#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !def ined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE typedef __builtin_va_list __gnuc_va_list; #endif ping?
Re: Allow clang++ to work on OpenBSD
Date: Sun, 11 Dec 2011 13:37:29 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Thu, 17 Nov 2011 19:06:24 +0100, Pascal Stumpf wrote: Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see: http://marc.info/?l=openbsd-techm=130229126704450w=2 I don't expect any fallout, but just to be sure, can this go through a bulk build on affected platforms (gcc4)? Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h26 May 2010 11:23:06 - 1.2 +++ os_defines.h17 Nov 2011 18:04:55 - @@ -35,12 +35,6 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 -#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 -#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !def ined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE typedef __builtin_va_list __gnuc_va_list; #endif ping? I still think this should be investigated deeper. Matthew did a bit of digging jusdging from: http://marc.info/?l=openbsd-portsm=129783295016631w=2 That raises the question what difference between the prototypes makes clang++ barf. If it is only thye missing restrict qualifiers, we should add those to our prototypes. As far as I can tell, the #defines that get removed by the diff do serve a purpose. Without them, compiling #include cstdio with g++ -D_POSIX_C_SOURCE=199309 will fail.
Re: Allow clang++ to work on OpenBSD
On Sun, 11 Dec 2011 15:43:02 +0100 (CET), Mark Kettenis wrote: Date: Sun, 11 Dec 2011 13:37:29 +0100 From: Pascal Stumpf pascal.stu...@cubes.de On Thu, 17 Nov 2011 19:06:24 +0100, Pascal Stumpf wrote: Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see: http://marc.info/?l=openbsd-techm=130229126704450w=2 I don't expect any fallout, but just to be sure, can this go through a bulk build on affected platforms (gcc4)? Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines. h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h 26 May 2010 11:23:06 - 1.2 +++ os_defines.h 17 Nov 2011 18:04:55 - @@ -35,12 +35,6 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 -#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 -#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !def ined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SO URCE typedef __builtin_va_list __gnuc_va_list; #endif ping? I still think this should be investigated deeper. Matthew did a bit of digging jusdging from: http://marc.info/?l=openbsd-portsm=129783295016631w=2 That raises the question what difference between the prototypes makes clang++ barf. If it is only thye missing restrict qualifiers, we should add those to our prototypes. As far as I can tell, the #defines that get removed by the diff do serve a purpose. Without them, compiling #include cstdio with g++ -D_POSIX_C_SOURCE=199309 will fail. Hmm, okay. Adding __restrict to the prototypes in stdio.h and s/restrict/__restrict/g in cstdio gets rid of some errors, but not all of them. So there still seems to be some difference it doesn't like, but apparently, I'm totally blind as to which one. In file included from cstdio.cc:1: /usr/include/g++/cstdio:169:11: error: target of using declaration conflicts with declaration already in scope using ::snprintf; ^ In file included from cstdio.cc:1: In file included from /usr/include/g++/cstdio:52: /usr/include/stdio.h:271:6: note: target of using declaration int snprintf(char * __restrict, size_t, const char * __restrict, ...) ^ In file included from cstdio.cc:1: /usr/include/g++/cstdio:158:4: note: conflicting declaration (snprintf)(char * __restrict, size_t, const char * __restrict, ...); ^ /usr/include/g++/cstdio:170:11: error: target of using declaration conflicts with declaration already in scope using ::vfscanf; ^ In file included from cstdio.cc:1: In file included from /usr/include/g++/cstdio:52: /usr/include/stdio.h:275:6: note: target of using declaration int vfscanf(FILE * __restrict, const char * __restrict, __va_list) ^ In file included from cstdio.cc:1: /usr/include/g++/cstdio:160:4: note: conflicting declaration (vfscanf)(FILE * __restrict, const char * __restrict, __gnuc_va_list); ^ /usr/include/g++/cstdio:171:11: error: target of using declaration conflicts with declaration already in scope using ::vscanf; ^ In file included from cstdio.cc:1: In file included from /usr/include/g++/cstdio:52: /usr/include/stdio.h:278:6: note: target of using declaration int vscanf(const char * __restrict, __va_list) ^ In file included from cstdio.cc:1: /usr/include/g++/cstdio:161:19: note: conflicting declaration extern C int (vscanf)(const char * __restrict, __gnuc_va_list); ^ /usr/include/g++/cstdio:172:11: error: target of using declaration conflicts with declaration already in scope using ::vsnprintf; ^ In file included from cstdio.cc:1: In file included from /usr/include/g++/cstdio:52: /usr/include/stdio.h:281:6: note: target of using declaration int vsnprintf(char * __restrict, size_t, const char * __restrict, __va_list) ^ In file included from cstdio.cc:1: /usr/include/g++/cstdio:163:4: note: conflicting declaration (vsnprintf)(char * __restrict, size_t, const char * __restrict, __gnuc_va_list); ^ /usr/include/g++/cstdio:173:11: error: target of using declaration conflicts with declaration already in scope using ::vsscanf; ^ In file included from cstdio.cc:1: In file included from /usr/include/g++/cstdio:52: /usr/include/stdio.h:285:6: note: target of using declaration int vsscanf(const char * __restrict, const char * __restrict, __va_list) ^ In file included from cstdio.cc:1: /usr/include/g++/cstdio:165:4: note: conflicting declaration (vsscanf)(const char *
Re: Allow clang++ to work on OpenBSD
Date: Thu, 17 Nov 2011 19:06:24 +0100 From: Pascal Stumpf pascal.stu...@cubes.de Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see: http://marc.info/?l=openbsd-techm=130229126704450w=2 I don't expect any fallout, but just to be sure, can this go through a bulk build on affected platforms (gcc4)? I don't think this is the right aproach. Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h 26 May 2010 11:23:06 - 1.2 +++ os_defines.h 17 Nov 2011 18:04:55 - @@ -35,12 +35,6 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 -#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 -#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE typedef __builtin_va_list __gnuc_va_list; #endif
Re: Allow clang++ to work on OpenBSD
On Wed, 23 Nov 2011 17:00:57 +0100 (CET), Mark Kettenis wrote: Date: Thu, 17 Nov 2011 19:06:24 +0100 From: Pascal Stumpf pascal.stu...@cubes.de Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see: http://marc.info/?l=openbsd-techm=130229126704450w=2 I don't expect any fallout, but just to be sure, can this go through a bulk build on affected platforms (gcc4)? I don't think this is the right aproach. What is? Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h, v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h26 May 2010 11:23:06 - 1.2 +++ os_defines.h17 Nov 2011 18:04:55 - @@ -35,12 +35,6 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 -#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 -#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !d efined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOUR CE typedef __builtin_va_list __gnuc_va_list; #endif
Allow clang++ to work on OpenBSD
Hi, this diff was already suggested by matthew@ some time ago. It renders clang++ usable with gcc's C++ include files, see: http://marc.info/?l=openbsd-techm=130229126704450w=2 I don't expect any fallout, but just to be sure, can this go through a bulk build on affected platforms (gcc4)? Index: os_defines.h === RCS file: /cvs/src/gnu/gcc/libstdc++-v3/config/os/bsd/openbsd/os_defines.h,v retrieving revision 1.2 diff -u -p -r1.2 os_defines.h --- os_defines.h26 May 2010 11:23:06 - 1.2 +++ os_defines.h17 Nov 2011 18:04:55 - @@ -35,12 +35,6 @@ // file will come before all others. #define _GLIBCXX_USE_C99 1 -#define _GLIBCXX_USE_C99_CHECK 1 -#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE = 1999)) -#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1 -#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1 -#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE typedef __builtin_va_list __gnuc_va_list; #endif
