public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Zack Weinberg <zack@codesourcery.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH Date: Fri, 27 Sep 2002 15:16:00 -0000 [thread overview] Message-ID: <20020927221602.17862.qmail@sources.redhat.com> (raw) The following reply was made to PR preprocessor/8055; it has been noted by GNATS. From: Zack Weinberg <zack@codesourcery.com> To: Mark Mitchell <mark@codesourcery.com> Cc: "ak03@gte.com" <ak03@gte.com>, Neil Booth <neil@daikokuya.co.uk>, "gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>, "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org> Subject: Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH Date: Fri, 27 Sep 2002 15:11:28 -0700 On Fri, Sep 27, 2002 at 01:50:20PM -0700, Mark Mitchell wrote: > > > --On Friday, September 27, 2002 12:50:09 PM -0700 Zack Weinberg > <zack@codesourcery.com> wrote: > > >Thank you for this bug report. I've reproduced the problem, and > >confirm your analysis. I'm going to do a complete bootstrap+test > >cycle on a slight modification of your patch (see below) and will > >apply to mainline if successful. > > I think we need to figure out if this is a regression before applying > it to the branch. Just in case. If it is a regression, it's fine. Reproducing the bug is a bit tricky; I have to instrument the buggy routine and then adjust the filler text in the test case by hand. 3.0, 3.2 (nee 3.1), and mainline all want different lengths of filler text. I can say that I reproduced the bug under laboratory conditions using top of trunk and top of 3.2 (nee 3.1) branch, and that the same procedure fails to provoke a bug using the top of the 3.0 branch, where the memory allocation code is different. I can also say that 2.95, being the last release to use cccp.c, handled stringification quite differently and is unlikely to have this bug. I haven't managed to reproduce the bug "in the wild" - i.e. using compilers I didn't build myself, or without instrumentation and tweaking. However, we have the original report from the FreeBSD people to say that it does occur in the wild. Is that good enough to call this a regression? zw
next reply other threads:[~2002-09-27 22:16 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-09-27 15:16 Zack Weinberg [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-10-04 11:46 Neil Booth 2002-09-27 15:56 Mark Mitchell 2002-09-27 13:56 Mark Mitchell 2002-09-27 13:16 Alexander Kabaev 2002-09-27 12:56 Zack Weinberg 2002-09-26 8:26 ak03
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=20020927221602.17862.qmail@sources.redhat.com \ --to=zack@codesourcery.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@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).