public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: [patch] Re: preprocessor/2706: #defines expanded when -fpreprocessed given
@ 2001-05-04  0:16 Zack Weinberg
  0 siblings, 0 replies; 2+ messages in thread
From: Zack Weinberg @ 2001-05-04  0:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: Nathan Sidwell <sidwell@codesourcery.com>, gcc-gnats@gcc.gnu.org,
   gcc-patches@gcc.gnu.org
Subject: Re: [patch] Re: preprocessor/2706: #defines expanded when -fpreprocessed given
Date: Fri, 4 May 2001 00:06:26 -0700

 On Fri, May 04, 2001 at 07:30:34AM +0100, Neil Booth wrote:
 > Zack Weinberg wrote:-
 > 
 > > It breaks c-torture/execute/920730-1t.c.  The traditional preprocessor
 > > doesn't recognize #include_next (in our limits.h), and passes it
 > > through to the compiler, which rejects it.
 > 
 > That's curious.  So it was only succeeding before because the integrated
 > CPP was processing a #include_next ignored by tradcpp?
 
 #include_next doesn't have IN_I.  It was succeeding because integrated
 CPP was *ignoring* it.
 
 GCC's limits.h and glibc's limits.h interact in a fashion which is
 probably illegal in the State of Georgia.  The upshot is that the test
 case gets all the info it needs without the #include_next operating.
 
 > I'll try to get tradcpp to do include_next in the next day or so, but
 > I'm a bit short of spare time at the moment.
 
 It shouldn't be too hard.  The difficulty is that the code to parse
 the directive, the code to scan the include path, and possibly the
 code to read the file are all tangled together in one huge function.
 *sigh*  If you don't get to it by Sunday I'll give it a shot, but
 tomorrow and Saturday are already booked solid.
 
 > Can we now close PR2706?
 
 My patch hasn't been applied yet.  I still need to test it on the
 mainline, and we need regression suite entries.
 
 zw


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [patch] Re: preprocessor/2706: #defines expanded when -fpreprocessed given
@ 2001-05-03 23:36 Neil Booth
  0 siblings, 0 replies; 2+ messages in thread
From: Neil Booth @ 2001-05-03 23:36 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zackw@Stanford.EDU>
Cc: Nathan Sidwell <sidwell@codesourcery.com>, gcc-gnats@gcc.gnu.org,
	gcc-patches@gcc.gnu.org
Subject: Re: [patch] Re: preprocessor/2706: #defines expanded when -fpreprocessed given
Date: Fri, 4 May 2001 07:30:34 +0100

 Zack Weinberg wrote:-
 
 > It breaks c-torture/execute/920730-1t.c.  The traditional preprocessor
 > doesn't recognize #include_next (in our limits.h), and passes it
 > through to the compiler, which rejects it.
 
 That's curious.  So it was only succeeding before because the integrated
 CPP was processing a #include_next ignored by tradcpp?
 
 I'll try to get tradcpp to do include_next in the next day or so, but
 I'm a bit short of spare time at the moment.
 
 Can we now close PR2706?
 
 Neil.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-05-04  0:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-04  0:16 [patch] Re: preprocessor/2706: #defines expanded when -fpreprocessed given Zack Weinberg
  -- strict thread matches above, loose matches on Subject: below --
2001-05-03 23:36 Neil Booth

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).