[Bug c++/63658] New: [4.8/4.9 Regression] Using class reference as template parameter causes compilation to fail

["patrick.riphagen at xsens dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 63658
           Summary: [4.8/4.9 Regression] Using class reference as template
                    parameter causes compilation to fail
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: patrick.riphagen at xsens dot com

Created attachment 33818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33818&action=edit
Source code containing the bug

We have a template class which is based on a descriptor class.
The template class is specialized later on.

I have attached a stripped version of the problematic code.

Using gcc 4.7 and 4.8 we did not have a problem compiling this code.
Using gcc 4.9.1 (gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6) ) this code does
not compile anymore.

The error is:

main.cpp:15:17: error: prototype for ‘void foo<D>::size() [with Descriptor& D =
(* & g_descriptor)]’ does not match any in class ‘foo<(* & g_descriptor)>’
 template<> void foo<g_descriptor>::size()
                 ^
main.cpp:11:7: error: candidate is: void foo<D>::size() [with Descriptor& D =
(* & g_descriptor)]
  void size ();

It looks like the prototype for and candidate look exactly the same, however
compilation still fails
>From gcc-bugs-return-465060-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 27 15:20:15 2014
Return-Path: <gcc-bugs-return-465060-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27654 invoked by alias); 27 Oct 2014 15:20:15 -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 27573 invoked by uid 48); 27 Oct 2014 15:20:11 -0000
From: "wdijkstr at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
Date: Mon, 27 Oct 2014 15:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wdijkstr at arm dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ramana at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61915-4-NlwHCVaeCI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61915-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61915-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-10/txt/msg02081.txt.bz2
Content-length: 2200

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

--- Comment #18 from Wilco <wdijkstr at arm dot com> ---
(In reply to Andrew Pinski from comment #17)
> (In reply to Wilco from comment #16)
> > (In reply to Andrew Pinski from comment #13)
> > > (In reply to Wilco from comment #9)
> > > > I committed a workaround
> > > > (http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00362.html) by increasing the
> > > > int<->fp move cost. Can you try this and check the issue has indeed gone?
> > > > You need -mcpu=cortex-a57.
> > >
> > > Note when I submitted ThunderX support I used a base of 2 instead of a base
> > > of 1 due to 2 being the default and all values are relative to that.  This
> > > is mentioned in https://gcc.gnu.org/onlinedocs/gccint/Costs.html .  In fact
> > > a value of 2 means reload will not look at the constraints of a move
> > > instruction.
> > >
> > > So I think the cortex* cpus should also re-base these values based on 2
> > > being gpr-to-gpr value.
> >
> > You mean only use multiples of 2? That's interesting as I've not seen that
> > done elsewhere. Are these costs in any way related to real issue and latency
> > cycles? Most targets have complex tables with all the exact latencies for
> > every little uarch detail, but from what I've seen in the allocator these
> > costs have almost no meaning.
>
> Not always multiple of 2 though in the case of ThunderX they are multiple of
> twos.  The costs are not really directly related to the latency cost but it
> is relative to one another.  So I could have used 2, 3, 4 (meaning latency
> of 1, 2, 3) instead.  I used the factor of 2 instead of 1 for ThunderX
> because 2 + 3 != 4 but rather 5.

OK.

> > So did you find that setting the FP move cost so low actually works alright
> > on ThunderX? I'd like to figure out a setting for the generic target that
> > works out well across all AArch64 implementations.
>
> Yes it seems to at least on the things we have benchmarked but we have not
> done much big benchmarks like SPEC yet.

Well in one testcase I'm seeing 11 str and 26 ldr spills on a53/a57 but 407
fmoves on thunderx. I don't see how that could be a good tradeoff unless fmov
has negative latency...