Re: different behaviors on gcc warning between one-step compile and separate-step compile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank Janathan for quickly response!

It is true that linemarker "3" marks that __null is from system headers and
the warning is suppressed.

But I think -Wsystem-headers is not a proper way to fix this. The projects
concerned about conversion-null usually use -Werror, and let the all
system-headers warning out will be a disaster, tons of deprecated-function
warning makes the compiling uncontrollable.

Jonathan Wakely <jwakely.gcc@xxxxxxxxx> 于2019年5月20日周一 下午4:16写道:

> On Mon, 20 May 2019 at 08:58, Jonathan Wakely <jwakely.gcc@xxxxxxxxx>
> wrote:
> >
> > On Mon, 20 May 2019 at 04:07, Wx L <lwxiang1994@xxxxxxxxx> wrote:
> > >
> > > hi, I used gcc5.5.0(configure only with --prefix), glibc2.17 to compile
> > > some code with *conversion-null *warning in it.
> > > it is every simple so I put it here:
> > >
> > > #include <stdio.h>
> > > int main()
> > > {
> > > return NULL;
> > > }
> > >
> > > *What I Got*
> > > I did compile with:
> > > g++ -Wall -S test.c
> > > as expected, here came out the warning "warning: converting to
> non-pointer
> > > type 'int' from NULL [-Wconversion-null]"
> > >
> > > then I did compile step by step:
> > > g++ -Wall -E test.c
> > > g++ -Wall -S test.i
> > >
> > > the warning just disappeared, nothing came out.
> > >
> > > *What I have Tried*
> > > I tried to figure out if all warning will be disabled, so I compile
> some
> > > code with different warning in it, just *conversion-null *will be
> disabled
> > > when separate-step compiling.
> > > I tried to figure out if all gcc version behave the same way, and I
> found
> > > gcc5.5.0,gcc7.1.0,gcc7.3.0 did, but gcc4.8.5 works when separate-step
> > > compiling.
> > > After comparing the preprocessing files(*.i) from gcc4.8.5 and
> gcc5.5.0, I
> > > found that gcc5.5.0 put some linemarkers in it while gcc4.8.5 don't.
> > > here is the line markers:
> > >
> > > int main()
> > > {
> > >         int a =
> > > # 4 "a.c" 3 4
> > >                __null
> > > # 4 "a.c"
> > >                    ;
> > >  return a;
> > > }
> > >
> > > if I do preprocess with gcc4.8.5, and do compile with gcc5.5.0, it
> warns
> > > well.
> > > if I do preprocess with gcc5.5.0, and do compile with gcc4.8.5, it can
> not
> > > warn *conversion-null.*
> > > if I do preprocess with gcc5.5.0 and add -P option(remove
> linemarkers), and
> > > do compile with gcc5.5.0, it warns well.
> > >
> > > Now I am sure that it is the linemarkers added by gcc5.5.0 preprocessor
> > > that cause the *conversion-null *warning not work as expected.
> > > But why one-step compile works? So I add -save-temps to one-step
> compile to
> > > see if it got a different preprocessing file.
> > > just like:
> > >
> > > g++ -Wall -save-temps -S test.c
> > >
> > > and now it can not warns too! the preprocessing file is exactly same
> as the
> > > one with "g++ -Wall -E test.c"
> > >
> > > *What Help I Need*
> > > After all the test, I confuse that if there is a bug with warning
> analyzer
> > > when analyzing the *conversion-null *warning code which around by
> > > linemarkers?
> >
> > I think the problem is that the definition of NULL comes from a system
> > header, and GCC gets confused when issuing diagnostics related to
> > macros defined in system headers.
> >
> > If you use -Wsystem-headers then you get a -Wconversion-null warning
> > even when preprocessing and compiling separately. This is related to
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77513
> >
> > Please report a bug.
>
> I think it's related to PR 57201 so I added your example there:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201#c15
>
> > > Is that -P a workaround to solve this problem when separate-step
> compiling?
> > > Will -P leads to some other problems?
> >
> > Yes, removing all line directives means the compiler doesn't know
> > which code comes from system headers, and so some standard library
> > features will no longer compile cleanly. The -P flag should be used
> > when the output of the preprocessor is not going to be consumed by the
> > compiler, it shouldn't be used for C or C++ code.
>




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux