[Bug other/94629] New: 10 issues located by the PVS-studio static analyzer

[Bug other/94629] New: 10 issues located by the PVS-studio static analyzer

[leo at yuriev dot ru]

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

            Bug ID: 94629
           Summary: 10 issues located by the PVS-studio static analyzer
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: leo at yuriev dot ru
  Target Milestone: ---

Today Andrey Karpov published a short article with the latest results of
checking GCC source code using the PVS-Studio static analyzer.

Andrey writes that he received a lot of warnings and presumably a significant
part of them are false-positive.
However, for this article, he chose and showed 10 very suspicious cases.

I am convinced that this is worth a close look.
There are clearly errors that are extremely difficult to notice with an eyes.

https://habr.com/en/company/pvs-studio/blog/497640/

Regards,
Leonid

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmalcolm at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2020-04-17
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Picking those obvious to me at the moment.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 48298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48298&action=edit
parts I am testing

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, the ipa_polymorphic_call_context::set_by_invariant looks possible
wrong-code ...

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:a64468a3034dd8e2d0794a5be84b8da544ffe2c3

commit r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Apr 17 09:19:32 2020 +0200

    fix PVS studio reported bugs

    2020-04-17  Richard Biener  <rguenther@suse.de>

            PR other/94629
            * cgraphclones.c (cgraph_node::create_clone): Remove duplicate
            initialization.
            * dwarf2out.c (dw_val_equal_p): Fix pasto in
            dw_val_class_vms_delta comparison.
            * optabs.c (expand_binop_directly): Fix pasto in commutation
            check.
            * tree-ssa-sccvn.c (vn_reference_lookup_pieces): Fix pasto in
            initialization.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We should for GCC11 discuss if we want to implement some of these checks,
either in -fanalyzer, or as normal GCC warnings.
E.g. the
 foo = something;
 // code that can't affect foo
 foo = somethingelse;
is perhaps something that should be warned as early as possible after getting
into GIMPLE, before inlining because it is quite common that inlines overwrite
something, and in the FEs it is likely too early.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jakub Jelinek from comment #5)
> We should for GCC11 discuss if we want to implement some of these checks,
> either in -fanalyzer, or as normal GCC warnings.
> E.g. the
>  foo = something;
>  // code that can't affect foo
>  foo = somethingelse;
> is perhaps something that should be warned as early as possible after
> getting into GIMPLE, before inlining because it is quite common that inlines
> overwrite something, and in the FEs it is likely too early.

A quick look at recent cppcheck output over the gcc trunk source code
suggests that there are 162 cases of redundant assignment like this.

Some of them might well be false positives.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to David Binderman from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > We should for GCC11 discuss if we want to implement some of these checks,
> > either in -fanalyzer, or as normal GCC warnings.
> > E.g. the
> >  foo = something;
> >  // code that can't affect foo
> >  foo = somethingelse;
> > is perhaps something that should be warned as early as possible after
> > getting into GIMPLE, before inlining because it is quite common that inlines
> > overwrite something, and in the FEs it is likely too early.
> 
> A quick look at recent cppcheck output over the gcc trunk source code
> suggests that there are 162 cases of redundant assignment like this.
> 
> Some of them might well be false positives.

Can you attach a list?  I can seed through them.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 48299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48299&action=edit
sorted list of redundant assignments

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Comment on attachment 48299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48299
sorted list of redundant assignments

  /* If there were any declarations or structure tags in that level,
     or if this level is a function body,
     create a BLOCK to record them for the life of this function.  */
  block = NULL_TREE;
  /* Avoid function body block if possible.  */
  if (functionbody && subblocks && BLOCK_CHAIN (subblocks) == NULL_TREE)
    keep = 0;
  else if (keep == 1 || functionbody)
    block = make_node (BLOCK);
  if (block != NULL_TREE)
    {
      BLOCK_VARS (block) = decls;
      BLOCK_SUBBLOCKS (block) = subblocks;
    }

  /* In each subblock, record that this is its superior.  */
  if (keep >= 0)
    for (link = subblocks; link; link = BLOCK_CHAIN (link))
      BLOCK_SUPERCONTEXT (link) = block;
certainly doesn't look like redundant assignment, yes, the block = NULL_TREE
could be moved into the if, but that is just programming style.
I must say I don't understand why the separate if (block != NULL_TREE) is in
there, perhaps from historic reasons there might have been more cases.
Now it would make much more sense to just do
  else if (keep == 1 || functionbody)
    {
      block = make_node (BLOCK);
      BLOCK_VARS (block) = decls;
      BLOCK_SUBBLOCKS (block) = subblocks;
    }

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ams at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I have a few unimportant tweaks for this in my tree.
Anyway, e.g. in the GCN plugin, I wonder if we don't need:
diff --git a/libgomp/plugin/plugin-gcn.c b/libgomp/plugin/plugin-gcn.c
index dc72c90962c..c733b8bfb18 100644
--- a/libgomp/plugin/plugin-gcn.c
+++ b/libgomp/plugin/plugin-gcn.c
@@ -1508,7 +1508,8 @@ init_hsa_context (void)
     = GOMP_PLUGIN_malloc_cleared (hsa_context.agent_count
                                  * sizeof (struct agent_info));
   status = hsa_fns.hsa_iterate_agents_fn (assign_agent_ids, &agent_index);
-  if (agent_index != hsa_context.agent_count)
+  if (status != HSA_STATUS_SUCCESS
+      || agent_index != hsa_context.agent_count)
     {
       GOMP_PLUGIN_error ("Failed to assign IDs to all GCN agents");
       return false;
@@ -3473,7 +3474,8 @@ GOMP_OFFLOAD_init_device (int n)
   status = hsa_fns.hsa_agent_iterate_regions_fn (agent->id,
                                                 get_kernarg_memory_region,
                                                 &agent->kernarg_region);
-  if (agent->kernarg_region.handle == (uint64_t) -1)
+  if (status != HSA_STATUS_SUCCESS
+      || agent->kernarg_region.handle == (uint64_t) -1)
     {
       GOMP_PLUGIN_error ("Could not find suitable memory region for kernel "
                         "arguments");
@@ -3486,7 +3488,8 @@ GOMP_OFFLOAD_init_device (int n)
   status = hsa_fns.hsa_agent_iterate_regions_fn (agent->id,
                                                 get_data_memory_region,
                                                 &agent->data_region);
-  if (agent->data_region.handle == (uint64_t) -1)
+  if (status != HSA_STATUS_SUCCESS
+      || agent->data_region.handle == (uint64_t) -1)
     {
       GOMP_PLUGIN_error ("Could not find suitable memory region for device "
                         "data");
or if instead we should drop the "status = " for the cases where nothing checks
it. Andrew?

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[ams at gcc dot gnu.org]

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

--- Comment #11 from Andrew Stubbs <ams at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> or if instead we should drop the "status = " for the cases where nothing
> checks it. Andrew?

I think checking the status is probably good practice, even though I don't
think there's an actual bug here.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Andrew Stubbs from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > or if instead we should drop the "status = " for the cases where nothing
> > checks it. Andrew?
> 
> I think checking the status is probably good practice, even though I don't
> think there's an actual bug here.

I have no way to test it, so if you want and can test it (perhaps with other
changes), please take it over, or we throw it away, we don't have to fix all
the warnings, we just should skim through it to find if there aren't any actual
bugs.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2e3897490e0f99b22a2813cfb34d59a1ea71ff68

commit r10-7774-g2e3897490e0f99b22a2813cfb34d59a1ea71ff68
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Apr 17 16:59:57 2020 +0200

    c, c++: Fix two redundantAssignment warnings [PR94629]

    This change fixes two obvious redundant assignments reported by cppcheck:
    trunk.git/gcc/c/c-parser.c:16969:2: style: Variable 'data.clauses' is
reassigned a value before the old one has been used. [redundantAssignment]
    trunk.git/gcc/cp/call.c:5116:9: style: Variable 'arg2' is reassigned a
value before the old one has been used. [redundantAssignment]

    2020-04-17  Jakub Jelinek  <jakub@redhat.com>

            PR other/94629
            * c-parser.c (c_parser_oacc_routine): Remove redundant assignment
            to data.clauses.

            * call.c (build_conditional_expr_1): Remove redundant assignment to
            arg2.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[dcb314 at hotmail dot com]

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

--- Comment #14 from David Binderman <dcb314 at hotmail dot com> ---
There is also this one from cppcheck:

trunk.git/libstdc++-v3/include/debug/formatter.h:302:40: warning: Redundant
assignment of '_M_variant._M_iterator._M_constness' to itself. [selfAssignment]

Source code is

      _M_variant._M_iterator._M_constness =
      _M_variant._M_iterator._M_constness =
        __it._S_constant() ? __const_iterator : __mutable_iterator;

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #15 from Martin Sebor <msebor at gcc dot gnu.org> ---
I agree (unsurprisingly) that adding warnings for some of the problems noted in
the article would be useful, not just for GCC itself but other projects.  I
don't have the impression that uncovering them would benefit from the sort of
interprocedural traversal the analyzer is mainly supposed to be good for. 
Since many fewer projects run the analyzer often enough or ever due to the
costs, implementing these warnings there would make them unavailable to the
majority of users, or delay finding these basic problems when they're the
cheapest to fix: before they are committed into the repository.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:a2c0fa35d0dc8912b0c1a658234221de61e60840

commit r10-7806-ga2c0fa35d0dc8912b0c1a658234221de61e60840
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Sun Apr 19 20:54:38 2020 +0100

    libstdc++: Fix redundant assignment (PR 94629)

    This appears to be a copy&paste error, which cppcheck diagnoses.

            PR other/94629
            * include/debug/formatter.h (_Error_formatter::_Parameter): Fix
            redundant assignment in constructor.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Binderman from comment #14)
> There is also this one from cppcheck:
> 
> trunk.git/libstdc++-v3/include/debug/formatter.h:302:40: warning: Redundant
> assignment of '_M_variant._M_iterator._M_constness' to itself.
> [selfAssignment]
> 
> Source code is
> 
>       _M_variant._M_iterator._M_constness =
>       _M_variant._M_iterator._M_constness =
>         __it._S_constant() ? __const_iterator : __mutable_iterator;

That's now fixed, thanks.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška <marxin at gcc dot gnu.org> ---
The code in ipa_polymorphic_call_context::set_by_invariant seems fishy. It's
there since the beginning: r5-3634-g6f8091fc3ed9d3cfa7a6dee7e9f9a34eb4308b2a.

@Honza: Can you please take a look?

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[leo at yuriev dot ru]

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

--- Comment #19 from Leo Yuriev <leo at yuriev dot ru> ---
(In reply to CVS Commits from comment #4)
> The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:a64468a3034dd8e2d0794a5be84b8da544ffe2c3
> 
> commit r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3
> Author: Richard Biener <rguenther@suse.de>
> Date:   Fri Apr 17 09:19:32 2020 +0200
> 
>     fix PVS studio reported bugs
>     
>     2020-04-17  Richard Biener  <rguenther@suse.de>
[...]
>             * dwarf2out.c (dw_val_equal_p): Fix pasto in
>             dw_val_class_vms_delta comparison.
>             * optabs.c (expand_binop_directly): Fix pasto in commutation
[...]

Seems the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051 should be closed
as fixed.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |frederik at gcc dot gnu.org,
                   |                            |tschwinge at gcc dot gnu.org

--- Comment #20 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Leo Yuriev from comment #0)
> https://habr.com/en/company/pvs-studio/blog/497640/

I've asked Frederik to look into "Fragment N3, Assigning a variable to itself";
<http://mid.mail-archive.com/87zhb6mcoi.fsf@euler.schwinge.homeip.net>.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Frederik Harwath <frederik@gcc.gnu.org>:

https://gcc.gnu.org/g:15256c8a8ac6573d250506c40dbe13082186c2aa

commit r10-7845-g15256c8a8ac6573d250506c40dbe13082186c2aa
Author: Frederik Harwath <frederik@codesourcery.com>
Date:   Tue Apr 21 12:36:14 2020 +0200

    Remove fishy self-assignment in omp-low.c [PR94629]

    The PR noticed that omp-low.c contains a self-assignment in the
    function new_omp_context:

    if (outer_ctx) {
        ...
        ctx->outer_reduction_clauses = ctx->outer_reduction_clauses;

    This is obviously useless.  The original intention might have been
    to copy the field from the outer_ctx to ctx.  Since this is done
    (properly) in the only function where this field is actually used
    (in function scan_omp_for) and the field is being initialized to zero
    during the struct allocation, there is no need to attempt to do
    anything to this field in new_omp_context. Thus this commit
    removes any assignment to the field from new_omp_context.

    2020-04-21  Frederik Harwath  <frederik@codesourcery.com>

            PR other/94629
            * gcc/omp-low.c (new_omp_context): Remove assignments to
            ctx->outer_reduction_clauses and ctx->local_reduction_clauses.

    Reviewed-by: Thomas Schwinge  <thomas@codesourcery.com>

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Stubbs <ams@gcc.gnu.org>:

https://gcc.gnu.org/g:966de09be91c639d66d252c9ae6ab8da5ebfca18

commit r10-7912-g966de09be91c639d66d252c9ae6ab8da5ebfca18
Author: Andrew Stubbs <ams@codesourcery.com>
Date:   Mon Apr 20 15:25:31 2020 +0100

    amdgcn: Check HSA return codes [PR94629]

    Ensure that the returned status values are not ignored.  The old code was
    not broken, but this is both safer and satisfies static analysis.

    2020-04-23  Andrew Stubbs  <ams@codesourcery.com>

            PR other/94629

            libgomp/
            * plugin/plugin-gcn.c (init_hsa_context): Check return value from
            hsa_iterate_agents.
            (GOMP_OFFLOAD_init_device): Check return values from both calls to
            hsa_agent_iterate_regions.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[ams at gcc dot gnu.org]

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

--- Comment #23 from Andrew Stubbs <ams at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Andrew Stubbs from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > or if instead we should drop the "status = " for the cases where nothing
> > > checks it. Andrew?
> > 
> > I think checking the status is probably good practice, even though I don't
> > think there's an actual bug here.
> 
> I have no way to test it, so if you want and can test it (perhaps with other
> changes), please take it over, or we throw it away, we don't have to fix all
> the warnings, we just should skim through it to find if there aren't any
> actual bugs.

I think this is done now. The patch needed to be changed a little because
HSA_STATUS_INFO_BREAK is also a valid return value (meaning that the iterator
exited early).

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[leo at yuriev dot ru]

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

--- Comment #24 from Leo Yuriev <leo at yuriev dot ru> ---
So, seems that all done and this issue should be closed?

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |hubicka at gcc dot gnu.org

--- Comment #25 from Martin Liška <marxin at gcc dot gnu.org> ---
No, there's still the 'ipa_polymorphic_call_context::set_by_invariant' issue
that's waiting for Honza.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #26 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #25)
> No, there's still the 'ipa_polymorphic_call_context::set_by_invariant' issue
> that's waiting for Honza.

Finally fixed with:

https://gcc.gnu.org/g:4f4820964ebffc03249d98239a4ad2b43dd1a486

commit r14-8191-g4f4820964ebffc03249d98239a4ad2b43dd1a486
Author: Jan Hubicka <jh@suse.cz>
Date:   Wed Jan 17 19:16:47 2024 +0100

    Remove accidental hack in ipa_polymorphic_call_context::set_by_invariant

    I managed to commit a hack setting offset to 0 in
    ipa_polymorphic_call_context::set_by_invariant.  This makes it to give up
on multiple
    inheritance, but most likely won't give bad code since the ohter base will
be of
    different type.

    gcc/ChangeLog:

            * ipa-polymorphic-call.cc
(ipa_polymorphic_call_context::set_by_invariant): Remove
            accidental hack reseting offset.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[dcb314 at hotmail dot com]

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

--- Comment #27 from David Binderman <dcb314 at hotmail dot com> ---
The original article checked gcc-10.
gcc-13 is checked in the following article:

https://pvs-studio.com/en/blog/posts/cpp/1067/

I suspect it would be most unwise if any release of gcc after 13 
introduced new bugs that were known to pvs-studio.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[jamborm at gcc dot gnu.org]

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

--- Comment #28 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to David Binderman from comment #27)
> The original article checked gcc-10.
> gcc-13 is checked in the following article:
> 
> https://pvs-studio.com/en/blog/posts/cpp/1067/
> 
> I suspect it would be most unwise if any release of gcc after 13 
> introduced new bugs that were known to pvs-studio.

And is there already a bugzilla bug about these (or should I create one)?
I believe a new one would be better than re-using this one.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[dcb314 at hotmail dot com]

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

--- Comment #29 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Jambor from comment #28)
> And is there already a bugzilla bug about these (or should I create one)?

Done. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528