valgrind & f951

valgrind & f951

[Harald Anlauf]

Dear all,

in order to be able to run f951 under valgrind on OpenSuse Leap 15.2,
I've already reduced the dwarf version back to 4,

diff --git a/gcc/common.opt b/gcc/common.opt
index c75dd36843e..7dbfcb589ed 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3171,7 +3171,7 @@ Common Driver JoinedOrMissing Negative(gdwarf-)
 Generate debug information in default version of DWARF format.

 gdwarf-
-Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
+Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
 Generate debug information in DWARF v2 (or later) format.

 gdwarf32

However, I am still seeing issues probably in the backend even for the
simplest code, such as

i = 1
end

which is annoying:

==29099== Memcheck, a memory error detector
==29099== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29099== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==29099== Command: /opt/gcc/11/lib/gcc/x86_64-pc-linux-gnu/11.0.1/f951 foo.f90
==29099==
 MAIN__ main
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data> {heap 4096k} <visibility> {heap 4096k} <build_ssa_passes> {heap 4096k} <opt_local_passes> {heap 4096k} <remove_symbols> {heap 4096k} <targetclone> {heap 4096k} <free-fnsummary> {heap 4096k}Streaming LTO
 <whole-program> {heap 4096k} <fnsummary> {heap 4096k} <inline> {heap 4096k} <modref> {heap 4096k} <free-fnsummary> {heap 4096k} <single-use> {heap 4096k} <comdats> {heap 4096k}Assembling functions:
 <simdclone> {heap 4096k} MAIN__ main==29099== Conditional jump or move depends on uninitialised value(s)
==29099==    at 0xBCB62E: sparseset_bit_p (sparseset.h:146)
==29099==    by 0xBCB62E: mark_pseudo_regno_live(int) (ira-lives.c:326)
==29099==    by 0xBCD270: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1433)
==29099==    by 0xBAE40D: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1801)
==29099==    by 0xBCDD8F: ira_create_allocno_live_ranges() (ira-lives.c:1733)
==29099==    by 0xBB0149: ira_build() (ira-build.c:3428)
==29099==    by 0xBA615C: ira (ira.c:5654)
==29099==    by 0xBA615C: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5977)
==29099==    by 0xCC4353: execute_one_pass(opt_pass*) (passes.c:2567)
==29099==    by 0xCC4C70: execute_pass_list_1(opt_pass*) (passes.c:2656)
==29099==    by 0xCC4C82: execute_pass_list_1(opt_pass*) (passes.c:2657)
==29099==    by 0xCC4CC4: execute_pass_list(function*, opt_pass*) (passes.c:2667)
==29099==    by 0x8E8C95: cgraph_node::expand() (cgraphunit.c:1830)
==29099==    by 0x8EA3C7: output_in_order (cgraphunit.c:2141)
==29099==    by 0x8EA3C7: symbol_table::compile() [clone .part.62] (cgraphunit.c:2359)
...
==29099== Use of uninitialised value of size 8
==29099==    at 0xBCB633: sparseset_bit_p (sparseset.h:146)
==29099==    by 0xBCB633: mark_pseudo_regno_live(int) (ira-lives.c:326)
==29099==    by 0xBCD270: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1433)
==29099==    by 0xBAE40D: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1801)
==29099==    by 0xBCDD8F: ira_create_allocno_live_ranges() (ira-lives.c:1733)
==29099==    by 0xBB0149: ira_build() (ira-build.c:3428)
==29099==    by 0xBA615C: ira (ira.c:5654)
==29099==    by 0xBA615C: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5977)
==29099==    by 0xCC4353: execute_one_pass(opt_pass*) (passes.c:2567)
==29099==    by 0xCC4C70: execute_pass_list_1(opt_pass*) (passes.c:2656)
==29099==    by 0xCC4C82: execute_pass_list_1(opt_pass*) (passes.c:2657)
==29099==    by 0xCC4CC4: execute_pass_list(function*, opt_pass*) (passes.c:2667)
==29099==    by 0x8E8C95: cgraph_node::expand() (cgraphunit.c:1830)
==29099==    by 0x8EA3C7: output_in_order (cgraphunit.c:2141)
==29099==    by 0x8EA3C7: symbol_table::compile() [clone .part.62] (cgraphunit.c:2359)
...

and I get tons of the above.

This is not a bootstrap-build compiler; it was configured with --disable-bootstrap.

Could this be the reason for the above?  I would really prefer to no do a full
bootstrap since I am interested only in the development of the Fortran-related
parts of the compiler?

Any insights appreciated.

Thanks,
Harald

Re: valgrind & f951

[Tobias Burnus]

Hi Harald,

On 21.03.21 20:50, Harald Anlauf via Fortran wrote:
> in order to be able to run f951 under valgrind on OpenSuse Leap 15.2,
> I've already reduced the dwarf version back to 4,
> +++ b/gcc/common.opt
> -Common Driver Joined UInteger Var(dwarf_version) Init(5) Negative(gstabs)
> +Common Driver Joined UInteger Var(dwarf_version) Init(4) Negative(gstabs)
you could also just use "-g -gdwarf-4" on the command line.
>   <simdclone> {heap 4096k} MAIN__ main==29099== Conditional jump or move depends on uninitialised value(s)
> ==29099==    at 0xBCB62E: sparseset_bit_p (sparseset.h:146)
This is a false positive; you need to configure GCC with 
|--enable-valgrind-annotations, see 
https://gcc.gnu.org/install/configure.html|I would really prefer to no 
do a full
> bootstrap since I am interested only in the development of the Fortran-related
> parts of the compiler?

If you don't bootstrap, be careful about compiler warnings as the 
bootstrap compiler runs with -Werror in stage2 & 3.

Tobias

Re: valgrind & f951

[Harald Anlauf]

Hi Tobias,

> This is a false positive; you need to configure GCC with
> |--enable-valgrind-annotations, see
> https://gcc.gnu.org/install/configure.html

thanks, that does the job after installing some valgrind-devel stuff.

I apparently got stuck readings the description of --enable-checking,
which also mentions valgrind, and then missed the relevant option.

> If you don't bootstrap, be careful about compiler warnings as the
> bootstrap compiler runs with -Werror in stage2 & 3.

As long as I don't touch code outside fortran/libgfortran and watch
new warnings, it is unlikely to break bootstrap for others.

Thanks,
Harald