From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 95DAA384AB4D; Thu, 9 May 2024 11:27:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 95DAA384AB4D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1715254060; bh=ZZACvMDjbhFit6WrMrD5FwJJk9i2E+M+2eUEMJUux5U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iTMqin5QSBaPNwXFkfDWEvSgKkTrnk3z5OIE6Ja4GKrRla5GB6ZkFSnvQSzWzGDQ0 YdSu9T0iDOwzAIEwdyIjryfc3Apl79eW5Z91wB17ykYb+YAoNqKXHMyyDInC4tJovr 7rAITVEoWY/kFouDWna1mHcg/ghykLAXCD7n5BRM= From: "sjames at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds Date: Thu, 09 May 2024 11:27:37 +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: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sjames at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jeevitha 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=3D112868 --- Comment #16 from Sam James --- (In reply to Peter Bergner from comment #14) > (In reply to Niels M=C3=B6ller from comment #13) > > I'm not that familiar with gcc development procedures. Do I understand = you > > correctly, that a fix for this bug will not be included in gcc-14 (acco= rding > > to https://gcc.gnu.org/develop.html#timeline, gcc-14 stage1 ended sever= al > > months ago), it will have to wait for gcc-15? >=20 > Correct, I meant waiting for GCC 15 stage1. I want it to burn-in on trunk > for a long while, because it had the potential to disrupt distro package > builds. It seems clean so far with the practice Gentoo builds, but I'll > feel more comfortable when other distros start using it too.=20 FWIW, we're keeping it going forward (so it'll be in e.g. our GCC 14 patchs= et when we unleash that on the masses). Just keep in mind that very few distributions build with > release checking. We only do default-checking for the branch when it's in development still a= nd also optionally via USE=3Ddebug. So, while testing by others is still valua= ble, I don't expect you'll get that much - at least without people specifically knowing to turn on checking and ensure stuff doesn't break. (Of course, making sure release checking works fine now too is important, b= ut you get my point.)=