Re: Extended doubt regarding the bug 93432

[Martin Sebor <msebor@gmail.com>]

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
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

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>> 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>>> 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>>> 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>>
>      >
>      >     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>>>
>      >      >> 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>>> 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>>), 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>>) 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>>) .
>      >      >>>> 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>> .
>      >      >>>>
>      >      >>>> 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.
>      >      >>>
>      >      >>>
>      >      >>>
>      >      >>
>      >
>