Namespace lookup: g++ 4.0.0 -> g++ 4.0.1 regression?
Consider the following snippet:
--8<---cut here---start->8---
namespace foo
{
class A
{
friend class B;
void bar (B);
};
class B {};
}
--8<---cut here---end--->8---
This compiles fine with:
g++ (GCC) 3.3.3
g++ (GCC) 4.0.0
But fails with g++ (GCC) 4.0.1:
$ g++ -c namespace.cc
namespace.cc:7: error: 'B' has not been declared
Why? If this a bug, I am not sure it is the same bug as:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
--
--Jhair
PGP key available from public servers - ID: 0xBAA600D0
Re: Namespace lookup: g++ 4.0.0 -> g++ 4.0.1 regression?
Jhair Tocancipa Triana <[EMAIL PROTECTED]> writes:
| Consider the following snippet:
|
| --8<---cut here---start->8---
| namespace foo
| {
| class A
| {
| friend class B;
|
| void bar (B);
| };
|
| class B {};
| }
| --8<---cut here---end--->8---
|
| This compiles fine with:
|
| g++ (GCC) 3.3.3
| g++ (GCC) 4.0.0
|
| But fails with g++ (GCC) 4.0.1:
|
| $ g++ -c namespace.cc
| namespace.cc:7: error: 'B' has not been declared
|
| Why? If this a bug, I am not sure it is the same bug as:
|
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19403
Yes. See second example from comment #6.
-- Gaby, in the friend mess again
Calling a pure virtual function
Hi all,
I was expecting the following code snippet to work, so am I doing
something wrong, or is there an issue with GCC? I was under the
impression that this is allowed, according to
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.1
It seems like GCC initially allows it as it starts to compile okay, but
then I get an undefined reference error from the linker (because it
seems to be actually calling Base::number(), which obviously won't work
as it's a pure virtual function.)
I was only able to try this with GCC 3.2.3 (i486 target) and 3.3.6
(djgpp/msdos target) and both versions give the same error.
Thanks,
Adam.
--
#include
using namespace std;
class Base {
public:
Base()
{
cout << "This is class " << this->number();
}
virtual int number() = 0;
};
class One: virtual public Base {
public:
int number()
{
return 1;
}
};
int main(void)
{
// Correctly fails stating Base is abstract
// Base *b = new Base();
// Won't compile giving undefined reference to Base::number()
One *o = new One();
return 0;
}
Re: Calling a pure virtual function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > It seems like GCC initially allows it as it starts to compile okay, but > then I get an undefined reference error from the linker (because it > seems to be actually calling Base::number(), which obviously won't work > as it's a pure virtual function.) it works for me if number() is not called in the Base constructor but in another non-virtual Base function. - -- Lion Vollnhals free time linux enthusiast -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0A2qM/kSIby6NMURAgGEAJ9sRFyaCSZEcO89oAb6DDWzG3iSYQCcCyyl HviQIF52XneHS58FL1S2oi4= =mNKz -END PGP SIGNATURE-
Re: Calling a pure virtual function
* Adam Nielsen:
> class Base {
> public:
> Base()
> {
> cout << "This is class " << this->number();
> }
>
> virtual int number() = 0;
> };
Roughly speaking, when number() is invoked, the object still has type
Base (with a corresponding vtable). One's constructor will change the
type once the Base part has been constructed.
The following FAQ entry covers this:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.3
Re: Calling a pure virtual function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I was under the > impression that this is allowed, according to > http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.1 See [23.3]. You aren't allowed to call the virtual function from the Base class constructor. - -- Lion Vollnhals free time linux enthusiast -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0A9zM/kSIby6NMURAmk2AJ4/BKj5sgEW3p1j+WzlyR8IoFe87ACfZw73 xiEmF0RB3eJrGdLZROlENCQ= =TNrh -END PGP SIGNATURE-
Re: Calling a pure virtual function
> Roughly speaking, when number() is invoked, the object still has type > Base (with a corresponding vtable). One's constructor will change the > type once the Base part has been constructed. Aha yes, I didn't even think of that! Thanks Florian and Lion for your helpful answers! > The following FAQ entry covers this: > http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.3 Hmm, I should've read just a little further... ;-) It still makes me wonder whether GCC is reporting the correct error for this mistake though, I would've expected a compiler error (something along the lines of 'you can't call a pure virtual function') rather than a linker error. Especially as GCC should be able to tell at compile time the base constructor is calling a pure virtual function. I guess it's treating the constructor like any other function, where this behaviour would be permitted. Either way, that solved the problem for me, so thanks again! Cheers, Adam.
Re: Calling a pure virtual function
* Adam Nielsen: > It still makes me wonder whether GCC is reporting the correct error for > this mistake though, I would've expected a compiler error (something > along the lines of 'you can't call a pure virtual function') rather than > a linker error. Especially as GCC should be able to tell at compile > time the base constructor is calling a pure virtual function. I guess > it's treating the constructor like any other function, where this > behaviour would be permitted. I think C++ allows for a definition for a purely abstract function (which would be called in this case).
gcc-4.1-20050709 is now available
Snapshot gcc-4.1-20050709 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050709/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-07-09 17:43 UTC You'll find: gcc-4.1-20050709.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050709.tar.bz2 C front end and core compiler gcc-ada-4.1-20050709.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050709.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050709.tar.bz2 C++ front end and runtime gcc-java-4.1-20050709.tar.bz2 Java front end and runtime gcc-objc-4.1-20050709.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050709.tar.bz2The GCC testsuite Diffs from 4.1-20050702 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
should libgcc depend on libc?
objdump -p says: Dynamic Section: NEEDED libc.so.37.0 SONAME libgcc_s.so.1.1 [...] nm | sort says: U _exit U abort U dl_iterate_phdr U free U malloc U memcpy U memset U mprotect U perror U sysconf w _Jv_RegisterClasses w __cxa_finalize Should I really not use -nostandardlibs for libgcc_s ? I just got a linker warning because I had bumped libc from .36.1 to .37.0 and am recompiling gcc... this yields executables linking against libgcc_s (.1.1) and libc (.37.0 AND .36.1). No problems, but a warning. Also, libgcc could be used with libc-replacements this way (not truly an issue with libgcc.so, but think of bootloaders). Do I overlook something? Thanks, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: updating libtool, etc.
Daniel Jacobowitz dixit: >> >Geoff> Does anyone mind if I update libtool to the latest released >> >version, >> >Geoff> 1.5.18, and regenerate everything with automake 1.9.5? >> > >> >If everyone agrees to go forward with this >> >> Oh, I should have said: "and if you don't mind, how do you feel >> about a GCC project fork of libtool?" >If you want to update libtool, you get to play the all-of-src-uses-it >game. I have been updating src directories to more recent autoconf >versions in the hope of getting rid of our outdated libtool someday. I >believe the only remaining holdout is newlib, but I didn't check >everything. The MirOS version of Libtool also works with autoconf 2.13 and automake 1.4 (in addition to autoconf 2.59 and automake 1.9), though we broke one AIX related macro in the process. It's based upon branch-1-5 of GNU libtool, and copyright assignment has already been done. If interested, check these (and the diff to -rFSF) out: * http://mirbsd.mirsolutions.de/cvs.cgi/contrib/gnu/libtool/libtool.m4 * http://mirbsd.mirsolutions.de/cvs.cgi/contrib/gnu/libtool/ltmain.in I use it (obviously) to build all ports which use it, plus stuff in the base system (binutils, gdb, gcc 3.4.5 but not newlib). The broken macro was _LT_AC_SYS_LIBPATH_AIX because one of the macros it invokes are not in autoconf 2.13. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
AMD 64 Problem with assembling
Hello, I have a question concerning successfully assembling and linking the following assembly program on a linux AMD 64 machine: #cpuid2.s View the CPUID Vendor ID string using C library calls .section .datatext output: .asciz "The processor Vendor ID is '%s'\n" .section .bss .lcomm buffer, 12 .section .text .globl main main: movl $0, %eax cpuid movl $buffer, %edi movl %ebx, (%edi) movl %edx, 4(%edi) movl %ecx, 8(%edi) push $buffer push $output call printf addl $8, %esp push $0 call exit This part of a book on assembly programming I am reading. Compile and Link: gcc -o cpuid2 cpuid2.s When running cpuid2 it crashes with a segmentation fault. Which switches do I have to add to call gcc? Thanks a lot! Greetings, Florian
Re: AMD 64 Problem with assembling
On Saturday, July 9, 2005, at 01:23 PM, Florian Michel wrote: I have a question concerning successfully assembling and linking the following assembly program on a linux AMD 64 machine: Wrong list, this list isn't for help with how to program is assembly. gcc-help would be more appropriate, though, that list is really for help in how to program in a language compiled by gcc, .s files aren't compiled.
Re: 4.1 news item
On Fri, 8 Jul 2005, Daniel Berlin wrote: > Here's a patch. Thanks. There are a couple of commas between items missing (usually when there is a line break) and some of the lines are too long (as with GCC sources we generally prefer lines no longer than ~77 characters). Is the new stack checking infrastructure really a port of IBM Pro Police, or a reimplementation by RTH and Jakub? Gerald
Re: 4.1 news item
On Sunday 10 July 2005 00:16, Gerald Pfeifer wrote: > On Fri, 8 Jul 2005, Daniel Berlin wrote: > > Here's a patch. > > Thanks. > > There are a couple of commas between items missing (usually when > there is a line break) and some of the lines are too long (as with > GCC sources we generally prefer lines no longer than ~77 characters). > > Is the new stack checking infrastructure really a port of IBM Pro > Police, or a reimplementation by RTH and Jakub? RTH said (http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01193.html): // The following is a functional re-implementation of the IBM stack smashing protection patch described here: http://www.research.ibm.com/trl/projects/security/ssp/ This version is *much* less intrusive than the IBM version: // Looks like a re-implementation to me, then! ;-) Gr. Steven
gcc-4.1-20050709: ICE in loop_givs_rescan, at loop.c:5517
I can't build gcc-4.1-20050709 for target arm; it fails with
gcc-4.1-20050709/libiberty/cp-demangle.c: In function 'd_print_comp':
gcc-4.1-20050709/libiberty/cp-demangle.c:3342: internal compiler error: in
loop_givs_rescan, at loop.c:5517
Compiling the same version of gcc for i686 manages
to avoid that error somehow, but it pops up later
building the Linux kernel:
mm/page_alloc.c: In function 'setup_per_zone_lowmem_reserve':
mm/page_alloc.c:1940: internal compiler error: in loop_givs_rescan, at
loop.c:5517
Likewise, compiling that version of gcc for alpha
dies while building the linux kernel, but for a different reason:
{standard input}:496: Error: macro requires $at register while noat in effect
make[1]: *** [arch/alpha/kernel/core_cia.o] Error 1
Sigh. I'll file bugs with preprocessed source tomorrow.
Stage 3 is certainly starting with a bang.
- Dan
--
Trying to get a job as a c++ developer? See
http://kegel.com/academy/getting-hired.html
Using gcc compiler on IXDP425 using eCos
Hello, I'm new to GCC and eCos and ixdp425. As a part of my college project, I am supposed to simulate a GSM mobile network and add extra feature of Wi-Fi also. For that, I have decided to use IXDP425 board and port eCos on it. As till now, I have been successful in making test programs run on the IXDP425 board compiled using a gcc compiler. Does that mean that I have ported eCos on the hardware? I know its a very silly question but since this is the first time I am working with hardware, I dont know much. Also, I am supposed to connect 2 GSM modems through the serial ports and a Wi-Fi lan card that will fit in the PCI slot. The Wi-Fi lan card should be such that its drivers for linux should be open-source and freely available on the net. Can anyone suggest me a Wi-Fi lan card which fulfils my requirements? Any help would be appreciated. Thanks, ROHIT -- if u dont know it, it doesnt exist
