Bug 51009

Hmm, does the newer g++ (i.e. C++ mode) claim C99 mode but not support the 
C99 restrict keyword?

Seems to work fine here (Solaris 11/x86 with bundled gcc 4.5.2), but it's
expanding to the gnu __restrict__ version instead, since it's not claiming C99:

alanc@also:/tmp [8:12am - 5] gcc --version
gcc (GCC) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

alanc@also:/tmp [8:12am - 6] cat test.cc
#include <X11/Intrinsic.h>
alanc@also:/tmp [8:12am - 7] g++ -c test.cc
alanc@also:/tmp [8:13am - 8] g++ -E test.cc | grep restrict
    const char * __restrict__ format,

Seems fine here (OS X) with various g++ versions.

With GCC 3.4.6, I get

    const char * __restrict__ format,

But with GCC 4.7.0 (which is the compiler I want to use), I get

    const char * restrict format,

(In reply to comment #3)
> With GCC 3.4.6, I get
> 
>     const char * __restrict__ format,
> 
> But with GCC 4.7.0 (which is the compiler I want to use), I get
> 
>     const char * restrict format,

Which is the correct and expected behavior for a C99-capable compiler.

So it's a bug in GCC 4.7?

BTW: We are talking about g++. Does C99 apply here, anyway?

(In reply to comment #5)
> So it's a bug in GCC 4.7?

It's seeming likely.

> BTW: We are talking about g++. Does C99 apply here, anyway?

That path is being hit because it claims to implement C99 without doing 
so - which is why it seems to be a bug in g++ - it shouldn't set the
__STDC_VERSION__ to C99 and then not recognize C99 keywords.

While tracking another problem I found this:

$ diff -u /usr/include/sys/feature_tests.h .../localgcc470/lib/gcc/i386-pc-solaris2.10/4.7.0/include-fixed/sys/feature_tests.h
@@ -345,7 +354,11 @@
  * declarations regardless of compiler version.
  */
 #if (defined(__STDC__) && defined(_STDC_C99))
+#ifdef __cplusplus
+#define        _RESTRICT_KYWD  __restrict
+#else
 #define        _RESTRICT_KYWD  restrict
+#endif
 #else
 #define        _RESTRICT_KYWD
 #endif

I can't comment on the usefulness of overriding the native header files, but this seems to indicate that g++ would like to see "__restrict".

And I wasn't aware that the OS and/or the compiler define _RESTRICT_KYWD. Shouldn't Xfuncproto.h use that definition and revert to it's own logic only in the absence of a predefined value?

(In reply to comment #7)
> And I wasn't aware that the OS and/or the compiler define _RESTRICT_KYWD.
> Shouldn't Xfuncproto.h use that definition and revert to it's own logic only in
> the absence of a predefined value?

No.  Xfuncproto.h is cross platform and used on many OS'es, it cannot rely
on a Solaris-only, undocumented, private definition in the Solaris system
header files.

I have talked about this a bit with Rainer Orth, who maintains the Solaris port
for gcc upstream, and he explained why g++ does this on Solaris, even though
it's not the most kosher.   Since g++ has to do this for ABI compatibility with
libm on Solaris, we'll probably have to workaround it in the Xfuncproto.h header.

Created attachment 66181 [details] [review]
Patch to Xfuncproto.h

This is the patch I sent to xorg-devel for review - it works for me on
Solaris 11 with Studio & gcc 4.5 - but I don't have gcc 4.6 or later, which
is where this problem occurs, so can't verify it solves the problem for you.

Yep, this works, thanks.  I've applied the patch to pkgsrc.

Thanks for confirming, pushed to git master.

To ssh://git.freedesktop.org/git/xorg/proto/x11proto
   f1b8b4d..c76d514  master -> master