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
