public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nikhil Benesch <nikhil.benesch@gmail.com>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: Ian Lance Taylor <iant@golang.org>,
	gcc-patches <gcc-patches@gnu.org>,
	gofrontend-dev <gofrontend-dev@googlegroups.com>
Subject: Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types
Date: Thu, 17 Dec 2020 11:31:18 -0500	[thread overview]
Message-ID: <27545742-2549-e0eb-63ce-42f019f4e7ec@gmail.com> (raw)
In-Reply-To: <yddim90y5ub.fsf@CeBiTec.Uni-Bielefeld.DE>

On 12/17/20 7:28 AM, Rainer Orth wrote:
> 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=
>      <record_type 0xfa50be40>, 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=<record_type 0xfa50be40>, 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=<pointer_type 0xfa50bea0>,
>      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=<record_type 0xfa50be40>,
>      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=<record_type 0xfa50be40>, use_type_name=<optimized out>,
>      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=<pointer_type 0xfa50bea0>,
>      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.

Whew, ok, great. Let's leave invalid-godump-2.patch as a curiosity for
Ian, then. The current approach of outputting dummy types for every
invalid type is unsatisfying, but in practice it seems to work alright.

Nikhil

  reply	other threads:[~2020-12-17 16:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 22:57 Nikhil Benesch
2020-12-10  2:48 ` Ian Lance Taylor
2020-12-10 19:18   ` Rainer Orth
2020-12-10 19:31     ` Nikhil Benesch
2020-12-10 19:34       ` Rainer Orth
2020-12-10 19:49         ` Nikhil Benesch
2020-12-10 21:44           ` Rainer Orth
2020-12-13 21:55             ` Nikhil Benesch
2020-12-13 23:30               ` Nikhil Benesch
2020-12-14  7:39                 ` Ian Lance Taylor
2020-12-14  8:22                   ` Nikhil Benesch
2020-12-14 10:30               ` Rainer Orth
2020-12-15  3:14                 ` Nikhil Benesch
2020-12-15  3:34                   ` Ian Lance Taylor
2020-12-15  3:48                     ` Nikhil Benesch
2020-12-15  8:00                       ` Nikhil Benesch
2020-12-16 14:00                         ` Nikhil Benesch
2020-12-16 19:20                           ` Rainer Orth
2020-12-16 20:13                             ` Nikhil Benesch
2020-12-17  4:59                               ` Nikhil Benesch
2020-12-17 12:28                                 ` Rainer Orth
2020-12-17 16:31                                   ` Nikhil Benesch [this message]
2020-12-17 18:05                                     ` Ian Lance Taylor
2020-12-17 18:21                                       ` Nikhil Benesch
2020-12-21  4:16                                         ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27545742-2549-e0eb-63ce-42f019f4e7ec@gmail.com \
    --to=nikhil.benesch@gmail.com \
    --cc=gcc-patches@gnu.org \
    --cc=gofrontend-dev@googlegroups.com \
    --cc=iant@golang.org \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).