[Bug c++/60775] New: Instantiates unused class template member function and therefor reports error

["gunther.laure at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6164 bytes --]

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

            Bug ID: 60775
           Summary: Instantiates unused class template member function and
                    therefor reports error
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gunther.laure at gmail dot com

g++ 4.8.2 reports following error when compiling the example code:

abstract_class.cpp:11:13: error: cannot allocate an object of abstract type
‘IfSomethingIterator’
     Derived operator--(int)
             ^
abstract_class.cpp:17:7: note:   because the following virtual functions are
pure within ‘IfSomethingIterator’:
 class IfSomethingIterator : public iterator_facade<IfSomethingIterator>
       ^
abstract_class.cpp:24:18: note:     virtual void
IfSomethingIterator::DoIncrement()
     virtual void DoIncrement() = 0;


The code successfully compiles with:
g++4.6.3
g++4.7.3
clang++ 3.3



/// example start
template <class Derived>
class iterator_facade
{
public:
    Derived& operator++()
    {
    }
    Derived operator--(int)
    {
    }
};

class IfSomethingIterator : public iterator_facade<IfSomethingIterator>
{
public:
    virtual ~IfSomethingIterator()
    {}
protected:
    virtual void DoIncrement() = 0;
};
/// example end
>From gcc-bugs-return-448442-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 07 11:20:50 2014
Return-Path: <gcc-bugs-return-448442-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22646 invoked by alias); 7 Apr 2014 11:20: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 22596 invoked by uid 48); 7 Apr 2014 11:20:44 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60766] [4.7/4.8/4.9 Regression] Wrong optimization with -O2
Date: Mon, 07 Apr 2014 11:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: major
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-60766-4-JMxKPt8ot3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60766-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60766-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-04/txt/msg00462.txt.bz2
Content-length: 2804

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`766

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 32556
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2556&actioníit
patch

The issue is that tree-ssa-loop-ivopts.c:cand_value_at converts niter
((unsigned int) n_3 * 2863311531 + 4294967294) to 'int' via

static void
cand_value_at (struct loop *loop, struct iv_cand *cand, gimple at, tree niter,
               aff_tree *val)
{
  aff_tree step, delta, nit;
  struct iv *iv = cand->iv;
  tree type = TREE_TYPE (iv->base);
  tree steptype = type;
  if (POINTER_TYPE_P (type))
    steptype = sizetype;

  tree_to_aff_combination (iv->step, steptype, &step);
  tree_to_aff_combination (niter, TREE_TYPE (niter), &nit);
  aff_combination_convert (&nit, steptype);
^^^

which just does

  comb->type = type;
  if (comb->rest && !POINTER_TYPE_P (type))
    comb->rest = fold_convert (type, comb->rest);

thus re-interprets everything as signed.  The whole aff_combination_convert
function looks suspicious ... but at this stage the easiest thing to do is
to avoid this 2nd call to this function (the other always converts to an
unsigned type).

Unfortunately doing that:

Index: gcc/tree-ssa-loop-ivopts.c
==================================================================--- gcc/tree-ssa-loop-ivopts.c  (revision 209181)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -4238,8 +4238,7 @@ cand_value_at (struct loop *loop, struct
     steptype = sizetype;

   tree_to_aff_combination (iv->step, steptype, &step);
-  tree_to_aff_combination (niter, TREE_TYPE (niter), &nit);
-  aff_combination_convert (&nit, steptype);
+  tree_to_aff_combination (fold_convert (steptype, niter), steptype, &nit);
   aff_combination_mult (&nit, &step, &delta);
   if (stmt_after_increment (loop, cand, at))
     aff_combination_add (&delta, &step);

reveals the other suspicious

void
tree_to_aff_combination (tree expr, tree type, aff_tree *comb)
{
  aff_tree tmp;
  enum tree_code code;
  tree cst, core, toffset;
  HOST_WIDE_INT bitpos, bitsize;
  enum machine_mode mode;
  int unsignedp, volatilep;

  STRIP_NOPS (expr);

which just re-introduces the exact same affine combination.

This is kind-of a mess.  Either the internal affine workings is
modulo two arithmetic and thus it doesn't need to care - but then
it needs to use unsigned arithmetic only at affine-to-tree time.
Or it depends on the sign of the affine combination but then it
has to be more careful.

IIRC it is the first, thus affine-to-tree is wrong in returning
signed arithmetic and keeping a "type" for the affine combination
doesn't make much sense (similar issue for pointer arithmetic btw,
where we choose a random "base").

But it's all kind of a mess.

Working, somewhat localized patch attached.