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 78D3D385842E for ; Wed, 30 Nov 2022 17:10:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 78D3D385842E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=symas.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=symas.com Received: from zmcc-3.zmailcloud.com (183.87.154.104.bc.googleusercontent.com [104.154.87.183]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-3-mx.zmailcloud.com (Postfix) with ESMTPS id 4DE6640597; Wed, 30 Nov 2022 11:14:03 -0600 (CST) Received: from zmcc-3.zmailcloud.com (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTPS id 765DF8036FD6; Wed, 30 Nov 2022 11:10:00 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id 671028035108; Wed, 30 Nov 2022 11:10:00 -0600 (CST) Received: from zmcc-3.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-3-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NXacBZKrvR8K; Wed, 30 Nov 2022 11:10:00 -0600 (CST) Received: from zmcc-3-mailbox-1.zmailcloud.com (zmcc-3-mailbox-1.zmailcloud.com [10.240.0.91]) by zmcc-3-mta-1.zmailcloud.com (Postfix) with ESMTP id 49F548036FD6; Wed, 30 Nov 2022 11:10:00 -0600 (CST) From: Robert Dubner To: "David Malcolm" , Cc: "Bob Dubner" References: <047c01d90370$5c3ecba0$14bc62e0$@symas.com> <7bcf1759ef1b27c2dcc1d98574b0f495022d38b0.camel@redhat.com> <04b801d9039d$ea2348b0$be69da10$@symas.com> In-Reply-To: <04b801d9039d$ea2348b0$be69da10$@symas.com> Subject: RE: Code generation: How to define file-scope static variables? Thread-Topic: Code generation: How to define file-scope static variables? Date: Wed, 30 Nov 2022 11:10:00 -0600 (CST) Message-ID: <062b01d904de$955c5f50$c0151df0$@symas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 X-Mailer: Zimbra 8.8.15_GA_4464 (Zimbra-ZCO/9.0.0.1923 (10.0.22000 en-US) P3288 T6868 R8136) Thread-Index: AQI4xAluAvMuN5FD6PRSWbWhovAmqwIb7dLxAjV0avKtdaQ4kA== Content-Language: en-us 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 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: David, for completion I am updating this message with what I've learned. I do this in the hope that I might assist the next poor souls that find themselves reverse-engineering front ends because they are creating their own front end. I claim only that this worked for me. I can't you tell what assumptions I've been making, because I don't know what I don't know. That said: I found that for file-static variables, the trick is to create a var_decl for the variable with TREE_STATIC(var_decl)=1, and then to call rest_of_decl_compilation (var_decl, true, false); // top_level is true; at_end is false Having done that for an integer_type var_decl with the name "dubner_at_work", and with an initial value of 123454321, I now see this at the very beginning of the generated .s file: ###################### .file "call-scope-1.cbl" .text .Ltext0: .file 0 "/home/bob/repos/gcc-cobol/gcc/cobol/failures/call-scope-1" "call-scope-1.cbl" .data .align 4 .type dubner_at_work, @object .size dubner_at_work, 4 dubner_at_work: .long 123454321 .section .rodata [...] ###################### And that's exactly what I wanted. Thanks for your help. It was your mention of "rest_of_compilation" that ended this marathon investigation, and I really appreciate it. Bob Dubner -----Original Message----- From: Gcc On Behalf Of Robert Dubner Sent: Monday, November 28, 2022 21:55 To: David Malcolm ; gcc@gcc.gnu.org Cc: Bob Dubner Subject: RE: Code generation: How to define file-scope static variables? David, thank you very much. That looks very much like what I was hoping for. I'll dig into it tomorrow. Heartfelt thanks, Bob Dubner. -----Original Message----- From: David Malcolm Sent: Monday, November 28, 2022 18:01 To: Robert Dubner ; gcc@gcc.gnu.org Cc: 'Bob Dubner' Subject: Re: Code generation: How to define file-scope static variables? On Mon, 2022-11-28 at 15:28 -0600, Robert Dubner wrote: > I am part of a team working on a COBOL front end for GCC. > > By reverse engineering other front ends, I learned, some months ago, > how to create a function_decl GENERIC node that is the root of a > GENERIC tree describing an entire function. > > By calling the routine cgraph_node::finalize_function() with that > function_decl, the assembly language for that function is created, and > all is well. > > But now I need to be able to create the equivalent of a file-scope > static variable in C. > > This C program file: > > ////////////////// > static int dubner_at_work = 123454321; int main(int argc, char **argv) > { > } > ////////////////// > > produces, in part, this assembly language: > > ############### > .file "ccc.c" > .text > .data > .align 4 > .type dubner_at_work, @object > .size dubner_at_work, 4 > dubner_at_work: > .long 123454321 > .text > .globl main > .type main, @function > [...] > ############### > > In my own GENERIC generation code, I believe that I am creating a > proper translation_unit_decl that contains the block and the vars > nodes for specifying "dubner_at_work". > > But I have been unable, after several days of looking, to figure out > the equivalent of "cgraph_node::finalize_function" for a > translation_unit_decl. The resulting assembly language doesn't have a > definition for "dubner_at_work". > > Can anybody describe how I can tell the downstream processing that I > need the translation_unit_decl to actually define storage? You might find libgccjit's gcc/jit/jit-playback.cc helpful for this, as it tends to contain minimal code to build trees (generally simplified/reverse-engineered from the C frontend). playback::context::global_new_decl makes the VAR_DECL node, and such trees are added to the jit playback::context's m_globals. In playback::context::replay, we have: /* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file() for a simple reference. */ FOR_EACH_VEC_ELT (m_globals, i, global) rest_of_decl_compilation (global, true, true); wrapup_global_declarations (m_globals.address(), m_globals.length()); So you'll probably want to do something similar for your globals. Caveat: this is all reverse-engineered by me/others from the C frontend (and I haven't touched this code in a while), so I may be missing things here. Dave