public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "james dot ashley at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/39494] New: Bad assembly when derived class has same name as virtual method Date: Wed, 18 Mar 2009 14:31:00 -0000 [thread overview] Message-ID: <bug-39494-17469@http.gcc.gnu.org/bugzilla/> (raw) I'm sorry...I don't know what "triplet" means. There was nothing about it in the FAQ. I took my best guess. g++ -v --version prints g++ (Debian 4.3.2-1.1) 4.3.2 cat /proc/version prints Linux version 2.6.26-1-686 (Debian 2.6.26-13) (waldi@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-24)) #1 SMP Sat Jan 10 18:29:31 UTC 2009 I'm using the stock g++ build that came from Debian, whatever compiler options they use. After I traced it down, the problem turned out to be fairly simple [to produce]. In what looks [to me] like the vtable for the constructor of the derived class, the compiler's appending *INTERNAL*. Since I don't know whether there's a page 2, The command gcc -c -Wall compilerBug.cpp produces the output /tmp/ccHFsjIR.s: Assembler messages: /tmp/ccHFsjIR.s:68: Warning: missing operand; zero assumed /tmp/ccHFsjIR.s:68: Error: undefined symbol `INTERNAL' in operation The line it's complaining about looks like this: .long _ZN7DerivedC1Ev *INTERNAL* I've boiled the precompiled source file down to # 1 "compilerBug.cpp" # 1 "<built-in>" # 1 "<command-line>" # 1 "compilerBug.cpp" class Base { public: virtual void Derived() = 0; }; class Derived : public Base { public: Derived(); }; Derived::Derived() : Base() {} (Everything else I tried to delete let the compiler optimize everything away). I have no idea what the standard says about how this should actually work (or not). Compiler error about conflicting symbols? Warning about "this is stupid, and you probably don't want to do it"? Or just go ahead and magically work? Especially since the work-around's as easy as renaming either the function or the derived class. I just know that the FAQ says that invalid assembly output is a bug, so here we go. Thanks *so* much for committing time and effort to work on the compiler. It really is the heart and soul of the entire free software movement. -- Summary: Bad assembly when derived class has same name as virtual method Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: james dot ashley at gmail dot com GCC build triplet: 4.3.2 GCC host triplet: 2.6.26-13 GCC target triplet: 2.6.26-13 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39494
next reply other threads:[~2009-03-18 14:31 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-03-18 14:31 james dot ashley at gmail dot com [this message] 2009-03-18 14:33 ` [Bug c++/39494] " james dot ashley at gmail dot com 2009-03-18 14:57 ` rguenth at gcc dot gnu dot org 2009-03-18 16:16 ` hjl dot tools at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-39494-17469@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).