RE: preprocessor/6084: cpp Segmentation Fault

RE: preprocessor/6084: cpp Segmentation Fault

[Gerwin, Joshua A]

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

Re: preprocessor/6084: cpp Segmentation Fault

[neil]

Synopsis: cpp Segmentation Fault

State-Changed-From-To: feedback->closed
State-Changed-By: neil
State-Changed-When: Tue May 21 13:34:26 2002
State-Changed-Why:
    Fixed I believe.

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

Re: preprocessor/6084: cpp Segmentation Fault

[neil]

Synopsis: cpp Segmentation Fault

State-Changed-From-To: closed->feedback
State-Changed-By: neil
State-Changed-When: Tue May 21 13:33:19 2002
State-Changed-Why:
    I think you'll find this is fixed in 3.1; Jakub found
    a fixed something suspiciously similar.

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

Re: preprocessor/6084: cpp Segmentation Fault

[neil]

Synopsis: cpp Segmentation Fault

State-Changed-From-To: feedback->closed
State-Changed-By: neil
State-Changed-When: Wed Apr 17 23:52:55 2002
State-Changed-Why:
    It appears quite likely that this bug is not due to CPP, but
    a compiler or environment problem.  If you manage to find
    out any more about what is causing it, particularly if it's
    CPP-related, I'll happily re-open this PR.

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

RE: preprocessor/6084: cpp Segmentation Fault

[Gerwin, Joshua A]

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: "'Richard Henderson'" <rth@redhat.com>
Cc: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
   "'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 19:38:17 -0700

 > -----Original Message-----
 > From: Richard Henderson [mailto:rth@redhat.com]
 > Sent: Monday, April 15, 2002 6:06 PM
 > To: Gerwin, Joshua A
 > Cc: 'Neil Booth'; '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
 > 
 > 
 > On Mon, Apr 15, 2002 at 11:25:25AM -0700, Gerwin, Joshua A wrote:
 > > (gdb) break maybe_print_line
 > > Cannot access memory at address 0x3c28
 > 
 > You built the compiler as a 64-bit binary didn't you?
 
 Clearly this is something not to be taken on lightly...Actually, a co-worker
 built the compiler, it is 64-bit. I did build the debugger as 64-bit,
 though.  
 
 > 
 > (1) 64-bit sparc code isn't stable in gcc 3.0,
 
 Oops... 
 
 > (2) Use -mcmodel=medlow to link the application below 4GB so
 >     that stabs debugging can function properly.
 > 
 
 Thanks.  This could help quite a bit.  
 
 > 
 > r~
 > 
 
 Josh Gerwin, System Programmer/Analyst
 joshua.a.gerwin@intel.com
 Intel Corp.
 NorthWest Engineering Computing

Re: preprocessor/6084: cpp Segmentation Fault

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
   "'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 18:05:36 -0700

 On Mon, Apr 15, 2002 at 11:25:25AM -0700, Gerwin, Joshua A wrote:
 > (gdb) break maybe_print_line
 > Cannot access memory at address 0x3c28
 
 You built the compiler as a 64-bit binary didn't you?
 
 (1) 64-bit sparc code isn't stable in gcc 3.0,
 (2) Use -mcmodel=medlow to link the application below 4GB so
     that stabs debugging can function properly.
 
 
 r~

Re: preprocessor/6084: cpp Segmentation Fault

['Neil Booth']

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

From: 'Neil Booth' <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>, gcc-gnats@gcc.gnu.org,
	gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Mon, 15 Apr 2002 19:56:55 +0100

 Gerwin, Joshua A wrote:-
 
 > I would if I could, but the debugger often reports back that it can't get at
 > the variables in question.
 > 
 > (gdb) info mem
 > Num Enb Low Addr           High Addr          Attrs 
 > 2   y   0x000000010000349c 0x0000000100012344 rw nocache 
 > 1   y   0x000000000011b018 0x0000000000120000 rw nocache 
 > (gdb) break maybe_print_line
 > Cannot access memory at address 0x3c28
 > 
 > for instance.  This prohibition is applied to display, print, and trace as
 > well.  I've had some success in getting DDD to sneak in there, and I'll see
 > if I can convince it can put a display on the print structure. 
 
 Does it occur if you compile cpp0 without optimization?
 
 Neil.

RE: preprocessor/6084: cpp Segmentation Fault

[Gerwin, Joshua A]

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:25:25 -0700

 > -----Original Message-----
 > From: 'Neil Booth' [mailto:neil@daikokuya.demon.co.uk]
 > Sent: Monday, April 15, 2002 11:16 AM
 > 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:-
 > 
 > > 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.
 > 
 > OK.  Why can't you give me more info?  Like the variables in question;
 > clearly one is NULL?  Maybe investigate why it is NULL in this case
 > and not when you switch command line args?  It would save us 
 > both a lot
 > of time.
 > 
 > Neil.
 > 
 I would if I could, but the debugger often reports back that it can't get at
 the variables in question.
 
 (gdb) info mem
 Num Enb Low Addr           High Addr          Attrs 
 2   y   0x000000010000349c 0x0000000100012344 rw nocache 
 1   y   0x000000000011b018 0x0000000000120000 rw nocache 
 (gdb) break maybe_print_line
 Cannot access memory at address 0x3c28
 
 for instance.  This prohibition is applied to display, print, and trace as
 well.  I've had some success in getting DDD to sneak in there, and I'll see
 if I can convince it can put a display on the print structure. 
 
 -- Josh 

Re: preprocessor/6084: cpp Segmentation Fault

['Neil Booth']

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

From: 'Neil Booth' <neil@daikokuya.demon.co.uk>
To: "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 19:15:40 +0100

 Gerwin, Joshua A wrote:-
 
 > 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.
 
 OK.  Why can't you give me more info?  Like the variables in question;
 clearly one is NULL?  Maybe investigate why it is NULL in this case
 and not when you switch command line args?  It would save us both a lot
 of time.
 
 Neil.

Re: preprocessor/6084: cpp Segmentation Fault

[Phil Edwards]

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

From: Phil Edwards <phil@jaj.com>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: joshg@hf.intel.com, gcc-gnats@gcc.gnu.org, rnesius@ichips.intel.com,
   "Nguyen, Tuan" <tuan.nguyen@intel.com>, gcc-bugs@gcc.gnu.org,
   neil@daikokuya.demon.co.uk
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Sat, 13 Apr 2002 04:20:53 -0400

 On Fri, Apr 12, 2002 at 03:57:12PM -0700, Gerwin, Joshua A wrote:
 > My hunch is that this is either a 3.0 problem, perhaps fixed in your version
 > of 3.1, or that the libc.so we're linking during compile is significantly
 > different.
 
 During compile of...?  The compiler itself?  If your libc.so were that
 broken, I'd expect much bigger breakage much earlier.
 
 
 > Program received signal SIGSEGV, Segmentation fault.
 > 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 > (gdb) bt
 > #0  0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 > #1  0xffffffff7f48d6d4 in _doprnt () from /usr/lib/64/libc.so.1
 > #2  0xffffffff7f48f180 in fprintf () from /usr/lib/64/libc.so.1
 
 Something is very weird here.  I don't recall a "/usr/lib/64" directory under
 SPARC/Solaris 7.  The 64-bit version should be /usr/lib/sparcv9/libc.so.1.
 
 
 Phil
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: preprocessor/6084: cpp Segmentation Fault

[Phil Edwards]

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

From: Phil Edwards <phil@jaj.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: "Gerwin, Joshua A" <joshua.a.gerwin@intel.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: Sat, 13 Apr 2002 04:15:28 -0400

 On Sat, Apr 13, 2002 at 06:07:26AM +0100, Neil Booth wrote:
 > Phil, could I ask you to try what Joshua claims above on 3.0 branch,
 > if you still have it lying around?
 
 I do (3.0.2), but all the machines are tied up for the next day and a half.
 Will test then.
 
 
 Phil
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: preprocessor/6084: cpp Segmentation Fault

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: "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: Sat, 13 Apr 2002 06:07:26 +0100

 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.
 
 > 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.
 
 > Here's the maybe_print_line function and related symbols, for handy
 > reference:
 
 I have the source on my machine, and the types, so this doesn't help.
 What does help is you backing up the call stack and finding out why
 the segfault is happening (and the offending variable at the time).
 
 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.

RE: preprocessor/6084: cpp Segmentation Fault

[Gerwin, Joshua A]

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: "'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, neil@daikokuya.demon.co.uk
Cc:  
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Fri, 12 Apr 2002 15:57:12 -0700

 > -----Original Message-----
 > From: Phil Edwards [mailto:phil@jaj.com]
 > Sent: Friday, April 12, 2002 1:27 PM
 > To: joshg@hf.intel.com; gcc-gnats@gcc.gnu.org; 
 > rnesius@ichips.intel.com;
 > tuan.nguyen@intel.com; gcc-bugs@gcc.gnu.org; 
 > neil@daikokuya.demon.co.uk
 > Subject: Re: preprocessor/6084: cpp Segmentation Fault
 > 
 > 
 > I haven't been able to reproduce this using today's 3.1 
 > sources.  (More at
 > the end.)
 > 
 My hunch is that this is either a 3.0 problem, perhaps fixed in your version
 of 3.1, or that the libc.so we're linking during compile is significantly
 different.  Note that I could produce a segfault in strlen with minimal
 options and no source at all, simply by having both -dD and -DM present.
 
 %cat empty.c
 /* no source */
 %which cpp
 /path/to/gcc/3.0.3-64/bin/cpp
 %cpp -dM -dD empty.c
 cpp: Internal error: Segmentation Fault (program cpp0)
 Please submit a full bug report.
 See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
 
 Running gcc, I observe
 
 (gdb) file /path/to/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0
 Load new symbol table from
 "/path/to/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0"? (y or
 n) y
 
 Reading symbols from
 /path/to/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0...done.
 (gdb) run -dM -dD empty.c
 Starting program:
 /path/to/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dM -dD
 empty.c
 
 Program received signal SIGSEGV, Segmentation fault.
 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 (gdb) bt
 #0  0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 #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 ()
 (gdb) 
 
 Also noteworthy, reversing the parameters fixes the segfault!
 
 (gdb) run -dD -dM
 The program being debugged has been started already.
 Start it from the beginning? (y or n) y
 Starting program:
 /usr/intel/pkgs/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dD
 -dM
 ^D
 #define __USER_LABEL_PREFIX__
 #define __HAVE_BUILTIN_SETJMP__ 1
 #define __REGISTER_PREFIX__
 #define __VERSION__ "3.0.3"
 
 Program exited normally.
 (gdb) run -dM -dD
 Starting program:
 /usr/intel/pkgs/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dM
 -dD
 ^D
 Program received signal SIGSEGV, Segmentation fault.
 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 
 Here's the maybe_print_line function and related symbols, for handy
 reference:
 
 static void
 maybe_print_line (line)
      unsigned int line;
 {
   /* End the previous line of text (probably only needed until we get
      multi-line tokens fixed).  */
   if (print.printed)
     {
       putc ('\n', print.outf);
       print.lineno++;
       print.printed = 0;
     }
 
   if (options->no_line_commands)
     {
       print.lineno = line;
       return;
     }
 
   /* print.lineno is zero if this is the first token of the file.  We
      handle this specially, so that a first line of "# 1 "foo.c" in
      file foo.i outputs just the foo.c line, and not a foo.i line.  */
   if (line >= print.lineno && line < print.lineno + 8 && print.lineno)
     {
       while (line > print.lineno)
         {
           putc ('\n', print.outf);
           print.lineno++;
         }
     }
   else
     {
       print.lineno = line;
       print_line ("");
     }
 }
 
 static void
 print_line (special_flags)
   const char *special_flags;
 {
   /* End any previous line of text.  */
   if (print.printed)
     putc ('\n', print.outf);
   print.printed = 0;
 
   fprintf (print.outf, "# %u \"%s\"%s%s\n",
            print.lineno, print.last_fname, special_flags,
 print.syshdr_flags);
 }
 
 (gdb) whatis print
 type = struct printer
 (gdb) ptype struct printer
 type = struct printer {
     FILE *outf;
     char *last_fname;
     char *syshdr_flags;
     unsigned int lineno;
     unsigned char printed;
 }
 
 This is about all the source diving I can do for it today.
 
 Josh Gerwin, System Programmer/Analyst
 joshua.a.gerwin@intel.com
 Intel Corp.
 NorthWest Engineering Computing

Re: preprocessor/6084: cpp Segmentation Fault

[Phil Edwards]

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

From: Phil Edwards <phil@jaj.com>
To: joshg@hf.intel.com, gcc-gnats@gcc.gnu.org, rnesius@ichips.intel.com,
   tuan.nguyen@intel.com, gcc-bugs@gcc.gnu.org, neil@daikokuya.demon.co.uk
Cc:  
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Fri, 12 Apr 2002 16:27:07 -0400

 I haven't been able to reproduce this using today's 3.1 sources.  (More at
 the end.)
 
 55% cat 6084_hello.c
 #include <stdio.h>
 #ifdef MATHTEST
 #include <math.h>
 #endif
 
 main()
 {
  float X;
  printf("Hello, World! \n");
  #ifdef MATHTEST
  X = sqrt(4);
  printf("the sqrt of 4 is %f \n", X);
  #endif
 }
 
 56% gcc -DPERL_CORE -fno-strict-aliasing -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mcpu=v9 -m64 -Wa,-xarch=v9 -O3 -m64 -dM -dD -dI -v 6084_hello.c
 Reading specs from /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/specs
 Configured with: /local/pme/unified/configure --prefix=/local/pme/instdir-v9 --enable-languages=c sparcv9-sun-solaris2.8
 Thread model: posix
 gcc version 3.1 20020412 (prerelease)
  /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=long unsigned int -D__PTRDIFF_TYPE__=long int -D__WCHAR_TYPE__=int -D__WINT_TYPE__=int -D__arch64__ -Acpu=sparc64 -Amachin e=sparcv9 -D__sparcv9 -DPERL_CORE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 6084_hello.c -quiet -dumpbase 6084_hello.c -dM -dD -dI -mcpu=v9 -m64 -m64 -O3 -version -fno-strict-aliasing -o /tmp/pedwards/ccGyKzGh.s
 GNU CPP version 3.1 20020412 (prerelease) (cpplib) (sparc ELF)
 GNU C version 3.1 20020412 (prerelease) (sparcv9-sun-solaris2.8)
         compiled by GNU C version 3.1 20020412 (prerelease).
 ignoring nonexistent directory "/local/pme/instdir-v9/sparcv9-sun-solaris2.8/include"
 #include "..." search starts here:
 #include <...> search starts here:
  /usr/local/include
  /local/pme/instdir-v9/include
  /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/include
  /usr/include
 End of search list.
  /usr/ccs/bin/as -V -Qy -s -xarch=v9 -xarch=v9 -o /tmp/pedwards/ccLEQgFp.o /tmp/pedwards/ccGyKzGh.s
 /usr/ccs/bin/as: Sun WorkShop 6 99/08/18
  /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/collect2 -V -Y P,/usr/lib/sparcv9 -Qy /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crt1.o /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crti.o /usr/lib/sparcv9/values-Xa.o /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crtbegin.o -L/local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1 -L/usr/ccs/bin -L/usr/ccs/lib -L/local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/../../.. /tmp/pedw ards/ccLEQgFp.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crtend.o /local/pme/instdir-v9/lib/gcc-lib/sparcv9-sun-solaris2.8/3.1/crtn.o
 ld: Software Generation Utilities - Solaris-ELF (4.0)
 57%
 
 
 A few observations that probably make no difference to this PR:
 
 - I note that you configured your compiler for "sparcv9-sun-solaris2".
   Usually the final bit is a complete OS version, like 2.7 or 2.8.
 
 - Your system was reported as
     SunOS 5.7 Generic_106541-19 sun4u sparc SUNW,Ultra-2
   The one I used to test is
     SunOS 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-30
 
 - You mentioned you were using NFS and AFS.  My test was all local.
 
 
 Phil
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: preprocessor/6084: cpp Segmentation Fault

['Neil Booth']

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

From: 'Neil Booth' <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
	"'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
	"'joshg@hf.intel.com'" <joshg@hf.intel.com>,
	"'rnesius@ichips.intel.com'" <rnesius@ichips.intel.com>,
	"Nguyen, Tuan" <tuan.nguyen@intel.com>,
	"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Thu, 4 Apr 2002 07:27:00 +0100

 Gerwin, Joshua A wrote:-
 
 > (gdb) run -dM -dD ../accessories/hello.c
 > Starting program:
 > /(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dM -dD
 > ../accessories/hello.c
 > 
 > Program received signal SIGSEGV, Segmentation fault.
 > 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 > (gdb) bt
 > #0  0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 > #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 ()
 
 That's curious, because there is no fprintf in my version of 3.0.3
 in maybe_print_line.  Have you patched yours from stock 3.0.3?
 
 Could you do some more research - I have no clue from the above
 backtrace.  Maybe step in yourself and see what's going wrong?
 
 Neil.

RE: preprocessor/6084: cpp Segmentation Fault

[Gerwin, Joshua A]

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>
Cc: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
   "'gcc-bugs@gcc.gnu.org'"<gcc-bugs@gcc.gnu.org>,
   "'joshg@hf.intel.com'" <joshg@hf.intel.com>,
   "'rnesius@ichips.intel.com'" <rnesius@ichips.intel.com>,
   "Nguyen, Tuan"<tuan.nguyen@intel.com>,
   "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Wed, 3 Apr 2002 16:57:40 -0800 

 I bit the bullet, built gdb on the 64-bit solaris 2.7 platform, and here's
 what I see:
 
 (gdb) run -dM -dD ../accessories/hello.c
 Starting program:
 /(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -dM -dD
 ../accessories/hello.c
 
 Program received signal SIGSEGV, Segmentation fault.
 0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 (gdb) bt
 #0  0xffffffff7f44035c in strlen () from /usr/lib/64/libc.so.1
 #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 ()
 (gdb) 
 
 > -----Original Message-----
 > From: Neil Booth [mailto:neil@daikokuya.demon.co.uk]
 > Sent: Tuesday, April 02, 2002 10:26 PM
 > To: Gerwin, Joshua A
 > Cc: 'neil@gcc.gnu.org'; 'gcc-bugs@gcc.gnu.org'; 'joshg@hf.intel.com';
 > 'rnesius@ichips.intel.com'; Nguyen, Tuan; 'gcc-gnats@gcc.gnu.org'
 > Subject: Re: preprocessor/6084: cpp Segmentation Fault
 > 
 > 
 > So, do you have a backtrace?  All you need to do is run the program
 > cpp0 within GDB, with the command line arguments you gave, and
 > when it segfaults give the "bt" command.
 > 
 > Neil.
 > 

Re: preprocessor/6084: cpp Segmentation Fault

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
	"'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
	"'joshg@hf.intel.com'" <joshg@hf.intel.com>,
	"'rnesius@ichips.intel.com'" <rnesius@ichips.intel.com>,
	"Nguyen, Tuan" <tuan.nguyen@intel.com>,
	"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Wed, 3 Apr 2002 07:26:29 +0100

 So, do you have a backtrace?  All you need to do is run the program
 cpp0 within GDB, with the command line arguments you gave, and
 when it segfaults give the "bt" command.
 
 Neil.

Re: preprocessor/6084: cpp Segmentation Fault

[Neil Booth]

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: "Gerwin, Joshua A" <joshua.a.gerwin@intel.com>
Cc: "'neil@gcc.gnu.org'" <neil@gcc.gnu.org>,
	"'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
	"'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
	"'joshg@hf.intel.com'" <joshg@hf.intel.com>,
	"'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>,
	"'rnesius@ichips.intel.com'" <rnesius@ichips.intel.com>,
	"Nguyen, Tuan" <tuan.nguyen@intel.com>,
	"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: Re: preprocessor/6084: cpp Segmentation Fault
Date: Fri, 29 Mar 2002 20:06:38 +0000

 Gerwin, Joshua A wrote:-
 
 > A minor experiment in option removal shows that the problem is potentially
 > tied to the 
 > -dD tag.  Compare:
 > 
 [...]
 > 
 > A clue, no?
 
 A clue, but not much more.  Sadly I can't reproduce the issue on x86
 Linux.
 
 Would you mind running it through gdb, and giving a backtrace of the
 line it segfaults on, and any relevant-looking variables?
 
 Thanks,
 
 Neil.

RE: preprocessor/6084: cpp Segmentation Fault

[Gerwin, Joshua A]

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@gcc.gnu.org'" <neil@gcc.gnu.org>,
   "'gcc-bugs@gcc.gnu.org'"<gcc-bugs@gcc.gnu.org>,
   "'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
   "'joshg@hf.intel.com'" <joshg@hf.intel.com>,
   "'nobody@gcc.gnu.org'"<nobody@gcc.gnu.org>,
   "'rnesius@ichips.intel.com'"<rnesius@ichips.intel.com>,
   "Nguyen, Tuan" <tuan.nguyen@intel.com>,
   "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: RE: preprocessor/6084: cpp Segmentation Fault
Date: Fri, 29 Mar 2002 11:35:17 -0800

 > -----Original Message-----
 > From: neil@gcc.gnu.org [mailto:neil@gcc.gnu.org]
 > Sent: Friday, March 29, 2002 12:20 AM
 > To: gcc-bugs@gcc.gnu.org; gcc-prs@gcc.gnu.org; joshg@hf.intel.com;
 > nobody@gcc.gnu.org; rnesius@ichips.intel.com; tuan.nguyen@intel.com
 > Subject: Re: preprocessor/6084: cpp Segmentation Fault
 > 
 > 
 > Synopsis: cpp Segmentation Fault
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: neil
 > State-Changed-When: Fri Mar 29 00:20:22 2002
 > State-Changed-Why:
 >     Changed to category preprocessor; not a front end issue.
 >     
 >     Quite a surpise to me, too.  I take pride in cpp not 
 > segfaulting 8-)
 >     
 >     Could you give me a testcase?  I can't reproduce it with
 >     the information supplied.
 >     Or, could you try 3.0.4?  There was a segfault fixed in the
 >     later 3.0 cycle, triggered by a combination of command
 >     line options, but I'm not sure which 3.0.x got it.
 >     Judging by your command line, I suspect it is caused by
 >     a certain combination of switches; can you reproduce it
 >     on a simple file like #include <stdio.h> or something?
 >     
 >     Alternatively, if you can't produce a simple testcase, 
 > but can get it to happen on Linux, then please send me the 
 > files so I can track this down, or tell me where it happens 
 > when you're debugging the cpp0 binary.
 >     
 >     Thanks!
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&
 database=gcc&pr=6084
 
 Sorry about the category thing, I didn't notice a preprocessor category on
 the submit form.  
 
 The first sighting of the cpp segfault was in a troublesome build of op.c in
 the vanilla perl 5.6.1 distribution from CPAN.  However, you need not go
 there.  Using the same command line options, I can get it to segfault
 without any source at all, simply by using ^D for stdin.  Since an empty
 file may be aesthetically unsatisfying, I submit the following:
 
 $ cat ../../../../accessories/hello.c 
 #include <stdio.h>
 #ifdef MATHTEST
 #include <math.h>
 #endif
 
 main() {
 float X;
 printf("Hello, World! \n");
 #ifdef MATHTEST
 X = sqrt(4);
 printf("the sqrt of 4 is %f \n", X);
 #endif
 }
 
 $ /(path/to)/gcc/3.0.3-64/bin/cpp -DPERL_CORE -fno-strict-aliasing
 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mcpu=v9 -m64 -Wa,-xarch=v9 -O3
 -m64 -dM -dD -dI -v ../../../../accessories/hello.c
 Reading specs from
 /(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/specs
 Configured with: ../gcc-3.0.3/configure --host=sparcv9-sun-solaris2
 --prefix=
 /(path/to)/gcc/3.0.3-64 --with-as=/usr/ccs/bin/as
 --with-nm=/(path/to)/gcc/3.0.3-64/bin/nm --with-ld=/usr/ccs/bin/ld
 Thread model: posix
 gcc version 3.0.3
  /(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/cpp0 -lang-c
 -v -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__
 -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4
 -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -dM -dD -dI -D__SIZE_TYPE__=long unsigned
 int -D__PTRDIFF_TYPE__=long int -D__WCHAR_TYPE__=int -D__WINT_TYPE__=int
 -D__arch64__ -Acpu=sparc64 -Amachine=sparcv9 -D__sparcv9 -DPERL_CORE
 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 ../../../../accessories/hello.c
 GNU CPP version 3.0.3 (cpplib) (sparc)
 ignoring nonexistent directory
 "/(path/to)/gcc/3.0.3-64/sparcv9-sun-solaris2/include"
 #include "..." search starts here:
 #include <...> search starts here:
  /usr/local/include
  /(path/to)/gcc/3.0.3-64/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/include
  /usr/include
 End of search list.
 cpp: Internal error: Segmentation Fault (program cpp0)
 Please submit a full bug report.
 See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
 
 A minor experiment in option removal shows that the problem is potentially
 tied to the 
 -dD tag.  Compare:
 
 $ /(path/to)/gcc/3.0.3-64/bin/cpp -mcpu=v9 -m64 -Wa,-xarch=v9 -O3 -m64 -dM
 -dD ../../../../accessories/hello.c
 cpp: Internal error: Segmentation Fault (program cpp0)
 Please submit a full bug report.
 See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
 
 $ /usr/intel/pkgs/gcc/3.0.3-64/bin/cpp -mcpu=v9 -m64 -Wa,-xarch=v9 -O3 -m64
 -dM ../../../../accessories/hello.c
 #define __USER_LABEL_PREFIX__
 #define _LONG_LONG_HTOL
 #define __SIZE_TYPE__ long unsigned int
 #define _LONG_ALIGNMENT 8
 #define _LONG_DOUBLE_ALIGNMENT 16
 #define P_tmpdir "/var/tmp/"
 #define _SSIZE_T
 #define __arch64__ 1
 #define __PTRDIFF_TYPE__ long int
 #define _FILE_OFFSET_BITS 64
 #define _ALIGNMENT_REQUIRED 1
 #define __HAVE_BUILTIN_SETJMP__ 1
 #define _SHORT_ALIGNMENT 2
 #define SEEK_SET 0
 #define _DOUBLE_ALIGNMENT 8
 #define freopen64 freopen
 #define putchar(x) putc((x), stdout)
 #define ftello64 ftello
 #define _NO_FDISK_PRESENT
 #define _BIT_FIELDS_HTOL
 #define _LONG_LONG_ALIGNMENT 8
 etcetera etcetera etcetera
 
 A clue, no?
 
 Josh Gerwin, System Programmer/Analyst
 joshua.a.gerwin@intel.com
 Intel Corp.
 NorthWest Engineering Computing

Re: preprocessor/6084: cpp Segmentation Fault

[neil]

Synopsis: cpp Segmentation Fault

State-Changed-From-To: open->feedback
State-Changed-By: neil
State-Changed-When: Fri Mar 29 00:20:22 2002
State-Changed-Why:
    Changed to category preprocessor; not a front end issue.
    
    Quite a surpise to me, too.  I take pride in cpp not segfaulting 8-)
    
    Could you give me a testcase?  I can't reproduce it with
    the information supplied.
    Or, could you try 3.0.4?  There was a segfault fixed in the
    later 3.0 cycle, triggered by a combination of command
    line options, but I'm not sure which 3.0.x got it.
    Judging by your command line, I suspect it is caused by
    a certain combination of switches; can you reproduce it
    on a simple file like #include <stdio.h> or something?
    
    Alternatively, if you can't produce a simple testcase, but can get it to happen on Linux, then please send me the files so I can track this down, or tell me where it happens when you're debugging the cpp0 binary.
    
    Thanks!

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