From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id B3ECD3858D1E for ; Sat, 19 Feb 2022 13:38:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B3ECD3858D1E Received: by mail-pg1-x534.google.com with SMTP id z4so10221847pgh.12 for ; Sat, 19 Feb 2022 05:38:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2/n6qw5ATWhYJHfa8ZDdpZ5p5QFkzdYYbpeKCVriD0Y=; b=AwABsM/TsnCc2TyRJQ5p/McWV72nIx3YNybNzFgkzBrDZmoZzWLHb86R0fRBTFhjNb OWFHZMNu3C6AMb6ZJCFg5IXVyJgVZ4uFqJKsd6H2tXsCU+WEp01EM/PFRgXLXz68CDH8 i6MeKJ9r3EzPI6ShAl6YTemkkTS4+CxnMs7B+js3Zd+2pVtK5aK0yEQALo6bm4JPPXgW 76mmG1b0p5SmPuym79LMPdvxEBFjcJoin7egKWmU4igPton3jIlgdn9LRCgo8BCZRiyd KMqv6okswVtr8JaYJi1+60fJStPaLuvCR124SL2m+nW7dj4YuxQ4oW/pt3Zq3JzMuwGE BEFA== X-Gm-Message-State: AOAM531kWmgxrBS6yS4aRc8uaDNgfD1Jbm8IJA9kjSZ+dVZPMpyx1AaG POaLpqT0O28NR1Qu8rjfQP16c7+WHDIaSd0et1w= X-Google-Smtp-Source: ABdhPJy3Qo7Hr5F3zNY/mqZTbzHjps1fXqAuBRM9SK5tRBNlH6E4z6LodCO5itRviYvFnmYV8aha+HwJjvY6179nE1M= X-Received: by 2002:a63:e657:0:b0:364:1f4e:d309 with SMTP id p23-20020a63e657000000b003641f4ed309mr9927402pgj.462.1645277929666; Sat, 19 Feb 2022 05:38:49 -0800 (PST) MIME-Version: 1.0 References: <641d2125-7809-77eb-f007-3dd784940873@gmail.com> <9dfb6d10-e6a5-f415-b58d-8ac8c6519a5e@gmail.com> <713a3312-0b01-2e61-e41e-d1cefd94819d@gmail.com> In-Reply-To: From: Krishna Narayanan Date: Sat, 19 Feb 2022 19:08:37 +0530 Message-ID: Subject: Re: Extended doubt regarding the bug 93432 To: Martin Sebor , gcc-help X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, KAM_EU, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2022 13:38:55 -0000 Thanks, I also tried by cloning,but that error persists,I did not try changing the ./gdbinit. "add-auto-load-safe-path /absolute/path/to/build/gcc" is what I tried putting it in .gdbinit ,that's it. To give an update about uninitialized variable bugs, I am going through the passes of RTL,tree and seeing their PHI nodes, hashtable and other pass details. I am preparing a test case for that and going forward with it. Thanks a lot! Krishna Narayanan On Thu, Feb 17, 2022 at 2:57 AM Martin Sebor wrote: > 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 > > ) 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 > > 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 "" > > > # 1 "" > > > # 31 "" > > > # 1 "/usr/include/stdc-predef.h" 1 3 4 > > > # 32 "" 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 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 > > < > 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 > > > > >> 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 > > > > > > > > > > > > >>> 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 > > > > > > > > > > > > > > > > >>> 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 > > > > > > > > > > > > > > > > >> > > > > > > > > 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 > > > > > > > > > > > > >>> > > > > >> wrote: > > > > >> > > > > >>> > > > > >>> > > > > >>> On Tue, 8 Feb 2022 at 16:25, Krishna Narayanan via > > > Gcc-help < > > > > >>> gcc-help@gcc.gnu.org > > > > > > > > > >>> wrote: > > > > >>> > > > > >>>> Hello, > > > > >>>> As an extension to the bug 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 > > > > > > > > > > > > > > > > >>) there is a warning averted but > > there > > > > >>>> is no warning shown for this code > > > > >>>> (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 > > > > > > > > > > > > > > > > >> . > > > > >>>> > > > > >>>> 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. > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > >