From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fencepost.gnu.org (fencepost.gnu.org [IPv6:2001:470:142:3::e]) by sourceware.org (Postfix) with ESMTPS id 5EC793857037 for ; Tue, 15 Dec 2020 03:34:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5EC793857037 Received: from eggs.gnu.org ([2001:470:142:3::10]:46428) by fencepost.gnu.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kp16a-0002jP-Kf for gcc-patches@gnu.org; Mon, 14 Dec 2020 22:34:28 -0500 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]:33499) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kp16Y-0007v8-Jo for gcc-patches@gnu.org; Mon, 14 Dec 2020 22:34:28 -0500 Received: by mail-lf1-x141.google.com with SMTP id l11so35722730lfg.0 for ; Mon, 14 Dec 2020 19:34:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ihjHMrBd9LXOhjbWNRrBOU7rk36Vw02TuxlMsooeKA=; b=biqnlZgN8JdSn+X4x+8wzRtbwFYgQoW90J9pm4AWFEnNqXEKmb2aC7eLgPCqdhOHuD xEyCLCI9iAUDwM3cnON3Moi4NFpyXTyY0oKcIG6BRSdgt+46Dk4T2fmf+505JlJuReBo MC5VYx4FT+ZvTz4EdfOrVz+Gc54AMjvPwjd0o1SStbzLci8jxFyB8QMU/ChNOzFOMqLb HjZDZIKXglmWOCl7fZ+1gaXNoJMizyjof1/48LETilTJzndznBeN0/q7M0WfGDlTVR97 dOn8R2XgLWhsvKRoiDJG+hRoWZrW/xNqvtC54dyz+YDtE1uXQcHvPxYy0hVW+NjOnJDM Tt/w== X-Gm-Message-State: AOAM530FyTbms6KO268bVf14GFsFqX6/3Dzovwn/lKT5EU/MTz4cjYEF P6xa8UY3Q4uuwtaO2F2wo4177Ji5BnuHXt8mv9Y7xg== X-Google-Smtp-Source: ABdhPJxGPz6nsGPa1bF7riZHbA3HjSKG+OQdJALLb3yCduxEm8unAqjXNJQTnvOqpY8QeMhc2N8BFclJTdBR2XFSTvA= X-Received: by 2002:a2e:b8d1:: with SMTP id s17mr12185373ljp.472.1608003264514; Mon, 14 Dec 2020 19:34:24 -0800 (PST) MIME-Version: 1.0 References: <52818e83-3ff8-31b3-f444-eb21e3931a82@gmail.com> <2913efa6-53ed-d5c1-fa04-7d14539dfbd9@gmail.com> <4b48e0a9-cac4-9df1-8cbe-ce499284f8b0@gmail.com> In-Reply-To: From: Ian Lance Taylor Date: Mon, 14 Dec 2020 19:34:12 -0800 Message-ID: Subject: Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types To: Nikhil Benesch Cc: Rainer Orth , gcc-patches , gofrontend-dev Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::141; envelope-from=iant@google.com; helo=mail-lf1-x141.google.com X-Spam_score_int: -91 X-Spam_score: -9.2 X-Spam_bar: --------- X-Spam_report: (-9.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 03:34:31 -0000 On Mon, Dec 14, 2020 at 7:14 PM Nikhil Benesch wrote: > > On 12/14/20 5:30 AM, Rainer Orth wrote: > > with the revised godump.c patch and this one for mk*sysinfo.sh, I still > > get failures on all of Solaris 11.3/x86, 11.4/x86, and 11.4/SPARC > > (didn't try 11.3/SPARC): > > > > * Solaris 11.3/x86 and 11.4/x86: > > > > runtime_sysinfo.go:5995:6: error: redefinition of '_upad128_t' > > > > gen-sysinfo has > > > > // type _upad128_t struct { _q INVALID-float-80; Godump_0_pad [4]byte; } > > type _upad128_t struct {} > > > > and mk*sysinfo.sh adds > > > > type _upad128_t struct { _l [4]uint32; } > > > > * Solaris 11.4/SPARC and x86: > > > > runtime_sysinfo.go:1178:55: error: use of undefined type '_in6_addr_t' > > > > runtime_sysinfo.go uses _in6_addr_t in _flow_arp_desc_s, > > _flow_l3_desc_s, _mac_ipaddr_s, _mac_resource_props_s, and > > _mactun_info_s, but there's no definition and you've removed the > > section of mk*sysinfo.sh to replace it by [16]byte. > > > > The issue is here, I believe: > > > > + -e 's/\([^a-zA-Z0-9_]\)_in6_addr\([^a-zA-Z0-9_]\)/\1[16]byte\2/g' \ > > + -e 's/\([^a-zA-Z0-9_]\)_in6_addr$/\1[16]byte/g' \ > > > > Neither line matches _in6_addr_t. Removing '_' from the second char > > set on the first line fixes this, but I'm unsure what exactly this is > > going to match on different systems. > > > > Rainer > > > > Sigh. Thanks. Perhaps the attached will work. > > (I'm still waiting on my own compilation to complete. Compilation on > gcc211 is glacial. I wonder if I'm doing something wrong.) > > The idea is to just rewrite both _in_addr and _in_addr_t. Perhaps > someone smarter than me can figure out how to write a simpler set > of basic REs. > > Also godump now emits a dummy `type _u?pad128_t struct {}` entry, > so we just suppress that and conditionally add it back. I don't understand this bit. Why are we seeing an empty struct definition, and why is this change the right fix? Is the problem that because we don't know how to emit the definition of the struct, godump.c winds up emitting an empty definition? That doesn't sound like the right thing to do for this case. Ian