Re: isnan function conflicts with C++ standard library declarations
Hi Bruno, On Wed, 28 Aug 2019, Bruno Haible wrote: Hi Martin, Well in addition to macOS, I can also still reproduce the issue on Linux (Ubuntu 18.04, with its default GCC 7) as well, so maybe it's an issue with newer C++ standard headers, regardless of platform? Indeed. I can reproduce it with GCC >= 6. And since clang sometimes uses the C++ header files from GCC, we also have to enable the workaround for clang. It is apparently not needed with AIX xlc, HP-UX cc, Solaris cc. Fixed by changing the condition to #if __GNUC__ >= 6 || defined __clang__ Thanks! That should probably work, and good to know in which GCC version this changed. This issue can crop up e.g. when trying to build gettext for mingw (which has got the gnulib isnan function bundled, even if it isn't used). I'm regularly building gettext on mingw and haven't seen this issue. Therefore thanks again for the reproduction example. I ran into it while trying to build gettext with clang (with my pure-llvm based toolchain, at https://github.com/mstorsjo/llvm-mingw in case you're interested), so I presume there's something that goes different in gettext with clang/lld compared to gcc Yes. It would make sense to compare the config.status file generated by an llvm build with those generated by a gcc build. Thanks for the pointers - I'll see if I'll dig further into that to see what the differences stem from. I only run into it if building a shared gettext, not with a static-only build, for some reason. The reason is that gettext is written in C, and only a few files are getting compiled by a C++ compiler, as a workaround to a problem with DLL import of variables and variable initializers. This workaround is not enabled when --disable-shared is specified. Ah, thanks, that explains things a bit. // Martin
Re: FreeBSD: Warnings about c-ctype macros used but marked unused
Hi Bruno, On 28.08.19 17:28, Bruno Haible wrote: >> The option -Wused-but-marked-unused is indirectly activated by >> -Weverything > > -Weverything is not something we can support in gnulib. For the > meaning of this option, see > https://quuxplusone.github.io/blog/2018/12/06/dont-use-weverything/ I can't agree 100% with the statements in this article. We use -Weverything + some -Wno- options successfully for our sources since years. Though, building the gnulib sources has a different set of options of course. >> which is set during the ./configure run (kind of a >> manywarnings module) > > Why do we have a 'manywarnings' module, not an 'allwarnings' module? > Look into the list of warnings that we don't add through 'manywarnings': > build-aux/gcc-warning.spec > build-aux/g++-warning.spec Thanks for the pointers. >> And I wonder why do the c_ macros are marked >> UNUSED at all (I assume that gnulib does it for some reason) ? > > 'c-ctype' uses the module 'extern-inline'. In extern-inline.m4 you can > see that on platforms where 'extern inline' cannot properly be supported, > we let _GL_INLINE expand to 'static _GL_UNUSED'. Without '_GL_UNUSED', > gcc (with some appropriate, useful warning options) would complain that > the functions are not used. > > The ability to use this warning option - which allows developers to > detect dead code - is more important than the option -Wused-but-marked-unused. That's reasonable. I'll put that option on the exclude list for the gnulib sources. Thanks for the explanation, I didn't see that in the first place (the FreeBSD is a CI image, not controlled by me). Regards, Tim signature.asc Description: OpenPGP digital signature
Re: isnan function conflicts with C++ standard library declarations
Hi Martin, > Well in addition to macOS, I can also still reproduce the issue on Linux > (Ubuntu 18.04, with its default GCC 7) as well, so maybe it's an issue > with newer C++ standard headers, regardless of platform? Indeed. I can reproduce it with GCC >= 6. And since clang sometimes uses the C++ header files from GCC, we also have to enable the workaround for clang. It is apparently not needed with AIX xlc, HP-UX cc, Solaris cc. Fixed by changing the condition to #if __GNUC__ >= 6 || defined __clang__ > >> This issue can crop up e.g. when trying to build gettext for mingw (which > >> has got the gnulib isnan function bundled, even if it isn't used). > > > > I'm regularly building gettext on mingw and haven't seen this issue. > > Therefore > > thanks again for the reproduction example. > > I ran into it while trying to build gettext with clang (with my pure-llvm > based toolchain, at https://github.com/mstorsjo/llvm-mingw in case you're > interested), so I presume there's something that goes different in gettext > with clang/lld compared to gcc Yes. It would make sense to compare the config.status file generated by an llvm build with those generated by a gcc build. > I only run into it > if building a shared gettext, not with a static-only build, for some > reason. The reason is that gettext is written in C, and only a few files are getting compiled by a C++ compiler, as a workaround to a problem with DLL import of variables and variable initializers. This workaround is not enabled when --disable-shared is specified. Bruno
Re: FreeBSD: Warnings about c-ctype macros used but marked unused
Hi Tim, > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on > LLVM 6.0.0) OK. > The option -Wused-but-marked-unused is indirectly activated by > -Weverything -Weverything is not something we can support in gnulib. For the meaning of this option, see https://quuxplusone.github.io/blog/2018/12/06/dont-use-weverything/ > which is set during the ./configure run (kind of a > manywarnings module) Why do we have a 'manywarnings' module, not an 'allwarnings' module? Look into the list of warnings that we don't add through 'manywarnings': build-aux/gcc-warning.spec build-aux/g++-warning.spec > And I wonder why do the c_ macros are marked > UNUSED at all (I assume that gnulib does it for some reason) ? 'c-ctype' uses the module 'extern-inline'. In extern-inline.m4 you can see that on platforms where 'extern inline' cannot properly be supported, we let _GL_INLINE expand to 'static _GL_UNUSED'. Without '_GL_UNUSED', gcc (with some appropriate, useful warning options) would complain that the functions are not used. The ability to use this warning option - which allows developers to detect dead code - is more important than the option -Wused-but-marked-unused. Bruno
Re: FreeBSD: Warnings about c-ctype macros used but marked unused
Hi Bruno, On 8/28/19 4:09 PM, Bruno Haible wrote: > Hi Tim, > >> Compiling on FreeBSD 12 gives a warning per use of c_ macros, for example >> >> http_parse.c:187:10: warning: 'c_isblank' was marked unused but was used >> [-Wused-but-marked-unused] >> while (c_isblank(*s)) s++; >> >> >> This is true also for c_isdigit, c_isspace, etc. > > A bit more details, please: > - Which version of gcc or clang is this? > - Where does the option -Wused-but-marked-unused come from? Is it part > of -Wall, or did you or your package add it explicitly? From config.log: FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) Target: x86_64-unknown-freebsd11.2 Thread model: posix InstalledDir: /usr/bin The option -Wused-but-marked-unused is indirectly activated by -Weverything, which is set during the ./configure run (kind of a manywarnings module). So it's not part of $CFLAGS or $CPPFLAGS but later used as part of AM_CFLAGS. I do not see that warning on Linux, with any version of clang (3.8, ... 9) or gcc (4.3, ..., 9.2). And I wonder why do the c_ macros are marked UNUSED at all (I assume that gnulib does it for some reason) ? Regards, Tim signature.asc Description: OpenPGP digital signature
Re: FreeBSD: Warnings about c-ctype macros used but marked unused
Hi Tim, > Compiling on FreeBSD 12 gives a warning per use of c_ macros, for example > > http_parse.c:187:10: warning: 'c_isblank' was marked unused but was used > [-Wused-but-marked-unused] > while (c_isblank(*s)) s++; > > > This is true also for c_isdigit, c_isspace, etc. A bit more details, please: - Which version of gcc or clang is this? - Where does the option -Wused-but-marked-unused come from? Is it part of -Wall, or did you or your package add it explicitly? Bruno
FreeBSD: Warnings about c-ctype macros used but marked unused
Compiling on FreeBSD 12 gives a warning per use of c_ macros, for example http_parse.c:187:10: warning: 'c_isblank' was marked unused but was used [-Wused-but-marked-unused] while (c_isblank(*s)) s++; This is true also for c_isdigit, c_isspace, etc. Is that expected behavior and if so, why ? Regards, Tim signature.asc Description: OpenPGP digital signature
Re: isnan function conflicts with C++ standard library declarations
Hi,
On Wed, 28 Aug 2019, Bruno Haible wrote:
Hi,
Martin Storsjö wrote:
When the isnan function is enabled in gnulib, the added bits in math.h
break if included in C++ translation units.
A minimal reproducion example is available at
https://martin.st/temp/gnulib-isnan-repro-0.0.0.tar.gz (preconfigured and
directly buildable) and
https://martin.st/temp/gnulib-isnan-repro-source.tar.gz (original source,
requires running gnulib-tool and autoreconf).
The error manifests both with GCC/libstdc++ and Clang/libc++, with error
messages like these:
In file included from myprog.cpp:2:0:
lib/math.h: In function ‘int isnan(float)’:
lib/math.h:2829:1: error: ‘int isnan(float)’ conflicts with a previous
declaration
_GL_MATH_CXX_REAL_FLOATING_DECL_2 (isnan)
^
In file included from /usr/include/c++/7/math.h:36:0,
from lib/math.h:27,
from myprog.cpp:2:
/usr/include/c++/7/cmath:618:3: note: previous declaration ‘constexpr bool
std::isnan(float)’
isnan(float __x)
^
I reproduce the issue on mingw - thanks for a very nicely made
reproduction example -, and have applied the fix below.
Thanks for the very quick fix!
In file included from myprog.cpp:2:
lib/math.h:2829:36: error: 'isnan' is missing exception specification 'throw()'
_GL_MATH_CXX_REAL_FLOATING_DECL_2 (isnan)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h:533:1:
note:
previous declaration is here
isnan(float __lcpp_x) _NOEXCEPT { return __libcpp_isnan(__lcpp_x); }
^
Probably I should test this also on macOS and other platforms...
Well in addition to macOS, I can also still reproduce the issue on Linux
(Ubuntu 18.04, with its default GCC 7) as well, so maybe it's an issue
with newer C++ standard headers, regardless of platform?
This issue can crop up e.g. when trying to build gettext for mingw (which
has got the gnulib isnan function bundled, even if it isn't used).
I'm regularly building gettext on mingw and haven't seen this issue. Therefore
thanks again for the reproduction example.
I ran into it while trying to build gettext with clang (with my pure-llvm
based toolchain, at https://github.com/mstorsjo/llvm-mingw in case you're
interested), so I presume there's something that goes different in gettext
with clang/lld compared to gcc, that makes the few bits of C++ in gettext
not be built and/or include gnulib's math.h with isnan. Otherwise I'm sure
lots of others would have run into it ages ago. (Also, I only run into it
if building a shared gettext, not with a static-only build, for some
reason.)
// Martin
Re: isnan function conflicts with C++ standard library declarations
Hi,
Martin Storsjö wrote:
> When the isnan function is enabled in gnulib, the added bits in math.h
> break if included in C++ translation units.
>
> A minimal reproducion example is available at
> https://martin.st/temp/gnulib-isnan-repro-0.0.0.tar.gz (preconfigured and
> directly buildable) and
> https://martin.st/temp/gnulib-isnan-repro-source.tar.gz (original source,
> requires running gnulib-tool and autoreconf).
>
> The error manifests both with GCC/libstdc++ and Clang/libc++, with error
> messages like these:
>
> In file included from myprog.cpp:2:0:
> lib/math.h: In function ‘int isnan(float)’:
> lib/math.h:2829:1: error: ‘int isnan(float)’ conflicts with a previous
> declaration
> _GL_MATH_CXX_REAL_FLOATING_DECL_2 (isnan)
> ^
> In file included from /usr/include/c++/7/math.h:36:0,
> from lib/math.h:27,
> from myprog.cpp:2:
> /usr/include/c++/7/cmath:618:3: note: previous declaration ‘constexpr bool
> std::isnan(float)’
> isnan(float __x)
> ^
I reproduce the issue on mingw - thanks for a very nicely made
reproduction example -, and have applied the fix below.
> In file included from myprog.cpp:2:
> lib/math.h:2829:36: error: 'isnan' is missing exception specification
> 'throw()'
> _GL_MATH_CXX_REAL_FLOATING_DECL_2 (isnan)
> ^
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h:533:1:
> note:
>previous declaration is here
> isnan(float __lcpp_x) _NOEXCEPT { return __libcpp_isnan(__lcpp_x); }
> ^
Probably I should test this also on macOS and other platforms...
> This issue can crop up e.g. when trying to build gettext for mingw (which
> has got the gnulib isnan function bundled, even if it isn't used).
I'm regularly building gettext on mingw and haven't seen this issue. Therefore
thanks again for the reproduction example.
2019-08-28 Bruno Haible
isfinite, isinf, isnan, signbit: Fix error in C++ mode on mingw.
Reported by Martin Storsjö in
.
* lib/math.in.h (_GL_MATH_CXX_REAL_FLOATING_DECL_2): Add more arguments.
(isfinite, isinf, isnan, signbit): On mingw, use an override through
'#define', because the inline definitions in the platform's
cannot be overridden in another way.
diff --git a/lib/math.in.h b/lib/math.in.h
index 99a2c6a..8292650 100644
--- a/lib/math.in.h
+++ b/lib/math.in.h
@@ -67,20 +67,20 @@ _gl_cxx_ ## func ## l (long double l)
\
{ \
return func (l); \
}
-# define _GL_MATH_CXX_REAL_FLOATING_DECL_2(func) \
+# define _GL_MATH_CXX_REAL_FLOATING_DECL_2(func,rpl_func,rettype) \
_GL_BEGIN_NAMESPACE \
-inline int \
-func (float f) \
+inline rettype \
+rpl_func (float f) \
{ \
return _gl_cxx_ ## func ## f (f); \
} \
-inline int \
-func (double d) \
+inline rettype \
+rpl_func (double d) \
{ \
return _gl_cxx_ ## func ## d (d); \
} \
-inline int \
-func (long double l)\
+inline rettype \
+rpl_func (long double l)\
{ \
return _gl_cxx_ ## func ## l (l); \
} \
@@ -2207,7 +2207,14 @@ _GL_EXTERN_C int gl_isfinitel (long double x);
# if defined isfinite || defined GNULIB_NAMESPACE
_GL_MATH_CXX_REAL_FLOATING_DECL_1 (isfinite)
# undef isfinite
-_GL_MATH_CXX_REAL_FLOATING_DECL_2 (isfinite)
+# if defined __MINGW32__
+ /* This platform's defines isfinite through a set of inline
+ functions. */
+_GL_MATH_CXX_REAL_FLOATING_DECL_2 (isfinite, rpl_isfinite, bool)
+#define isfinite rpl_isfinite
+# else
+_GL_MATH_CXX_REAL_FLOATING_DECL_2 (isfinite, isfinite, bool)
+# endif
# endif
#
