[Bug analyzer/111475] New: Many C++ analyzer tests FAIL

[Bug analyzer/111475] New: Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

            Bug ID: 111475
           Summary: Many C++ analyzer tests FAIL
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: vultkayn at gcc dot gnu.org
  Target Milestone: ---
            Target: *-*-solaris2.11

Between 20230908 (f9cb357ae962ba2922b8507f4d96227780a063b9) and 20230911
(88a0a883960910530bfefa750461168f539f4a00), man (ca.350 per multilib) analyzer
tests FAIL on Solaris (both 32 and 64-bit, SPARC and x86).  There may be a
common pattern (I've only looked at one example):

FAIL: c-c++-common/analyzer/allocation-size-1.c  -std=c++14  (test for
warnings, line 33)
FAIL: c-c++-common/analyzer/allocation-size-1.c  -std=c++14 note (test for
warnings, line 65)
FAIL: c-c++-common/analyzer/allocation-size-1.c  -std=c++14 note at line 21
(test for warnings, line 15)

Comparing the full output on Solaris

/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:
In function 'void test_2()':
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:15:37:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:15:37:
note: (1) allocated 42 bytes and assigned to 'int32_t*' {aka 'int*'} here;
'sizeof (int32_t {aka int})' is '4'
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:
In function 'void test_4()':
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:34:12:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:34:12:
note: (1) allocated 42 bytes and assigned to 'int32_t*' {aka 'int*'} here;
'sizeof (int32_t {aka int})' is '4'
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:
In function 'void test_6()':
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:68:12:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:68:12:
note: (1) allocated and assigned to 'int32_t*' {aka 'int*'} here; 'sizeof
(int32_t {aka int})' is '4'
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:
In function 'void test_11()':
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:125:37:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:125:37:
note: (1) allocated 3 bytes and assigned to 'int32_t*' {aka 'int*'} here;
'sizeof (int32_t {aka int})' is '4'

and Linux

/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:
In function 'void test_2()':
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:15:37:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:15:37:
note: (1) allocated 42 bytes here
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:15:37:
note: (2) assigned to 'int32_t*' {aka 'int*'} here; 'sizeof (int32_t {aka
int})' is '4'
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:
In function 'void test_4()':
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:34:12:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:33:22:
note: (1) allocated 42 bytes here
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:34:12:
note: (2) assigned to 'int32_t*' {aka 'int*'} here; 'sizeof (int32_t {aka
int})' is '4'
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:
In function 'void test_6()':
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:68:12:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:65:22:
note: (1) allocated here
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:68:12:
note: (2) assigned to 'int32_t*' {aka 'int*'} here; 'sizeof (int32_t {aka
int})' is '4'
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:
In function 'void test_11()':
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:125:37:
warning: allocated buffer size is not a multiple of the pointee's size
[CWE-131] [-Wanalyzer-allocation-size]
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:125:37:
note: (1) allocated 3 bytes here
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:125:37:
note: (2) assigned to 'int32_t*' {aka 'int*'} here; 'sizeof (int32_t {aka
int})' is '4'

ISTM that the primary difference is here:

/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:15:37:
note: (1) allocated 42 bytes and assigned to 'int32_t*' {aka 'int*'} here;
'sizeof (int32_t {aka int})' is '4'

vs.

/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:15:37:
note: (1) allocated 42 bytes here
/vol/gcc/src/hg/master/local/gcc/testsuite/c-c++-common/analyzer/allocation-size-1.c:15:37:
note: (2) assigned to 'int32_t*' {aka 'int*'} here; 'sizeof (int32_t {aka
int})' is '4'

i.e. the wording of the note, where the testsuite doesn't cater to the first
form.

This creates an incredible amount of noise, unfortunately.

[Bug analyzer/111475] Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug analyzer/111475] Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
After

commit ae034b9106fbdd855ec22ce221bb61a1a9a532c3
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Thu Dec 14 16:53:50 2023 -0500

    testsuite: move more analyzer test cases to c-c++-common (3) [PR96395]

there are now 840 additional FAILs.  This causes 1458 out of 1871 FAILs
(Solaris/x86) resp. 1588 out of 2236 FAILs (Solaris/SPARC) to be analyzer
related.

Compared to 98 out of 485 (i386) resp. 98 out of 529 (sparc) on the gcc-13
branch, this makes for a massive regression (factor 14 resp. 18).

[Bug analyzer/111475] Many C++ analyzer tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
David, can you provide some help or suggestions here?  I'm completely
lost in the analyzer code.  Thanks.

[Bug analyzer/111475] Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> ---
I've now reduced c-c++-common/analyzer/allocation-size-1.c:test_2 to minimal
preprocessed the inputs, still showing the difference:

$ cc1plus -fpreprocessed as1-sol2.ii -quiet -std=c++98
-fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events -fdiagnostics-text-art-charset=none
-fmessage-length=0 -fanalyzer -fanalyzer-call-summaries -o as1.s

* as1-sol2.ii:

as1-sol2.ii:17:37: note: (1) allocated 42 bytes and assigned to ‘int32_t*’ {aka
‘int*’} here; ‘sizeof (int32_t {aka int})’ is ‘4’

* as1-lx.ii:

as1-lx.ii:21:37: note: (1) allocated 42 bytes here
as1-lx.ii:21:37: note: (2) assigned to ‘int32_t*’ {aka ‘int*’} here; ‘sizeof
(int32_t {aka int})’ is ‘4’

[Bug analyzer/111475] Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #4 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 57156
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57156&action=edit
Solaris testcase: as1-sol2.ii

[Bug analyzer/111475] Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #5 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 57157
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57157&action=edit
Linux testcase: as1-lx.ii

[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Many C++ analyzer tests     |[14 regression] Many C++
                   |FAIL                        |analyzer tests FAIL

--- Comment #6 from Rainer Orth <ro at gcc dot gnu.org> ---
This actually is a regression from GCC 13: with the as1-sol2.ii testcase,
GCC 13 cc1plus produces the same output as on Linux, while GCC 14 cc1plus
differs as described.

[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-04-23
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
A reghunt identified this patch as the culprit:

commit 55f6a7d949abc708d1c6ebc01eb3053f96d1472b
Author: benjamin priour <vultkayn@gcc.gnu.org>
Date:   Sun Aug 27 14:36:14 2023 +0200

    analyzer: Move gcc.dg/analyzer tests to c-c++-common (1) [PR96395]

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #8 from Rainer Orth <ro at gcc dot gnu.org> ---
I wonder what to do about this PR for GCC 14:

* It increased analyzer failures from 92 on the gcc-13 branch to 1482 on trunk.

* This is a massive regression for sparc-sun-solaris2.11, a primary target.

* I never got any response from either the patch author or David as analyzer
  maintainer.

In the worst case, I guess it's better to disable the analyzer testsuite on
Solaris rather than having this insane amount of noise.

Thoughts?

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #9 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Sorry about this.

Is there a machine in the compile farm I can test this on?

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #9 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
> Sorry about this.
>
> Is there a machine in the compile farm I can test this on?

Sure, both cfarm215 (Solaris/x86) and cfarm216 (Solaris/SPARC).  With
the attached Solaris testcase, you can reproduce it even on Linux.

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #11 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks.  I've been working on this on cfarm216; I have a messy set of patches
with this improvement to g++.sum with analyzer.exp so far:

# of expected passes           11395 -> 12015
# of unexpected failures         684 ->    64
# of unexpected successes          4 ->     0
# of expected failures           443 ->   447
# of unsupported tests            50

However I'm don't have access to my regular workstation/testing box until late
tomorrow, so I'm holding off on posting until I've cleaned them up and put them
through my usual testing regime.

Sorry again about the noise

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
"dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:
> --- Comment #11 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
> Thanks.  I've been working on this on cfarm216; I have a messy set of patches
> with this improvement to g++.sum with analyzer.exp so far:
>
> # of expected passes           11395 -> 12015
> # of unexpected failures         684 ->    64
> # of unexpected successes          4 ->     0
> # of expected failures           443 ->   447
> # of unsupported tests            50
>
> However I'm don't have access to my regular workstation/testing box until late
> tomorrow, so I'm holding off on posting until I've cleaned them up and put them
> through my usual testing regime.

That's excellent news, thanks for the update.

[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:

https://gcc.gnu.org/g:5219414f3cde3c1037e289a6654cd722cfa75dea

commit r15-131-g5219414f3cde3c1037e289a6654cd722cfa75dea
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Fri May 3 09:05:29 2024 -0400

    testsuite: fix analyzer C++ failures on Solaris [PR111475]

    As part of PR analyzer/96395, these patches moved testcases from
    gcc.dg/analyzer to c-c++-common/analyzer:
    - r14-3503-g55f6a7d949abc7
    - r14-3823-g50b5199cff6908
    - r14-6564-gae034b9106fbdd

    Unfortunately this led to numerous g++ testsuite failures on Solaris,
    tracked as PR analyzer/111475.

    Almost all of the failures are due to standard library differences where
    including a C standard library on C++ e.g. <stdlib.h> leads to the plain
    symbols referencing the symbols "std::" via a "using" declaration,
    whereas I had written the code expecting them to use symbols in the root
    namespace.

    The analyzer has special-case handling of many functions by name.
    This patch generalizes such handling to also match against functions
    in "std::" for all of the cases I found in the testsuite (via manual
    inspection of the preprocessed test cases against Solaris headers).
    This fixes cases where the analyzer was failing to "know about" the
    behavior of such functions.

    Other such failures are due to "std::" prefixes appearing in names of
    functions in the output, leading to mismatches against expected output.
    The patch adds regexes to some cases, and moves some other cases back
    from c-c++-common to gcc.dg where the dg-multiline syntax isn't
    expressive enough.

    Various "fd-*.c" failures relate to Solaris's socket-handling functions
    not being marked with "noexcept", where due to PR analyzer/97111 we
    mishandle the exception-handling edges in the CFG, leading to leak
    false positives.  The patch works around this by adding -fno-exceptions
    to these cases, pending a proper fix for PR analyzer/97111.

    gcc/analyzer/ChangeLog:
            PR analyzer/111475
            * analyzer.cc (is_special_named_call_p): Add "look_in_std" param.
            (is_std_function_p): Make non-static.
            * analyzer.h (is_special_named_call_p): Add optional "look_in_std"
            param.
            (is_std_function_p): New decl.
            * engine.cc (stmt_requires_new_enode_p): Look for both "signal"
            and "std::signal".
            * kf.cc (register_known_functions): Add various "std::" copies
            of the known functions.
            * known-function-manager.cc
            (known_function_manager::~known_function_manager): Clean up
            m_std_ns_map_id_to_kf.
            (known_function_manager::add_std_ns): New.
            (known_function_manager::get_match): Also look for known "std::"
            functions.
            (known_function_manager::get_by_identifier_in_std_ns): New.
            * known-function-manager.h
            (known_function_manager::add_std_ns): New decl.
            (known_function_manager::get_by_identifier_in_std_ns): New decl.
            (known_function_manager::m_std_ns_map_id_to_kf): New field.
            * sm-file.cc (register_known_file_functions): Add various "std::"
            copies of the known functions.
            * sm-malloc.cc (malloc_state_machine::on_stmt): Handle
            "std::realloc".
            * sm-signal.cc (signal_unsafe_p): Consider "std::" copies of the
            functions as also being async-signal-unsafe.
            (signal_state_machine::on_stmt): Consider "std::signal".

    gcc/testsuite/ChangeLog:
            PR analyzer/111475
            * c-c++-common/analyzer/fd-glibc-byte-stream-socket.c: Add
            -fno-exceptions for now.
            * c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c: Likewise.
            * c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c: Rename
to...
            * c-c++-common/analyzer/fd-manpage-getaddrinfo-server.c: ...this,
and
            add -fno-exceptions for now.
            * c-c++-common/analyzer/fd-socket-meaning.c: Add -fno-exceptions
            for now.
            * c-c++-common/analyzer/fd-symbolic-socket.c: Likewise.
            * c-c++-common/analyzer/flexible-array-member-1.c: Use regexp to
            handle C vs C++ differences in spelling of function name, which
            could have a "std::" prefix on some targets.
            * c-c++-common/analyzer/pr106539.c: Likewise.
            * c-c++-common/analyzer/malloc-ipa-8-unchecked.c: Move back to...
            * gcc.dg/analyzer/malloc-ipa-8-unchecked.c: ...here, dropping
            attempt to generalize output for C vs C++.
            * c-c++-common/analyzer/signal-4a.c: Move back to...
            * gcc.dg/analyzer/signal-4a.c: ...here, dropping attempt to
            generalize output for C vs C++.
            * c-c++-common/analyzer/signal-4b.c: Move back to...
            * gcc.dg/analyzer/signal-4b.c: ...here, dropping attempt to
            generalize output for C vs C++.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

[Bug analyzer/111475] [14 regression] Many C++ analyzer tests FAIL

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |14.2
            Summary|[14/15 regression] Many C++ |[14 regression] Many C++
                   |analyzer tests FAIL         |analyzer tests FAIL

--- Comment #14 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Testing the above patch on sparc-sun-solaris2.11 (cfarm216) shows this
improvement to
the results of 'gmake check-g++ RUNTESTFLAGS="analyzer.exp=*"':

 # of expected passes          11395 -> 12043
 # of unexpected failures        684 ->     0
 # of unexpected successes         4 ->     0
 # of expected failures          443 ->   447

So I believe this is fixed on trunk; waiting until after GCC 14.1 to backport
to gcc 14.