develooper Front page | perl.perl5.porters | Postings from September 2021

Can we get rid of '-Wc++-compat' build-time warnings?

Thread Next
From:
James E Keenan
Date:
September 16, 2021 19:19
Subject:
Can we get rid of '-Wc++-compat' build-time warnings?
Message ID:
26cc488f-9bc8-d0fc-1cb0-f4146b189b93@pobox.com
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

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About