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@xxxxxxxxx
<mailto:msebor@xxxxxxxxx>> wrote:
On 2/8/22 10:37, Jonathan Wakely via Gcc-help wrote:
> On Tue, 8 Feb 2022 at 17:18, Krishna Narayanan <
> krishnanarayanan132002@xxxxxxxxx
<mailto:krishnanarayanan132002@xxxxxxxxx>> 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@xxxxxxxxx <mailto:jwakely.gcc@xxxxxxxxx>>
>> wrote:
>>
>>>
>>>
>>> On Tue, 8 Feb 2022 at 16:25, Krishna Narayanan via Gcc-help <
>>> gcc-help@xxxxxxxxxxx <mailto:gcc-help@xxxxxxxxxxx>> 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.
>>>
>>>
>>>
>>
