[Bug c++/61867] gcc can't detect obviously false test

[Bug c++/61867] gcc can't detect obviously false test

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org
           Severity|normal                      |enhancement

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
There are many cases where this may trigger false positives. The mask used in
the assignment or the value used in the comparison may come from a macro
expansion, and be compile-time dependent. Or the comparison may be some kind of
debug/assert check to ensure people don't mess up the assignment.

Does cppcheck document what is actually warned and what is not and how to
work-around the warning in case the code is actually valid?

I am sure cppcheck warns about a lot of things that GCC does not, but the
difficulty lies in getting the corner-cases right and the right level of
warning versus annoying users.
>From gcc-bugs-return-456884-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 21 19:49:16 2014
Return-Path: <gcc-bugs-return-456884-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19860 invoked by alias); 21 Jul 2014 19:49:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19737 invoked by uid 55); 21 Jul 2014 19:49:11 -0000
From: "paul.richard.thomas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
Date: Mon, 21 Jul 2014 19:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paul.richard.thomas at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61831-4-estMFdHSwF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg01475.txt.bz2
Content-length: 2368

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida831

--- Comment #32 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Dear Dominique,

The problem is due to:
              atmp.10.offset = 0;
              {
                integer(kind=8) S.12;

                S.12 = 0;
                while (1)
                  {
                    if (S.12 > 0) goto L.4;
                    {
                      struct string_t D.2386;
                      struct string_t D.2385;

                      D.2385 = (*(struct string_t[1] * restrict)
atmp.7.data)[S.12];
                      D.2386 = new_prt_spec (&D.2385);
                      if (D.2385.chars.data != 0B)
      /* between here  */
                        {
                          __builtin_free ((void *) D.2385.chars.data);
                        }
                      D.2385.chars.data = 0B;
     /* and here */
                      (*(struct string_t[1] * restrict)
atmp.10.data)[S.12] = D.2386;
                    }
                    S.12 = S.12 + 1;
                  }
                L.4:;
              }
              process_configuration (&atmp.10);
              if ((struct string_t[1] * restrict) atmp.10.data != 0B)

I cannot see yet, where it comes in nor when it was introduced.

Paul

On 21 July 2014 12:51, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?ida831
>
> --- Comment #31 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Further reduced test
>
> program main
>   implicit none
>
>   type :: string_t
>      character(LEN=1), dimension(:), allocatable :: chars
>   end type string_t
>
>   type(string_t) :: prt_in, tmp(1)
>   integer :: i
>   prt_in = string_t(["W"])
>   do i = 1, 16
>      print *, i
>      tmp = new_prt_spec ([prt_in])
>   end do
>
> contains
>
>   elemental function new_prt_spec (name) result (prt_spec)
>     type(string_t), intent(in) :: name
>     type(string_t) :: prt_spec
>   end function new_prt_spec
>
> end program main
>
>> However, nevertheless you would want to understand why the elemental
>> function causes a malloc crash for dim 1 arrays and works for scalars
>> and dim > 1 arrays as input.
>
> The faulty block is not used for scalars.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/61867] gcc can't detect obviously false test

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> I'm pretty sure gcc does detect it and optimizes appropriately, it just
> doesn't warn.

I've checked the output from using -S and I agree.
All the code to do the detection & reduction seems to be in place.

I think that all that needs to happen is a warning is produced
where either the detection or reduction takes place.

As ever, users are free to ignore warnings. egrep -v is
useful, I find.

[Bug c++/61867] gcc can't detect obviously false test

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Binderman from comment #3)
> I think that all that needs to happen is a warning is produced
> where either the detection or reduction takes place.

There is no single place, it's a result of constant propagation and a whole
range of optimisations cooperating. Those optimisations are a good thing, you
don't want to spit out a warning every time the compiler decides it can remove
part of the code, you'd end up with either hundreds of warnings for correct
code or disabling all optimisations.

> As ever, users are free to ignore warnings. egrep -v is
> useful, I find.

egrep is useless for ignoring warnings. It might help on the command line, but
not if you run the compiler from an editor or IDE, or with -Werror etc.

Just because you don't mind ignoring warnings doesn't mean it is appropriate
for GCC to start spitting out poor quality warnings.

[Bug c++/61867] gcc can't detect obviously false test

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Indeed we don't want to warn here.  The knowledge is spread across two
different
statements and that's already too far for this kind of thing.

Remember we just "weakened" the transposed memset arg warning to not warn
about

n = 0;
memset (p, 'x', n);

but only about

memset (p, 'x', 0);