public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* pure virtual method called
@ 1999-07-01 16:43 Yotam Medini
  1999-07-01 21:25 ` Alexandre Oliva
  0 siblings, 1 reply; 5+ messages in thread
From: Yotam Medini @ 1999-07-01 16:43 UTC (permalink / raw)
  To: egcs-bugs

Yet another simple example. 
This should have been a _compile_ time error, not run time.

################################################################
emu:195> g++ -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
emu:196> cat virtcalled.cc
class ABS
{
 public:
   virtual void vf() const = 0;
}; // ABS

void dum(const ABS& a) {
  a.vf();
}

int main(int, char**) {
# if defined(GoodCheck)
   ABS  abs;
# endif
   dum(ABS());
   return 0;
}
emu:197> g++ -o /tmp/vc -Wall virtcalled.cc
emu:198> /tmp/vc
pure virtual method called
emu:199> 
##############################################################

-- yotam
>From gufl0000@stud.uni-sb.de Thu Jul 01 17:54:00 1999
From: "Guido Flohr" <gufl0000@stud.uni-sb.de>
To: egcs-bugs@egcs.cygnus.com
Subject: typedef in preprocessor macros
Date: Thu, 01 Jul 1999 17:54:00 -0000
Message-id: <19990702021722.B920@zowee.rz.uni-sb.de>
X-SW-Source: 1999-07/msg00041.html
Content-length: 512

Hi,

the info documentation to egcs-2.90.29 gives this code example as a safe
macro:

#define max(a,b) \
  ({typedef _ta = (a), _tb =(b); \
    _ta _a = a; _tb _b = b; \
    _a > _b ? _a : _b; })

The above mentioned egcs -Wall will compile about "type defaults to `int'
in declaration of _ta" (and the same for `_tb').  The same already happens
with gcc 2.8.1 but not with gcc 2.7.2.

Who is wrong? The docs or the compiler?

Thank you!

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de
>From ghazi@caip.rutgers.edu Thu Jul 01 19:12:00 1999
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: wilson@cygnus.com
Cc: egcs-bugs@egcs.cygnus.com, law@cygnus.com
Subject: Re: gcc-2.95 19990627 irix6 bootstrap fails with "-O3 -funroll-all-loops"
Date: Thu, 01 Jul 1999 19:12:00 -0000
Message-id: <199907020212.WAA05700@caip.rutgers.edu>
X-SW-Source: 1999-07/msg00042.html
Content-length: 1233

 > From: Jim Wilson <wilson@cygnus.com>
 > 
 > Here is a quick fix that should be safe enough for gcc 2.95.
 > I started a bootstrap to test it, but it will quite a while to complete.
 > 
 > Thu Jul  1 15:20:30 1999  Jim Wilson  <wilson@cygnus.com>
 > 
 > 	* unroll.c (unroll_loop): Don't delete NOTE_INSN_DELETED_LABEL notes.
 > 

Hi Jim,

	Thanks for looking into this one.  Your patch allows the
bootstrap to continue further, but it dies in the same place in
dwarf2out.c:8720, this time when building f771 equiv.o:

 > stage1/xgcc -Bstage1/ -B/usr/local/mips-sgi-irix6.2/bin/ -c -DIN_GCC
 > 	-g -O3 -funroll-all-loops -W -Wall -I. -I..
 > 	-I../../../egcs-2.95-CVS19990701/gcc/f
 > 	-I../../../egcs-2.95-CVS19990701/gcc/f/..
 > 	-I../../../egcs-2.95-CVS19990701/gcc/f/../config
 > 	-I../../../egcs-2.95-CVS19990701/gcc/f/../../include
 > 	-I../../../egcs-2.95-CVS19990701/gcc/f/equiv.c
 > ../../../egcs-2.95-CVS19990701/gcc/f/equiv.c: In function
 > 	`ffeequiv_update_init':
 > ../../../egcs-2.95-CVS19990701/gcc/f/equiv.c:1499: Internal compiler
 > 	error at dwarf2out.c:8720
 > make[3]: *** [equiv.o] Error 1

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions
>From dvv@dvv.ru Thu Jul 01 19:25:00 1999
From: dvv@dvv.ru (Dima Volodin)
To: egcs-bugs@egcs.cygnus.com
Subject: what is wrong here?
Date: Thu, 01 Jul 1999 19:25:00 -0000
Message-id: <377d22f9.20361699@localhost>
X-SW-Source: 1999-07/msg00043.html
Content-length: 472

267_dv@lazybones: cat bug.cc
namespace N {

class C {
        friend void ::f ();
        int  m;
} c;

}       // namespace N

void
f () {
        N::c.m = 0;
}
268_dv@lazybones: g++ -S bug.cc
bug.cc:4: parse error before `('
bug.cc: In function `void f()':
bug.cc:5: `int N::C::m' is private
bug.cc:12: within this context
269_dv@lazybones: g++ -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/gcc-2.95/specs
gcc version gcc-2.95 19990629 (prerelease)


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: pure virtual method called
  1999-07-01 16:43 pure virtual method called Yotam Medini
@ 1999-07-01 21:25 ` Alexandre Oliva
  0 siblings, 0 replies; 5+ messages in thread
From: Alexandre Oliva @ 1999-07-01 21:25 UTC (permalink / raw)
  To: yotam; +Cc: egcs-bugs

On Jul  1, 1999, Yotam Medini <yotam@tharas.com> wrote:

> This should have been a _compile_ time error, not run time.

> class ABS {
>    virtual void vf() const = 0;
[snip]
>    dum(ABS());

Thanks.  The upcoming gcc 2.95 will report:

t.cc: In function `int main(int, char **)':
t.cc:15: cannot allocate an object of type `ABS'
t.cc:15:   since the following virtual functions are abstract:
t.cc:4:         void ABS::vf() const

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: pure virtual method called
@ 1998-11-06 17:21 Mike Stump
  0 siblings, 0 replies; 5+ messages in thread
From: Mike Stump @ 1998-11-06 17:21 UTC (permalink / raw)
  To: Gilles.Depeyrot, egcs-bugs

> Date: Fri, 6 Nov 98 19:35:34 +0100
> From: Gilles Depeyrot <Gilles.Depeyrot@wanadoo.fr>

> pure virtual method called

> What can I do to figure out where the problem is ?

Set a breakpoint on __pure_vitual, then run it again.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: pure virtual method called
  1998-11-06 10:35 Gilles Depeyrot
@ 1998-11-06 13:25 ` Martin von Loewis
  0 siblings, 0 replies; 5+ messages in thread
From: Martin von Loewis @ 1998-11-06 13:25 UTC (permalink / raw)
  To: Gilles.Depeyrot; +Cc: egcs-bugs

> pure virtual method called
[...]

> Debugging doesn't help because it seems to happen during the
> initialization of the global/static data before main is called.

You should try debugging, anyway. In gdb, set a breakpoint on
__pure_virtual, then use the backtrace. Typically, you should see a
constructor or other method call which in turn calls __pure_virtual.

If you don't, it might mean that everything was inlined. This is
strange, as g++ should have complained about the pure virtual call,
then. You still could use assembly output to see the problem. Maybe a
code review might help, as well.

Regards,
Martin


^ permalink raw reply	[flat|nested] 5+ messages in thread

* pure virtual method called
@ 1998-11-06 10:35 Gilles Depeyrot
  1998-11-06 13:25 ` Martin von Loewis
  0 siblings, 1 reply; 5+ messages in thread
From: Gilles Depeyrot @ 1998-11-06 10:35 UTC (permalink / raw)
  To: egcs-bugs

Hello everyone,

Using egcs-1.1 on solaris 2.5, I have a rather large C++ application
that compiles and links fine but displays the message:

pure virtual method called

at runtime and exits with a status code of -1.

Debugging doesn't help because it seems to happen during the 
initialization
of the global/static data before main is called.

What can I do to figure out where the problem is ?

Thanks,
Gilles

Gilles Depeyrot                    < mailto:Gilles.Depeyrot@wanadoo.fr >
                             < http://perso.wanadoo.fr/gilles.depeyrot >



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~1999-07-01 21:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-01 16:43 pure virtual method called Yotam Medini
1999-07-01 21:25 ` Alexandre Oliva
  -- strict thread matches above, loose matches on Subject: below --
1998-11-06 17:21 Mike Stump
1998-11-06 10:35 Gilles Depeyrot
1998-11-06 13:25 ` Martin von Loewis

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