From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CCE1738708DA; Tue, 25 Jun 2024 21:47:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CCE1738708DA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1719352078; bh=wuMlTVbkBRh8VUjXvsQmsQmm3//Mb3D0bfnl7o0T+yo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XKaLSThETopI9at3D3nc/GNohIDpsZLa/hhqKZfx1vA33KpRa2bZrrNCdVTtLPAR9 M1G2WU6AM3Iryh8cXwcB/5Az4sUmAoDna2/RsMVkNFuQqTdqC4K+3GiMwmtmgnEnsH /QY4EzkVdvLHFvnyYpUMmi8mDGOfZjEpgocUyVQY= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/115587] [14/15 Regression] Possible uninitialized variable (decl) in c_parser_omp_loop_nest since r14-3489-g143151ac2013c2 Date: Tue, 25 Jun 2024 21:47:58 +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: 15.0 X-Bugzilla-Keywords: internal-improvement, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: sandra at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.2 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=3D115587 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:b383719aebe45bbe8cc3944e515ed7caa30e8744 commit r14-10346-gb383719aebe45bbe8cc3944e515ed7caa30e8744 Author: Sandra Loosemore Date: Tue Jun 25 13:54:43 2024 +0000 Fix PR c/115587, uninitialized variable in c_parser_omp_loop_nest This function had a reference to an uninitialized variable on the error path. The problem was diagnosed by clang but not gcc. It seems the cleanest solution is to initialize all the loop-clause variables at the point of declaration rather than at different places in the code. The C++ front end didn't have this problem, but I've made similar changes there to keep the code in sync. gcc/c/ChangeLog: PR c/115587 * c-parser.cc (c_parser_omp_loop_nest): Move initializations to point of declaration. gcc/cp/ChangeLog: PR c/115587 * parser.cc (cp_parser_omp_loop_nest): Move initializations to point of declaration. (cherry picked from commit 21f1073d388af8af207183b0ed592e1cc47d20ab)=