I am causing valgrind errors...

[Robert Dubner <rdubner@symas.com>]

This message is a bit of a Hail Mary play.  I am not asking anybody to spend 
any real effort on this question; I am, instead, hoping that somebody will 
say, "Oh, sure; you can fix that by doing so-and-so..." or "That happens 
when the GENERIC tree is ..."

Jim Lowden and I are working on a COBOL front end for GCC.  We are, at this 
point, pretty far along.  He's been focusing on the parsing; I've been doing 
the code generation.

Our front end is based on GCC-13; I just merged in "40e16fda0f4 - 
(gnu-gcc/releases/gcc-13) Daily bump." a few hours ago.

The minimalist background is this:  I start the process of building a 
function by calling
build_varargs_function_type_array().

I feed the returned type_decl to build_fn_decl(), which returns a 
function_decl.

That function_decl becomes the root of a tree that gets everything else 
tacked on.

When I am done creating the function, I pass that function_decl to

    cgraph_node::finalize_function (function_decl, true);

This whole process works; we've been producing executables this way for a 
couple of years.  But I freely admit that I don't know if I am performing 
all necessary magical incantations properly.

The COBOL program I am compiling here does absolutely nothing; it just 
returns.  But our COBOL executables have significant overhead; it’s the 
nature of COBOL.  There are a bunch of variables that get created, whether 
they are used or not, and there is boilerplate code on both entry and exit 
to COBOL functions.

Here's the thing:  when I run valgrind on the compilation -- not on the 
executable, but on the compiler with the COBOL front end -- I am getting a 
bunch of errors that look like variations of this:

==1232157== Command: /home/bob/repos/gcc-cobol/build/gcc/cobol1 
playpen.cbl -quiet -dumpbase 
playpen.cbl -mtune=generic -march=x86-64 -ggdb -O0 -o playpen.s -cmain
==1232157==
==1232157== Conditional jump or move depends on uninitialised value(s)
==1232157==    at 0xABA0CB: sparseset_bit_p (sparseset.h:146)
==1232157==    by 0xABA0CB: mark_pseudo_regno_live(int) (ira-lives.cc:326)
==1232157==    by 0xABBDC0: process_bb_node_lives(ira_loop_tree_node*) 
(ira-lives.cc:1434)
==1232157==    by 0xA9E8D5: ira_traverse_loop_tree(bool, 
ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void 
(*)(ira_loop_tree_node*)) (ira-build.cc:1807)
==1232157==    by 0xABC6F3: ira_create_allocno_live_ranges() 
(ira-lives.cc:1734)
==1232157==    by 0xAA038C: ira_build() (ira-build.cc:3483)
==1232157==    by 0xA971BA: ira (ira.cc:5783)
==1232157==    by 0xA971BA: (anonymous 
namespace)::pass_ira::execute(function*) (ira.cc:6106)
==1232157==    by 0xB95A71: execute_one_pass(opt_pass*) (passes.cc:2651)
==1232157==    by 0xB9632F: execute_pass_list_1(opt_pass*) (passes.cc:2760)
==1232157==    by 0xB96341: execute_pass_list_1(opt_pass*) (passes.cc:2761)
==1232157==    by 0xB9636C: execute_pass_list(function*, opt_pass*) 
(passes.cc:2771)
==1232157==    by 0x846BA7: expand (cgraphunit.cc:1841)
==1232157==    by 0x846BA7: cgraph_node::expand() (cgraphunit.cc:1794)
==1232157==    by 0x847E80: output_in_order (cgraphunit.cc:2191)
==1232157==    by 0x847E80: symbol_table::compile() [clone .part.0] 
(cgraphunit.cc:2395)

Please note that the compiler is generating a good executable from the 
function_decl I am passing to cgraph_ node::finalize_function().  But I 
don't like leaving unexplained errors behind me.  They tend to sneak up 
behind, and they often have teeth.

So, here's my question to the giant brains with eidetic memories who 
populate this list:  Can anybody give me a hint as to what I might be doing 
wrong, either with the tree of GENERIC tags or with the way I am asking the 
GCC back end to compile it, to give valgrind that particular bit of 
indigestion?

Thank you so much for even reading this, and thanks for any hint you might 
have.

Bob Dubner