[Bug preprocessor/15638] New: gcc should have option to treat missing headers as fatal

[Bug preprocessor/15638] New: gcc should have option to treat missing headers as fatal

[jlawson-gcc at bovine dot net]

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.

-- 
           Summary: gcc should have option to treat missing headers as fatal
           Product: gcc
           Version: 3.2.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jlawson-gcc at bovine dot net
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-24 22:29 -------
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>.

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


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[neil at gcc dot gnu dot org]

------- Additional Comments From neil at gcc dot gnu dot org  2004-05-28 09:23 -------
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.

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


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[falk at debian dot org]

------- Additional Comments From falk at debian dot org  2004-05-28 09:33 -------
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.

-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-28 12:02 -------
I think this is fixed by -Wfatal-errors anyways.

-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[bbrownstone at hotmail dot com]

------- Additional Comments From bbrownstone at hotmail dot com  2004-05-28 16:22 -------
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.

-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[bbrownstone at hotmail dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bbrownstone at hotmail dot
                   |                            |com


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2004-05-28 18:58 -------
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


-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[jlawson-gcc at bovine dot net]

------- Additional Comments From jlawson-gcc at bovine dot net  2004-05-28 22:51 -------
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.

-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-26 20:21 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-06-26 20:21:34
               date|                            |


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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.

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[eving.tw at gmail dot com]

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

--- Comment #20 from Lucia Huang <eving.tw at gmail dot com> ---
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.
>

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[manu at gcc dot gnu.org]

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

--- Comment #19 from Manuel López-Ibáñez <manu 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.

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.
>From gcc-bugs-return-448191-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 03 12:48:19 2014
Return-Path: <gcc-bugs-return-448191-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27333 invoked by alias); 3 Apr 2014 12:48:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27286 invoked by uid 48); 3 Apr 2014 12:48:16 -0000
From: "nheghathivhistha at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
Date: Thu, 03 Apr 2014 12:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: nheghathivhistha at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58678-4-MKjD3Tdb2W@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58678-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58678-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00211.txt.bz2
Content-length: 4162

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX678

--- Comment #57 from David Kredba <nheghathivhistha at gmail dot com> ---
I got it again with trunk revision 209048:

/usr/bin/x86_64-pc-linux-gnu-g++  -fPIC -flto=4 -fuse-linker-plugin -O2 -ggdb
-pipe -march=core2 -mtune=core2 -mno-3dnow -mno-sse4.2 -mno-avx -mno-xop
-mno-fma4 -mno-sse4a  -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions
-DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual
-fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden
-Wl,--enable-new-dtags -Wl,--no-undefined -lc  -flto=4 -fuse-linker-plugin
-Wl,--as-needed -Wl,-O2 -Wl,-flto -O2 -ggdb -pipe -march=core2 -mtune=core2
-mno-3dnow -mno-sse4.2 -mno-avx -mno-xop -mno-fma4 -mno-sse4a -shared
-Wl,-soname,phonon.so -o lib/phonon.so
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart0.cpp.o
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart1.cpp.o
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart2.cpp.o
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart3.cpp.o
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart4.cpp.o
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart5.cpp.o
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart6.cpp.o
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart7.cpp.o
-lpython3.2 -lphonon /usr/lib64/qt4/libQtDBus.so /usr/lib64/qt4/libQtCore.so
-lpthread /usr/lib64/qt4/libQtGui.so -Wl,-rpath,/usr/lib64/qt4:
/tmp/ccpIV11w.ltrans24.ltrans.o: In function `__base_dtor ':
/usr/include/phonon/backendcapabilities.h:57: undefined reference to `vtable
for Phonon::BackendCapabilities::Notifier'
/usr/include/phonon/backendcapabilities.h:57: undefined reference to `vtable
for Phonon::BackendCapabilities::Notifier'
/usr/include/phonon/backendcapabilities.h:57: undefined reference to `vtable
for Phonon::BackendCapabilities::Notifier'
collect2: error: ld returned 1 exit status

And it is sipphononpart5.cpp.o again.

I use Markus's binutils patch (now trunk binutils got it too! :-) ) and the
only patch more to revision 209048 is the one from Martin Jambor (Simple
enhancements to dumping in ipa.c and ipa-cp.c).

It fails with python-3.2 only, python 2.7 and 3.3 version looks to be fine.
Without LTO it compiles fine.

Both binutils' nm and gcc-nm returns: no symbols
for /usr/lib64/libphonon.so.4.7.1.

But mc (Internal viewer of a Midnight Commander) can se them:

00000000000273f0 T Phonon::BackendCapabilities::notifier()

List of vtables inside /usr/lib64/libphonon.so.4.7.1:

                 U vtable for __cxxabiv1::__class_type_info
                 U vtable for __cxxabiv1::__si_class_type_info
                 U vtable for __cxxabiv1::__vmi_class_type_info
000000000026d580 V vtable for Phonon::SeekSlider
000000000026dd80 V vtable for Phonon::AudioOutput
000000000026dc00 V vtable for Phonon::MediaObject
000000000026e0c0 V vtable for Phonon::PulseStream
000000000026cb40 V vtable for Phonon::VideoPlayer
000000000026ce00 V vtable for Phonon::VideoWidget
000000000026c380 V vtable for Phonon::EffectWidget
000000000026c1c0 V vtable for Phonon::GlobalConfig
000000000026e180 V vtable for Phonon::PulseSupport
000000000026d340 V vtable for Phonon::VolumeSlider
000000000026e000 V vtable for Phonon::AudioDataOutput
000000000026c900 V vtable for Phonon::MediaController
000000000026d880 V vtable for Phonon::StreamInterface
000000000026d8c0 V vtable for Phonon::MediaNodePrivate
000000000026db40 V vtable for Phonon::VolumeFaderEffect
000000000026e280 V vtable for Phonon::MediaSourcePrivate
000000000026df00 V vtable for Phonon::AbstractAudioOutput
000000000026e2c0 V vtable for Phonon::AbstractMediaStream
000000000026c780 V vtable for Phonon::AbstractMediaStreamPrivate
000000000026dcc0 V vtable for Phonon::Effect
000000000026dea0 V vtable for Phonon::MediaNode

Objdump -t see no symbols, -T see symbols.

I rebuild phonon by the same compiler/binutils as pykde4.

Could you kindly please check if you are affected too?
Thank you in advance.

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[pinskia at gcc dot gnu.org]

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.

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[eving.tw at gmail dot com]

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

Lucia Huang <eving.tw at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eving.tw at gmail dot com

--- Comment #17 from Lucia Huang <eving.tw at gmail dot com> ---
Hi, 
Is there an option to revert this change?  To generate an error or warning for
a missing header?  Thanks.

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[jsm28 at gcc dot gnu dot org]

------- Comment #16 from jsm28 at gcc dot gnu dot org  2009-03-31 12:45 -------
Fixed for 4.5.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|                            |4.4.0
      Known to work|                            |4.5.0
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[jsm28 at gcc dot gnu dot org]

------- Comment #15 from jsm28 at gcc dot gnu dot org  2009-03-31 12:43 -------
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


-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[joseph at codesourcery dot com]

------- Comment #14 from joseph at codesourcery dot com  2009-02-11 01:16 -------
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


-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[joseph at codesourcery dot com]

------- Comment #13 from joseph at codesourcery dot com  2009-02-10 15:35 -------
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".


-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[manu at gcc dot gnu dot org]

------- Comment #12 from manu at gcc dot gnu dot org  2009-02-10 15:24 -------
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.


-- 


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[jsm28 at gcc dot gnu dot org]

------- Comment #11 from jsm28 at gcc dot gnu dot org  2009-02-10 15:17 -------
I plan to fix this for 4.5.  Testing the preliminary patch to make cpplib use
the diagnostic.c infrastructure.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-01-21 03:04:29         |2009-02-10 15:17:10
               date|                            |


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[bangerth at dealii dot org]

------- Comment #10 from bangerth at dealii dot org  2007-03-28 17:37 -------
(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.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org


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

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2007-02-15 17:51 -------
*** Bug 30808 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc-bugzilla at seebs dot
                   |                            |net


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