New compilation warnings with gcc 9.1.0 #17014

p5pRT · 2019-05-23T09:23:48Z

Migrated from rt.perl.org#134130 (status was 'open')

Searchable as RT134130$

p5pRT · 2019-05-23T09:23:48Z

From @dur-randir

Created by @dur-randir

I get the following warnings when building perl on Debian with gcc 9.1.0

Wformat-overflow:

locale.c: In function ‘Perl__is_cur_LC_category_utf8’:
locale.c:5087:17: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
5087 | Perl_croak(aTHX_
| ^~~~~~~~~~~~~~~~
5088 | "panic: %s: %d: Corrupt
utf8ness_cache: missing"
|

 5089 |                            " separator %\.\*s\<\-\- HERE %s\\n"\,
&nbsp;      |                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 5090 |                            \_\_FILE\_\_\, \_\_LINE\_\_\,
&nbsp;      |                            ~~~~~~~~~~~~~~~~~~~
 5091 |                            \(int\) \(e \- PL\_locale\_utf8ness\)\,
PL\_locale\_utf8ness\,
&nbsp;      |

5092 | e);
| ~~
locale.c:5089:53: note: format string is defined here
5089 | " separator %.*s<-- HERE %s\n",
| ^~

Wc++-compat (lots of, here's the pattern):

byte_t.c:322:24: warning: uninitialized const ‘utf8_viscii’ is invalid
in C++ [-Wc++-compat]
322 | static const encpage_t utf8_viscii[];
| ^~~~~~~~~~~
byte_t.c:1144:24: warning: duplicate declaration of
‘utf8_AdobeStandardEncoding’ is invalid in C++ [-Wc++-compat]
1144 | static const encpage_t utf8_AdobeStandardEncoding[10] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
byte_t.c:12:24: note: previous declaration of
‘utf8_AdobeStandardEncoding’ was here
12 | static const encpage_t utf8_AdobeStandardEncoding[];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl 5.31.0:

Configured by dur-randir at Wed Feb 27 14:51:01 MSK 2019.

Summary of my perl5 (revision 5 version 31 subversion 0) configuration:
  Commit id: 58f4626762668e1c1948832073998af84b2c85d0
  Platform:
    osname=linux
    osvers=4.19.0-5-amd64
    archname=x86_64-linux
    uname='linux dorothy 4.19.0-5-amd64 #1 smp debian 4.19.37-3
(2019-05-15) x86_64 gnulinux '
    config_args='-de -Dusedevel -DDEBUGGING -Dcc=gcc-9'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='gcc-9'
    ccflags ='-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe
-fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
    optimize='-O2 -g'
    cppflags='-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe
-fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='9.1.0'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='gcc-9'
    ldflags =' -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib
/usr/lib/gcc/x86_64-linux-gnu/9/include-fixed
/usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu
/lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
    libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.28.so
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version='2.28'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E'
    cccdlflags='-fPIC'
    lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl):
  Compile-time options:
    DEBUGGING
    HAS_TIMES
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_DEVEL
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
  Built under linux
  Compiled at May 23 2019 12:15:21
  %ENV:
    PERLBREW_BASHRC_VERSION="0.78"
    PERLBREW_HOME="/home/afl/.perlbrew"
    PERLBREW_MANPATH="/home/afl/perlbrew/perls/perl-5.20.2/man"
    PERLBREW_PATH="/home/afl/perlbrew/bin:/home/afl/perlbrew/perls/perl-5.20.2/bin"
    PERLBREW_PERL="perl-5.20.2"
    PERLBREW_ROOT="/home/afl/perlbrew"
    PERLBREW_VERSION="0.78"
  @INC:
    lib
    /usr/local/lib/perl5/site_perl/5.31.0/x86_64-linux
    /usr/local/lib/perl5/site_perl/5.31.0
    /usr/local/lib/perl5/5.31.0/x86_64-linux
    /usr/local/lib/perl5/5.31.0

p5pRT · 2019-05-23T15:25:25Z

From @hvds

On Thu, 23 May 2019 02:23:48 -0700, randir wrote:

This is a bug report for perl from sergey.aleynikov@gmail.com,
generated with the help of perlbug 1.41 running under perl 5.31.0.

-----------------------------------------------------------------
[Please describe your issue here]

I get the following warnings when building perl on Debian with gcc
9.1.0

Wformat-overflow:

locale.c: In function ‘Perl__is_cur_LC_category_utf8’:
locale.c:5087:17: warning: ‘%s’ directive argument is null [-Wformat-
overflow=]

This one definitely looks like a bug, code was added by Karl in de3a307.

Wc++-compat (lots of, here's the pattern):

byte_t.c:322:24: warning: uninitialized const ‘utf8_viscii’ is invalid
in C++ [-Wc++-compat]
322 | static const encpage_t utf8_viscii[];
| ^~~~~~~~~~~
byte_t.c:1144:24: warning: duplicate declaration of
‘utf8_AdobeStandardEncoding’ is invalid in C++ [-Wc++-compat]
1144 | static const encpage_t utf8_AdobeStandardEncoding[10] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
byte_t.c:12:24: note: previous declaration of
‘utf8_AdobeStandardEncoding’ was here
12 | static const encpage_t utf8_AdobeStandardEncoding[];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~

These I don't think we should care about, we explicitly use different code #ifdef __cplusplus.

Hugo

p5pRT · 2019-05-23T15:25:25Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2019-05-23T16:43:35Z

From @dur-randir

On Thu, 23 May 2019 08:25:25 -0700, hv wrote:

These I don't think we should care about, we explicitly use different
code #ifdef __cplusplus.

They've enabled them by default, so should perl add -Wno-c++-compat (or whatever is it called)?

p5pRT · 2019-07-23T13:01:42Z

From @hvds

On Thu, 23 May 2019 08:25:25 -0700, hv wrote:

On Thu, 23 May 2019 02:23:48 -0700, randir wrote:

This is a bug report for perl from sergey.aleynikov@gmail.com,
generated with the help of perlbug 1.41 running under perl 5.31.0.

-----------------------------------------------------------------
[Please describe your issue here]

I get the following warnings when building perl on Debian with gcc
9.1.0

Wformat-overflow:

locale.c: In function ‘Perl__is_cur_LC_category_utf8’:
locale.c:5087:17: warning: ‘%s’ directive argument is null [-Wformat-
overflow=]

This one definitely looks like a bug, code was added by Karl in
de3a307.

This was fixed in 01b9105.

Hugo

p5pRT · 2019-07-23T13:05:32Z

From @hvds

On Thu, 23 May 2019 09:43:35 -0700, randir wrote:

On Thu, 23 May 2019 08:25:25 -0700, hv wrote:

These I don't think we should care about, we explicitly use different
code #ifdef __cplusplus.

They've enabled them by default, so should perl add -Wno-c++-compat
(or whatever is it called)?

I have little opinion on that, I know little about the use or intent of perl's C++ support. If it's possible, ideal would be to disable such warnings only within the ifndef __cplusplus branches: they're potentially useful elsewhere.

Hugo

jkeenan · 2019-12-13T19:41:42Z

As of Dec 8, the state of build-time warnings with gcc-9 looked like this:

$ ~/bin/perl/report-build-warnings make.freebsd13.gcc9.useithreads.output.txt.gz
File:  make.freebsd13.gcc9.useithreads.output.txt.gz

  Wc++-compat                              240
  Wcast-function-type                        1
  Wformat-overflow=                          3
  Wunused-variable                           4

Now, this was measured on FreeBSD-31 (I don't have gcc-9 available on my linuxes) with a threaded build. I can supply a list of all the specific warnings if so desired.

I really would like to see the -Wc++-compat warnings (almost all of which are in file byte_t.c) cleared up. Rationale: We will inevitably see much more testing (smoke-testing and otherwise) with gcc-9 in the year to come. To have this many warnings of one category may obscure the first appearance of other, more serious warnings.

@khwilliamson , @hvds, @dur-randir , what can we do to make this happen?

Thank you very much.
Jim Keenan

hvds · 2019-12-14T10:19:26Z

Thinking further on this, as long as we're regularly building with C++ we get no additional value from C++-compat warnings when building in non-C++ mode. So I think disabling those warnings in C builds would be the right thing to do.

Hugo

jkeenan · 2019-12-14T14:26:57Z

Thinking further on this, as long as we're regularly building with C++ we get no additional value from C++-compat warnings when building in non-C++ mode. So I think disabling those warnings in C builds would be the right thing to do.

Hugo

The problem I see with simply turning a particular category of warnings off is that we would not thereafter be prompted to write source code with enough precision to cover different C-compilers. Rather than suppressing reporting of a problem, shouldn't we learn how to fix the problem (assuming it's actually possible to do so)?

Thank you very much.
Jim Keenan

hvds · 2019-12-14T18:41:25Z

Thinking further on this, as long as we're regularly building with C++ we get no additional value from C++-compat warnings when building in non-C++ mode. So I think disabling those warnings in C builds would be the right thing to do.

The problem I see with simply turning a particular category of warnings off is that we would not thereafter be prompted to write source code with enough precision to cover different C-compilers. Rather than suppressing reporting of a problem, shouldn't we learn how to fix the problem (assuming it's actually possible to do so)?

Sorry, I don't think I understand your point. The warning is about C++-compatibility, but we handle C++-compatibility ourselves by having distinct code branches. Where we have two code branches, one for C compilers and the other for C++ compilers, we do not need the former to be C++-compatible.

If we compile the code under g++ at the same version, we'll get all the C++-compatibility warnings that are useful to us. Those are the ones we should care about.

Hugo

jkeenan · 2020-01-28T22:04:47Z

Thinking further on this, as long as we're regularly building with C++ we get no additional value from C++-compat warnings when building in non-C++ mode. So I think disabling those warnings in C builds would be the right thing to do.

The problem I see with simply turning a particular category of warnings off is that we would not thereafter be prompted to write source code with enough precision to cover different C-compilers. Rather than suppressing reporting of a problem, shouldn't we learn how to fix the problem (assuming it's actually possible to do so)?

Sorry, I don't think I understand your point. The warning is about C++-compatibility, but we handle C++-compatibility ourselves by having distinct code branches. Where we have two code branches, one for C compilers and the other for C++ compilers, we do not need the former to be C++-compatible.

@hvds Would you be able to supply an example of your suggested ("two-branch") approach would work with one of our source-code files?

If we compile the code under g++ at the same version, we'll get all the C++-compatibility warnings that are useful to us. Those are the ones we should care about.

Thank you very much.
Jim Keenan

hvds · 2020-01-29T11:51:42Z

Sorry, I don't think I understand your point. The warning is about C++-compatibility, but we handle C++-compatibility ourselves by having distinct code branches. Where we have two code branches, one for C compilers and the other for C++ compilers, we do not need the former to be C++-compatible.

@hvds Would you be able to supply an example of your suggested ("two-branch") approach would work with one of our source-code files?

The "two-branch" approach is what we currently have anywhere we compile distinct code depending on #ifdef __cpluspus. Just grep the code for 'cplusplus' to see all the examples.

Any code that is explicitly not compiled when __cplusplus is not defined is not expected to be C++-compatible, and it is not useful to get warnings that it is not.

jkeenan · 2020-11-13T20:51:34Z

As of Dec 8, the state of build-time warnings with gcc-9 looked like this:
$ ~/bin/perl/report-build-warnings make.freebsd13.gcc9.useithreads.output.txt.gz
File:  make.freebsd13.gcc9.useithreads.output.txt.gz

  Wc++-compat                              240
  Wcast-function-type                        1
  Wformat-overflow=                          3
  Wunused-variable                           4
Now, this was measured on FreeBSD-31 (I don't have gcc-9 available on my linuxes) with a threaded build. I can supply a list of all the specific warnings if so desired.

I now have gcc-9.3.0 available on Linux following an upgrade to Ubuntu 20.04 LTS. Here is the current status of build-time warnings on an unthreaded build on Linux with that C-compiler:

$ report-build-warnings blead.2ce8ebb919.linux.unthreaded.maketp.output.txt.gz 
File:  blead.2ce8ebb919.linux.unthreaded.maketp.output.txt.gz

  Wc++-compat                              240

Thank you very much.
Jim Keenan

jkeenan · 2021-03-22T01:13:56Z

I now have gcc-9.3.0 available on Linux following an upgrade to Ubuntu 20.04 LTS. Here is the current status of build-time warnings on an unthreaded build on Linux with that C-compiler:
$ report-build-warnings blead.2ce8ebb919.linux.unthreaded.maketp.output.txt.gz 
File:  blead.2ce8ebb919.linux.unthreaded.maketp.output.txt.gz

  Wc++-compat                              240

Status unchanged as of commit 3e25f6d (Mar 21 2021).

jkeenan · 2021-09-15T13:23:44Z

I now have gcc-9.3.0 available on Linux following an upgrade to Ubuntu 20.04 LTS. Here is the current status of build-time warnings on an unthreaded build on Linux with that C-compiler:
$ report-build-warnings blead.2ce8ebb919.linux.unthreaded.maketp.output.txt.gz 
File:  blead.2ce8ebb919.linux.unthreaded.maketp.output.txt.gz

  Wc++-compat                              240
Status unchanged as of commit 3e25f6d (Mar 21 2021).

The status of build-time warnings when we compile with gcc-9 has changed since the last update to this ticket.

This commit:

commit 9cc5c436f846b78979eaa14aa6678db1270f7a46
CommitDate: Sat May 22 10:21:26 2021 +0200

    Update Scalar-List-Utils to 1.56

... introduced warnings in these categories:

  Wsign-compare                              4
  Wtype-limits                               2

If you compile with clang10, you set a slightly different set of the same warnings categories associated with the same commit.

I have filed this ticket upstream: https://rt.cpan.org/Ticket/Display.html?id=136985

@leonerd, can you take a look?

Thank you very much.
Jim Keenan

jkeenan · 2022-02-23T00:36:52Z

I now have gcc-9.3.0 available on Linux following an upgrade to Ubuntu 20.04 LTS. Here is the current status of build-time warnings on an unthreaded build on Linux with that C-compiler:
$ report-build-warnings blead.2ce8ebb919.linux.unthreaded.maketp.output.txt.gz 
File:  blead.2ce8ebb919.linux.unthreaded.maketp.output.txt.gz

  Wc++-compat                              240
Status unchanged as of commit 3e25f6d (Mar 21 2021).

Status unchanged as of 765cd54 (Feb 22 2022).

This silences the build warnings reported in #19588 and in #17014. It includes some test updates, but no functionality changes.

demerphq · 2022-04-07T08:39:08Z

With the merge of Encode 3.17 I believe we have no further gcc 9.1.0 warnings from -Wc++-compat, so I am closing this issue.

This silences the build warnings reported in Perl#19588 and in Perl#17014. It includes some test updates, but no functionality changes.

p5pRT added Severity Low type-core labels Oct 19, 2019

jkeenan added the build-time-warnings Replaces [META] Build-time warnings RT #133556 label Nov 4, 2019

jkeenan removed the affects-5.31 label Apr 3, 2021

jkeenan mentioned this issue May 31, 2021

5.34.0: perl linking LTO warnings #18842

Closed

xenu removed the Severity Low label Dec 29, 2021

jkeenan mentioned this issue Apr 6, 2022

Encode produces copious warnings during build under gcc #19588

Closed

demerphq added a commit that referenced this issue Apr 7, 2022

Update Encode to 3.17

05e1b3e

This silences the build warnings reported in #19588 and in #17014. It includes some test updates, but no functionality changes.

demerphq mentioned this issue Apr 7, 2022

Update Encode to 3.17 #19593

Merged

demerphq added a commit that referenced this issue Apr 7, 2022

Update Encode to 3.17

ab5cf2e

This silences the build warnings reported in #19588 and in #17014. It includes some test updates, but no functionality changes.

demerphq closed this as completed Apr 7, 2022

scottchiefbaker pushed a commit to scottchiefbaker/perl5 that referenced this issue Nov 3, 2022

Update Encode to 3.17

81a1c34

This silences the build warnings reported in Perl#19588 and in Perl#17014. It includes some test updates, but no functionality changes.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New compilation warnings with gcc 9.1.0 #17014

New compilation warnings with gcc 9.1.0 #17014

p5pRT commented May 23, 2019

p5pRT commented May 23, 2019

p5pRT commented May 23, 2019

p5pRT commented May 23, 2019

p5pRT commented May 23, 2019

p5pRT commented Jul 23, 2019

p5pRT commented Jul 23, 2019

jkeenan commented Dec 13, 2019

hvds commented Dec 14, 2019

jkeenan commented Dec 14, 2019

hvds commented Dec 14, 2019

jkeenan commented Jan 28, 2020

hvds commented Jan 29, 2020

jkeenan commented Nov 13, 2020

jkeenan commented Mar 22, 2021

jkeenan commented Sep 15, 2021

jkeenan commented Feb 23, 2022

demerphq commented Apr 7, 2022

New compilation warnings with gcc 9.1.0 #17014

New compilation warnings with gcc 9.1.0 #17014

Comments

p5pRT commented May 23, 2019

p5pRT commented May 23, 2019

From @dur-randir

Created by @dur-randir

p5pRT commented May 23, 2019

From @hvds

p5pRT commented May 23, 2019

p5pRT commented May 23, 2019

From @dur-randir

p5pRT commented Jul 23, 2019

From @hvds

p5pRT commented Jul 23, 2019

From @hvds

jkeenan commented Dec 13, 2019

hvds commented Dec 14, 2019

jkeenan commented Dec 14, 2019

hvds commented Dec 14, 2019

jkeenan commented Jan 28, 2020

hvds commented Jan 29, 2020

jkeenan commented Nov 13, 2020

jkeenan commented Mar 22, 2021

jkeenan commented Sep 15, 2021

jkeenan commented Feb 23, 2022

demerphq commented Apr 7, 2022