[Bug c++/61080] New: Spurious no return statement warning with deleted operators

[Bug c++/61080] New: Spurious no return statement warning with deleted operators

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

            Bug ID: 61080
           Summary: Spurious no return statement warning with deleted
                    operators
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jamborm at gcc dot gnu.org
                CC: paolo.carlini at oracle dot com

Since r210043 I'm getting the following warning which I believe is spurious:

$ ~/gcc/small/inst/bin/g++ -Wall -Werror=return-type  -fpermissive -fno-rtti
-fno-exceptions -fno-math-errno -std=gnu++0x 2.C -S

2.C: In instantiation of ‘WeakMapPtr<K, V>& WeakMapPtr<K, V>::operator=(const
WeakMapPtr<K, V>&) [with K = JSObject*; V = JSObject*]’:
2.C:32:16:   required from here
2.C:16:17: error: no return statement in function returning non-void
[-Werror=return-type]
     WeakMapPtr &operator=(const WeakMapPtr &wmp) = delete;
                 ^
cc1plus: some warnings being treated as errors

$ cat 2.C
struct AAA
{
  int a1, a2, a3;
  void *p;
};

template <typename K, typename V>
class WeakMapPtr
{
  public:
    WeakMapPtr() : ptr(nullptr) {};
    bool init(AAA *cx);
  private:
    void *ptr;
    WeakMapPtr(const WeakMapPtr &wmp) = delete;
    WeakMapPtr &operator=(const WeakMapPtr &wmp) = delete;
};

template <typename K, typename V>
bool WeakMapPtr<K, V>::init(AAA *cx)
{
    ptr = cx->p;
    return true;
}

struct JSObject
{
  int blah;
  float meh;
};

template class WeakMapPtr<JSObject*, JSObject*>;
>From gcc-bugs-return-450699-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 06 18:00:39 2014
Return-Path: <gcc-bugs-return-450699-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29451 invoked by alias); 6 May 2014 18:00:38 -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 29432 invoked by uid 48); 6 May 2014 18:00:35 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/61075] parallel std::accumulate reduct type cannot be different than the iterated type
Date: Tue, 06 May 2014 18:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
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: cf_gcchost
Message-ID: <bug-61075-4-ufp7gxyhQm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61075-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61075-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-05/txt/msg00391.txt.bz2
Content-length: 1479

http://gcc.gnu.org/bugzilla/show_bug.cgi?ida075

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|Linux  3.13.5-gentoo #10    |
                   |SMP Fri Apr 25 16:12:35     |
                   |CEST 2014 x86_64 Intel(R)   |
                   |Xeon(R) CPU W3690 @ 3.47GHz |
                   |GenuineIntel GNU/Linux      |

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm not sure if this is easily fixable. When running in parallel we split the
range into N sub-ranges, accumulate over each sub-range, then accumulate the
results. This means that we need an "init" value to start accumulating each
sub-range, which we get by dereferencing the first iterator in the sub-range.

Therefore the parallal accumulate has an additional requirement not present on
the serial accumulate: is_convertible<iterator_traits<Iter>::value_type, T>

(It also implicitly assumes that the functor is associative.)

It might be possible to make it work if we relax the specification, requiring
the functor to be commutative and saying it is unspecified whether we call
binary_op(init, *first) or binary_op(*first, init), but then the algorithm
isn't really std::accumulate (it becomes more like the
std::experimental::reduce algorithm from the
http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3850.pdf draft)

[Bug c++/61080] Spurious no return statement warning with deleted operators

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

--- Comment #1 from Martin Jambor <jamborm at gcc dot gnu.org> ---
So for now I ended up with the following bit in my tree (it's easier
to add this than to fight Mozilla build system not to add Werrors).
Just checking DECL_DELETED_FN when emitting the error is not enough
because later on a similar warning in middle end tree-cfg.c is given
(control reaches end of non-void function).


diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index ffaff5c..56d0226 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13992,6 +13992,9 @@ finish_function (int flags)
   if (!processing_template_decl)
     save_function_data (fndecl);

+  if (DECL_DELETED_FN (fndecl))
+    TREE_NO_WARNING (fndecl) = 1;
+
   /* Complain if there's just no return statement.  */
   if (warn_return_type
       && !VOID_TYPE_P (TREE_TYPE (fntype))

[Bug c++/61080] Spurious no return statement warning with deleted operators

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> ---
I think it's because that change of mine amounts to explicitly saying that a
deleted function is anyway a defined function but with an empty body (what
else?) thus no return statement. I briefly wondered whether that could give
problems, possibly for unused arguments too. So, a possible approach would be
returning earlier from that front-end function which I changed (eg, see my
initial proposal for a draft, which you could probably try) or we could try to
cope with the fallbacks as you already tried... Maybe Jason could provide some
initial guidance?

[Bug c++/61080] Spurious no return statement warning with deleted operators

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
By the way your fix makes perfect sense to me, I would suggest adding a
comment, testing it and sending it to the mailing list with Jason in CC.

[Bug c++/61080] Spurious no return statement warning with deleted operators

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
We shouldn't be trying to generate the body of a deleted function.

[Bug c++/61080] Spurious no return statement warning with deleted operators

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thanks. Thus should we go back to the pre-r210043 behavior and somehow handle
the case in instantiate_decl under the early:

  if (/* If there is no definition, we cannot instantiate the
     template.  */
      ! pattern_defined
      /* If it's OK to postpone instantiation, do so.  */
      || defer_ok
      /* If this is a static data member that will be defined
     elsewhere, we don't want to instantiate the entire data
     member, but we do want to instantiate the initializer so that
     we can substitute that elsewhere.  */
      || (external_p && VAR_P (d)))
    {
      /* .... */

which does very few checks and then soon does goto out? The problem with
setting pattern_defined is that this entire early handling is skipped, not just
its inner permerror for explicit instantiations when no definition is
available. And by now we now that early handling otherwise works pretty well...

[Bug c++/61080] Spurious no return statement warning with deleted operators

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> ---
This (rather heavy handed?) tweak also appears to work (with it these deleted
functions can keep flowing through instantiate_decl):

Index: pt.c
===================================================================
--- pt.c    (revision 210126)
+++ pt.c    (working copy)
@@ -19888,7 +19888,7 @@ instantiate_decl (tree d, int defer_ok,
       if (DECL_OMP_DECLARE_REDUCTION_P (code_pattern)
       && TREE_CODE (DECL_CONTEXT (code_pattern)) == FUNCTION_DECL)
     DECL_SAVED_TREE (d) = pop_stmt_list (block);
-      else
+      else if (!DECL_DELETED_FN (code_pattern))
     {
       d = finish_function (0);
       expand_or_defer_fn (d);

[Bug c++/61080] Spurious no return statement warning with deleted operators

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #5)
> Thanks. Thus should we go back to the pre-r210043 behavior and somehow
> handle the case in instantiate_decl under the early:
> 
>   if (/* If there is no definition, we cannot instantiate the
> 	 template.  */
>       ! pattern_defined
>       /* If it's OK to postpone instantiation, do so.  */
>       || defer_ok
>       /* If this is a static data member that will be defined
> 	 elsewhere, we don't want to instantiate the entire data
> 	 member, but we do want to instantiate the initializer so that
> 	 we can substitute that elsewhere.  */
>       || (external_p && VAR_P (d)))
>     {
>       /* .... */
> 
> which does very few checks and then soon does goto out?

Yes, we probably want to add a deleted check to this condition.
>From gcc-bugs-return-450739-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 07 01:14:10 2014
Return-Path: <gcc-bugs-return-450739-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7867 invoked by alias); 7 May 2014 01:14:09 -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 7792 invoked by uid 48); 7 May 2014 01:14:04 -0000
From: "chrismonkie at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61089] New: Misleading error message regarding inability to convert pointers
Date: Wed, 07 May 2014 01:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chrismonkie at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61089-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg00431.txt.bz2
Content-length: 1847

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61089

            Bug ID: 61089
           Summary: Misleading error message regarding inability to
                    convert pointers
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chrismonkie at gmail dot com

Problem:
Compiling the code below yields
t.cpp: In function ‘int main(int, char**)’:
t.cpp:14:14: error: cannot convert ‘boost::shared_ptr<derived>::element_type*
{aka derived*}’ to ‘base*’ for argument ‘1’ to ‘void func(base*)’

Derived and base are just forward declared so it makes sense that the compiler
won't convert one to the other. The issue is that the error message is
misleading. Normally if you forward declare and forget to include the header
and try to call something the compiler gives you a nice error message which
reminds you to include the appropriate header.
t.cpp:9:3: error: invalid use of incomplete type ‘struct base’
t.cpp:3:7: error: forward declaration of ‘struct base’

This seems like the same thing should happen. The compiler knows the types are
forward declared and needs to call an implicit conversion function so it needs
the complete types.


Version:
arm-linux-gnueabihf-gcc (crosstool-NG - Ambarella Linaro Multilib GCC [CortexA9
& ARMv6k] 2013.09) 4.8.2 20130902 (prerelease)

Commandline:
g++ -I PATH_TO_BOOST t.cpp

Code:
#include <boost/shared_ptr.hpp>

class base; // {};

class derived; // : public base {};

void func(base* p)
{
}

int main(int argc, char** argv)
{
    boost::shared_ptr<derived> p;
    func(p.get());

    return 0;
}
>From gcc-bugs-return-450740-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 07 01:32:04 2014
Return-Path: <gcc-bugs-return-450740-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17521 invoked by alias); 7 May 2014 01:32:03 -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 17471 invoked by uid 48); 7 May 2014 01:31:59 -0000
From: "mkuvyrkov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/61033] Infinite loop in variable tracking
Date: Wed, 07 May 2014 01:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mkuvyrkov at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mkuvyrkov at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc assigned_to
Message-ID: <bug-61033-4-6jrC5ghR8w@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61033-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61033-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-05/txt/msg00432.txt.bz2
Content-length: 588

http://gcc.gnu.org/bugzilla/show_bug.cgi?ida033

Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkuvyrkov at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |mkuvyrkov at gcc dot gnu.org

--- Comment #2 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> ---
Assigned to myself as Michael does not have a GCC developer account yet.
Michael is the one working on this bug.

[Bug c++/61080] [4.10 Regression] Spurious no return statement warning with deleted operators

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-05-07
                 CC|paolo.carlini at oracle dot com    |
           Assignee|unassigned at gcc dot gnu.org      |paolo.carlini at oracle dot com
   Target Milestone|---                         |4.10.0
            Summary|Spurious no return          |[4.10 Regression] Spurious
                   |statement warning with      |no return statement warning
                   |deleted operators           |with deleted operators
     Ever confirmed|0                           |1

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Mine.

[Bug c++/61080] [4.10 Regression] Spurious no return statement warning with deleted operators

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

--- Comment #9 from paolo at gcc dot gnu.org <paolo at gcc dot gnu.org> ---
Author: paolo
Date: Wed May  7 14:30:23 2014
New Revision: 210161

URL: http://gcc.gnu.org/viewcvs?rev=210161&root=gcc&view=rev
Log:
/cp
2014-05-07  Paolo Carlini  <paolo.carlini@oracle.com>

    PR c++/61080
    * pt.c (instantiate_decl): Avoid generating the body of a
    deleted function.

/testsuite
2014-05-07  Paolo Carlini  <paolo.carlini@oracle.com>

    PR c++/61080
    * g++.dg/cpp0x/deleted7.C: New.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/deleted7.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/61080] [4.10 Regression] Spurious no return statement warning with deleted operators

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61080

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Fixed.