[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC
From: |
Dwight Guth |
Subject: |
Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC |
Date: |
Mon, 22 Feb 2016 15:46:59 -0600 |
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 that uses
it. Autoconf defines the restrict keyword to __restrict, because it detects
that this keyword exists. However, glibc defines away the __restrict
keyword to empty in this case. This leads the restrict keyword being
removed in all cases even though the compiler treats it as a valid keyword.
Attached is my testsuite.log file for information about my environment. I
believe that glibc's behavior is also wrong in this case, but even if glibc
were to do the correct thing and define __restrict to the keyword, you
would still have a bug in autoconf caused by a circular define. You can't
see this in the case with gcc, but if another compiler were to define
__restrict as a macro but not a keyword, this would then cause compilation
to crash whenever the __restrict keyword is used, because the circular
define would prevent macro replacement, __restrict would not be a keyword.
I'm pretty sure that the way you want to handle this is that if __restrict
is preprocessed into "foo", then config.h should define "restrict" as "foo"
instead of as "__restrict".
testsuite.log
Description: Text Data
- Bug with AC_C_RESTRICT on non-GNU-C compiler when using GLIBC,
Dwight Guth <=