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 C5D8E3858C50 for ; Thu, 1 Dec 2022 16:57:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C5D8E3858C50 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=1669913865; 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=EA4UsnWQezMPiwqiY1L9Q3v9uk+zdSXYGx6g5HW/f5I=; b=VeCioF/Ii+kVv6f1RDCpoUVtQRFxa8F1XCxzuTszmyQMLOhvTXgm34sMNsq0zBvdi/TteT NfsDHhHua49+tXMH+i7SaSMmP4NGYAP+uI0L7end9ouoLHYo4PJ7FLmW+jNPYuXZNLgNaD SjZQ5ZOWkNAMZzMQ8xEiFLQVbVXEuv8= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-414-Ts5tiwIUO4uw-ykRU5798A-1; Thu, 01 Dec 2022 11:57:44 -0500 X-MC-Unique: Ts5tiwIUO4uw-ykRU5798A-1 Received: by mail-qt1-f197.google.com with SMTP id f4-20020a05622a114400b003a57f828277so6066337qty.22 for ; Thu, 01 Dec 2022 08:57:44 -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=6ZM/8Zbi2lZhIRal0ovEacM3H95+x9FcqB11tn2Ubm4=; b=zwtSgixy+mcZ8nmvOYuwA/c2yECWRWZdzPXcYEQ/qDZ+52VyOAA+eKw2JD7Xrrs0vN CSqEasbzzi3t4EyBmVH/AMBSn1ES76dmaUzyV4p31uQXMkx7bHI8RyX7AHd2ctCCtINl gkMQDzcBOt0MOX1KwdwUCNaikMbOoaTWtOXNpfF1+vPUtaX86K0s2RWArCzJhZGC12bX tBW1T01I4b1NVV2NnoLxl9NEl5pyyQeuu5KKHBxY0sD/98xpul71CejYDiMe7UofiKqx WpBT0PPcE7MMeeCqMbZ0xCKqkNIXfzNvgTg4wT6zzYo1jw2SuObZ4MyyOgOBKYYj/eZJ k5Bg== X-Gm-Message-State: ANoB5plIp7FDfhGa+nsO4mAx7LafnSeYr+a0Fqdi0lKN6r1TV9PyNakw Z1IYg60M6m3NQqqeWiINBly9t56089gExl6X6EaJrXjy63+nqjpFHTWSJcfDm0fEWPt/9OfHmXu qKDnaOjg= X-Received: by 2002:ad4:5a12:0:b0:4c6:cfb3:461f with SMTP id ei18-20020ad45a12000000b004c6cfb3461fmr37961598qvb.18.1669913863919; Thu, 01 Dec 2022 08:57:43 -0800 (PST) X-Google-Smtp-Source: AA0mqf7Ka7wYaQGFviBrAU2k5lv9lq8s0oZByjuOZ56PSHGG1W7VvqXoLRfnfC1V2+4TldDarrK4EQ== X-Received: by 2002:ad4:5a12:0:b0:4c6:cfb3:461f with SMTP id ei18-20020ad45a12000000b004c6cfb3461fmr37961581qvb.18.1669913863665; Thu, 01 Dec 2022 08:57:43 -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 s18-20020a05620a29d200b006f9ddaaf01esm3893676qkp.102.2022.12.01.08.57.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Dec 2022 08:57:43 -0800 (PST) Message-ID: <138f2f9ca9eeee76f3fc7532e32a535ac8884fe2.camel@redhat.com> Subject: Re: [PATCH] libgccjit: Fix float vector comparison From: David Malcolm To: Antoni Boucher , gcc-patches@gcc.gnu.org, jit@gcc.gnu.org Cc: Guillaume Gomez Date: Thu, 01 Dec 2022 11:57:42 -0500 In-Reply-To: <5827fc95314506387b9b0e5c5da865eb28cf28e8.camel@zoho.com> References: <30eb27a08792e1e2b92e663753f22e31f65c7791.camel@redhat.com> <15fbee19972751bfa05c24ec95bc441c621c98ad.camel@zoho.com> <74150b934836583a532d310c68d29384daf2fbd0.camel@redhat.com> <5827fc95314506387b9b0e5c5da865eb28cf28e8.camel@zoho.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=-5.7 required=5.0 tests=BAYES_00,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 Thu, 2022-12-01 at 10:33 -0500, Antoni Boucher wrote: > On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote: > > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote: > > > Thanks, David. > > > Since we're not in phase 1 anymore, do we need an approval before > > > I > > > merge like last year or can I merge immediately? > >=20 > > I think it counts as a bug fix and thus you can go ahead and merge > > (assuming you've done the usual testing). > >=20 > > > I also have many other patches (all in jit) that I need to > > > prepare > > > and > > > post to this mailing list. > > > What do you think? > >=20 > > Given that you're one of the main users of libgccjit I think > > there's > > a > > case for stretching the deadlines a bit here. > >=20 > > Do you have a repo I can look at? >=20 > Yes! The commits are in my fork: > https://github.com/antoyo/gcc >=20 > The only big one is the one adding support for target-dependent > builtins: > https://github.com/antoyo/gcc/commit/6d4313d4c02dd878f43917c978f299f51193= 30f0 >=20 > Regarding this one, there's the issue that since we record the > builtins > on the first context run, we only have access to the builtins from > the > second run. > Do you have any idea how to fix this? > Or do you consider this is acceptable? This is implemented behind the new gcc_jit_context_get_target_builtin_function entrypoint, right? If so, perhaps that recording::context::get_target_builtin_function could detect if it's the first time it's been called on this context, and if so make a playback::context to do the detection? That way it would be transparent to the user, and work first time. I see you have patches to add function and variable attributes; I wonder if this would be cleaner internally if there was a recording::attribute class, rather than the std::pair currently in use (some attributes have int arguments rather than string, others have multiple args). I also wondered if a "gcc_jit_attribute" type could be exposed to the user, e.g.: attr1 =3D gcc_jit_context_new_attribute (ctxt, "noreturn"); attr2 =3D gcc_jit_context_new_attribute_with_string (ctxt, "alias", "__foo"); gcc_jit_function_add_attribute (ctxt, attr1); gcc_jit_function_add_attribute (ctxt, attr2); or somesuch? But I think the API you currently have is OK. >=20 > I also have a WIP branch which adds support for try/catch: > https://github.com/antoyo/gcc/commit/6219339fcacb079431596a0bc6cf8d430a1b= d5a1 > I'm not sure if this one is going to be ready soon or not. I see that the new entrypoints have e.g.: /* Add a try/catch statement. This is equivalent to this C++ code: try { try_block } catch { catch_block } */ void gcc_jit_block_add_try_catch (gcc_jit_block *block, =09=09=09 gcc_jit_location *loc, =09=09=09 gcc_jit_block *try_block, =09=09=09 gcc_jit_block *catch_block); but I'm not sure how this is meant to interact with the CFG-like model used by the rest of the gcc_jit_block_* API. What happens at the end of the blocks? Does the generated code use the C++ ABI for exception- handling? Dave >=20 > Thanks. >=20 > >=20 > > Dave > >=20 > >=20 > > >=20 > > > On Thu, 2022-12-01 at 09:28 -0500, David Malcolm wrote: > > > > On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher via Jit > > > > wrote: > > > > > Hi. > > > > > This fixes bug 107770. > > > > > Thanks for the review. > > > >=20 > > > > Thanks, the patch looks good to me. > > > >=20 > > > > Dave > > > >=20 > > >=20 > >=20 >=20