Re: Extended doubt regarding the bug 93432

[Martin Sebor <msebor@gmail.com>]

On 2/15/22 05:10, Krishna Narayanan wrote:
> Thank you Sir,
> I got the warnings and did try the test-bug.c with different 
> optimizations and got the expected warnings.I am now familiar with how 
> the warnings work with respect to the optimizations we use, my intention 
> was to step through the gcc source code which gives a warning for 
> uninitialized variable and understand it that's why I did the uninit.c 
> in the previous steps.
> And for the above steps Step 3: It says Function 
> "pass_late_warn_uninitialized::execute" not defined.I referred this 
> (https://splichal.eu/lcov/gcc/tree-ssa-uninit.c.gcov.html 
> <https://splichal.eu/lcov/gcc/tree-ssa-uninit.c.gcov.html>) for the code.

Accessing the official GCC source code repository is described here:
   https://gcc.gnu.org/git.html

> When I invoke the cc1 there is an error,
>   gdb.error: No enum type named tree_code.
> .gdbinit:15: Error in sourced command file:
> Error while executing Python code.

These look like GDB errors coming out of your .gdbinit file.

> When I set any other breakpoint it goes for an exit.c ,I didn't get this 
> behaviour, Is it because of some mistake in the prior steps of 
> configuration and building?

It's hard for me to say since I'm not sure what you did.  I recommend
cloning the GCC Git repository as described on the page above.  Then
configure the compiler as I described below.  You can find more details
on configuring GCC here:
   https://gcc.gnu.org/install/configure.html

Then build GCC as I described.  Refer to the online instructions for
details:
   https://gcc.gnu.org/install/build.html

Then you should be able to start GCC in GDB as I described below.

Martin


> Thanks and Regards,
> Krishna Narayanan.
> 
> On Tue, Feb 15, 2022 at 1:52 AM Martin Sebor <msebor@gmail.com 
> <mailto:msebor@gmail.com>> wrote:
> 
>     On 2/14/22 09:59, Krishna Narayanan wrote:
>      > Yes I tried this but still it shows the same error,
>      > # 1 "tree-ssa-uninit.c"
>      > # 1 "<built-in>"
>      > # 1 "<command-line>"
>      > # 31 "<command-line>"
>      > # 1 "/usr/include/stdc-predef.h" 1 3 4
>      > # 32 "<command-line>" 2
>      > # 1 "tree-ssa-uninit.c"
>      > tree-ssa-uninit.c:21:10: fatal error: config.h: No such file or
>     directory
>      >     21 | #include "config.h"
>      >        |          ^~~~~~~~~~
>      > I have also given "make CFLAGS='-g3'  all " in the configuration.
>      > I have attached a screenshot of the terminal, I don't know what
>     is going
>      > wrong on my end.
>      > Can you please help me out with this?
> 
>     I was trying to explain is that given a source file, say
>     test-bug-93432.c, with the test case from bug 93432 but that also
>     #includes a bunch of standard headers (such as <stdio.h> that's
>     missing from the test case), to see what goes on in GCC as it
>     compiles the test case, I follow these steps:
> 
>         1) Create a prpeprocessing translation unit:
>            $ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -E
>     $CPPFLAGS
>     test-bug-93432.c > test-bug-93432.i
> 
>            CPPFLAGS above is [a variable that expands to] the options that
>            affect the preprocessor, most commonly -D and -I.  (For the test
>            case in bug 93432 CPPFLAGS can be empty since gcc knows about
>            headers in /usr/include).
> 
>         2) Debug GCC with the translation unit without specifying CPPFLAGS:
>            $ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc
>     test-bug-93432.i -wrapper gdb,--arg
> 
>     But you seem to be compiling tree-ssa-uninit.c, the GCC source file
>     that implements the uninitialized warnings, rather than the test case
>     for the warning.  I don't think you want to do that if what you're
>     trying to understand is how the warning works.
> 
>     What you want to do is something along the lines below (starting with
>     building the debugging version of GCC itself):
> 
>         1) build GCC with debugging information and no optimization, e.g.,
>              $ mkdir -p /build/gcc-master
>              $ (cd /build/gcc-master && /src/gcc/configure
>     --enable-stage1-languages=c,c++)
>              $ make -C /build/gcc-master -j16 -l12 stage1-bubble
>     CFLAGS='-O0
>     -g3' CXXFLAGS='-O0 -g3' STAGE1_CFLAGS='-O0 -g3' STAGE1_CXXFLAGS='-O0
>     -g3'
>            You should adjust the arguments to the -j and -l options to
>            the machine you're building on (the number of CPUs and cores
>            and interactive jobs/users running on it).
> 
>         2) start GDB with the GCC you built in (1)
>              $ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc
>     test-bug-93432.i -wrapper gdb,--arg
> 
>         3) set breakpoints in the main entry points in tree-ssa-uninit.cc,
>            e.g.,
>              (gdb) break pass_late_warn_uninitialized::execute
>              (gdb) break execute_early_warn_uninitialized
> 
>         4) run GCC with -O2 -Wall as command line options and
>     test-bug-93432.i
>            as the command line argument within GDB:
>              (gdb) run -O2 -Wall -quiet test-bug-93432.i
> 
>     I'd expect there to be a page somewhere under
>     https://gcc.gnu.org/wiki <https://gcc.gnu.org/wiki>
>     that describes this and more, but all I found was the page below:
>     https://gcc.gnu.org/wiki/Top-Level_Bootstrap?highlight=%28stage1-bubble%29
>     <https://gcc.gnu.org/wiki/Top-Level_Bootstrap?highlight=%28stage1-bubble%29>
> 
>     It might help others get started to update it with the steps that work
>     for you (after checking with someone here that they make sense.)
> 
>     Martin
> 
>      > Thanks,
>      > Krishna Narayanan
>      >
>      > On Mon, Feb 14, 2022 at 8:54 PM Martin Sebor <msebor@gmail.com
>     <mailto:msebor@gmail.com>
>      > <mailto:msebor@gmail.com <mailto:msebor@gmail.com>>> wrote:
>      >
>      >     On 2/11/22 11:10, Krishna Narayanan wrote:
>      >      > Hello,
>      >      > I tried to run the gcc in the debugger but I am getting a
>     repetitive
>      >      > error for header files,I tried using -I followed by the
>     path of the
>      >      > header file (-I/home/krishna/objdir/gcc) in the command
>     but still
>      >     the
>      >      > error is persistent.
>      >      > Error:
>      >      > In file included from *tree-ssa-uninit.c:22*:
>      >      > *system.h:209:10*: fatal error: safe-ctype.h: No such file or
>      >     directory
>      >      >    209 | #include "safe-ctype.h"
>      >      >        |          ^~~~~~~~~~~~~~
>      >      > compilation terminated.
>      >      > How do I resolve this?Can you please help me out with this and
>      >     where did
>      >      > I go wrong?
>      >
>      >     I usually create a translation unit (a .i file for a C source and
>      >     a .ii file for a C++ source) by compiling the .c or .C file with
>      >     the -E option and then start GCC the debugger on that file.  For
>      >     example, with an unoptimized GCC stage1 build with -g3 enabled in
>      >     /build/gcc-master, I invoke it in GDB like so:
>      >
>      >         $ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc
>     tu.i -wrapper
>      >     gdb,--arg
>      >
>      >     (In Emacs, I use gdb,-i=mi,--arg as the trailing pieces.)
>     This lets
>      >     me avoid many of the -I command line options that the GCC driver
>      >     otherwise passes to to th compiler implicitly.
>      >
>      >     Martin
>      >
>      >      > Thanks and regards,
>      >      > Krishna Narayanan.
>      >      >
>      >      >
>      >      > On Wed, Feb 9, 2022 at 3:20 AM Martin Sebor
>     <msebor@gmail.com <mailto:msebor@gmail.com>
>      >     <mailto:msebor@gmail.com <mailto:msebor@gmail.com>>
>      >      > <mailto:msebor@gmail.com <mailto:msebor@gmail.com>
>     <mailto:msebor@gmail.com <mailto:msebor@gmail.com>>>> wrote:
>      >      >
>      >      >     On 2/8/22 10:37, Jonathan Wakely via Gcc-help wrote:
>      >      >      > On Tue, 8 Feb 2022 at 17:18, Krishna Narayanan <
>      >      >      > krishnanarayanan132002@gmail.com
>     <mailto:krishnanarayanan132002@gmail.com>
>      >     <mailto:krishnanarayanan132002@gmail.com
>     <mailto:krishnanarayanan132002@gmail.com>>
>      >      >     <mailto:krishnanarayanan132002@gmail.com
>     <mailto:krishnanarayanan132002@gmail.com>
>      >     <mailto:krishnanarayanan132002@gmail.com
>     <mailto:krishnanarayanan132002@gmail.com>>>> wrote:
>      >      >      >
>      >      >      >> Thanks for your response,Could you please clarify
>     if this
>      >     is a bug?
>      >      >      >>
>      >      >      >
>      >      >      > It warns with -O1, which is the documented behaviour:
>      >      >      >
>      >      >      >        The effectiveness of some warnings depends on
>      >      >     optimizations also
>      >      >      > being enabled. For example -Wsuggest-final-types is
>     more
>      >      >      >        effective with link-time optimization and
>      >      >     -Wmaybe-uninitialized does
>      >      >      > not warn at all unless optimization is enabled.
>      >      >
>      >      >     Yes, although the latter sentence is no longer completely
>      >     accurate.
>      >      >     Since GCC 11 -Wmaybe-uninitialized doesn't need
>     optimization
>      >     to trigger
>      >      >     for code that passes an uninitialized object to a function
>      >     that takes
>      >      >     a const reference.  Let me update the manual with that.
>      >      >
>      >      >      > So no, I don't think it' a bug. GCC is behaving as
>     designed.
>      >      >     Ideally it
>      >      >      > would be better at warning without optimization,
>     but changing
>      >      >     that would be
>      >      >      > hard.
>      >      >
>      >      >     It might be tricky to handle this case without causing
>     false
>      >     positives
>      >      >     in others.
>      >      >
>      >      >     Krishna, to understand why some of these cases are
>     diagnosed
>      >     and others
>      >      >     aren't, you need to look at either the dump from the
>     uninit pass
>      >      >     (-fdump-tree-uninit) with -O1 and above, or at some early
>      >     dump (e.g.,
>      >      >     -fdump-tree-ssa) at -O0.  Here's a link to the former on
>      >     Godbolt for
>      >      >     your example:
>      >      >
>      >      > https://gcc.godbolt.org/z/89c4s7o6E
>     <https://gcc.godbolt.org/z/89c4s7o6E>
>      >     <https://gcc.godbolt.org/z/89c4s7o6E
>     <https://gcc.godbolt.org/z/89c4s7o6E>>
>      >      >     <https://gcc.godbolt.org/z/89c4s7o6E
>     <https://gcc.godbolt.org/z/89c4s7o6E>
>      >     <https://gcc.godbolt.org/z/89c4s7o6E
>     <https://gcc.godbolt.org/z/89c4s7o6E>>>
>      >      >
>      >      >     The best way is of course to step through GCC in a
>     debugger (for
>      >      >     the uninitialized warnings the code is in
>      >     gcc/tree-ssa-uninit.cc).
>      >      >
>      >      >     Martin
>      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >> Regards,
>      >      >      >> Krishna Narayanan.
>      >      >      >>
>      >      >      >> On Tue, Feb 8, 2022 at 10:28 PM Jonathan Wakely
>      >      >     <jwakely.gcc@gmail.com <mailto:jwakely.gcc@gmail.com>
>     <mailto:jwakely.gcc@gmail.com <mailto:jwakely.gcc@gmail.com>>
>      >     <mailto:jwakely.gcc@gmail.com <mailto:jwakely.gcc@gmail.com>
>     <mailto:jwakely.gcc@gmail.com <mailto:jwakely.gcc@gmail.com>>>>
>      >      >      >> wrote:
>      >      >      >>
>      >      >      >>>
>      >      >      >>>
>      >      >      >>> On Tue, 8 Feb 2022 at 16:25, Krishna Narayanan via
>      >     Gcc-help <
>      >      >      >>> gcc-help@gcc.gnu.org
>     <mailto:gcc-help@gcc.gnu.org> <mailto:gcc-help@gcc.gnu.org
>     <mailto:gcc-help@gcc.gnu.org>>
>      >     <mailto:gcc-help@gcc.gnu.org <mailto:gcc-help@gcc.gnu.org>
>     <mailto:gcc-help@gcc.gnu.org <mailto:gcc-help@gcc.gnu.org>>>> wrote:
>      >      >      >>>
>      >      >      >>>> Hello,
>      >      >      >>>> As an extension to the bug 93432
>      >      >      >>>>
>     (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
>     <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432>
>      >     <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
>     <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432>>
>      >      >     <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
>     <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432>
>      >     <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432
>     <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93432>>>), I would like to
>      >      >      >>>> add a few more points,here in the given code
>      >      >      >>>> (https://godbolt.org/z/sYjqjqh3d
>     <https://godbolt.org/z/sYjqjqh3d>
>      >     <https://godbolt.org/z/sYjqjqh3d
>     <https://godbolt.org/z/sYjqjqh3d>>
>      >      >     <https://godbolt.org/z/sYjqjqh3d
>     <https://godbolt.org/z/sYjqjqh3d>
>      >     <https://godbolt.org/z/sYjqjqh3d
>     <https://godbolt.org/z/sYjqjqh3d>>>) there is a warning averted but
>     there
>      >      >      >>>> is no warning shown for this code
>      >      >      >>>> (https://gcc.godbolt.org/z/oo5sf4oec
>     <https://gcc.godbolt.org/z/oo5sf4oec>
>      >     <https://gcc.godbolt.org/z/oo5sf4oec
>     <https://gcc.godbolt.org/z/oo5sf4oec>>
>      >      >     <https://gcc.godbolt.org/z/oo5sf4oec
>     <https://gcc.godbolt.org/z/oo5sf4oec>
>      >     <https://gcc.godbolt.org/z/oo5sf4oec
>     <https://gcc.godbolt.org/z/oo5sf4oec>>>) .
>      >      >      >>>> I tried it with "-fno-strict-aliasing -fwrapv
>      >      >      >>>> -fno-aggressive-loop-optimizations" and
>      >      >     "fsanitize=undefined".There
>      >      >      >>>> are no errors for gcc but clang has runtime
>     errors,the
>      >     error for
>      >      >      >>>> clang: https://gcc.godbolt.org/z/1hq8x1o8E
>     <https://gcc.godbolt.org/z/1hq8x1o8E>
>      >     <https://gcc.godbolt.org/z/1hq8x1o8E
>     <https://gcc.godbolt.org/z/1hq8x1o8E>>
>      >      >     <https://gcc.godbolt.org/z/1hq8x1o8E
>     <https://gcc.godbolt.org/z/1hq8x1o8E>
>      >     <https://gcc.godbolt.org/z/1hq8x1o8E
>     <https://gcc.godbolt.org/z/1hq8x1o8E>>> .
>      >      >      >>>>
>      >      >      >>>> Can we have a warning in the second case as well? It
>      >     will be
>      >      >     much more
>      >      >      >>>> convenient as there is a lapse of initialization.
>      >      >      >>>>
>      >      >      >>>
>      >      >      >>> Yes, ideally it would warn.
>      >      >      >>>
>      >      >      >>>
>      >      >      >>>
>      >      >      >>
>      >      >
>      >
>