public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/39494]  New: Bad assembly when derived class has same name as virtual method
@ 2009-03-18 14:31 james dot ashley at gmail dot com
  2009-03-18 14:33 ` [Bug c++/39494] " james dot ashley at gmail dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: james dot ashley at gmail dot com @ 2009-03-18 14:31 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-03-18 16:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-18 14:31 [Bug c++/39494] New: Bad assembly when derived class has same name as virtual method james dot ashley at gmail dot com
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

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).