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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 5E6C2398E47B for ; Fri, 19 Feb 2021 21:13:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5E6C2398E47B Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-402-M5N3O7sJOdq2C7QcPGKT6Q-1; Fri, 19 Feb 2021 16:13:53 -0500 X-MC-Unique: M5N3O7sJOdq2C7QcPGKT6Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 329EE107ACE3; Fri, 19 Feb 2021 21:13:52 +0000 (UTC) Received: from t14s.localdomain (ovpn-112-59.phx2.redhat.com [10.3.112.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5015E5D9C2; Fri, 19 Feb 2021 21:13:51 +0000 (UTC) Message-ID: <71b1c0e3405fbb537ee925dcab68cafebd32fc9d.camel@redhat.com> Subject: Re: [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126] From: David Malcolm To: Andrea Corallo , David Malcolm via Gcc-patches Cc: jit@gcc.gnu.org, nd@arm.com Date: Fri, 19 Feb 2021 16:13:50 -0500 In-Reply-To: References: <20210219023144.1800203-1-dmalcolm@redhat.com> User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 21:13:58 -0000 On Fri, 2021-02-19 at 11:16 +0100, Andrea Corallo wrote: > David Malcolm via Gcc-patches writes: > > > I tried several approaches to fixing this; this seemed the > > least invasive. > > Hi Dave, > > thanks for fixing this. > > I do have a trivial question: are we guaranteed that the middle-end > will > not try to add any build-in other than a trap? No; the middle-end can add various other builtins. The C/C++ FE have c_define_builtins, which calls def_builtin_1 on everything with DEF_BUILTIN, then calls: targetm.init_builtins (); build_common_builtin_nodes (); jit_langhook_init calls build_common_builtin_nodes. The jit builtins_manager creates recording::functions (and their supporting types) for any builtins that are explicitly used, and these recording::functions get turned into trees during playback. I looked at the doing the equivalent of DEF_BUILTIN for any builtins that haven't been created yet, but when to do it? (a) in the builtin manager... but not all builtin-types are supported yet (e.g. BT_FLOAT16), so it would be a big patch to do it that way (b) in jit_langhook_init... but then if the user creates a builtin that wasn't referenced before in a 2nd in-memory compile, I think the types can get out-of-sync. So I went with the patch I did as it seems to be the least invasive way of fixing the specific problem. Dave