public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: wilson@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, rose@acm.org,
	wilson@gcc.gnu.org, wilson@redhat.com
Subject: Re: debug/3468: GCC 3.0 produces invalid .def directive for virtual template
Date: Tue, 10 Dec 2002 14:31:00 -0000	[thread overview]
Message-ID: <20021210223109.28152.qmail@sources.redhat.com> (raw)

Synopsis: GCC 3.0 produces invalid .def directive for virtual template

State-Changed-From-To: open->closed
State-Changed-By: wilson
State-Changed-When: Tue Dec 10 14:31:08 2002
State-Changed-Why:
    In general, it isn't possible to fully support C++ with the coff/sdb
    debug info format.  The format was designed for K&R C, and is
    so unextensible that it can't even handle ISO C correctly.
    
    Use of a better debug info format is strongly recommended.
    The GNU tools support stabs-in-coff, and this is the default
    debug info format for this reason.
    
    I am unable to reproduce the problem using the provided
    testcase.  It contains unexpanded macros for some reason.
    I was able to generate my own testcase using gcc-3.0 sources
    and reproduced the problem.
    
    The suggested patch from Peter Vermaas is the correct way to
    work around this problem.
    
    I tried building current gcc sources, and they do not show this
    failure.  The internal representation of vtable pointers has 
    changed such that this work around is not at present needed.
    Therefore, I am not checking in the patch.
    
    I did discover a new problem though.  The new mangler is
    creating mangled names that start with digits.  For instance
    __type_traits<bool> is mangled into 13__type_traitsIbE in the
    same file.  The sdb format doesn't allow symbols to start with
    digits, so neither the mangled nor unmangled name is valid.
    There is no easy way to work around this problem.  We would
    have to create our own unique names for the purposes of
    emitting valid coff/sdb debug info, and I don't see the point of
    doing that. 
    
    If we really need a fix here, I could add a check for C++ and
    coff/sdb and avoid emitting any debug info at all.  That solves
    the problem, but may not be a useful solution to you.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3468


             reply	other threads:[~2002-12-10 22:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-10 14:31 wilson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-03 11:36 bangerth
2002-03-26  2:46 Peter Vermaas
2001-06-28 17:56 rose

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=20021210223109.28152.qmail@sources.redhat.com \
    --to=wilson@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    --cc=gcc-gnats@gcc.gnu.org \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=rose@acm.org \
    --cc=wilson@redhat.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: link
Be 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).