This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PCH not being used, but I can't tell why
> X-Original-To: geoffk@foam.wonderslug.com
> Date: Tue, 12 Aug 2003 02:19:03 -0400
> From: Phil Edwards <phil@jaj.com>
> Cc: bkoz@redhat.com, gcc@gcc.gnu.org
> Content-Disposition: inline
> User-Agent: Mutt/1.5.3i
> X-OriginalArrivalTime: 12 Aug 2003 06:23:17.0593 (UTC) FILETIME=[37EBB490:01C3609A]
>
> On Mon, Aug 11, 2003 at 05:16:51PM -0700, Geoff Keating wrote:
> > It should be being called from validate_pch in cppfiles.c (as
> > "cb.valid_pch"), right above where the line with the 'x' is printed.
> > The only way it wouldn't be called is if open_file had earlier
> > returned 'false'. Could you see if that's really happening, and if so
> > why open_file is doing that?
>
> Because open_file was passed "." followed by ".." before ever getting to
> an actual file.
>
> if (open_file (file))
> {
> happy things
> }
> else
> file->pch = 2; // 2 == "is not and can never be a valid pch file"
>
> The first attempt to open the .pch file actually finds the .gch directory,
> which then causes a readdir loop, passing each entry to validate_pch,
> but 1) not skipping the pointless directory entries, and 2) not clearing
> the pch flag in each loop.
>
> So, the first probe on "." sets pch = 2, and it's never reset, only examined.
> The rest of the logic relies on (or assumes) that 'file' won't be referring
> to a series of difference files, which is false here.
>
>
> Applying the patch below gives me this:
>
> cc1plus: warning: /mnt/build/build-2003-08-11/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g: not used because `__tune_i686__' not defined
> cc1plus: warning: /mnt/build/build-2003-08-11/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu/bits/stdc++.h.gch/O2g: not used because `__tune_i686__' not defined
>
> ...whatever the fsck that means.
It probably means that there's a -mtune= mismatch between building the
PCH and using it.
> Resetting the pch status flag seems necessary. The skipping of "." and
> ".." isn't needed for correctness as long as the flag is reset, but it does
> speed things up a tad. I don't know cpplib, maybe there's some abstracted
> test that should be used instead of strcmp against string literals, but
> this is the essence of what needs to be done in pch_open_file():
Even this isn't enough; it's possible for a directory to have some
files that are "never valid" and others that are valid. What has to
happen is that the changes to '->pch' are moved into the outer loop.
> Index: cppfiles.c
> ===================================================================
> RCS file: /home/pme/Repositories/GCC/gcc/gcc/cppfiles.c,v
> retrieving revision 1.186
> diff -u -p -r1.186 cppfiles.c
> --- cppfiles.c 9 Aug 2003 22:14:07 -0000 1.186
> +++ cppfiles.c 12 Aug 2003 06:08:09 -0000
> @@ -273,12 +273,16 @@ pch_open_file (cpp_reader *pfile, _cpp_f
> while ((d = readdir (pchdir)) != NULL)
> {
> dlen = strlen (d->d_name) + 1;
> + if ((strcmp (d->d_name, ".") == 0)
> + || (strcmp (d->d_name, "..") == 0))
> + continue;
> if (dlen + plen > len)
> {
> len += dlen + 64;
> pchname = xrealloc (pchname, len);
> }
> memcpy (pchname + plen, d->d_name, dlen);
> + file->pch = 0;
> valid = validate_pch (pfile, file, pchname);
> if (valid)
> break;
>
--
- Geoffrey Keating <geoffk@geoffk.org>