Re: "insn outside basic block" in custom back end
On Tue, Oct 17, 2006 at 07:07:00PM +0200, Frank Riese wrote:
> function8.c: In function 'foo':
> function8.c:3: error: insn outside basic block
> (insn 28 20 29 (set (reg/f:QI 20)
> (subreg:QI (reg:HI 18) 0)) 3 {movqi} (nil)
> (nil))
> function8.c:3: internal compiler error: in rtl_verify_flow_info, at
> cfgrtl.c:2065
Does this patch
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01239.html> fix it?
--
Rask Ingemann Lambertsen
gcc-4.3-20061125 is now available
Snapshot gcc-4.3-20061125 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20061125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 119204 You'll find: gcc-4.3-20061125.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20061125.tar.bz2 C front end and core compiler gcc-ada-4.3-20061125.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20061125.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20061125.tar.bz2 C++ front end and runtime gcc-java-4.3-20061125.tar.bz2 Java front end and runtime gcc-objc-4.3-20061125.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20061125.tar.bz2The GCC testsuite Diffs from 4.3-20061118 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
Configure test hangs on powerpc64-linux
I tried to build GCC HEAD today, using binutils 2.16. It gets stuck during configure, here: checking linker EH-compatible garbage collection of sections... The backtrace looks like: #0 0x10048e60 in ppc64_elf_gc_mark_hook (sec=0x10183078, info=0x1014e278, rel=0x1018c228, h=0x0, sym=0x1017fc30) at /scratch/joseph/3.4.0/linux/binutils-2.16/bfd/elf64-ppc.c:4892 #1 0x100704fc in _bfd_elf_gc_mark (info=0x1014e278, sec=0x10183078, [EMAIL PROTECTED]: 0x10048ddc ) at /scratch/joseph/3.4.0/linux/binutils-2.16/bfd/elflink.c:8771 #2 0x10070b10 in bfd_elf_gc_sections (abfd=0x10160570, info=0x1014e278) at /scratch/joseph/3.4.0/linux/binutils-2.16/bfd/elflink.c:9085 #3 0x1001343c in lang_process () at /scratch/joseph/3.4.0/linux/binutils-2.16/ld/ldlang.c:4721 #4 0x10014e7c in main (argc=269804016, argv=0x1fff558) at /scratch/joseph/3.4.0/linux/binutils-2.16/ld/ldmain.c:458 It never returns from ppc64_elf_gc_mark_hook (spins looking things up in a hash table, I don't have the matching source handy). I expect this is fixed in later binutils, but has anyone else seen this happen? Is there some way we can avoid an infinite loop in configure for this case? -- Daniel Jacobowitz CodeSourcery
Cannot call pure virtual function from base class constructor.
Hi, I have created a base class who's constructor calls a pure virtual function I derive this class, implement the function, compile and receive this error message, "error: abstract virtual `IDXTYPE DataSet::indexFxn(uint) [with DATA = float, IDXTYPE = float]' called from constructor" Without context to my code basically reads, "error: abstract virtual function called from constructor" I know that it would not make sense for the base class to call a pure virtual function. However, this constructor is being called in response to a derived class of the base being initialized who defines the pure virtual function of the base. I can see how this error may happen if the constructor for the base class is called before the derived class at which time the pointer to the derived class' implementation of the base class' virtual function is not initialized (I don't know for sure if this is the order of what happens but it is my best educated guess). I don't see that this error is necessary, unless the derived class does not implement the pure virtual function of the base. Even if this were the case, the derived class could initialize the pointer table with it's implementation for the base class pure virtual function before the base class constructor call to the pure virtual function? Is this behaviour a cause of the C++ standard or is it specific to GCC? Thanks, -- Brad
Re: Cannot call pure virtual function from base class constructor.
Hi, I've found that this article explains very well why one *cannot* call a virtual function during construction (or destruction). http://www.artima.com/cppsource/nevercall.html HTH, Fang > I have created a base class who's constructor calls a pure virtual > function I derive this class, implement the function, compile and > receive this error message, "error: abstract virtual `IDXTYPE > DataSet::indexFxn(uint) [with DATA = float, IDXTYPE = > float]' called from constructor" > > Without context to my code basically reads, "error: abstract virtual > function called from constructor" > > I know that it would not make sense for the base class to call a pure > virtual function. However, this constructor is being called in > response to a derived class of the base being initialized who defines > the pure virtual function of the base. > > I can see how this error may happen if the constructor for the base > class is called before the derived class at which time the pointer to > the derived class' implementation of the base class' virtual function > is not initialized (I don't know for sure if this is the order of what > happens but it is my best educated guess). I don't see that this error > is necessary, unless the derived class does not implement the pure > virtual function of the base. Even if this were the case, the derived > class could initialize the pointer table with it's implementation for > the base class pure virtual function before the base class constructor > call to the pure virtual function? > > Is this behaviour a cause of the C++ standard or is it specific to GCC? David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!)
Re: Configure test hangs on powerpc64-linux
> It never returns from ppc64_elf_gc_mark_hook (spins looking things up > in a hash table, I don't have the matching source handy). I expect > this is fixed in later binutils, but has anyone else seen this happen? > Is there some way we can avoid an infinite loop in configure for this > case? The test needs to check that --gc-sections works, so indirectly invoking ppc64_elf_gc_mark_hook seems to be unavoidable. You could try to tweak the contents of the sections if you understand why ppc64_elf_gc_mark_hook loops. -- Eric Botcazou
