From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19141 invoked by alias); 7 Nov 2002 23:38:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 19121 invoked from network); 7 Nov 2002 23:38:23 -0000 Received: from unknown (HELO monkey.daikokuya.co.uk) (213.152.55.49) by sources.redhat.com with SMTP; 7 Nov 2002 23:38:23 -0000 Received: from neil by monkey.daikokuya.co.uk with local (Exim 3.36 #1 (Debian)) id 189wE7-0006MQ-00; Thu, 07 Nov 2002 23:38:19 +0000 Date: Thu, 07 Nov 2002 15:38:00 -0000 From: Neil Booth To: Richard Henderson , gcc-patches@gcc.gnu.org, Roland McGrath Subject: Re: [CPP] -M vs -include Message-ID: <20021107233819.GA23967@daikokuya.co.uk> References: <20021102142400.A2249@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021102142400.A2249@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00517.txt.bz2 Richard Henderson wrote:- > The following test case: > > % echo > x.h > % echo > z.h > % echo '#include "z.h"' > z.c > % gcc -M -include x.h z.c > > produced > > z.o: z.c x.h > > instead of the expected > > z.o: z.c x.h z.h > > This caused the dependencies created by glibc to be wrong, which > leads to extremely irritating non-recompilation errors. > > The following patch appears to cure the problem. Neil, can you > comment on why you added this in the first place? cpp_scan_nooutput's semantics are to return when the current buffer (and anything it includes) have been scanned; this is why it sets return_at_eof. This is what we need for -imacros; with your suggested patch -imacros would not stop after the first -imacros file; it would continue its scan and only get its CPP_EOF at the end of the main file. Oops. The bug is that cpp_preprocess_file in cppmain.c is assuming, in calling cpp_scan_nooutput the way it does, that the current buffer is the main file, and so that when the current buffer is finished, the whole job is done. In the presence of -include, that is not true, as _cpp_maybe_push_include_file has put the first -included file on top of the main file and made it the current one. Easily fixed by forcing cpp_preprocess_file to loop until it really has done all the buffers. I seem to recall removing this loop thinking it didn't achieve anything. Heh. The loop condition sucks; I'll do something better for 3.4. Thanks for finding this issue. I'll apply the patch after a bootstrap etc. Neil. * cppmain.c (cpp_preprocess_file): Loop to pop any -included buffers. Index: cppmain.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cppmain.c,v retrieving revision 1.104 diff -u -p -r1.104 cppmain.c --- cppmain.c 12 Aug 2002 17:21:52 -0000 1.104 +++ cppmain.c 7 Nov 2002 23:35:42 -0000 @@ -78,7 +78,13 @@ cpp_preprocess_file (pfile, in_fname, ou /* A successful cpp_read_main_file guarantees that we can call cpp_scan_nooutput or cpp_get_token next. */ if (options->no_output) - cpp_scan_nooutput (pfile); + { + /* Loop in case of -included buffers. */ + do + cpp_scan_nooutput (pfile); + while (pfile->buffer->prev + || pfile->buffer->cur < pfile->buffer->rlimit); + } else if (options->traditional) scan_translation_unit_trad (pfile); else