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 D852E3833025 for ; Thu, 17 Dec 2020 12:28:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D852E3833025 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gcc-refused-email@gnu.org Received: from eggs.gnu.org ([2001:470:142:3::10]:53542) by fencepost.gnu.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kpsOZ-00059q-Fu for gcc-patches@gnu.org; Thu, 17 Dec 2020 07:28:36 -0500 Received: from smtp.cebitec.uni-bielefeld.de ([129.70.160.84]:59960) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpsOX-0007B2-0Z for gcc-patches@gnu.org; Thu, 17 Dec 2020 07:28:35 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 54C4FA744; Thu, 17 Dec 2020 13:28:30 +0100 (CET) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t48QPKJuE15C; Thu, 17 Dec 2020 13:28:29 +0100 (CET) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddb2f4.dip0.t-ipconnect.de [79.221.178.244]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 0CB8EA743; Thu, 17 Dec 2020 13:28:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1608208109; bh=6jy3HcEwUeX6cpKZm5NEA5dgk8XsQDJZwvCdsrybgJw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Ty7mSwud3hDX5yCscVb/8MdsHKWaHcTDpL6dRxiYTQScsiIcX18OaDbVuRyJJfJt9 GTAbRtBujbF868xoy0eCzM/Ft51fGi3Y6t95aQj+a614+LMG+N25hYLAGiT/Vmgyds jxE2ydVrXYhdW3MXlyIYuVwF8jZ/nD2sKJ51ii4d9veNXLxWBuHUS9PC38xhY0Hpvm 1VbwfMfy5zGEo8bUvakTE9xFctHDStRmtcF+ruqQA8PjDpokweh+jVLhR9h3e4kN51 srjJ+7e9//2CJmkcxIhEUbGxZmVnJ7ZwXDn9kcuCLaIjHgJPpgfJHpUaWjqfFreLE3 RNc4aCODUqNuw== From: Rainer Orth To: Nikhil Benesch Cc: Ian Lance Taylor , gcc-patches , gofrontend-dev Subject: Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types References: <52818e83-3ff8-31b3-f444-eb21e3931a82@gmail.com> <2913efa6-53ed-d5c1-fa04-7d14539dfbd9@gmail.com> <4b48e0a9-cac4-9df1-8cbe-ce499284f8b0@gmail.com> <3ea15d6f-20d1-69e5-aecf-003f51a385ff@gmail.com> Date: Thu, 17 Dec 2020 13:28:28 +0100 In-Reply-To: (Nikhil Benesch's message of "Wed, 16 Dec 2020 23:59:38 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: none client-ip=129.70.160.84; envelope-from=ro@cebitec.uni-bielefeld.de; helo=smtp.CeBiTec.Uni-Bielefeld.DE X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-3790.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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: Thu, 17 Dec 2020 12:28:38 -0000 Hi Nikhil, >> I suspect what is happening here is that godump sees "typedef ucontext_t struct >> ucontext" and outputs the typedef immediately. Only later does it observe that >> "struct ucontext" is invalid. At that point it is too late to comment out the >> typedef for _ucontext_t. > > Oh, wait, Rainer, did you apply *both* solaris-godump.patch and > invalid-dummy.patch? I think if you apply only the former (i.e., only I did indeed. TBH I sort of lost track which patches were and weren't required to get this fixed ;-) > solaris-godump.patch), which is the only bit I've submitted upstream, > all will be well. > > For good measure, I've also fixed the issue in invalid-dummy.patch > and attached a new version. But I'm still not sure whether it is a > worthwhile change, and it's something we can discuss separately from > solaris-godump.patch. I first tried with the new version included, but that broke badly: cc1 -fpreprocessed sysinfo.i -quiet -O -std=gnu99 -fdump-go-spec=tmp-gen-sysinfo.go -o sysinfo.s now SEGVs with either infinite or very deep recursion: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x08ea285e in go_format_type (container=container@entry=0xfeffd738, type= , use_type_name=true, is_func_ok=true, p_art_i=0x0, is_anon_record_or_union=false) at /vol/gcc/src/hg/master/local/gcc/godump.c:688 688 { (gdb) where #0 0x08ea285e in go_format_type (container=container@entry=0xfeffd738, type=, use_type_name=true, is_func_ok=true, p_art_i=0x0, is_anon_record_or_union=false) at /vol/gcc/src/hg/master/local/gcc/godump.c:688 #1 0x08ea2cff in go_format_type (container=container@entry=0xfeffd738, type=type@entry=, use_type_name=use_type_name@entry=true, is_func_ok=false, p_art_i=0xfe6fe174, is_anon_record_or_union=false) at /vol/gcc/src/hg/master/local/gcc/tree.h:3453 #2 0x08ea3506 in go_format_type (container=container@entry=0xfeffd738, type=type@entry=, use_type_name=use_type_name@entry=false, is_func_ok=false, p_art_i=0xfe6fe174, is_anon_record_or_union=false) at /vol/gcc/src/hg/master/local/gcc/godump.c:1002 #3 0x08ea3335 in go_format_type (container=container@entry=0xfeffd738, type=, use_type_name=, is_func_ok=true, p_art_i=0xfe6fe234, is_anon_record_or_union=false) at /vol/gcc/src/hg/master/local/gcc/godump.c:741 #4 0x08ea2cff in go_format_type (container=container@entry=0xfeffd738, type=type@entry=, use_type_name=use_type_name@entry=true, is_func_ok=false, p_art_i=0xfe6fe3b4, is_anon_record_or_union=false) at /vol/gcc/src/hg/master/local/gcc/tree.h:3453 I've now reverted that part and the build is into make check, as you suspected. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University