and define __GNUC__, like Clang does.
This is
also consistent with the fact that the documentation generated in config.h
for AC_C_RESTRICT says "Do not define if restrict is supported directly."
(although this documentation seems inconsistent with the online
documentation, which corr
reasonable solution
to me, however, when combined with the behavior of AC_C_RESTRICT, this
leads to a circular definition that causes both of these macro replacements
to be cancelled. Since our compiler does not actually support the
__restrict keyword (it's merely defined as a macro by glibc), this
On 02/22/2016 01:46 PM, Dwight Guth wrote:
Currently there is a problem with the way the AC_C_RESTRICT macro behaves
if you are using GLIBC with a C99-compliant compiler that does not define
the __GNUC__ macro, but does define __restrict.
Which compiler is this, exactly? What does it define
Currently there is a problem with the way the AC_C_RESTRICT macro behaves
if you are using GLIBC with a C99-compliant compiler that does not define
the __GNUC__ macro, but does define __restrict. You can see this for
yourself by passing `CFLAGS="-U __GNUC__"` to a configure script th
The AC_C_RESTRICT macro should prioritize the standard restrict keyword first
instead of __restrict or any other.
The problem with going with alternate versions of restrict instead of the
standard keyword first is that the alternatives have possibly different
behaviours from the standard. As well
On 06/19/2010 10:13 AM, Ralf Wildenhues wrote:
> I don't really that we can set this automatically, due to the binary
> incompatibility, so we may need to resort to C++ specific restrict
> setting based on __cplusplus. Thoughts?
We've already tried hard to make AC_C_RESTRIC
Tru64/OSF 5.1D fails the "AC_C_RESTRICT and C++" test, when using the
vendor C and C++ compiler:
265. c.at:266: testing AC_C_RESTRICT and C++ ...
../../autoconf/tests/c.at:316: autoconf
../../autoconf/tests/c.at:317: autoheader
../../autoconf/tests/c.at:318: ./configure $configure_opti
gcc in all cases. But if we're mistaken, and
> people really DO want to mix vendor C and g++ (or vendor C++ and
gcc),
> then we must either entirely avoid restrict in C++, or else we
must indeed
> make AC_C_RESTRICT perform additional testing inside an
> AC_LANG_PUSH([C++])/AC_L
gt; or you use gcc in all cases. But if we're mistaken, and
> people really DO want to mix vendor C and g++ (or vendor C++ and gcc),
> then we must either entirely avoid restrict in C++, or else we must indeed
> make AC_C_RESTRICT perform additional testing inside an
> AC_LANG
On Mar 17, 2009, at 10:34 AM, Eric Blake wrote:
I guess I replied inaccurately. The goal is to make AC_C_RESTRICT
(the
existing macro) work correctly.
Gotcha; thanks for the clarification.
Ralf brought up an interesting point - how often do people mix C and
C++
compilers of different
On Mar 17, 2009, at 2:46 AM, Ralf Wildenhues wrote:
> It seems that AC_C_RESTRICT can sometimes find "restrict" for the
PGI C
> compiler, but it can sometimes find "__restrict". Both of these
values
> work for the PGI C compiler, but only "__restrict&qu
t; That's the goal for autoconf 2.64.
>>
>
> Hmm -- this seems to be different than what Ralf W. replied...? Greping
> through a git clone of the autoconf repo, I don't see any mention of
> AC_RESTRICT...?
I guess I replied inaccurately. The goal is to make AC_C_R
On Mar 16, 2009, at 7:11 PM, Eric Blake wrote:
> - Or should there be a new AC_RESTRICT test that makes a solution
for
> both the C and C++ compilers?
That's the goal for autoconf 2.64.
Hmm -- this seems to be different than what Ralf W. replied...?
Greping through a git clone of the au
* Jeff Squyres wrote on Mon, Mar 16, 2009 at 11:54:13PM CET:
>
> It seems that AC_C_RESTRICT can sometimes find "restrict" for the PGI C
> compiler, but it can sometimes find "__restrict". Both of these values
> work for the PGI C compiler, but only
sg00056.html
> - Or should there be a new AC_RESTRICT test that makes a solution for
> both the C and C++ compilers?
That's the goal for autoconf 2.64.
> It seems that AC_C_RESTRICT can sometimes find "restrict" for the PGI C
> compiler, but it can sometimes find "_
existence, and/or the output from AC_C_RESTRICT will become safe for
both C/C++? Specifically, Open MPI uses the "restrict" keyword in a
header file that is included in both C and C++ source code; we now
have a problem if the support for "restrict" is different b
x 6827771..0044b63 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2007-10-22 Paul Eggert <[EMAIL PROTECTED]>
+ and Eric Blake <[EMAIL PROTECTED]>
+
+ * lib/autoconf/c.m4 (AC_C_RESTRICT): Work around Sun C++ compatibility
+ problem reported by Bruno Ha
Yes, this works around the issue. Thanks!
Then how about this autoconf patch?
2007-10-22 Eric Blake <[EMAIL PROTECTED]>
and Paul Eggert <[EMAIL PROTECTED]>
Don't define restrict for Sun C++.
* lib/autoconf/c.m4 (AC_C_RESTRICT): Add verbatim block
Paul Eggert wrote:
> Would it suffice to append this to config.h? I don't have easy access
> to Sun C 5.0 any more (it's pretty old).
The same issue also holds with the Sun Studio 11 compiler
(in /opt/SUNWspro/SunStudio11/SUNWspro/bin).
> /* Work around a bug in Sun C++: it does not support _Res
Bruno Haible <[EMAIL PROTECTED]> writes:
> /* Define to equivalent of C99 restrict keyword, or to nothing if this
> is not supported. Do not define if restrict is supported directly. */
> #ifdef __cplusplus
> #define restrict
> #else
> #define restrict _Restrict
> #endif
That s
;.
2 Error(s) detected.
FAIL: lang-c++
What's happening? gnulib's string.h replacement uses the 'restrict' keyword.
AC_C_RESTRICT has put this into config.h:
#define restrict _Restrict
The lang-c++ test has this C++ code:
#include "config.h"
...
indirectly
On Mon, May 14, 2007 at 09:58:55AM -0700, Paul Eggert wrote:
> Noah Misch <[EMAIL PROTECTED]> writes:
>
> > * lib/autoconf/c.m4 (AC_C_RESTRICT): Check `restrict' last.
>
> Thanks, that makes sense to me. I installed the patch enclosed at the
> end of this me
Noah Misch <[EMAIL PROTECTED]> writes:
> * lib/autoconf/c.m4 (AC_C_RESTRICT): Check `restrict' last.
Thanks, that makes sense to me. I installed the patch enclosed at the
end of this message.
I noticed that there's similar kerfufflery in Autoconf for 'inline&
yes
> gcc -std=gnu99 |yes | yes
> g++ |no| yes
AC_C_RESTRICT currently tests `restrict' first. If `restrict' is unavailable,
it tests various implementation-specific alternatives. Let us prefer the
alternatives: they are more stable acr
Hi,
The NEWS of autoconf 2.60 has this:
** AC_PROG_CC_STDC
Has been unobsoleted, and will check if the compiler supports ISO
C99, falling back to ANSI C89 if not.
This leads to a problem: AC_C_RESTRICT, AC_PROG_CC_STDC, and mixed C/C++
are incompatible.
In detail:
My package
25 matches
Mail list logo
