public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: mrs@wrs.com (Mike Stump) To: egcs-bugs@cygnus.com, hjl@innovix.com Cc: glenn@dodgson.wonderland.caltech.edu Subject: Re: c++ code that egcs kills ... Date: Fri, 21 Aug 1998 18:10:00 -0000 [thread overview] Message-ID: <199808220047.RAA21631@kankakee.wrs.com> (raw) > From: hjl@innovix.com (H.J. Lu) > To: egcs-bugs@cygnus.com > Date: Fri, 21 Aug 1998 10:01:34 -0700 (PDT) > What is the unfinished part of the thunks implemantation? The below. > The only thing I can find is that expand_indirect_vtbls_init () in > search.c has > if (flag_vtable_thunks) > { > /* We don't have dynamic thunks yet! > So for now, just fail silently. */ > } > else > { > .... > } > If the dynamic thunks is working, will that bug be fixed? Yes. > Do we need a new thunks implemantation to fix it? It's more vbase related than thunk related; Jason talks of a new way to organize vbases, that is one way to fix it. Implementation of dynamic thunks would also do it. > If the dynamic thunks is not implemanted and it does generate > incorrect codes, why doesn't egcs issue a warning to user? A warning isn't realistic I feel. You would have to warn about _any_ vbase code. This is like saying, sorry, we don't know how to code a compiler, and we will bite you if you try and use this sucker... I'd rather just turn off thunks than do a warning.
next reply other threads:[~1998-08-21 18:10 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 1998-08-21 18:10 Mike Stump [this message] -- strict thread matches above, loose matches on Subject: below -- 1998-08-24 13:51 Glenn W. Bach 1998-08-23 10:36 Mike Stump 1998-08-21 18:10 Mike Stump 1998-08-21 11:25 Glenn W. Bach 1998-08-21 10:01 H.J. Lu 1998-08-21 8:08 Mike Stump 1998-08-20 16:55 Glenn W. Bach 1998-08-21 8:49 ` Alexandre Oliva 1998-08-20 12:52 Glenn W. Bach 1998-08-20 14:23 ` Alexandre Oliva
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=199808220047.RAA21631@kankakee.wrs.com \ --to=mrs@wrs.com \ --cc=egcs-bugs@cygnus.com \ --cc=glenn@dodgson.wonderland.caltech.edu \ --cc=hjl@innovix.com \ /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).