When gcc fails to #include a header because the named file is missing, it prints an error yet continues trying to compile the source file. (In most cases, this ends up printing hundreds/thousands of error messages that are caused by the fact that the definitions in that header file were not processed.) Although the initial error resulting from the missing header will be sufficient to eventually cause gcc to fail the compilation, it only stops after attempting to go through the entire source file. gcc should have an option to treat missing includes as fatal, and stop compilation immediately.
Not something we want but for 3.5.0 and above you can use -Wfatal-errors to make all errors fatal, see <http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.htm>.
I think we do want this - it's clearly the right thing to do. Indeed, the only reason we don't currently halt is that cpp's separate diagnostic mechanism from the main compiler has no way of asking the main compiler to stop.
Do you mean always stopping is the right thing, or having an option for it? I'd be opposed to an option, we already have way too many options, and this doesn't seem important enough.
I think this is fixed by -Wfatal-errors anyways.
Always stopping would be an improvement over never stopping. If a header is missing, the error messages that follow tend to be of little or no use, and only serve to scroll the original useful message off the terminal.
Subject: Re: gcc should have option to treat missing headers as fatal Always stopping is the right thing. Once Per finishes his fileline conversion, it will be possible to send cpplib's errors through diagnostic.c, and we will then be able to make this a fatal error. zw
I can imagine it being useful to want to use default compilation options that abort immediately on the first include failure, yet continue compilation on other types of errors. (for example, seeing multiple errors when you are search/replace on variable names is useful.) Continuing compilation when an include failure occurs is almost never a good idea and rarely useful due to the spectacular cascade of errors that are commonly produced.
Confirmed.
*** Bug 30808 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Always stopping is the right thing. Once Per finishes his fileline > conversion, it will be possible to send cpplib's errors through > diagnostic.c, and we will then be able to make this a fatal error. One possibility that doesn't involve a new interface between cc1 and cpplib would be if cpplib simply indicated that the token stream ends here, if it can't find a header file. I can think of a few cases where we'd complain about open braces that haven't been closed (think of an #include inside 'extern "C" {...}') but there shouldn't be the pages and pages of error messages coming. W.
I plan to fix this for 4.5. Testing the preliminary patch to make cpplib use the diagnostic.c infrastructure.
Could we take a look at the patch? I have also a half-baked patch. Are you going to replace cpplib functions completely or just set up call-backs as C++ does? If the latter, then there is already a patch in bug 34695.
Subject: Re: gcc should have option to treat missing headers as fatal On Tue, 10 Feb 2009, manu at gcc dot gnu dot org wrote: > Could we take a look at the patch? I have also a half-baked patch. Are you > going to replace cpplib functions completely or just set up call-backs as C++ > does? If the latter, then there is already a patch in bug 34695. I'll post my patch once it's passed testing. It makes cpplib use callbacks unconditionally, removing cpplib's own support for printing diagnostics directly, and its notions of pedantic_errors, inhibit_warnings, warn_system_headers, inhibit_errors, warnings_are_errors (and client_diagnostic and cpplib's own count of errors). I don't see any of the patches in bug 34695 as particularly useful in this regard. For a library, having a single callback hook for diagnostics seems better to me than requiring that the library's user define functions with special names such as "error" and "warning".
Subject: Re: gcc should have option to treat missing headers as fatal I have now posted my preliminary patch: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00491.html
Subject: Bug 15638 Author: jsm28 Date: Tue Mar 31 12:43:29 2009 New Revision: 145341 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145341 Log: PR preprocessor/15638 gcc: * c-common.c (c_cpp_error): Handle CPP_DL_FATAL. gcc/fortran: * cpp.c (cb_cpp_error): Handle CPP_DL_FATAL. gcc/testsuite: * gcc.dg/cpp/missing-header-1.c: New test. * gcc.dg/cpp/include2.c: Only test #include <>. Expect "compilation terminated" message. * gcc.dg/cpp/include2a.c: New test. Copy of include2.c but only test #include "". * gcc.dg/pch/counter-2.c, gcc.dg/pch/valid-1.c, gcc.dg/pch/valid-2.c, gcc.dg/pch/warn-1.c: Expect "compilation terminated" message. libcpp: * files.c (_cpp_find_file): Call open_file_failed after diagnosing invalid PCH. (open_file_failed): Make error for missing file fatal. * include/cpplib.h (CPP_DL_FATAL): Define. Added: trunk/gcc/testsuite/gcc.dg/cpp/include2a.c trunk/gcc/testsuite/gcc.dg/cpp/missing-header-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/cpp.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/include2.c trunk/gcc/testsuite/gcc.dg/pch/counter-2.c trunk/gcc/testsuite/gcc.dg/pch/valid-1.c trunk/gcc/testsuite/gcc.dg/pch/valid-2.c trunk/gcc/testsuite/gcc.dg/pch/warn-1.c trunk/libcpp/ChangeLog trunk/libcpp/files.c trunk/libcpp/include/cpplib.h
Fixed for 4.5.
Hi, Is there an option to revert this change? To generate an error or warning for a missing header? Thanks.
(In reply to Lucia Huang from comment #17) > Hi, > Is there an option to revert this change? To generate an error or warning > for a missing header? Thanks. What is the use case for having this as a non fatal error? I cannot think of one. The main reason why is a fatal error is due missing an include will cause cascading errors latter on.
(In reply to Lucia Huang from comment #17) > Hi, > Is there an option to revert this change? To generate an error or warning > for a missing header? Thanks. Hi Lucia, no there is no such option. I don't think anyone will spent their free time adding such an option, would you? You can get almost the same effect by adding a dummy header with an #error or a #warning directive.
Hi Andrew: We use gcc as preprocessor to extand header files for C code. It is used in a script to parse and check for error in a large code base (6000+ files). Not all headers are needed to be extanded. As the code base is large, creating dummy files for the missing header is not a good plan. So far we force the script to run with older version gcc. Thanks, Lucia On Thu, Apr 3, 2014 at 4:11 PM, pinskia at gcc dot gnu.org < gcc-bugzilla@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15638 > > --- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > (In reply to Lucia Huang from comment #17) > > Hi, > > Is there an option to revert this change? To generate an error or > warning > > for a missing header? Thanks. > > What is the use case for having this as a non fatal error? I cannot think > of > one. The main reason why is a fatal error is due missing an include will > cause > cascading errors latter on. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
See comment 3. Every new option to GCC requires extra testing and extra maintenance. IMHO it's not a good idea to add an option to support one use case in a single codebase, which doesn't even use GCC the way it's supposed to be used. If you need a preprocessor that works in a specific way then use a specific version of GCC that works that way. It is not worth changing all future versions to work that way.