[Bug fortran/67982] New: Incorrect -Wunused-function warning

[Bug fortran/67982] New: Incorrect -Wunused-function warning

[Joost.VandeVondele at mat dot ethz.ch]

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

            Bug ID: 67982
           Summary: Incorrect -Wunused-function warning
           Product: gcc
           Version: 5.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The following code illustrates an incorrect -Wunused-function warning:

> cat test.f90
MODULE base
  INTERFACE 
    SUBROUTINE bar_int()
    END SUBROUTINE 
  END INTERFACE
  PUBLIC hook
  PRIVATE 
  PROCEDURE(bar_int), POINTER :: hook=>NULL()
END MODULE base

MODULE foo
  USE base, ONLY: hook  
  PUBLIC init
  PRIVATE 
CONTAINS
  SUBROUTINE init()
     hook=>bar
  END SUBROUTINE init
  SUBROUTINE bar()
     WRITE(6,*) "In bar"
  END SUBROUTINE 
END MODULE

USE foo, ONLY: init
USE base, ONLY: hook
CALL init()
CALL hook()
END

> gfortran -Wunused-function test.f90
test.f90:19:0:

   SUBROUTINE bar()
 ^
Warning: ‘bar’ defined but not used [-Wunused-function]

> ./a.out
 In bar
>From gcc-bugs-return-499674-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 16 05:09:49 2015
Return-Path: <gcc-bugs-return-499674-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 78565 invoked by alias); 16 Oct 2015 05:09:49 -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 78495 invoked by uid 48); 16 Oct 2015 05:09:45 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/67600] [5/6 Regression] Segfault when assigning only one char to ostreambuf_iterator<char> compiled with -O2 or -O3
Date: Fri, 16 Oct 2015 05:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67600-4-kDax2Y7SAp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67600-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67600-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: 2015-10/txt/msg01229.txt.bz2
Content-length: 1843

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, what it does is:
Determining dynamic type for call: _50 = OBJ_TYPE_REF(_47;(struct
basic_streambuf)&ostr._M_stringbuf->13) (&ostr._M_stringbuf, 88);
  Starting walk at: _46 = MEM[(struct basic_streambuf *)&ostr +
8B]._vptr.basic_streambuf;
  instance pointer: &ostr._M_stringbuf  Outer instance pointer: ostr offset: 0
(bits) vtbl reference: MEM[(struct basic_streambuf *)&ostr +
8B]._vptr.basic_streambuf
  Checking constructor call:
std::__cxx11::basic_ostringstream<char>::basic_ostringstream (&ostr, 16);
  Recording type: struct basic_ostringstream at offset 0
  Determined dynamic type.
  Targets of polymorphic call of type 5:struct basic_streambuf token 13
    Outer type (dynamic):struct basic_ostringstream

Now the code is:

  <bb 2>:
  std::__cxx11::basic_ostringstream<char>::basic_ostringstream (&ostr, 16);
  MEM[(struct  &)&iter] ={v} {CLOBBER};
  MEM[(struct  &)&iter] ={v} {CLOBBER};
  iter._M_sbuf = &ostr._M_stringbuf;
  iter._M_failed = 0;
  _30 = iter._M_failed;
  if (_30 != 0)
    goto <bb 8>;
  else
    goto <bb 3>;

  <bb 3>:
  _32 = iter._M_sbuf;
  _33 = MEM[(char_type * *)_32 + 40B];
  _34 = MEM[(char_type * *)_32 + 48B];
  _35 = _33 < _34;
  _36 = (long int) _35;
  _37 = _36;
  if (_33 < _34)
    goto <bb 4>;
  else
    goto <bb 5>;

  <bb 4>:
  *_33 = 88;
  _38 = MEM[(char_type * *)_32 + 40B];
  _39 = _38 + 1;
  MEM[(char_type * *)_32 + 40B] = _39;
  goto <bb 6>;

  <bb 5>:
  _46 = MEM[(struct basic_streambuf *)_32]._vptr.basic_streambuf;
  _47 = MEM[(int (*__vtbl_ptr_type) () *)_46 + 104B];
  _50 = OBJ_TYPE_REF(_47;(struct basic_streambuf)_32->13) (_32, 88);

so the analysis looks OK to me.

[Bug fortran/67982] Incorrect -Wunused-function warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-10-16
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
AFAICT this has been fixed on trunk (6.0) between revisions r224160
(2015-06-05, warning) and r224647 (2015-06-19, no warning). I did not find any
obvious candidate for the fix; without it the fix cannot be back ported.

[Bug fortran/67982] Incorrect -Wunused-function warning

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat dot ethz
                   |                            |.ch

--- Comment #2 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
Maybe r224201 ? Otherwise this might need bisection.

[Bug fortran/67982] Incorrect -Wunused-function warning

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Maybe r224201 ?

It is

Author: hubicka
Date:   Sun Jun 7 21:30:58 2015 UTC (4 months, 1 week ago)
Changed paths:  13 (showing only 10; show all)
Log Message:    
        * alias.c (get_alias_set): Be ready for TYPE_CANONICAL
        of ptr_type_node to not be ptr_to_node.
        * tree.c (gimple_types_compatible_p): Do not match TREE_CODE of
        TREE_TYPE of pointers.
        * gimple-expr.c (useless_type_conversion): Reorder the check for
        function pointers and TYPE_CANONICAL.
        * lto.c (hash_canonical_type): Do not hash TREE_CODE of TREE_TYPE of
        pointers.
        * gfortran.dg/lto/bind_c-1_0.f90: New testcase.
        * gfortran.dg/lto/bind_c-1_1.c: New testcase.
        * gcc.dg/lto/c-compatible-types_0.c: Rename to ...
        * gcc.dg/lto/c-compatible-types-1_0.c: this one; fix template
        * gcc.dg/lto/c-compatible-types_1.c: Rename to ...
        * gcc.dg/lto/c-compatible-types-1_1.c: this one; harden for
        -fshort-enum.

so I doubt it.

> Otherwise this might need bisection.

Be my guest!

[Bug fortran/67982] Incorrect -Wunused-function warning

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #5 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Dominique d'Humieres from comment #4)
> > Otherwise this might need bisection.
> 
> Note that I cannot do easily the bissection on darwin due to a lot of
> bootstrap failures in the range r224161-r224647. If nobody volunteer to do
> the bisection, I'll close this PR as FIXED on trunk (6.0).

Let's leave it open for a while, it would be good to commit a testcase to trunk
to make sure this doesn't regress. As it seems fixed 'accidentally' this might
be a good idea. I might do this, even though it will take a while (it is a bit
unfortunate that the time overhead of submitting & committing a patch is not
small).