GCC Bugzilla Bug 29172

The --combine option fails to forget the "once" property of a header file when
gcc moves on to dealing with the next *.c file. The pragma should function just
the same as the usual "#ifndef _SOME_ARBITRARY_CRAP" hack.

k 0 $ cat once.h
#pragma once
#define D
k 0 $ cat a.c
#include "once.h"
#ifndef D
#error No def in a.c!
#endif
k 0 $ cat b.c
#include "once.h"
#ifndef D
#error No def in b.c!
#endif
k 0 $ gcc --combine a.c b.c
b.c:3:2: error: #error No def in b.c!
k 1 $ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20060828 (Red Hat 4.1.1-20)
k 0 $

I bet the C front-end forgot to tell the preprocessor to rest the "pragma once"
table.

Why is this still UNCONFIRMED, and why is it marked enhancement?

The compiler is failing to follow the documented behavior.

(In reply to comment #2)
> The compiler is failing to follow the documented behavior.
Because I (or anyone else) have not got around to actually testing the testcase
:).

(In reply to comment #3)
> (In reply to comment #2)
> > The compiler is failing to follow the documented behavior.
> Because I (or anyone else) have not got around to actually testing the testcase
> :).

I still don't see how this is an enhancement.

The compiler is documented to behave one way. It does something else.
That's not "add my new pet feature". That's "you have a clear defect".
Supposedly gcc supports "#pragma once" (it seems to, and is documented
as such) and supposedly gcc supports "--combine" (it seems to, kind of,
aside from the many bugs, but at least this feature is documented).
Nothing says that these features cause each other to break horribly,
yet they do.

Confirmed.
The problem is that the loop in c_common_parse_file calls
cpp_undef_all -- which undefines all symbols but does not
mark _cpp_file objects as not seen.
We probably need a new libcpp API for this.

Testing a patch.

Subject: Bug 29172

Author: tromey
Date: Thu Dec  6 18:56:26 2007
New Revision: 130656

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130656
Log:
gcc
        PR c/29172:
        * c-opts.c (c_common_parse_file): Call cpp_clear_file_cache.
libcpp
        PR c/29172:
        * internal.h (struct cpp_reader) <file_hash_entries>: Changed
        type.
        <file_hash_entries_allocated, file_hash_entries_used>: Removed.
        * files.c (FILE_HASH_POOL_SIZE): New macro.
        (struct file_hash_entry_pool): New.
        (destroy_all_cpp_files): New function.
        (allocate_file_hash_entries): Allocate a file_hash_entry_pool.
        (new_file_hash_entry): Update.
        (free_file_hash_entries): New function.
        (_cpp_cleanup_files): Call free_file_hash_entries and
        destroy_all_cpp_files.
        (cpp_clear_file_cache): New function.
        * include/cpplib.h (cpp_clear_file_cache): Declare.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-opts.c
    trunk/libcpp/ChangeLog
    trunk/libcpp/files.c
    trunk/libcpp/include/cpplib.h
    trunk/libcpp/internal.h

Fixed on trunk.

Fixed so closing.