DESCRIPTION The following code compiles on Intel without issue with gcc-4.1.3 and gcc-4.2, but fails at LINE=29 on cross-compile with ppc_85xx-gcc-4.0: $ cat -n Foo.cc 1 2 #include <tr1/tuple> 3 #include <tr1/unordered_map> 4 #include <vector> 5 #include <string> 6 7 typedef std::vector<int> IntVector; 8 typedef std::tr1::unordered_map<std::string, IntVector, std::tr1::hash<std::string> > VectorMap; 9 10 class Foo 11 { 12 public: 13 Foo(VectorMap& map) : map_(map) {} 14 void insert(std::string s, int value); 15 16 private: 17 VectorMap& map_; 18 }; 19 20 void Foo::insert(std::string s, int value) 21 { 22 bool vector_exists = true; 23 24 VectorMap::iterator i = map_.find(s); 25 if (i == map_.end()) 26 { 27 IntVector v; 28 std::pair<std::string, IntVector> p(s, v); 29 std::tr1::tie(i, vector_exists) = map_.insert(p); 30 } 31 32 if (!vector_exists) 33 { 34 return; 35 } 36 37 (*i).second.push_back(value); 38 } 39 $ ppc_85xx-g++ -v -save-temps -c Foo.cc Using built-in specs. Target: powerpc-linux Configured with: /opt/eldk/build/ppc-2006-01-11/work/usr/src/denx/BUILD/crosstool-0.35/build/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux/gcc-4.0.0/configure --target=powerpc-linux --host=i686-host_pc-linux-gnu --prefix=/var/tmp/eldk.BjN6Wo/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux --with-headers=/var/tmp/eldk.BjN6Wo/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux/powerpc-linux/include --with-local-prefix=/var/tmp/eldk.BjN6Wo/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux/powerpc-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.0.0 (DENX ELDK 4.0 4.0.0) /opt/exported/ppc/eldk/toolchain/release-4.0/usr/bin/../libexec/gcc/powerpc-linux/4.0.0/cc1plus -E -quiet -v -iprefix /opt/exported/ppc/eldk/toolchain/release-4.0/usr/bin/../lib/gcc/powerpc-linux/4.0.0/ -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix Foo.cc -mcpu=8540 -mfloat-gprs=yes -mspe=yes -mabi=spe -fpch-preprocess -o Foo.ii ignoring nonexistent directory "/opt/exported/ppc/eldk/toolchain/release-4.0/usr/lib/gcc/powerpc-linux/4.0.0/../../../../include/c++/4.0.0" ignoring nonexistent directory "/opt/exported/ppc/eldk/toolchain/release-4.0/usr/lib/gcc/powerpc-linux/4.0.0/../../../../include/c++/4.0.0/backward" ignoring nonexistent directory "/opt/exported/ppc/eldk/toolchain/release-4.0/usr/lib/gcc/powerpc-linux/4.0.0/../../../../powerpc-linux/sys-include" ignoring nonexistent directory "/opt/exported/ppc/eldk/toolchain/release-4.0/usr/lib/gcc/powerpc-linux/4.0.0/../../../../powerpc-linux/include" #include "..." search starts here: #include <...> search starts here: /opt/exported/ppc/eldk/toolchain/release-4.0/usr/lib/gcc/powerpc-linux/4.0.0/include /opt/exported/ppc/eldk/toolchain/release-4.0/ppc_85xx/usr/include/c++/4.0.0 /opt/exported/ppc/eldk/toolchain/release-4.0/ppc_85xx/usr/include/c++/4.0.0/powerpc-linux /opt/exported/ppc/eldk/toolchain/release-4.0/ppc_85xx/usr/include/c++/4.0.0/backward /opt/exported/ppc/eldk/toolchain/release-4.0/usr/../ppc_85xx/usr/include End of search list. /opt/exported/ppc/eldk/toolchain/release-4.0/usr/bin/../libexec/gcc/powerpc-linux/4.0.0/cc1plus -fpreprocessed Foo.ii -quiet -dumpbase Foo.cc -mcpu=8540 -mfloat-gprs=yes -mspe=yes -mabi=spe -auxbase Foo -version -o Foo.s GNU C++ version 4.0.0 (DENX ELDK 4.0 4.0.0) (powerpc-linux) compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.3 2.96-113). GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96936 /opt/exported/ppc/eldk/toolchain/release-4.0/ppc_85xx/usr/include/c++/4.0.0/tr1/tuple_iterate.h: In constructor 'std::tr1::tuple<_T1, _T2, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass, std::tr1::_NullClass>::tuple(const std::pair<_U1, _U2>&) [with _U1 = Internal::hashtable_iterator<std::pair<const std::string, IntVector>, false, false>, _U2 = bool, _T1 = Internal::hashtable_iterator<std::pair<const std::string, IntVector>, false, false>&, _T2 = bool&]': Foo.cc:29: instantiated from here /opt/exported/ppc/eldk/toolchain/release-4.0/ppc_85xx/usr/include/c++/4.0.0/tr1/tuple_iterate.h:58: error: invalid initialization of reference of type 'Internal::hashtable_iterator<std::pair<const std::string, IntVector>, false, false>&' from expression of type 'const Internal::hashtable_iterator<std::pair<const std::string, IntVector>, false, false>' /opt/exported/ppc/eldk/toolchain/release-4.0/ppc_85xx/usr/include/c++/4.0.0/tr1/tuple_iterate.h:58: error: invalid initialization of reference of type 'bool&' from expression of type 'const bool' #------------------------------------------------------------------------------- WORKAROUND Replace LINE=29 with lines 30..33 inclusive as shown below. $ cat -n Foo2.cc 1 2 #include <tr1/tuple> 3 #include <tr1/unordered_map> 4 #include <vector> 5 #include <string> 6 7 typedef std::vector<int> IntVector; 8 typedef std::tr1::unordered_map<std::string, IntVector, std::tr1::hash<std::string> > VectorMap; 9 10 class Foo2 11 { 12 public: 13 Foo2(VectorMap& map) : map_(map) {} 14 void insert(std::string s, int value); 15 16 private: 17 VectorMap& map_; 18 }; 19 20 void Foo2::insert(std::string s, int value) 21 { 22 bool vector_exists = true; 23 24 VectorMap::iterator i = map_.find(s); 25 if (i == map_.end()) 26 { 27 IntVector v; 28 std::pair<std::string, IntVector> p(s, v); 29 // std::tr1::tie(i, vector_exists) = map_.insert(p); // broken 30 std::pair<VectorMap::iterator, bool> result(map_.end(), false); 31 result = map_.insert(p); 32 i = result.first; 33 vector_exists = result.second; 34 } 35 36 if (!vector_exists) 37 { 38 return; 39 } 40 41 (*i).second.push_back(value); 42 } 43
Created attachment 15779 [details] Preprocessed .ii file that reproduces the compilation error 1) uncompress as follows $ gzip -d Foo.ii.gz # giving Foo.ii 2) compile as follows (with gcc-4.0.0 cross compiler): $ ppc_85xx-g++ Foo.ii
I do not understand: do you have any evidence that current, maintained, branches of GCC (ie 4_2, 4_3) have problems here? I do not. Because certainly people are not going to do anything on 4_0, and a C++ issue like that, an error from the C++ front-end, is also extremely unlikely to depend on the target.
Subject: Re: Cannot use std::tr1::tie() with unordered_map<> of std::vector<> Paolo - Sorry for this delayed response. a) The problem does not exist on gcc 4.2 (Intel), but I do not have a 4.2 PPC x-compiler - only 4.0. So I cannot confirm a x-compile issue in 4.2. b) It would be very helpful if you would tell me GCC's support policy. i.e. How far back from the latest release will bug reports be considered? In this case, I've reported a bug only three minor releases back of the latest [4.2 at the time] and you seem to be saying "too old". c) I identified the problem as "C++", but more correctly it is an STL problem. d) If and when I can reproduce the problem in a current release, I'll let you know. Thanks, ... Dave paolo dot carlini at oracle dot com wrote: > > > ------- Comment #2 from paolo dot carlini at oracle dot com > 2008-06-18 22:13 ------- > I do not understand: do you have any evidence that current, maintained, > branches of GCC (ie 4_2, 4_3) have problems here? I do not. Because > certainly > people are not going to do anything on 4_0, and a C++ issue like that, > an error > from the C++ front-end, is also extremely unlikely to depend on the > target. > > > -- > > paolo dot carlini at oracle dot com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |WAITING > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36567 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
(In reply to comment #3) > a) The problem does not exist on gcc 4.2 (Intel), but I do not have a > 4.2 PPC x-compiler - only 4.0. So I cannot confirm a x-compile issue in 4.2. Ok. > b) It would be very helpful if you would tell me GCC's support policy. > i.e. How far back from the latest release will bug reports be > considered? In this case, I've reported a bug only three minor releases > back of the latest [4.2 at the time] and you seem to be saying "too old". Well, it's easy, we just closed 4_1-branch, 4_0-branch has been closed a lot of time ago. That means, you can certainly find somehow a volunteer working on the release branch you care about, but since the branch is closed, the fix will not appear in any further official release from the branch. > c) I identified the problem as "C++", but more correctly it is an STL > problem. Wrongly. There is no "STL" mention in the C++ Standard in force (C++98 + TC1), "STL" is a legacy acronym dating back to the HP / SGI times. The problem would be, in case, libstdc++, that this our (GNU) implementation of the C++ Standard Library. > d) If and when I can reproduce the problem in a current release, I'll > let you know. Ok. For now, I'm going to close this one, for lack, to date, of compelling evidence. Thanks again.