From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id 2CDDA385840E for ; Wed, 16 Feb 2022 21:27:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2CDDA385840E Received: by mail-io1-xd32.google.com with SMTP id m185so1341242iof.10 for ; Wed, 16 Feb 2022 13:27:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:references:content-language:in-reply-to :content-transfer-encoding; bh=M9t8asOMt1oZVQnqaeOp239Ldf/6pGEZeL6xJFxTGUk=; b=E/ZVwrBDIqsoKHa0TBg1HhVzYGxovMJWV4mfX1VueM0iX1g3YUEU4/TvkS2Uu9AjHR hm3GhZSyUeDMz1dYx8/g4ERWp4HRfHhbTGjg7ELctnb1Y5RjATC35sSqrSkoV/Hilwxv 6h3joP4bTPjnlC6tebMB+rfxhXl3wpy1L25k+D0W9ba5178FlBgoOJOSAAG/xw0nqoIf Fi/N6MwCwqRQiNveC/D6x3fEorrsRCbkHbmj0Z3Qgf/ighD7ztWt2b8Hr6r2glyrGR5L LGAv0T3YiTbhRZTKhjTq1zPU7jkosFTP/SXrtYN/jNgasMi/HTN2CPRQJWJT6vweokpS 5YWQ== X-Gm-Message-State: AOAM532yTHF5bZFElGZb5w0QcDQOCCVJgr3kQcl4mXt5KGl0momcqJpV ej1BBEIwU3Jqe3rJ3r0qWF+ZPla+BTQ= X-Google-Smtp-Source: ABdhPJwyTtj/UAwzlTGkpTQfJhvIzHO8DrnyS9eM4w5WkYy5ju7iNHTg5SirWBnyg8K/8AQEv6WPaw== X-Received: by 2002:a6b:8e17:0:b0:60d:c43a:6992 with SMTP id q23-20020a6b8e17000000b0060dc43a6992mr3142463iod.24.1645046830389; Wed, 16 Feb 2022 13:27:10 -0800 (PST) Received: from [192.168.0.41] (184-96-236-24.hlrn.qwest.net. [184.96.236.24]) by smtp.gmail.com with ESMTPSA id t195sm578482iof.47.2022.02.16.13.27.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Feb 2022 13:27:09 -0800 (PST) Message-ID: Date: Wed, 16 Feb 2022 14:27:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 From: Martin Sebor Subject: Re: Extended doubt regarding the bug 93432 To: Krishna Narayanan , gcc-help References: <641d2125-7809-77eb-f007-3dd784940873@gmail.com> <9dfb6d10-e6a5-f415-b58d-8ac8c6519a5e@gmail.com> <713a3312-0b01-2e61-e41e-d1cefd94819d@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_EU, KAM_NUMSUBJECT, KAM_SHORT, NICE_REPLY_A, 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-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: Wed, 16 Feb 2022 21:27:19 -0000 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 > > > 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. > >      >      >>> > >      >      >>> > >      >      >>> > >      >      >> > >      > > > >