public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/20315] New: G++ Problem with two-stage name lookup
@ 2005-03-04 11:59 cmarco at indra dot es
  2005-03-04 15:15 ` [Bug target/20315] pch problems on solaris bangerth at dealii dot org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: cmarco at indra dot es @ 2005-03-04 11:59 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4590 bytes --]

I had a derived class template which was making use of two protected 
variables of it’s base class. Now using GCC 3.4.4 (which implements the two-
stage dependant name lookup) I’ve read that you need to use the prefix this-> 
or the prefix BaseClassName<T> to avoid getting a undeclared variable message, 
but it doesn´t work, at least with this version of the compiler. When you 
compile with the –m64 option, the first time the compiler not generate the .o 
file just generate a .gch file and if you repeat the operation !!?, the 
internal compiler error message appear.

If you compile at 32 bits generate the .gch file in ever occasion you compile 
it but the error message not appear.?

I have tried the flag –fpermissive without luck.

We are compiling with 64 bits. Do you now any work around?

Code:
template <typename T> class Base {
  int i;
};
template <typename T> class Derived : public Base<T> {
   int get_i() {return Base<T>::i;}
};


Preprocessed Code:
# 1 "test.h"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "test.h"
template <typename T> class Base {
  int i;
};
template <typename T> class Derived : public Base<T> {
   int get_i() {return Base<T>::i;}
};


Problem :
sun1:~/test> g++ -m64 -Wno-deprecated -x c++ -c test.h
cc1plus: internal compiler error: in default_pch_valid_p, at ./toplev.c:4142
Please submit a full bug report,
with preprocessed source if appropriate.

Bug Information:
sun1:~/test> g++ -v -save-temps -m64 -Wno-deprecated -x c++ -c test.h
Reading specs from /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/specs
Configured with: ./configure --prefix=/usr/users/afernand/comp/gcc-bootstrap-
34 --enable-language=c --without-headers --disable-shared : 
(reconfigured) ./configure --prefix=/usr/users/afernand/comp/gcc-bootstrap-34 -
-enable-language=c --without-headers --disable-shared : 
(reconfigured) ./configure --prefix=/usr/users/afernand/comp/gcc-bootstrap-34 -
-enable-language=c --without-headers --disable-shared : 
(reconfigured) ./configure --prefix=/usr/users/afernand/comp/gcc-34 --enable-
language=c,c++
Thread model: posix
gcc version 3.4.4 20041222 (prerelease)
 /usr/local/gcc-34/bin/../libexec/gcc/sparc-sun-solaris2.9/3.4.4/cc1plus -E -
quiet -v -iprefix /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/ -D__arch64__ -D__sparcv9 test.h -mptr64 -mstack-bias -mno-
v8plus -mcpu=v9 -m64 -Wno-deprecated -o test.ii
ignoring nonexistent directory "/usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../sparc-sun-solaris2.9/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/users/afernand/comp/gcc-34/lib/gcc/sparc-
sun-solaris2.9/3.4.4/../../../../sparc-sun-solaris2.9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4
 /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.9
 /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4/backward
 /usr/local/gcc-34/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.4/include
 /usr/users/afernand/comp/gcc-34/lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4
 /usr/users/afernand/comp/gcc-34/lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.9
 /usr/users/afernand/comp/gcc-34/lib/gcc/sparc-sun-
solaris2.9/3.4.4/../../../../include/c++/3.4.4/backward
 /usr/users/afernand/comp/gcc-34/include
 /usr/users/afernand/comp/gcc-34/lib/gcc/sparc-sun-solaris2.9/3.4.4/include
 /usr/include
End of search list.
 /usr/local/gcc-34/bin/../libexec/gcc/sparc-sun-solaris2.9/3.4.4/cc1plus -
fpreprocessed test.ii -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet -
dumpbase test.h -m64 -auxbase test -Wno-deprecated -version -o test.s --output-
pch=test.h.gch
GNU C++ version 3.4.4 20041222 (prerelease) (sparc-sun-solaris2.9)
  compiled by GNU C version 3.4.4 20041222 (prerelease).
GGC heuristics: --param ggc-min-expand=65 --param ggc-min-heapsize=65536

Waiting to hear from you soon.

 

Best Regards.

-- 
           Summary: G++ Problem with two-stage name lookup
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: cmarco at indra dot es
                CC: cmarco at indra dot es,gcc-bugs at gcc dot gnu dot org


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


^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-04-20  2:19 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-03-04 11:59 [Bug c++/20315] New: G++ Problem with two-stage name lookup cmarco at indra dot es
2005-03-04 15:15 ` [Bug target/20315] pch problems on solaris bangerth at dealii dot org
2005-03-09  8:35 ` [Bug pch/20315] " cmarco at indra dot es
2005-03-09  9:13 ` ebotcazou at gcc dot gnu dot org
2005-03-16 10:53 ` ebotcazou at gcc dot gnu dot org
2005-03-17  8:56 ` cmarco at indra dot es
2005-03-17 10:35 ` ebotcazou at gcc dot gnu dot org
2005-03-29 18:54 ` ebotcazou at gcc dot gnu dot org
2005-03-30  7:36 ` cmarco at indra dot es
2005-04-20  2:20 ` pinskia at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).