From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 5C1523874178; Fri, 16 Dec 2022 23:55:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C1523874178
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1671234924;
	bh=hWmeKTsTnWq2wW+YyTzqytL7x1UnfaQ3Ppx4p7UHrq4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=YRLVJ0K0jTFOwiW1tBYYKyRni8YLXv/Z7oUNUCAKppaCRUbt4bAi6nQD/Q5Y2ejx5
	 2sFszJjXTjSNoel8gUlN9oWVLfdHPGmHR6xBzOM8LfRb9IF5bI/QtnYLsFTcmL2uG2
	 p+3WHL1/bauVOx5u1vYshU9Hoiq7tnXEV/n0MTbo=
From: "tneumann at users dot sourceforge.net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcc/107675] [13 Regression] GCC-13 is significantly slower
 to startup on C++ statically linked programs
Date: Fri, 16 Dec 2022 23:55:21 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcc
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tneumann at users dot sourceforge.net
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107675-4-vAgPJxjroo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107675-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107675-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107675

--- Comment #16 from Thomas Neumann <tneumann at users dot sourceforge.net>=
 ---
I have committed a fix:

commit 6e56633daae79f514b0e71f4d9849bcd8d9ce71f
Author: Thomas Neumann
Date:   Fri Dec 9 18:23:44 2022 +0100

    initialize fde objects lazily

    When registering an unwind frame with __register_frame_info_bases
    we currently initialize that fde object eagerly. This has the
    advantage that it is immutable afterwards and we can safely
    access it from multiple threads, but it has the disadvantage
    that we pay the initialization cost even if the application
    never throws an exception.

    This commit changes the logic to initialize the objects lazily.
    The objects themselves are inserted into the b-tree when
    registering the frame, but the sorted fde_vector is
    not constructed yet. Only on the first time that an
    exception tries to pass through the registered code the
    object is initialized. We notice that with a double checking,
    first doing a relaxed load of the sorted bit and then re-checking
    under a mutex when the object was not initialized yet.

    Note that the check must implicitly be safe concering a concurrent
    frame deregistration, as trying the deregister a frame that is
    on the unwinding path of a concurrent exception is inherently racy.

    libgcc/ChangeLog:
            * unwind-dw2-fde.c: Initialize fde object lazily when
            the first exception tries to pass through.=