public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Extended doubt regarding the bug 93432
@ 2022-02-08 16:24 Krishna Narayanan
  2022-02-08 16:58 ` Jonathan Wakely
  0 siblings, 1 reply; 15+ messages in thread
From: Krishna Narayanan @ 2022-02-08 16:24 UTC (permalink / raw)
  To: gcc-help

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.
Hoping for your reply soon.

Thanks and regards,
Krishna Narayanan.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-08 16:24 Extended doubt regarding the bug 93432 Krishna Narayanan
@ 2022-02-08 16:58 ` Jonathan Wakely
  2022-02-08 17:17   ` Krishna Narayanan
  0 siblings, 1 reply; 15+ messages in thread
From: Jonathan Wakely @ 2022-02-08 16:58 UTC (permalink / raw)
  To: Krishna Narayanan; +Cc: gcc-help

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-08 16:58 ` Jonathan Wakely
@ 2022-02-08 17:17   ` Krishna Narayanan
  2022-02-08 17:37     ` Jonathan Wakely
  0 siblings, 1 reply; 15+ messages in thread
From: Krishna Narayanan @ 2022-02-08 17:17 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: gcc-help

Thanks for your response,Could you please clarify if this is a bug?
Regards,
Krishna Narayanan.

On Tue, Feb 8, 2022 at 10:28 PM Jonathan Wakely <jwakely.gcc@gmail.com>
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.
>
>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-08 17:17   ` Krishna Narayanan
@ 2022-02-08 17:37     ` Jonathan Wakely
  2022-02-08 17:47       ` Krishna Narayanan
                         ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Jonathan Wakely @ 2022-02-08 17:37 UTC (permalink / raw)
  To: Krishna Narayanan; +Cc: gcc-help

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.


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.





> Regards,
> Krishna Narayanan.
>
> On Tue, Feb 8, 2022 at 10:28 PM Jonathan Wakely <jwakely.gcc@gmail.com>
> 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.
>>
>>
>>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-08 17:37     ` Jonathan Wakely
@ 2022-02-08 17:47       ` Krishna Narayanan
  2022-02-08 21:50       ` Martin Sebor
  2022-02-09 16:59       ` Segher Boessenkool
  2 siblings, 0 replies; 15+ messages in thread
From: Krishna Narayanan @ 2022-02-08 17:47 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: gcc-help

Noted Sir,Thank you for the clarification.


On Tue, Feb 8, 2022 at 11:07 PM Jonathan Wakely <jwakely.gcc@gmail.com>
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.
>
>
> 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.
>
>
>
>
>
>> Regards,
>> Krishna Narayanan.
>>
>> On Tue, Feb 8, 2022 at 10:28 PM Jonathan Wakely <jwakely.gcc@gmail.com>
>> 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.
>>>
>>>
>>>
>>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-08 17:37     ` Jonathan Wakely
  2022-02-08 17:47       ` Krishna Narayanan
@ 2022-02-08 21:50       ` Martin Sebor
  2022-02-09  5:06         ` Krishna Narayanan
  2022-02-11 18:10         ` Krishna Narayanan
  2022-02-09 16:59       ` Segher Boessenkool
  2 siblings, 2 replies; 15+ messages in thread
From: Martin Sebor @ 2022-02-08 21:50 UTC (permalink / raw)
  To: Jonathan Wakely, Krishna Narayanan; +Cc: gcc-help

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 <jwakely.gcc@gmail.com>
>> 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.
>>>
>>>
>>>
>>


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-08 21:50       ` Martin Sebor
@ 2022-02-09  5:06         ` Krishna Narayanan
  2022-02-11 18:10         ` Krishna Narayanan
  1 sibling, 0 replies; 15+ messages in thread
From: Krishna Narayanan @ 2022-02-09  5:06 UTC (permalink / raw)
  To: Martin Sebor, gcc-help, Jonathan Wakely

Yes Sir,
 I will go through the dump from uninit pass with required optimizations.I
will try the tree-ssa-uninit.cc on gdb.
Thanks and Regards,
Krishna Narayanan.


On Wed, Feb 9, 2022 at 3:20 AM Martin Sebor <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> 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 <jwakely.gcc@gmail.com>
> >> 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.
> >>>
> >>>
> >>>
> >>
>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-08 17:37     ` Jonathan Wakely
  2022-02-08 17:47       ` Krishna Narayanan
  2022-02-08 21:50       ` Martin Sebor
@ 2022-02-09 16:59       ` Segher Boessenkool
  2022-02-09 18:43         ` Krishna Narayanan
  2 siblings, 1 reply; 15+ messages in thread
From: Segher Boessenkool @ 2022-02-09 16:59 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: Krishna Narayanan, gcc-help

On Tue, Feb 08, 2022 at 05:37:12PM +0000, Jonathan Wakely via Gcc-help wrote:
> 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.
> 
> 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.

GCC does not execute most of its code at -O0.  This is important for
speed of course, but much more importantly it also allows us to use -O0
when other optimisation levels crash or generate wrong code.  This is
useful for the compiler developers of course, but it also is an
important workaround for users, when bad things happen.


Segher

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-09 16:59       ` Segher Boessenkool
@ 2022-02-09 18:43         ` Krishna Narayanan
  0 siblings, 0 replies; 15+ messages in thread
From: Krishna Narayanan @ 2022-02-09 18:43 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: Jonathan Wakely, gcc-help

Noted with thanks.
Krishna Narayanan

On Wed, Feb 9, 2022 at 10:31 PM Segher Boessenkool <
segher@kernel.crashing.org> wrote:

> On Tue, Feb 08, 2022 at 05:37:12PM +0000, Jonathan Wakely via Gcc-help
> wrote:
> > 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.
> >
> > 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.
>
> GCC does not execute most of its code at -O0.  This is important for
> speed of course, but much more importantly it also allows us to use -O0
> when other optimisation levels crash or generate wrong code.  This is
> useful for the compiler developers of course, but it also is an
> important workaround for users, when bad things happen.
>
>
> Segher
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-08 21:50       ` Martin Sebor
  2022-02-09  5:06         ` Krishna Narayanan
@ 2022-02-11 18:10         ` Krishna Narayanan
  2022-02-14 15:24           ` Martin Sebor
  1 sibling, 1 reply; 15+ messages in thread
From: Krishna Narayanan @ 2022-02-11 18:10 UTC (permalink / raw)
  To: Martin Sebor, gcc-help

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?
Thanks and regards,
Krishna Narayanan.


On Wed, Feb 9, 2022 at 3:20 AM Martin Sebor <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> 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 <jwakely.gcc@gmail.com>
> >> 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.
> >>>
> >>>
> >>>
> >>
>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-11 18:10         ` Krishna Narayanan
@ 2022-02-14 15:24           ` Martin Sebor
       [not found]             ` <CABhGnjvSO8svWrBNiO3aKJDjZ5mx2pE-kKgH-0pmyBYjLTwBRw@mail.gmail.com>
  0 siblings, 1 reply; 15+ messages in thread
From: Martin Sebor @ 2022-02-14 15:24 UTC (permalink / raw)
  To: Krishna Narayanan, gcc-help

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>> 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>> 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>
> 
>     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>>
>      >> 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>> 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>), I would like to
>      >>>> add a few more points,here in the given code
>      >>>> (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>) .
>      >>>> 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> .
>      >>>>
>      >>>> 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.
>      >>>
>      >>>
>      >>>
>      >>
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
       [not found]             ` <CABhGnjvSO8svWrBNiO3aKJDjZ5mx2pE-kKgH-0pmyBYjLTwBRw@mail.gmail.com>
@ 2022-02-14 20:22               ` Martin Sebor
  2022-02-15 12:10                 ` Krishna Narayanan
  0 siblings, 1 reply; 15+ messages in thread
From: Martin Sebor @ 2022-02-14 20:22 UTC (permalink / raw)
  To: Krishna Narayanan, gcc-help

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-14 20:22               ` Martin Sebor
@ 2022-02-15 12:10                 ` Krishna Narayanan
  2022-02-16 21:27                   ` Martin Sebor
  0 siblings, 1 reply; 15+ messages in thread
From: Krishna Narayanan @ 2022-02-15 12:10 UTC (permalink / raw)
  To: Martin Sebor, gcc-help

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.
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.
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?
Thanks and Regards,
Krishna Narayanan.

On Tue, Feb 15, 2022 at 1:52 AM Martin Sebor <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
> 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.
> >      >      >>>
> >      >      >>>
> >      >      >>>
> >      >      >>
> >      >
> >
>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-15 12:10                 ` Krishna Narayanan
@ 2022-02-16 21:27                   ` Martin Sebor
  2022-02-19 13:38                     ` Krishna Narayanan
  0 siblings, 1 reply; 15+ messages in thread
From: Martin Sebor @ 2022-02-16 21:27 UTC (permalink / raw)
  To: Krishna Narayanan, gcc-help

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Extended doubt regarding the bug 93432
  2022-02-16 21:27                   ` Martin Sebor
@ 2022-02-19 13:38                     ` Krishna Narayanan
  0 siblings, 0 replies; 15+ messages in thread
From: Krishna Narayanan @ 2022-02-19 13:38 UTC (permalink / raw)
  To: Martin Sebor, gcc-help

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 <msebor@gmail.com> 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
> > <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.
> >      >      >      >>>
> >      >      >      >>>
> >      >      >      >>>
> >      >      >      >>
> >      >      >
> >      >
> >
>
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-02-19 13:38 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-08 16:24 Extended doubt regarding the bug 93432 Krishna Narayanan
2022-02-08 16:58 ` Jonathan Wakely
2022-02-08 17:17   ` Krishna Narayanan
2022-02-08 17:37     ` Jonathan Wakely
2022-02-08 17:47       ` Krishna Narayanan
2022-02-08 21:50       ` Martin Sebor
2022-02-09  5:06         ` Krishna Narayanan
2022-02-11 18:10         ` Krishna Narayanan
2022-02-14 15:24           ` Martin Sebor
     [not found]             ` <CABhGnjvSO8svWrBNiO3aKJDjZ5mx2pE-kKgH-0pmyBYjLTwBRw@mail.gmail.com>
2022-02-14 20:22               ` Martin Sebor
2022-02-15 12:10                 ` Krishna Narayanan
2022-02-16 21:27                   ` Martin Sebor
2022-02-19 13:38                     ` Krishna Narayanan
2022-02-09 16:59       ` Segher Boessenkool
2022-02-09 18:43         ` Krishna Narayanan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).