From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id AC8EB385B536 for ; Mon, 28 Nov 2022 23:02:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AC8EB385B536 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669676574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1lhvlI4l6CTQLlv5RlBSiRFNE+nY9/D+ytyFJaC1FOE=; b=eX3En/etYj08fwCg1l0wlOTxTVJj7ug0N5ryGi2co97C+U2SWPdOTAKHZrTGDI+hKxjQj4 kVxWmi2jD17w8nIVXhn33hH9O3lT/UVtdGHjiNSr/7yAU6bRWNC+X8Yyz2qrqZ2T11vIha 8WpZw2yxpZtE95VxSW6tDz2UYLDhCk4= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-360-DU8HUZE0NwieUjt7A7H_DQ-1; Mon, 28 Nov 2022 18:01:29 -0500 X-MC-Unique: DU8HUZE0NwieUjt7A7H_DQ-1 Received: by mail-qv1-f71.google.com with SMTP id nh17-20020a056214391100b004bb6c16bd4dso16053389qvb.17 for ; Mon, 28 Nov 2022 15:01:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1lhvlI4l6CTQLlv5RlBSiRFNE+nY9/D+ytyFJaC1FOE=; b=QrbtnqiFTIDpxKtUNo0l5q0LY57Ronxk7GEF3qL78L3F6eKtwNWBMuhYQ0q8EClR37 MBOUdEjgY2Hy7Ar3A8EIGjFd0M3vLm9sjbke5JS3xsiWa/arElWe4mu/6wmKk7zO1WpN 4AwCZi0tXmR+4M6AY+tHaZi7mMt739P09hBtPOKU3YsdK0uUSXV0BMPsZnHH2JjleMx5 TBnITSesUgSXZOJdwwwXmvc3IDSqj9luFhjJNuYHAtn/ZS0OKE9EtuSKl6xBUadhcPsj TVhbCz0VmVFgJUUGEV4or1SfLmr3119YDcRuxZaU2o8M+sHm5C+3k2pLMUurkSCNgHWZ EYaA== X-Gm-Message-State: ANoB5pnbAelc7afNykYiLJuU2L75Ro2Qze8GSb0LhADRJeMmxZTb9qmY efRWmYYWv2UrNSU+eQqLTJjf2OxE5jJcIrMep7ASHVZstBXqZRQQCaR4aV1PNvRqZTDg9YJgR7K avUU+57s= X-Received: by 2002:a05:620a:51c4:b0:6ec:5235:8c0 with SMTP id cx4-20020a05620a51c400b006ec523508c0mr32929206qkb.179.1669676488951; Mon, 28 Nov 2022 15:01:28 -0800 (PST) X-Google-Smtp-Source: AA0mqf7wK1bYrSrS42zxGqQCnzK2mCIG1VqtwGzrcOcrO9g+mUG+FHxAeFYuna0xuEB7jOtIbI0x/w== X-Received: by 2002:a05:620a:51c4:b0:6ec:5235:8c0 with SMTP id cx4-20020a05620a51c400b006ec523508c0mr32929168qkb.179.1669676488466; Mon, 28 Nov 2022 15:01:28 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id a195-20020ae9e8cc000000b006fb3884e10bsm9151560qkg.24.2022.11.28.15.01.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 15:01:28 -0800 (PST) Message-ID: <7bcf1759ef1b27c2dcc1d98574b0f495022d38b0.camel@redhat.com> Subject: Re: Code generation: How to define file-scope static variables? From: David Malcolm To: Robert Dubner , gcc@gcc.gnu.org Cc: 'Bob Dubner' Date: Mon, 28 Nov 2022 18:01:26 -0500 In-Reply-To: <047c01d90370$5c3ecba0$14bc62e0$@symas.com> References: <047c01d90370$5c3ecba0$14bc62e0$@symas.com> User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: 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. >=20 > 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.=C2=A0=C2=A0=20 >=20 > By calling the routine cgraph_node::finalize_function() with that > function_decl, the assembly language for that function is created, > and all > is well. >=20 > But now I need to be able to create the equivalent of a file-scope > static > variable in C. >=20 > This C program file: >=20 > ////////////////// > static int dubner_at_work =3D 123454321; > int main(int argc, char **argv) > =C2=A0 { > =C2=A0 } > ////////////////// >=20 > produces, in part, this assembly language: >=20 > ############### > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.file=C2=A0=C2=A0=C2=A0"c= cc.c" > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.text > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.data > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.align 4 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.type=C2=A0=C2=A0=C2=A0du= bner_at_work, @object > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.size=C2=A0=C2=A0=C2=A0du= bner_at_work, 4 > dubner_at_work: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.long=C2=A0=C2=A0=C2=A012= 3454321 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.text > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.globl=C2=A0=C2=A0main > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.type=C2=A0=C2=A0=C2=A0ma= in, @function > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[...] > ############### >=20 > 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". >=20 > 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.=C2=A0 The resulting assembly language doesn't have > a > definition for "dubner_at_work". >=20 > 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