From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F0DDF38555AB; Fri, 12 May 2023 15:55:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F0DDF38555AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683906914; bh=K2zO2m2gQdZH7T8DtjNOwSUIk9LmOs7f0kRfCUkP600=; h=From:To:Subject:Date:In-Reply-To:References:From; b=odWMBK9/lErQtV/0Kt8B8gBx6k7c24bMA/m5O0oILHvh/vaNKtxxqnOr+r9xVxHUk Kl1UFHQ2G0QwCE+uoPjYieoTtPLRs+XBNzGISCdBsx4plZQmz4k8mOc/AJtup+sRpl 3ZMZy4onFpx5/PeDAj9J9c5zEME/+2oDdviQEpng= From: "amonakov at gcc dot gnu.org" 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:55:14 +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: amonakov at gcc dot gnu.org 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 #22 from Alexander Monakov --- (In reply to Jan Hubicka from comment #19) > 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... Wait. There's absolutely no connection between lifetime-dse and the ranger issue uncovered by -flto-partition=3D1to1. Selective -fno-lifetime-dse sure= ly works, as you said it's fully handled by the front-end. I was just saying t= hat applying -fno-lifetime-dse to User.cpp is insufficient because problematic codegen happens in other translation units (where objects of class User are constructed). Fully agreed that fixing the ranger bug would be nice regardless. > 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. Makes sense I guess.=