From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 122D33858C52; Tue, 20 Dec 2022 09:22:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 122D33858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1671528170; bh=nsV+jlwOxV1CLlKQNSxi7DT745l1JeNBytLogll5by8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WOZ04zBYCu8GEBhyQQ52XlT6cKW8Ep8WJcw/BAU49n6+FQHVHRZQYZs9JkC4LamSV lN4nj5AepVvt1qSdxz+JS5QTqkbXv0XlgpprzzN3eMW+yTOlqSBxU/5md4Yghc82zW zELPFpKRgsvCTgw3qfuP9Vk3B9w21I8IidjICcyQ= From: "ktkachov at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't) Date: Tue, 20 Dec 2022 09:22:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-invalid-code, needs-bisection X-Bugzilla-Severity: normal X-Bugzilla-Who: ktkachov at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 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: 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=3D107209 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) > Looking at other backends, rs6000 uses in *gimple_fold_builtin gsi_replace > (..., true); > all the time, ix86 gsi_replace (..., false); all the time, alpha with tru= e, > aarch64 with true. But perhaps what is more important if the builtins > folded are declared nothrow or not, if they are nothrow, then they should= n't > have any EH edges at the start already and so it shouldn't matter what is > used. The vmulx_f64 intrinsic is not marked "nothrow" by the logic: 1284 static tree 1285 aarch64_get_attributes (unsigned int f, machine_mode mode) 1286 { 1287 tree attrs =3D NULL_TREE; 1288 1289 if (!aarch64_modifies_global_state_p (f, mode)) 1290 { 1291 if (aarch64_reads_global_state_p (f, mode)) 1292 attrs =3D aarch64_add_attribute ("pure", attrs); 1293 else 1294 attrs =3D aarch64_add_attribute ("const", attrs); 1295 } 1296 1297 if (!flag_non_call_exceptions || !aarch64_could_trap_p (f, mode)) 1298 attrs =3D aarch64_add_attribute ("nothrow", attrs); 1299 1300 return aarch64_add_attribute ("leaf", attrs); 1301 } aarch64_could_trap_p returns true for it as it can raise an FP exception. Should that affect the nothrow attribute though? Shouldn't that be for C++ exceptions only?=