From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout1.rbg.tum.de (mailout1.rbg.tum.de [IPv6:2a09:80c0::201]) by sourceware.org (Postfix) with ESMTPS id 968EB3858D28 for ; Mon, 19 Sep 2022 13:55:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 968EB3858D28 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 [131.159.254.14]) by mailout1.rbg.tum.de (Postfix) with ESMTPS id 186EA9B; Mon, 19 Sep 2022 15:55:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=in.tum.de; s=20220209; t=1663595748; bh=UIUUz/w2VhwKiE1/r9otVJOLDEx2719tFLw/ox2PZxU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=LfNJt4SmbLm4qBplW7EGiXS2yN3iGacNTwOLfvcXnqEG5jrvs++H15rm5Ki64nkGl 473gx7ciQTrhYbEKTsO9U/7dUu+O/w65efRHosQ/BRNYqdghFtbZzy34eSryu9alEz z+nExcrBqGUHjoRhBKu8v/nEIWQAGsbQTw1FZW/A6CJ5OuBsBtDzdQOyV8B0xSe8T+ sY+DPRmtLU4JfdJOIQor+jITooivNGFEvrmFWe/8s1RoG7I7pbgSiX9kIWSgJinbFm uQztT/P4XgAjDDphofcJ/4CFygc7uXdIuOmU/3vHIIoGigaUY6d+IrjaQN6BwRROO5 CxXfkjeUhPW+g== Received: by mailrelay1.rbg.tum.de (Postfix, from userid 112) id 15D261A8; Mon, 19 Sep 2022 15:55:48 +0200 (CEST) Received: from mailrelay1.rbg.tum.de (localhost [127.0.0.1]) by mailrelay1.rbg.tum.de (Postfix) with ESMTP id E87C91A1; Mon, 19 Sep 2022 15:55:47 +0200 (CEST) Received: from mail.in.tum.de (mailproxy.in.tum.de [IPv6:2a09:80c0::78]) by mailrelay1.rbg.tum.de (Postfix) with ESMTPS id E7060CD; Mon, 19 Sep 2022 15:55:47 +0200 (CEST) Received: by mail.in.tum.de (Postfix, from userid 112) id E38864A034B; Mon, 19 Sep 2022 15:55:47 +0200 (CEST) Received: (Authenticated sender: neumann) by mail.in.tum.de (Postfix) with ESMTPSA id A31414A010F; Mon, 19 Sep 2022 15:55:47 +0200 (CEST) (Extended-Queue-bit xtech_dd@fff.in.tum.de) Message-ID: <6c1149d1-3017-ca9b-08b6-b7100578b453@in.tum.de> Date: Mon, 19 Sep 2022 15:55:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v4] eliminate mutex in fast path of __register_frame Content-Language: en-US To: Stephan Bergmann , gcc-patches@gcc.gnu.org References: <2a4776b9-9271-bb3c-a626-d5ec22dae6f3@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=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,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: > I haven't debugged this in any way, nor checked whether it only impacts > exactly my below scenario, but noticed the following: > > At least when building LibreOffice with Clang (16 trunk) with ASan and > UBsan enabled against libstdc++ (with --gcc-toolchain and > LD_LIBRARY_PATH to pick up a libstdc++ trunk build including this change > at build and run-time), at least one of the LibreOffice tests executed > during the build started to fail with Apparently a registered frame is not found when deregistering, which triggers an assert. I will debug this. Could you send me a script or a description on how to reproduce the issue? Best Thomas