[Bug c++/65221] New: typedef-name identifier not resolved in static member instantiation

[Bug c++/65221] New: typedef-name identifier not resolved in static member instantiation

[pit at shgn dot de]

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

            Bug ID: 65221
           Summary: typedef-name identifier not resolved in static member
                    instantiation
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pit at shgn dot de

Consider the following minimal example:

template< typename A >
struct X
{
  using this_type = X<A>;
//  typedef X<A> this_type;
  static this_type inst;
};

template< typename A >
X<A> X<A>::inst;

g++ 4.9.1 (Debian 4.9.1-19) produces the following error:

$ g++ --std=c++11 -c test.cpp

test.cpp:10:12: error: conflicting declaration ‘X<A> X<A>::inst’
 X<A> X<A>::inst;
            ^
test.cpp:6:20: note: previous declaration as ‘X<A>::this_type X<A>::inst’
   static this_type inst;
                    ^
test.cpp:10:12: error: declaration of ‘X<A>::this_type X<A>::inst’
outside of class is not definition [-fpermissive]
 X<A> X<A>::inst;

I expected the compiler to resolve the typedef-name from the
alias-declaration when instantiating the static member.  If we
use this_type instead of the type directly:

template< typename A >
const typename X<A>::this_type X<A>::inst;

the code compiles again. I assume that gcc is unable to map X<A> to the
alias-declaration this_type.  Commenting out the alias declaration and
using the typedef line solves the problem.  The standard however states
in §7.1.3 (2):

A typedef-name can also be introduced by an alias-declaration. The
identifier following the using keyword becomes a typedef-name and the
optional attribute-specifier-seq following the identifier appertains to
that typedef-name. It has the same semantics as if it were introduced by
the typedef specifier. In particular, it does not define a new type and
it shall not appear in the type-id.
>From gcc-bugs-return-478585-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 26 12:39:39 2015
Return-Path: <gcc-bugs-return-478585-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 109408 invoked by alias); 26 Feb 2015 12:39:39 -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 109135 invoked by uid 48); 26 Feb 2015 12:39:35 -0000
From: "alalaw01 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64997] [AArch64] Illegal EON on SIMD registers
Date: Thu, 26 Feb 2015 13:37: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: alalaw01 at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: alalaw01 at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-64997-4-st4Tkp48tT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64997-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64997-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-02/txt/msg02917.txt.bz2
Content-length: 403

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

alalaw01 at gcc dot gnu.org changed:

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

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Fixed r220969

[Bug c++/65221] typedef-name identifier not resolved in static member instantiation

[gcc-bugzilla at mail dot shgn.de]

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

--- Comment #1 from Philipp Ittershagen <gcc-bugzilla at mail dot shgn.de> ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-19'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-19)

[Bug c++/65221] typedef-name identifier not resolved in static member instantiation

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Even doing this:
> template< typename A >
> struct X
> {
>   using this_type = X<A>;
> //  typedef X<A> this_type;
>   static this_type inst;
> };
> 
> template< typename A >
> typename X<A>::thistype X<A>::inst;
There is a typo here, it should have been this_type and that one always worked.


Also the original test in comment #0 seems to work in GCC 7+.

[Bug c++/65221] typedef-name identifier not resolved in static member instantiation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |7.0
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=69481
             Status|NEW                         |RESOLVED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed for GCC 7, most likely by the patch set that fixed PR 69481.