public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 11:06:00 -0000	[thread overview]
Message-ID: <20020415180603.19617.qmail@sources.redhat.com> (raw)

The following reply was made to PR preprocessor/6084; it has been noted by GNATS.

From: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
To: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
   "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'Phil Edwards'" <phil@jaj.com>, joshg@hf.intel.com, gcc-gnats@gcc.gnu.org,
   rnesius@ichips.intel.com, "Nguyen, Tuan"<tuan.nguyen@intel.com>,
   gcc-bugs@gcc.gnu.org
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 11:02:43 -0700

 > -----Original Message-----
 > From: Neil Booth [mailto:neil@daikokuya.demon.co.uk]
 > Sent: Friday, April 12, 2002 10:07 PM
 > To: Gerwin, Joshua A
 > Cc: 'Phil Edwards'; joshg@hf.intel.com; gcc-gnats@gcc.gnu.org;
 > rnesius@ichips.intel.com; Nguyen, Tuan; gcc-bugs@gcc.gnu.org
 > Subject: Re: preprocessor/6084: cpp Segmentation Fault
 > 
 > 
 > Gerwin, Joshua A wrote:-
 > 
 > > #1  0xffffffff7f48d6d4 in _doprnt () from /usr/lib/64/libc.so.1
 > > #2  0xffffffff7f48f180 in fprintf () from /usr/lib/64/libc.so.1
 > > #3  0x100003d28 in maybe_print_line ()
 > > #4  0x100003e1c in cb_define ()
 > > #5  0x100004904 in do_define ()
 > > #6  0x100004778 in run_directive ()
 > > #7  0x100011d20 in init_builtins ()
 > > #8  0x100012344 in cpp_start_read ()
 > > #9  0x100003680 in do_preprocessing ()
 > > #10 0x10000349c in main ()
 > 
 > As I've already pointed out to you, and you confirmed with your
 > mail, there is no fprintf() in the function maybe_print_line.
 > 
 
 OK, here's my theory as to why I think you aren't seeing it in
 maybe_print_line.  Often when we compile, we use an optimizing flag (admit
 it, you do this sometimes too!) and in this case the optimizer dropped the
 jump to the separate print_line function and put the fprintf directly in
 maybe_print_line.  So in cppmain.c (line 329 by my reckoning), effectively
 substitute 
 
     else
     {
       print.lineno = line;
       print_line ("");
     }
 
 with 
 
     else
     {
       print.lineno = line;
       if (print.printed) putc ('\n', print.outf);
       print.printed = 0;
       fprintf (print.outf, "# %u \"%s\"%s%s\n",
            print.lineno, print.last_fname, "", print.syshdr_flags);
     }
  
 This saves a subroutine call.
 
 > > Also noteworthy, reversing the parameters fixes the segfault!
 > 
 > That makes me even more suspicious that something is very wrong
 > with your env.  Exactly the same code should be running, with the
 > same internal state, once you get to do_preprocessing()
 > when you flip the order.
 
 Right.  I wouldn't be a bit surprised if something is very wrong with this
 platform environment.  I've been doing compiles on Solaris 5.8 that work
 flawlessly, when they break down on Solaris 2.7 for what appears to be No
 Good Reason.  
 
 > 
 > Phil, could I ask you to try what Joshua claims above on 3.0 branch,
 > if you still have it lying around?  If you still can't get anything,
 > I'll close this PR, since it is unreproducable with a seemingly
 > impossible backtrace.
 > 
 > Thanks a lot,
 > 
 > Neil.
 > 
 
 While I respectfully disagree that it's completely impossible, and it is
 reproducable on at least this particular platform, I will not overly object
 to closing out the PR as it may be specific to some peculiarity of our
 compiler and/or OS environment.  If you think of anything else worth
 checking, let me know.
 
 Thanks for your assistance.
 
 Josh Gerwin, System Programmer/Analyst
 joshua.a.gerwin@intel.com
 Intel Corp.
 NorthWest Engineering Computing


             reply	other threads:[~2002-04-15 18:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-15 11:06 Gerwin, Joshua A [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-05-21 13:34 neil
2002-05-21 13:33 neil
2002-04-17 23:52 neil
2002-04-15 19:46 Gerwin, Joshua A
2002-04-15 18:06 Richard Henderson
2002-04-15 12:06 'Neil Booth'
2002-04-15 11:36 Gerwin, Joshua A
2002-04-15 11:16 'Neil Booth'
2002-04-13  1:26 Phil Edwards
2002-04-13  1:16 Phil Edwards
2002-04-12 22:16 Neil Booth
2002-04-12 16:06 Gerwin, Joshua A
2002-04-12 13:36 Phil Edwards
2002-04-03 22:36 'Neil Booth'
2002-04-03 17:06 Gerwin, Joshua A
2002-04-02 22:36 Neil Booth
2002-03-29 12:16 Neil Booth
2002-03-29 11:36 Gerwin, Joshua A
2002-03-29  0:20 neil

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=20020415180603.19617.qmail@sources.redhat.com \
    --to=joshua.a.gerwin@intel.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: 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).