From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9FF383858D33; Fri, 8 Mar 2024 20:01:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9FF383858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709928063; bh=OPTv2QxLvAp4Tt8ouV4dB21hqTewxrhzAUGogLwp3No=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EWEw45yC7m0nzQaCUxzINnWYQrFFGYAPIajerKuM1xwHl+at3InjLPJ3Qlv16oDM0 jig+7y2HtJV8+W8RsqpcIMjO3G0JKopB0DpnLu0ITRnp7yFUwUPKRnkBMU90BosbgP GEozdk1MNBL5vBhCDP7p+CTmm6avr0HnoXhaZDek= From: "kyle.shores44 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/110644] Error in gfc_format_decoder Date: Fri, 08 Mar 2024 20:01:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 13.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kyle.shores44 at gmail dot com 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=3D110644 --- Comment #20 from Kyle Shores --- (In reply to Steve Kargl from comment #19) > On Fri, Mar 08, 2024 at 05:42:05PM +0000, kyle.shores44 at gmail dot com > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110644 > >=20 > > --- Comment #17 from Kyle Shores --- > > I was able to get tuv-x to compile by putting use statements in problem= atic > > files at the top of the module. In one case, I had to match the use ord= ering to > > the order that the objects were used in the module (unsure if that matt= ered), > > and I also removed an object in a use only statement that wasn't used i= n that > > same file and then it compiled (these last two issues were for the same= file > > test/unit/radiator/from_host.F90) > >=20 > >=20 >=20 > It seems your code is hitting a NULL pointer dereference when > generating a warning. In resolve.cc(resolve_procedure_expression), > one finds >=20 > /* A non-RECURSIVE procedure that is used as procedure expression within > its > own body is in danger of being called recursively. */ > if (is_illegal_recursion (sym, gfc_current_ns)) > gfc_warning (0, "Non-RECURSIVE procedure %qs at %L is possibly callin= g" > " itself recursively. Declare it RECURSIVE or use" > " %<-frecursive%>", sym->name, &expr->where); >=20 > for whatever reason &expr->where is a NULL pointer. If I change > the above to remove &expr->where, then your code compiles with=20 > a bunch of warningsi, e.g., >=20 > [ 95%] Building Fortran object > test/oldtuv/CMakeFiles/oldphotolib.dir/util/la_srb.type.F90.o > /usr/home/sgk/tmp/tuv-x/test/oldtuv/util/la_srb.type.F90:873:28: >=20 > 873 | end module la_srb_type > | 1 > Warning: Non-RECURSIVE procedure 'get_config_array' at (1) is possibly > calling itself recursively. Declare it RECURSIVE or use '-frecursive' >=20=20 > Unfortunately, without a much smaller example code, I cannot go > any further in debugging your problem. Well that's odd, that function doesn't call itself recursively For example get_config_array: https://github.com/NCAR/tuv-x/blob/6930151e3cd89189df4ec046fdf19c02300d4380= /src/util/config.F90#L715-L754 Either way, this PR fixes the issue for gcc 13 be moving use statements aro= und https://github.com/NCAR/tuv-x/pull/53. The bug still exists in gcc 13, but = for anyone else who encounters this issue, they can try pulling use statements = up to the top of the module=