Bug 53549 - [4.7/4.8 Regression] g++ and armadillo 3.2.0, operator() is inaccessible
[4.7/4.8 Regression] g++ and armadillo 3.2.0, operator() is inaccessible
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: c++
4.7.0
: P3 major
: 4.7.2
Assigned To: fabien
: rejects-valid
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-01 10:10 UTC by Christoffer Hirth
Modified: 2012-07-23 05:25 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.6.3
Known to fail: 4.7.1, 4.8.0
Last reconfirmed: 2012-06-12 00:00:00


Attachments
pre-processed source exposing the bug (273.44 KB, application/x-gzip)
2012-06-12 08:59 UTC, Conrad
Details
arma323.ii.gz (273.96 KB, application/x-gzip)
2012-07-10 07:22 UTC, Conrad
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoffer Hirth 2012-06-01 10:10:53 UTC
Compiling my project using armadillo fails with `is inaccessible' when trying to use fixed size vectors, for example `ivec3'.

Armadillo is version 3.2.0 from http://arma.sourceforge.net/

The bug is seen in both gcc 4.7.0 and gcc-snapshot 4.8.20120520, on Arch Linux.
The bug is not present in gcc 4.6.3.


===============
Test program:
[toffyrn@bohr Test]$ cat main.cpp 
#include <armadillo>

int main(int argc, char** argv)
{
    arma::ivec3 jjj;

    return 0;
}

================
Error:
[toffyrn@bohr Test]$ g++ main.cpp -o run  -larmadillo
In file included from /usr/include/armadillo:399:0,
                 from main.cpp:1:
/usr/include/armadillo_bits/Col_bones.hpp: In instantiation of ‘class arma::Col<int>::fixed<3u>’:
main.cpp:5:17:   required from here
/usr/include/armadillo_bits/Col_meat.hpp:512:1: error: ‘const arma::subview_col<eT> arma::Col<eT>::operator()(const arma::span&) const’ is inaccessible
In file included from /usr/include/armadillo:142:0,
                 from main.cpp:1:
/usr/include/armadillo_bits/Col_bones.hpp:113:9: error: within this context
In file included from /usr/include/armadillo:399:0,
                 from main.cpp:1:
/usr/include/armadillo_bits/Col_meat.hpp:500:1: error: ‘arma::subview_col<eT> arma::Col<eT>::operator()(const arma::span&)’ is inaccessible
In file included from /usr/include/armadillo:142:0,
                 from main.cpp:1:
/usr/include/armadillo_bits/Col_bones.hpp:113:9: error: within this context


================
GCC version:
[toffyrn@bohr Test]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120505/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.0 20120505 (prerelease) (GCC)
Comment 1 Jakub Jelinek 2012-06-01 10:30:09 UTC
Please provide preprocessed source, see http://gcc.gnu.org/bugs.html for details.
Comment 2 Christoffer Hirth 2012-06-01 10:39:15 UTC
I'm sorry that I forgot to include this. It is now uploaded to: http://dl.dropbox.com/u/82144428/main.ii
If more details are needed please let me know.
Comment 3 Conrad 2012-06-01 13:27:47 UTC
arma::ivec3 from Armadillo works under gcc 4.4.6 20110731 (Red Hat 4.4.6-3).

This bug might be related to 52470 and 52685:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52470
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52685

However, Christoffer mentioned that arma::ivec3 doesn't work with gcc-snapshot 4.8.20120520, while bug 52685 seems to be resolved as of 2012-03-29.
Comment 4 Conrad 2012-06-12 08:59:54 UTC
Created attachment 27607 [details]
pre-processed source exposing the bug

bug confirmed on Fedora 17, using gcc version 4.7.0 20120507 (Red Hat 4.7.0-5)

attached is "arma.ii.gz", generated using:
g++ -v -save-temps -O2 -o arma arma.cpp


output of g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)
Comment 5 Richard Biener 2012-06-12 09:18:57 UTC
Confirmed.  May be a deliberate change to conform to the C++ standard.
Comment 6 Conrad 2012-06-12 09:42:08 UTC
bug not present when compiling with Clang 3.0

(I've found clang to often have more thorough/readable diagnostics than gcc)

output of clang -v:
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Comment 7 Jonathan Wakely 2012-06-12 10:33:26 UTC
I *think* this is equivalent:

template<typename T>
class M
{
public:
    int operator()(unsigned);
};

template<typename T>
class C : public M<T>
{
public:
    using M<T>::operator();

    int operator()();


    template<int I>
        class F : public C<T>
        {
        public:

            using C<T>::operator();
        };

};

int main()
{
    C<int>::F<2> f;
    f();
}

using.cc: In instantiation of 'class C<int>::F<2>':
using.cc:29:18:   required from here
using.cc:14:9: error: 'int C<T>::operator()()' is inaccessible
     int operator()();
         ^
using.cc:18:15: error: within this context
         class F : public C<T>
               ^

There's only one "inaccesible" error because ther's only one operator() overload in the reduced example, ading a const overload (as in the original) gives two "inaccessible" errors.

This looks like another "using" issue, CC'ing Fabien.

N.B. Clang++ accepts the example above, but Comeau online rejects this because C<T>::F uses C<T> before it is complete.  I think Comeau is correct.

Moving the definition of F to a point when C<T> is complete is acepted by Comeau and Clang and older G++ versions but gives a different error with G++ trunk:

template<typename T>
class M
{
public:
    int operator()(unsigned);
};

template<typename T>
class C : public M<T>
{
public:
    using M<T>::operator();

    int operator()();

    template<int I> class F;

};

template<typename T>
template<int I>
    class C<T>::F : public C<T>
    {
    public:

        using C<T>::operator();
    };

int main()
{
    C<int>::F<2> f;
    f();
}

using.cc:26:30: error: no members matching 'C<T>::operator()' in 'class C<T>'
         using C<T>::operator();
                              ^
Comment 8 Jonathan Wakely 2012-06-12 10:39:20 UTC
Further reduced, a single example showing both errors:

template<typename T>
struct C
{
    int operator()();

    template<int I>
        struct F : C
        {
            using C<T>::operator();
        };
};

template<typename T>
struct C2
{
    int operator()();

    template<int> struct F2;
};


template<typename T>
template<int I>
    struct C2<T>::F2 : C2<T>
    {
        using C2<T>::operator();
    };

C<int>::F<2> f1;

using.cc:26:31: error: no members matching 'C2<T>::operator()' in 'struct C2<T>'
         using C2<T>::operator();
                               ^
using.cc: In instantiation of 'struct C<int>::F<2>':
using.cc:29:14:   required from here
using.cc:4:9: error: 'int C<T>::operator()()' is inaccessible
     int operator()();
         ^
using.cc:7:16: error: within this context
         struct F : C
                ^
Comment 9 Jakub Jelinek 2012-06-12 12:17:37 UTC
This started to be rejected with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182711
Comment 10 Conrad 2012-07-10 07:22:00 UTC
Created attachment 27769 [details]
arma323.ii.gz

Retested with gcc 4.7.1 and Armadillo 3.2.3 (latest upstream version).

This time a related but different bug in GCC is exposed.
arma323.ii.gz is the attached pre-processed source.

Code compiles fine on gcc 4.4.6 and clang 3.0.

/usr/local/bin/g++ arma323.cpp -o arma323 -O2 -Wall -pedantic

In file included from /usr/include/armadillo:141:0,
                 from arma323.cpp:2:
/usr/include/armadillo_bits/Mat_bones.hpp:545:26: error: no members matching ‘arma::Mat<eT>::operator=’ in ‘class arma::Mat<eT>’
/usr/include/armadillo_bits/Mat_bones.hpp:546:27: error: no members matching ‘arma::Mat<eT>::operator()’ in ‘class arma::Mat<eT>’
In file included from /usr/include/armadillo:142:0,
                 from arma323.cpp:2:
/usr/include/armadillo_bits/Col_bones.hpp:175:27: error: no members matching ‘arma::Col<eT>::operator()’ in ‘class arma::Col<eT>’
In file included from /usr/include/armadillo:143:0,
                 from arma323.cpp:2:
/usr/include/armadillo_bits/Row_bones.hpp:173:27: error: no members matching ‘arma::Row<eT>::operator()’ in ‘class arma::Row<eT>’


GCC 4.7.1 was compiled directly from sources, using GCC 4.7.0 on a Fedora 17 machine.

/usr/local/bin/g++ -v

Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.7.1 (GCC)
Comment 11 Jason Merrill 2012-07-17 18:09:07 UTC
Author: jason
Date: Tue Jul 17 18:08:59 2012
New Revision: 189582

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189582
Log:
	PR c++/53549
	* parser.c (cp_parser_class_head): Call xref_basetypes here.
	(cp_parser_class_specifier_1): Not here.
	* pt.c (tsubst_decl) [USING_DECL]: Check uses_template_parms
	as well as DECL_DEPENDENT_P.

Added:
    trunk/gcc/testsuite/g++.dg/template/current-inst1.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/parse/crash35.C
Comment 12 Jason Merrill 2012-07-17 19:27:55 UTC
Author: jason
Date: Tue Jul 17 19:27:51 2012
New Revision: 189585

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189585
Log:
	PR c++/53549
	* parser.c (cp_parser_class_head): Call xref_basetypes here.
	(cp_parser_class_specifier_1): Not here.
	* pt.c (tsubst_decl) [USING_DECL]: Check uses_template_parms
	as well as DECL_DEPENDENT_P.

Added:
    branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/current-inst1.C
Modified:
    branches/gcc-4_7-branch/gcc/cp/ChangeLog
    branches/gcc-4_7-branch/gcc/cp/parser.c
    branches/gcc-4_7-branch/gcc/cp/pt.c
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_7-branch/gcc/testsuite/g++.dg/parse/crash35.C
Comment 13 Jason Merrill 2012-07-17 19:28:40 UTC
Fixed.
Comment 14 Conrad 2012-07-23 05:25:29 UTC
(In reply to comment #13)
> Fixed.

Thanks!