From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.rbg.tum.de (mailout1.rbg.tum.de [131.159.0.201]) by sourceware.org (Postfix) with ESMTPS id A8B613858C66 for ; Mon, 15 May 2023 13:05:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A8B613858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=in.tum.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=in.tum.de Received: from mailrelay1.rbg.tum.de (mailrelay1.in.tum.de [IPv6:2a09:80c0:254::14]) by mailout1.rbg.tum.de (Postfix) with ESMTPS id 8AB4B71; Mon, 15 May 2023 15:05:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=in.tum.de; s=20220209; t=1684155953; bh=37OpEkxEsU4urWTaAm+57F8g2hZEsTCHK7/YghN+94k=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=U+j6xdjJOF+WVdPK64b0tBRvBanLNVkOOBO8euKiXwdgBTOjXBfCjNDKwqS3BJC2f bNrT57DCVJGmwdGSvolIMQV5GU4wyTKUrHcJdmFqD5uE400NvnTW87yXFhDiGMkYAg ssGyDaGITxtZvmmLvEWwRArR01ZDE3OaWhROxRREFT8iPibO+myxj1KriHYE/KTBxz YmPR+hnOqHGvZpi35P5s2gEsfYBom/u404e6TjhA5AlQVt7oE+Erhrq9NgAFh8R4xt Gwt6aZptzVazBiO0Ap/7CGWaxHTX0jCBRpgV/JRomnDDnK5z3ro/b8QdXM5Gw8oQxA Z7pQdRRAbELjg== Received: by mailrelay1.rbg.tum.de (Postfix, from userid 112) id 8519919E; Mon, 15 May 2023 15:05:53 +0200 (CEST) Received: from mailrelay1.rbg.tum.de (localhost [127.0.0.1]) by mailrelay1.rbg.tum.de (Postfix) with ESMTP id 31C61CD; Mon, 15 May 2023 15:05:53 +0200 (CEST) Received: from mail.in.tum.de (vmrbg426.in.tum.de [131.159.0.73]) by mailrelay1.rbg.tum.de (Postfix) with ESMTPS id 2C35C24; Mon, 15 May 2023 15:05:53 +0200 (CEST) Received: by mail.in.tum.de (Postfix, from userid 112) id 2548C4A03DA; Mon, 15 May 2023 15:05:53 +0200 (CEST) Received: (Authenticated sender: neumann) by mail.in.tum.de (Postfix) with ESMTPSA id 81F024A0247; Mon, 15 May 2023 15:05:52 +0200 (CEST) (Extended-Queue-bit xtech_js@fff.in.tum.de) Message-ID: <60bab096-fa10-345a-1b18-0f05585e0a14@in.tum.de> Date: Mon, 15 May 2023 15:05:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] Fix assertion for unwind-dw2-fde.c btree changes Content-Language: en-US To: Kyrylo Tkachov , Richard Biener Cc: =?UTF-8?Q?S=c3=b6ren_Tempel?= , "gcc-patches@gcc.gnu.org" , "alice@ayaya.dev" References: <2TMB4YQOP1E1R.2QLW7HCD1NVF3@8pit.net> <23a59ecf-9f5e-4d55-9f31-48242b775ec7@in.tum.de> From: Thomas Neumann In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,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: > Hello, this patch breaks the build on targets where range is not declared i.e. where the #ifdef ATOMIC_FDE_FAST_PATH path is not taken. argh, I did not realize I tested the patch only on atomic fast path platforms. The patch below fixes that by moving the check inside the #ifdef. I will check that everything works on atomic and non-atomic platforms and commit the trivial move then. Sorry for the breakage. Best Thomas From 550dc27f547a067e96137adeb85148d8a84c81a0 Mon Sep 17 00:00:00 2001 From: Thomas Neumann Date: Mon, 15 May 2023 14:59:22 +0200 Subject: [PATCH] fix assert in non-atomic path The non-atomic path does not have range information, we have to adjust the assert handle that case, too. libgcc/ChangeLog: * unwind-dw2-fde.c: Fix assert in non-atomic path. --- libgcc/unwind-dw2-fde.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libgcc/unwind-dw2-fde.c b/libgcc/unwind-dw2-fde.c index 8683a65aa02..df461a1527d 100644 --- a/libgcc/unwind-dw2-fde.c +++ b/libgcc/unwind-dw2-fde.c @@ -240,6 +240,7 @@ __deregister_frame_info_bases (const void *begin) // And remove ob = btree_remove (®istered_frames, range[0]); + bool empty_table = (range[1] - range[0]) == 0; #else init_object_mutex_once (); __gthread_mutex_lock (&object_mutex); @@ -276,11 +277,12 @@ __deregister_frame_info_bases (const void *begin) out: __gthread_mutex_unlock (&object_mutex); + bool empty_table = false; #endif // If we didn't find anything in the lookup data structures then they // were either already destroyed or we tried to remove an empty range. - gcc_assert (in_shutdown || ((range[1] - range[0]) == 0 || ob)); + gcc_assert (in_shutdown || (empty_table || ob)); return (void *) ob; } -- 2.39.2