[pph] name lookup problem
Gab has been debugging a failure that goes like this:
In testsuite/g++.dg/pph/x1functions.h:
struct type {
int mbr_decl_then_def(int);
int mbr_decl_inline(int i) { }
}
In testsuite/g++.dg/pph/x1functions.cc:
#include "x1functions.h"
int type::mbr_decl_then_def(int i)
{ return mbr_decl_inline( i ); }
We first compile x1functions.h into x1functions.pph. Then we compile
x1functions.cc with
$ gcc -fpph-hdr=x1functions x1functions.cc
This causes the #include directive to ignore x1functions.h and instead
load x1functions.pph. So, the parser really starts parsing at the
first token of x1functions.cc. The problem starts when it then tries
to lookup the IDENTIFIER_NODE mbr_decl_inline. It fails to realize
that the identifier is the FUNCTION_DECL type::mbr_decl_inline().
We have been tracing why the name lookup fails and it seems that this
is failing because mbr_decl_inline does not have a proper
IDENTIFIER_BINDINGS set. At first, we thought that maybe we were not
streaming this field out, but the parser removes and reattaches
different binding information using scope_chain->bindings.
In fact, scope_chain has a lot of state that I think needs to be saved
in each pph image. I am still not too sure how the parser uses the
various fields in scope_chain, but it seems to be keeping lists and
stacks as it goes in and out of classes and types during parsing.
Since we told it to skip the header file text, when it started parsing
the .cc file, none of the state that it would've collected while
parsing the .h file was present.
Am I on the right track? My impression is that for each header file
that we pre-parse we should save this state in scope_chain. The issue
then becomes, given more than one pph image, how should the different
scope_chains be merged?
Thanks. Diego.
gcc-4.6-20110610 is now available
Snapshot gcc-4.6-20110610 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110610/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 174931 You'll find: gcc-4.6-20110610.tar.bz2 Complete GCC MD5=724ad4671375fffa41cfad80b621af62 SHA1=003444efa5ff738dd996c7a9738f051bc2fbc5f9 Diffs from 4.6-20110603 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: mips-elf-gcc -fno-delayed-branch problem
On Thu, 19 May 2011, Richard Sandiford wrote: > Maybe it would be worth breaking with tradition and making > -fno-delayed-branch imply -Wa,-O0 though. Back in the day, > the assembler's version of delayed-branch filling was applied > to pretty much every function, so the separation was probably > more obvious. However, CCC now tries to emit most functions as > ".set noreorder"/ ".set nomacro", so -fno-delayed-branch does > actually stop the assembler filling branches in most situations. > I can see that it'd be confusing to suddenly have the assembler > kick in when you add something like an inline asm. > > So yeah, I'll try to get around to that this weekend... While I think the change is sane, it is bound to break *something* somewhere, so could you please make sure there's a way to get the old behavior? Right now it seems like adding -Wa,-O2 would work if you do it as above, but that might change. And a minor NEWS item? brgds, H-P
Invocation mismatch - some data files may have been removed
I am seeing some non-fatal warnings when doing a profiledbootstrap/ltobootstap on x86_64 darwin. These are of the form... profiling:/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/graphite-poly.gcda:Invocation mismatch - some data files may have been removedprofiling:/sw/src/fink.build/gcc47-4.7.0-1000/darwin_objdir/gcc/omega.gcda:Invocation mismatch - some data files may have been removed are these expected? Jack
Re: template class
Dear Mr. Bjarne Stroustrup:
Thanks your suggestion, I follow it but it show fatal error:Array.cpp:
no such file
so
I add #include "Array.cpp" in my main program, pg52.cpp
then
it can compile
but
when I run it, it response
Segmentation fault
again it's g++ 4.5.2. What may cause wrong?
hope to see your suggestion/advice again, and thanks a lot in advance,
Eric
-
On Fri, 2011-06-10 at 22:18 -0400, bs wrote:
> On 6/10/2011 9:43 PM, eric wrote:
> > Dear Bjarne Stroustrup:
> >
> >I copied a piece of codes from book(C++ primer 3rd Ed) chapter 2 about
> > page 52.
> > but it failed to be compiled under my g++ 4.5.2
> > here is the program
>
> That book is an antique, but I think that the problem may simply be that
> you can't separately compile pg52.cpp and Array.cpp. Try
> #include in Array.h .
>
> > ---
> >
> > eric@eric-laptop:~/CppPrimer3$ g++ Array.cpp pg52.cpp
> > /tmp/ccE9MPMg.o: In function `main':
> > pg52.cpp:(.text+0x23): undefined reference to `Array::Array(int)'
> > pg52.cpp:(.text+0x37): undefined reference to
> > `Array::Array(int)'
> > pg52.cpp:(.text+0x4b): undefined reference to `Array::Array(int)'
> > collect2: ld returned 1 exit status
> > --
> > #include
> > #include "Array.h"
> >
> >
> >
> > int main() {
> >const int array_size = 4;
> >
> >// elemType becomes int
> >Array ia(array_size);
> >
> >// elemType becomes double
> >Array da(array_size);
> >
> >// elemType becomes char
> >Array ca(array_size);
> >
> > int ix;
> >
> > for ( ix = 0; ix< array_size; ++ix ) {
> > ia[ix] = ix;
> > da[ix] = ix * 1.75;
> > ca[ix] = ix + 'a';
> > }
> >
> > for ( ix = 0; ix< array_size; ++ix )
> >std::cout<< "[ "<< ix<< " ] ia: "<< ia[ix]
> > << "\tca: "<< ca[ix]
> > << "\tda: "<< da[ix]<< std::endl;
> >
> > return 0;
> > }
> > ---
> > // Array.cpp
> >
> > #include "Array.h"
> >
> > /*
> > Array::Array(elemType *iarray, int iarray_size)
> > {
> >ia = iarray;
> >_size = iarray_size;
> > }
> > */
> >
> > template Array::Array(const Array &rhs )
> > {
> >ia = rhs;
> > }
> >
> > template Array::Array(const int size )
> > {
> >_size = size;
> > }
> >
> >
> > --
> > #ifndef Array_H
> > #define Array_H
> >
> >
> > template< class elemType>
> > class Array {
> > public:
> >// parameterize element type
> >explicit Array( int size = DefaultArraySize );
> >Array( elemType *array, int array_size );
> >Array( const Array&rhs );
> >
> >virtual ~Array() { delete [] ia; }
> >
> >bool operator==( const Array& ) const;
> >bool operator!=( const Array& ) const;
> >
> >Array& operator=( const Array& );
> >int size() const { return _size; }
> >
> >/* virtual */ elemType& operator[](int index){ return ia[index]; }
> >/*
> >virtual void sort();
> >
> >virtual elemType min() const;
> >virtual elemType max() const; */
> >/* virtual */ int find( const elemType&value ) const;
> >
> > protected:
> > static const int DefaultArraySize = 12;
> >
> > int _size;
> > elemType *ia;
> > };
> >
> > #endif
> > ---
> > I asked mailing list in gcc, but so far I did not get any useful
> > response. I know the book's author Stanley B. Lippman or Josee Lajoie
> > ever work with you. And I tried to reach Stanley B. Lippman, I can not
> > find his email addreess. I emailed Josee Lajoie but again never get any
> > message from her (for 2 or 3 days).
> > hope to get your help on this problem.
> > Thanks your efforts a lot in advance
> > Eric
> >
> >
>
Re: template class
eric writes: > Thanks your suggestion, I follow it but it show fatal error:Array.cpp: > no such file > so > I add #include "Array.cpp" in my main program, pg52.cpp > then > it can compile > but > when I run it, it response > Segmentation fault > > again it's g++ 4.5.2. What may cause wrong? > > hope to see your suggestion/advice again, and thanks a lot in advance, This message is not appropriate for the mailing list gcc@gcc.gnu.org. Please do not send C++ questions to this mailing list. Thanks. Ian
Re: template class
FWIW
Array( const Array&rhs );
On Fri, Jun 10, 2011 at 08:30:05PM -0700, eric wrote:
> Dear Mr. Bjarne Stroustrup:
>
> Thanks your suggestion, I follow it but it show fatal error:Array.cpp:
> no such file
> so
> I add #include "Array.cpp" in my main program, pg52.cpp
> then
> it can compile
> but
> when I run it, it response
> Segmentation fault
>
> again it's g++ 4.5.2. What may cause wrong?
>
> hope to see your suggestion/advice again, and thanks a lot in advance,
> Eric
> -
>
> On Fri, 2011-06-10 at 22:18 -0400, bs wrote:
> > On 6/10/2011 9:43 PM, eric wrote:
> > > Dear Bjarne Stroustrup:
> > >
> > >I copied a piece of codes from book(C++ primer 3rd Ed) chapter 2 about
> > > page 52.
> > > but it failed to be compiled under my g++ 4.5.2
> > > here is the program
> >
> > That book is an antique, but I think that the problem may simply be that
> > you can't separately compile pg52.cpp and Array.cpp. Try
> > #include in Array.h .
> >
> > > ---
> > >
> > > eric@eric-laptop:~/CppPrimer3$ g++ Array.cpp pg52.cpp
> > > /tmp/ccE9MPMg.o: In function `main':
> > > pg52.cpp:(.text+0x23): undefined reference to `Array::Array(int)'
> > > pg52.cpp:(.text+0x37): undefined reference to
> > > `Array::Array(int)'
> > > pg52.cpp:(.text+0x4b): undefined reference to `Array::Array(int)'
> > > collect2: ld returned 1 exit status
> > > --
> > > #include
> > > #include "Array.h"
> > >
> > >
> > >
> > > int main() {
> > >const int array_size = 4;
> > >
> > >// elemType becomes int
> > >Array ia(array_size);
> > >
> > >// elemType becomes double
> > >Array da(array_size);
> > >
> > >// elemType becomes char
> > >Array ca(array_size);
> > >
> > > int ix;
> > >
> > > for ( ix = 0; ix< array_size; ++ix ) {
> > > ia[ix] = ix;
> > > da[ix] = ix * 1.75;
> > > ca[ix] = ix + 'a';
> > > }
> > >
> > > for ( ix = 0; ix< array_size; ++ix )
> > >std::cout<< "[ "<< ix<< " ] ia: "<< ia[ix]
> > > << "\tca: "<< ca[ix]
> > > << "\tda: "<< da[ix]<< std::endl;
> > >
> > > return 0;
> > > }
> > > ---
> > > // Array.cpp
> > >
> > > #include "Array.h"
> > >
> > > /*
> > > Array::Array(elemType *iarray, int iarray_size)
> > > {
> > >ia = iarray;
> > >_size = iarray_size;
> > > }
> > > */
> > >
> > > template Array::Array(const Array &rhs )
> > > {
> > >ia = rhs;
> > > }
> > >
> > > template Array::Array(const int size )
> > > {
> > >_size = size;
> > > }
> > >
> > >
> > > --
> > > #ifndef Array_H
> > > #define Array_H
> > >
> > >
> > > template< class elemType>
> > > class Array {
> > > public:
> > >// parameterize element type
> > >explicit Array( int size = DefaultArraySize );
> > >Array( elemType *array, int array_size );
> > >Array( const Array&rhs );
> > >
> > >virtual ~Array() { delete [] ia; }
> > >
> > >bool operator==( const Array& ) const;
> > >bool operator!=( const Array& ) const;
> > >
> > >Array& operator=( const Array& );
> > >int size() const { return _size; }
> > >
> > >/* virtual */ elemType& operator[](int index){ return ia[index]; }
> > >/*
> > >virtual void sort();
> > >
> > >virtual elemType min() const;
> > >virtual elemType max() const; */
> > >/* virtual */ int find( const elemType&value ) const;
> > >
> > > protected:
> > > static const int DefaultArraySize = 12;
> > >
> > > int _size;
> > > elemType *ia;
> > > };
> > >
> > > #endif
> > > ---
> > > I asked mailing list in gcc, but so far I did not get any useful
> > > response. I know the book's author Stanley B. Lippman or Josee Lajoie
> > > ever work with you. And I tried to reach Stanley B. Lippman, I can not
> > > find his email addreess. I emailed Josee Lajoie but again never get any
> > > message from her (for 2 or 3 days).
> > > hope to get your help on this problem.
> > > Thanks your efforts a lot in advance
> > > Eric
> > >
> > >
> >
>
--
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software
So many immigrant groups have swept through our town that Brooklyn, like
Atlantis, reaches mythological proportions in the mind of the world - RI Safir
1998
http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
"Yeah - I write Free Software...so SUE ME"
"The tremendous problem we face is that we are becoming sharecroppers to our
own cultural heritage -- we need the ability to participate in our own society."
"> I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been
attached at the hip since the
