When we build Perl 5 blead using 'gcc' version 9 or later, we get 240
instances of the '-Wc++-compat' warning. When we build with 'gcc'
version 8, we do not get this build-time warning at all.
A typical '-Wc++-compat' warning will look like this:
#####
gcc12 -c -I./Encode -I../Encode -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H
-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include -D_FORTIFY_SOURCE=2 -Wall -Werror=pointer-arith
-Werror=vla -Wextra -Wc++-compat -Wwrite-strings
-Werror=declaration-after-statement -O2 -DVERSION=\"2.04\"
-DXS_VERSION=\"2.04\" -DPIC -fPIC "-I../../.." byte_t.c
byte_t.c:12:24: warning: uninitialized 'const
utf8_AdobeStandardEncoding' is invalid in C++ [-Wc++-compat]
12 | static const encpage_t utf8_AdobeStandardEncoding[];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
#####
... or like this:
#####
gcc9 -c -I./Encode -I../Encode -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H
-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include -D_FORTIFY_SOURCE=2 -Wall -Werror=pointer-arith
-Werror=vla -Wextra -Wc++-compat -Wwrite-strings
-Werror=declaration-after-statement -O2 -DVERSION=\"2.03\"
-DXS_VERSION=\"2.03\" -DPIC -fPIC "-I../../.." cp_00_t.c
cp_00_t.c:12:24: warning: uninitialized const 'cp949_utf8' is invalid in
C++ [-Wc++-compat]
12 | static const encpage_t cp949_utf8[];
| ^~~~~~~~~~
cp_00_t.c:17:24: warning: uninitialized const 'utf8_cp949' is invalid in
C++ [-Wc++-compat]
17 | static const encpage_t utf8_cp949[];
| ^~~~~~~~~~
cp_00_t.c:5583:24: warning: duplicate declaration of 'cp949_utf8' is
invalid in C++ [-Wc++-compat]
5583 | static const encpage_t cp949_utf8[129] = {
| ^~~~~~~~~~
cp_00_t.c:12:24: note: previous declaration of 'cp949_utf8' was here
12 | static const encpage_t cp949_utf8[];
| ^~~~~~~~~~
cp_00_t.c:13928:24: warning: duplicate declaration of 'utf8_cp949' is
invalid in C++ [-Wc++-compat]
13928 | static const encpage_t utf8_cp949[26] = {
| ^~~~~~~~~~
cp_00_t.c:17:24: note: previous declaration of 'utf8_cp949' was here
17 | static const encpage_t utf8_cp949[];
| ^~~~~~~~~~
#####
AFAICT, all 240 instances of these warnings occur while compiling '*.c'
files generated underneath the 'cpan/Encode/' directory as 'make' runs.
The Encode library is maintained upstream on CPAN.
According to the GNU docs
(https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Warning-Options.html#Warning-Options),
the purpose of this warning is: "Warn about ISO C constructs that are
outside of the common subset of ISO C and ISO C++, e.g. request for
implicit conversion from void * to a pointer to non-void type."
Now, you might think that, what with all these warnings about
incompatibility with C++, our builds would gag when building with 'g++'
version 9 as opposed to gcc-9. But that's not the case. On both Linux
and FreeBSD, g++-9 sails right through the Encode compilation without
losing its breath or its lunch. Neither does the (presumably)
equivalent version of 'clang' have a problem with Encode compilation.
So it appears that these 240 '-Wc++-compat' warnings are effectively
false positives. That's really annoying because they constitute more
than 97% of all the build-time warnings emitted by 'gcc'. This
distracts us from other warnings, most of which originate in code
committed fairly recently. For that reason, they are a nuisance that we
should address. I can think of a number of possible approaches to
remediation:
* We can simply remove '-Wcc++-compat' entirely. I took a first stab at
this in the 'smoke-me/jkeenan/compat-exploration' branch, wherein I
removed the string '-Wc++-compat' in exactly one location.
#####
commit 0b8cd7e46f95b6afc88ed2830ca01b753f13e233 (HEAD -> compat-exploration)
Author: James E Keenan <jkeenan@cpan.org>
AuthorDate: Tue Sep 14 22:03:05 2021 +0000
Commit: James E Keenan <jkeenan@cpan.org>
CommitDate: Wed Sep 15 20:32:06 2021 +0000
Suppose we don't warn about cc compatibility
diff --git a/cflags.SH b/cflags.SH
index 162538583d..6da6ed48a7 100755
--- a/cflags.SH
+++ b/cflags.SH
@@ -182,7 +182,7 @@ Intel*) ;; # # Is that you, Intel C++?
-Werror=pointer-arith \
-Werror=vla \
-Wextra -W \
- -Wc++-compat -Wwrite-strings"
+ -Wwrite-strings"
# declaration after statement is normal in C++ rather than an
# extension and compilers complain if we try to warn about it
case "$d_cplusplus" in
#####
This silenced the 240 build-time warnings when compiling with 'gcc'
version 9 or later and appears to have had no harmful results in [smoke
testing](http://perl.develop-help.com/?b=smoke-me%2Fjkeenan%2Fcompat-exploration)
or [CI](https://github.com/Perl/perl5/actions/runs/1237882207). We
would presumably purge that string from the remaining locations in the
core distribution.
* We could explicitly compile with '-Wno-c++-compat' (or however it's
spelled). I've tried this locally; it eliminates the 240 warnings --
but I haven't smoke-tested it with other compilers.
* We could work with the Encode maintainer to revise the upstream code
such that, when compiled in Perl 5 with gcc 9 or later, it does not
warn. We would then continue to build with '-Wc++-compat'. (This may
be difficult, as the files being warned about are not source code but
'*.c' files generated by 'cpan/Encode/bin/enc2xs'.)
How should we proceed?
Thank you very much.
Jim Keenan
instances of the '-Wc++-compat' warning. When we build with 'gcc'
version 8, we do not get this build-time warning at all.
A typical '-Wc++-compat' warning will look like this:
#####
gcc12 -c -I./Encode -I../Encode -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H
-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include -D_FORTIFY_SOURCE=2 -Wall -Werror=pointer-arith
-Werror=vla -Wextra -Wc++-compat -Wwrite-strings
-Werror=declaration-after-statement -O2 -DVERSION=\"2.04\"
-DXS_VERSION=\"2.04\" -DPIC -fPIC "-I../../.." byte_t.c
byte_t.c:12:24: warning: uninitialized 'const
utf8_AdobeStandardEncoding' is invalid in C++ [-Wc++-compat]
12 | static const encpage_t utf8_AdobeStandardEncoding[];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
#####
... or like this:
#####
gcc9 -c -I./Encode -I../Encode -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H
-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong
-I/usr/local/include -D_FORTIFY_SOURCE=2 -Wall -Werror=pointer-arith
-Werror=vla -Wextra -Wc++-compat -Wwrite-strings
-Werror=declaration-after-statement -O2 -DVERSION=\"2.03\"
-DXS_VERSION=\"2.03\" -DPIC -fPIC "-I../../.." cp_00_t.c
cp_00_t.c:12:24: warning: uninitialized const 'cp949_utf8' is invalid in
C++ [-Wc++-compat]
12 | static const encpage_t cp949_utf8[];
| ^~~~~~~~~~
cp_00_t.c:17:24: warning: uninitialized const 'utf8_cp949' is invalid in
C++ [-Wc++-compat]
17 | static const encpage_t utf8_cp949[];
| ^~~~~~~~~~
cp_00_t.c:5583:24: warning: duplicate declaration of 'cp949_utf8' is
invalid in C++ [-Wc++-compat]
5583 | static const encpage_t cp949_utf8[129] = {
| ^~~~~~~~~~
cp_00_t.c:12:24: note: previous declaration of 'cp949_utf8' was here
12 | static const encpage_t cp949_utf8[];
| ^~~~~~~~~~
cp_00_t.c:13928:24: warning: duplicate declaration of 'utf8_cp949' is
invalid in C++ [-Wc++-compat]
13928 | static const encpage_t utf8_cp949[26] = {
| ^~~~~~~~~~
cp_00_t.c:17:24: note: previous declaration of 'utf8_cp949' was here
17 | static const encpage_t utf8_cp949[];
| ^~~~~~~~~~
#####
AFAICT, all 240 instances of these warnings occur while compiling '*.c'
files generated underneath the 'cpan/Encode/' directory as 'make' runs.
The Encode library is maintained upstream on CPAN.
According to the GNU docs
(https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Warning-Options.html#Warning-Options),
the purpose of this warning is: "Warn about ISO C constructs that are
outside of the common subset of ISO C and ISO C++, e.g. request for
implicit conversion from void * to a pointer to non-void type."
Now, you might think that, what with all these warnings about
incompatibility with C++, our builds would gag when building with 'g++'
version 9 as opposed to gcc-9. But that's not the case. On both Linux
and FreeBSD, g++-9 sails right through the Encode compilation without
losing its breath or its lunch. Neither does the (presumably)
equivalent version of 'clang' have a problem with Encode compilation.
So it appears that these 240 '-Wc++-compat' warnings are effectively
false positives. That's really annoying because they constitute more
than 97% of all the build-time warnings emitted by 'gcc'. This
distracts us from other warnings, most of which originate in code
committed fairly recently. For that reason, they are a nuisance that we
should address. I can think of a number of possible approaches to
remediation:
* We can simply remove '-Wcc++-compat' entirely. I took a first stab at
this in the 'smoke-me/jkeenan/compat-exploration' branch, wherein I
removed the string '-Wc++-compat' in exactly one location.
#####
commit 0b8cd7e46f95b6afc88ed2830ca01b753f13e233 (HEAD -> compat-exploration)
Author: James E Keenan <jkeenan@cpan.org>
AuthorDate: Tue Sep 14 22:03:05 2021 +0000
Commit: James E Keenan <jkeenan@cpan.org>
CommitDate: Wed Sep 15 20:32:06 2021 +0000
Suppose we don't warn about cc compatibility
diff --git a/cflags.SH b/cflags.SH
index 162538583d..6da6ed48a7 100755
--- a/cflags.SH
+++ b/cflags.SH
@@ -182,7 +182,7 @@ Intel*) ;; # # Is that you, Intel C++?
-Werror=pointer-arith \
-Werror=vla \
-Wextra -W \
- -Wc++-compat -Wwrite-strings"
+ -Wwrite-strings"
# declaration after statement is normal in C++ rather than an
# extension and compilers complain if we try to warn about it
case "$d_cplusplus" in
#####
This silenced the 240 build-time warnings when compiling with 'gcc'
version 9 or later and appears to have had no harmful results in [smoke
testing](http://perl.develop-help.com/?b=smoke-me%2Fjkeenan%2Fcompat-exploration)
or [CI](https://github.com/Perl/perl5/actions/runs/1237882207). We
would presumably purge that string from the remaining locations in the
core distribution.
* We could explicitly compile with '-Wno-c++-compat' (or however it's
spelled). I've tried this locally; it eliminates the 240 warnings --
but I haven't smoke-tested it with other compilers.
* We could work with the Encode maintainer to revise the upstream code
such that, when compiled in Perl 5 with gcc 9 or later, it does not
warn. We would then continue to build with '-Wc++-compat'. (This may
be difficult, as the files being warned about are not source code but
'*.c' files generated by 'cpan/Encode/bin/enc2xs'.)
How should we proceed?
Thank you very much.
Jim Keenan