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.