From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D6FCB3856DFB; Fri, 12 May 2023 15:29:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D6FCB3856DFB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683905383; bh=YaXNucvyWkEWgOTelbHhGCbCtYo3wAbkaFTTfj7skVk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C5pKnY3m4LKMgeXDHrbUnyl8gZ0XEQyMzcmT2RVz2rFJtBsD189AQXO7/z5DncjMq S8sm+Ed1IaKRi1m3Kz+zuWjRwyACXWnC1j4NjSla2a+2IoYME5FDmnQajiyWtqPcAr 0HQ9WaQ+2r7l/XQ9WuGDF0Ab0tlUloEse7XMx8Gk= From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang Date: Fri, 12 May 2023 15:29:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: needs-reduction, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106943 --- Comment #19 from Jan Hubicka --- > > Is there any need to over-engineer this like that? I would hope enabling > > -fno-lifetime-dse globally would not be controversial for LLVM It would be really nice to have the ranger bug fixed. Since lifetime DSE is all handled in C++ FE there is no good reason why it should not work to LTO togehter objects compiled with the flag and without... llvm is really nice benchmark for LTO and PGO, so it would be nice if it was not fragile and built with -O3 -flto. In my testing GCC produced binary with LTO+PGO is a lot smaller. It seems to also generate code faster but parsing is bit slower, which I think may be related to -fstrict-aliasing.=