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 9B16C3858291 for ; Thu, 27 Jul 2023 13:10:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9B16C3858291 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=1690463408; 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: in-reply-to:in-reply-to:references:references; bh=wU/LgO+OuKHbJFbpat4I/o5CgKtNclTMQrcMmjA9FAE=; b=fDwYtaUA+pUvNQryQnOeNbAs/WTFkrllaLjxQiSBHuem2sA5HPYKKVgfSsoJnXOho4RRee EF9BspLbTY5K6hDCvPfi6LXWgZZoXIC4UmQAw/edCTyDKlzBDlLrOfAl9DhmgxPDeaGhAt 2doxyI6Fy4pk8T0/ij8kXs0PBt2R/cY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-656-YSUM1NK0MsSEQIq3ayASFw-1; Thu, 27 Jul 2023 09:10:06 -0400 X-MC-Unique: YSUM1NK0MsSEQIq3ayASFw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0B2E5857FFF; Thu, 27 Jul 2023 13:10:06 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.39.193.181]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 90B512166B25; Thu, 27 Jul 2023 13:10:05 +0000 (UTC) From: Florian Weimer To: Thomas Koenig via Gcc Cc: Thomas Koenig Subject: Re: Calling convention for Intel APX extension References: <4fef10d7-71ea-e31d-3dd5-97ba0994b61c@netcologne.de> Date: Thu, 27 Jul 2023 15:10:04 +0200 In-Reply-To: <4fef10d7-71ea-e31d-3dd5-97ba0994b61c@netcologne.de> (Thomas Koenig via Gcc's message of "Thu, 27 Jul 2023 10:38:25 +0200") Message-ID: <87cz0d33gz.fsf@oldenburg3.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.5 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_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: * Thomas Koenig via Gcc: > Intel recommends to have the new registers as caller-saved for > compatibility with current calling conventions. If I understand this > correctly, this is required for exception unwinding, but not if the > function called is __attribute__((nothrow)). Nothrow functions still can call longjmp, so that's probably not the right discriminator. For glibc on Linux, we have some extra space in jmpbuf in the signal mask (we have 1024 bits, but the kernel can use just 64, some of those have already been repurposed), but it's going to be tough for cancellation support because of a historic microoptimization there. Thanks, Florian