From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zmcc-3-mx.zmailcloud.com (zmcc-3-mx.zmailcloud.com [34.200.143.36]) by sourceware.org (Postfix) with ESMTPS id D4F003858407 for ; Wed, 10 Jan 2024 20:47:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D4F003858407 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=symas.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=symas.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D4F003858407 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=34.200.143.36 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704919631; cv=none; b=VYVmfYYBKusGHjs+gBKEOdjBRxSJJ1d4cpd0Eto042/m8OidpjlCjingcGI2Q8IFO76Rgyd6JNDUIszQ/3Hrc26KyUtkA98mE2I0wKG7XXRZ0VcPNnllVaqikxoSdxtewL0tjOA//IC4yhmi9UkHDP2b3uW3/ZQJ2nJee6LVAcU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704919631; c=relaxed/simple; bh=0O1spFRC1eX/bJHBIaDH9yeYJ8e8BOkRwGyjGix7Qf0=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=YXkqHhq83dI3jNhjc8chE/bcucQ76y0a1rXQNQPRZE9dIEZcYT7uoNE+We96Id6IOFc+0kmdLDUp/jD74gCxq5tPw6Dz7VlC/VA76dv2QeWktSimkZRFoZmoRL/DCFWWUJl/OxFeYFSyoAiMbaegI7e47u44J1UgspSIgD8fR9s= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from zmcc-3.zmailcloud.com (ec2-3-15-255-223.us-east-2.compute.amazonaws.com [3.15.255.223]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by zmcc-3-mx.zmailcloud.com (Postfix) with ESMTPS id 1F538C6A12 for ; Wed, 10 Jan 2024 14:47:09 -0600 (CST) Received: from zmcc-3.zmailcloud.com (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTPS id 05D808027; Wed, 10 Jan 2024 14:47:09 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id E91A68029; Wed, 10 Jan 2024 14:47:08 -0600 (CST) Received: from zmcc-3.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-3-mta-1.zmailcloud.com [127.0.0.1]) (amavis, port 10026) with ESMTP id RUKEs2u4byJz; Wed, 10 Jan 2024 14:47:08 -0600 (CST) Received: from zmcc-3-mailbox-1.zmailcloud.com (zmcc-3-mailbox-1.zmailcloud.com [172.31.28.18]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id B592B8027; Wed, 10 Jan 2024 14:47:08 -0600 (CST) From: Robert Dubner To: "'GCC Mailing List'" Cc: "Robert Dubner" References: <7b2c4b10-4134-4f1b-9597-de66d6072f16@redhat.com> In-Reply-To: <7b2c4b10-4134-4f1b-9597-de66d6072f16@redhat.com> Subject: I am causing valgrind errors... Thread-Topic: I am causing valgrind errors... Date: Wed, 10 Jan 2024 14:47:08 -0600 (CST) Message-ID: <00c401da4406$2e55d300$8b017900$@symas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Outlook 16.0 X-Mailer: Zimbra 9.0.0_GA_4583 (Zimbra-ZCO/9.0.0.1939 (10.0.22621 en-US) P49d0 T45c R915) Thread-Index: AdpEAS6nCaSYLxFcQ/qwzPWme1Bkwg== Content-Language: en-us Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is a bit of a Hail Mary play. I am not asking anybody to sp= end=20 any real effort on this question; I am, instead, hoping that somebody wil= l=20 say, "Oh, sure; you can fix that by doing so-and-so..." or "That happens=20 when the GENERIC tree is ..." Jim Lowden and I are working on a COBOL front end for GCC. We are, at th= is=20 point, pretty far along. He's been focusing on the parsing; I've been do= ing=20 the code generation. Our front end is based on GCC-13; I just merged in "40e16fda0f4 -=20 (gnu-gcc/releases/gcc-13) Daily bump." a few hours ago. The minimalist background is this: I start the process of building a=20 function by calling build_varargs_function_type_array(). I feed the returned type_decl to build_fn_decl(), which returns a=20 function_decl. That function_decl becomes the root of a tree that gets everything else=20 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= =20 couple of years. But I freely admit that I don't know if I am performing= =20 all necessary magical incantations properly. The COBOL program I am compiling here does absolutely nothing; it just=20 returns. But our COBOL executables have significant overhead; it=E2=80=99= s the=20 nature of COBOL. There are a bunch of variables that get created, whethe= r=20 they are used or not, and there is boilerplate code on both entry and exi= t=20 to COBOL functions. Here's the thing: when I run valgrind on the compilation -- not on the=20 executable, but on the compiler with the COBOL front end -- I am getting = a=20 bunch of errors that look like variations of this: =3D=3D1232157=3D=3D Command: /home/bob/repos/gcc-cobol/build/gcc/cobol1=20 playpen.cbl -quiet -dumpbase=20 playpen.cbl -mtune=3Dgeneric -march=3Dx86-64 -ggdb -O0 -o playpen.s -cmai= n =3D=3D1232157=3D=3D =3D=3D1232157=3D=3D Conditional jump or move depends on uninitialised val= ue(s) =3D=3D1232157=3D=3D at 0xABA0CB: sparseset_bit_p (sparseset.h:146) =3D=3D1232157=3D=3D by 0xABA0CB: mark_pseudo_regno_live(int) (ira-live= s.cc:326) =3D=3D1232157=3D=3D by 0xABBDC0: process_bb_node_lives(ira_loop_tree_n= ode*)=20 (ira-lives.cc:1434) =3D=3D1232157=3D=3D by 0xA9E8D5: ira_traverse_loop_tree(bool,=20 ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void=20 (*)(ira_loop_tree_node*)) (ira-build.cc:1807) =3D=3D1232157=3D=3D by 0xABC6F3: ira_create_allocno_live_ranges()=20 (ira-lives.cc:1734) =3D=3D1232157=3D=3D by 0xAA038C: ira_build() (ira-build.cc:3483) =3D=3D1232157=3D=3D by 0xA971BA: ira (ira.cc:5783) =3D=3D1232157=3D=3D by 0xA971BA: (anonymous=20 namespace)::pass_ira::execute(function*) (ira.cc:6106) =3D=3D1232157=3D=3D by 0xB95A71: execute_one_pass(opt_pass*) (passes.c= c:2651) =3D=3D1232157=3D=3D by 0xB9632F: execute_pass_list_1(opt_pass*) (passe= s.cc:2760) =3D=3D1232157=3D=3D by 0xB96341: execute_pass_list_1(opt_pass*) (passe= s.cc:2761) =3D=3D1232157=3D=3D by 0xB9636C: execute_pass_list(function*, opt_pass= *)=20 (passes.cc:2771) =3D=3D1232157=3D=3D by 0x846BA7: expand (cgraphunit.cc:1841) =3D=3D1232157=3D=3D by 0x846BA7: cgraph_node::expand() (cgraphunit.cc:= 1794) =3D=3D1232157=3D=3D by 0x847E80: output_in_order (cgraphunit.cc:2191) =3D=3D1232157=3D=3D by 0x847E80: symbol_table::compile() [clone .part.= 0]=20 (cgraphunit.cc:2395) Please note that the compiler is generating a good executable from the=20 function_decl I am passing to cgraph_ node::finalize_function(). But I=20 don't like leaving unexplained errors behind me. They tend to sneak up=20 behind, and they often have teeth. So, here's my question to the giant brains with eidetic memories who=20 populate this list: Can anybody give me a hint as to what I might be doi= ng=20 wrong, either with the tree of GENERIC tags or with the way I am asking t= he=20 GCC back end to compile it, to give valgrind that particular bit of=20 indigestion? Thank you so much for even reading this, and thanks for any hint you migh= t=20 have. Bob Dubner