[Bug pch/13218] New: Potential problems with PCH and includes relative to current directory

[Bug pch/13218] New: Potential problems with PCH and includes relative to current directory

[carlo at gcc dot gnu dot org]

There is a potential problem with PCH
when the PCH header file includes other
header files without using absolute paths
(and nobody uses absolute paths, so you
might as well say: when including other
header files), in combination with search
paths for header files that are relative
to the current directory (i.e. -I. -I..)

Namely, when there exist two or more such
header files with the same name, then gcc
does not see that in fact a *different*
headerfile is being included then what
the pch was compiled with.

HOW TO REPEAT

I attached a tar ball that will allow you
reproduce the following example.

Please edit Makefile first and adjust the
value of CC first!

~/c++/tests/pch>make
make[1]: Entering directory `/home/carlo/c++/tests/pch'
make[2]: Entering directory `/home/carlo/c++/tests/pch/a'
rm -f a.out ../include/pch.h.gch
make[2]: Leaving directory `/home/carlo/c++/tests/pch/a'
make[2]: Entering directory `/home/carlo/c++/tests/pch/b'
rm -f a.out ../include/pch.h.gch
make[2]: Leaving directory `/home/carlo/c++/tests/pch/b'
make[1]: Leaving directory `/home/carlo/c++/tests/pch'

First we show how it works WITHOUT pch:
make[1]: Entering directory `/home/carlo/c++/tests/pch/a'
gcc-cvs-3.4 -I. -I../include -W -Wall -pedantic -Winvalid-pch a.c
make[1]: Leaving directory `/home/carlo/c++/tests/pch/a'
Running program a...
Program 'a': Sorry, not enough authorisation.
make[1]: Entering directory `/home/carlo/c++/tests/pch/b'
gcc-cvs-3.4 -I. -I../include -W -Wall -pedantic -Winvalid-pch b.c
make[1]: Leaving directory `/home/carlo/c++/tests/pch/b'
Running program b...
Program 'b': Innocent little program.

Next we show what happens WITH pch:
make[1]: Entering directory `/home/carlo/c++/tests/pch/a'
rm -f ../include/pch.h.gch      # Work around PR12606
gcc-cvs-3.4 -I. -I../include -W -Wall -pedantic -Winvalid-pch -c -o
../include/pch.h.gch ../include/pch.h
gcc-cvs-3.4 -I. -I../include -W -Wall -pedantic -Winvalid-pch a.c
make[1]: Leaving directory `/home/carlo/c++/tests/pch/a'
Running program a...
Program 'a': Sorry, not enough authorisation.
make[1]: Entering directory `/home/carlo/c++/tests/pch/b'
gcc-cvs-3.4 -I. -I../include -W -Wall -pedantic -Winvalid-pch b.c
make[1]: Leaving directory `/home/carlo/c++/tests/pch/b'
Running program b...
Program 'b': Commencing world destruction...

-- 
           Summary: Potential problems with PCH and includes relative to
                    current directory
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: pch
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: carlo at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[carlo at gcc dot gnu dot org]

------- Additional Comments From carlo at gcc dot gnu dot org  2003-11-28 17:12 -------
Created an attachment (id=5224)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=5224&action=view)
Test case, run GNU 'make'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-11-28 17:44 -------
Confirmed, as pch does not record this as it would cause you not to use PCH at all most of the 
time.
I would say we really just have to document the behavior here.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |documentation
   Last reconfirmed|0000-00-00 00:00:00         |2003-11-28 17:44:12
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[carlo at gcc dot gnu dot org]

------- Additional Comments From carlo at gcc dot gnu dot org  2003-11-28 18:03 -------
Well, an alternative would be to re-run the preprocessor
on the source of the pch file and compare the resulting
outcome.  This takes some time, but you only have to
do it for every different 'current directory' that gcc
is in at the moment it includes the pch file.

The pch file should then included:
- The current directory.
- A checksum on the preprocessor output till then.

Extra cpu needed: rerun the preprocessor for every
additional current directory from which the pch
seems to be needed.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[carlo at gcc dot gnu dot org]

------- Additional Comments From carlo at gcc dot gnu dot org  2003-11-28 18:05 -------
"-The current directory" above
should be "-The current directories so far"
that result in the same checksum.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-11-28 18:10 -------
The whole point to PCH is not to rerun the preprocessor as that can be just as slow as just using 
the header files.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[carlo at gcc dot gnu dot org]

------- Additional Comments From carlo at gcc dot gnu dot org  2003-11-28 23:06 -------
I know, but - like I said - you'd only need to
run it for each different working directory
that the pch is used from.  There are in general
a LOT less directories than source files.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[geoffk at gcc dot gnu dot org]

------- Additional Comments From geoffk at gcc dot gnu dot org  2003-11-30 06:12 -------
This is perfectly normal behaviour.  Conceptually, PCH operates *after* include directives are 
processed.  It would not make sense for it to operate before, since PCH requires include directives 
to determine which PCH file to use.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

Re: [Bug pch/13218] Potential problems with PCH and includes relative to current directory

[Carlo Wood]

On Sun, Nov 30, 2003 at 06:12:12AM -0000, geoffk at gcc dot gnu dot org wrote:
> 
> ------- Additional Comments From geoffk at gcc dot gnu dot org  2003-11-30 06:12 -------
> This is perfectly normal behaviour.  Conceptually, PCH operates *after* include directives are 
> processed.  It would not make sense for it to operate before, since PCH requires include directives 
> to determine which PCH file to use.

It is the same PCH in both cases.  Same directory, same pch.h, same pch.h.cgh,
same commandline parameters.  Completely 100% such that one would expect PCH
to work; and even when it would not work, one would expect a warning or simply
the pch file NOT to be used and lead to world destruction.

It is just that the pch.h uses an #include *somewhere* that is a different
header file based on the current directory.

You can call it "perfectly normal behaviour", but I liked the "damn, but we can't fix
this - lets document it"-remark  more.

-- 
Carlo Wood <carlo@alinoe.com>

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[carlo at alinoe dot com]

------- Additional Comments From carlo at alinoe dot com  2003-11-30 17:10 -------
Subject: Re:  Potential problems with PCH and includes relative to current directory

On Sun, Nov 30, 2003 at 06:12:12AM -0000, geoffk at gcc dot gnu dot org wrote:
> 
> ------- Additional Comments From geoffk at gcc dot gnu dot org  2003-11-30 06:12 -------
> This is perfectly normal behaviour.  Conceptually, PCH operates *after* include directives are 
> processed.  It would not make sense for it to operate before, since PCH requires include directives 
> to determine which PCH file to use.

It is the same PCH in both cases.  Same directory, same pch.h, same pch.h.cgh,
same commandline parameters.  Completely 100% such that one would expect PCH
to work; and even when it would not work, one would expect a warning or simply
the pch file NOT to be used and lead to world destruction.

It is just that the pch.h uses an #include *somewhere* that is a different
header file based on the current directory.

You can call it "perfectly normal behaviour", but I liked the "damn, but we can't fix
this - lets document it"-remark  more.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[carlo at alinoe dot com]

------- Additional Comments From carlo at alinoe dot com  2003-11-30 17:13 -------
Subject: Re:  Potential problems with PCH and includes relative to current directory

On Sun, Nov 30, 2003 at 06:10:39PM +0100, Carlo Wood wrote:
> the pch file NOT to be used and lead to world destruction.
                               ^__ instead leading
(where 'world destruction' is refering to the tar ball test case)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

[Bug pch/13218] Potential problems with PCH and includes relative to current directory

[geoffk at gcc dot gnu dot org]

------- Additional Comments From geoffk at gcc dot gnu dot org  2003-12-01 04:42 -------
The instructions given for reproducing the behaviour quoted are wrong, a command that does 
work is:

PATH=.:$PATH make -f makefile.1 CC=gcc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13218

Re: [Bug pch/13218] Potential problems with PCH and includes relative to current directory

[Geoff Keating]

Your problem is that you're using '-I.', but '.' is not the same
directory when building and using the PCH.  If you used '-I../b', or
better yet an absolute path, your problem would go away.

GCC's PCH is *not* a header cache.  It does not check that you haven't
changed, moved, or deleted source files since you created the
PCH---whether through using emacs, changing the current directory,
using chroot(), moving the PCH to a completely different machine,
different -I paths, filesystem corruption, or whatever.  It doesn't
check that 'foo.h.gch' is actually the precompiled version of 'foo.h'
(you can perfectly well do 'gcc bar.h -o foo.h.gch'); it doesn't even
check that there *is* a 'foo.h'.  All these checks are the
responsibility of the build system---or, to be precise, if you want
these done then you should make the build system do them.  (There are
many cases where you do *not* want them done.)

There is no suggestion anywhere in the documentation that GCC does
any checking of this kind.  In fact, it specifically says:

> You will probably want to use a tool like @command{make} to keep the
> precompiled header up-to-date when the headers it contains change.


I don't think we should change the documentation to list all the
things that GCC doesn't do.  It'd be a very long list.

I'm even a bit hesitant to give people more guidance about how to use
PCH than we do now, in the GCC manual.  It seems like such advice
would be better somewhere else, like the automake manual.  I suspect
that in the general case ('How should I use PCH in my project?'), all
answers are as likely to mislead as to help.


I admit that it would be more convenient if PCH could be used to
create a fully transparent header cache.  However, PCH is really not
the best tool for that task; you can only include one PCH in a
compilation, it's designed for speed over convenience, it requires
significant build system and source code changes to use, and PCH files
are too big.  Per Bothner's "compile server" project *is* intended to
do this, but it is as yet experimental, and by itself it won't be as
fast as PCH files.

-- 
- Geoffrey Keating <geoffk@geoffk.org>