From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DCBA8384AB65; Thu, 16 May 2024 07:20:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCBA8384AB65 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1715844044; bh=PP38VzXtozrO8OFMq89JCkMdMHAJ2857rVVu7P0j1OQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Zzne2hcXXvI7HT7Mk9R59TTSzjo4Xsz545FmVLdyCBghsgIQFiQsJqjlXwZZAq4iv nnaTFTVJPebOZYF+8VwxPXUMKpx/SlJyP9tye2O0i960nK1mJaTEQ63UvKnW7vHeV5 DA/xFcM8aiFKRRbRDKnIae3zmliGElW4okXGBsvs= From: "natalie.perlin at noaa dot gov" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314 Date: Thu, 16 May 2024 07:20:44 +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.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: natalie.perlin at noaa dot gov 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=3D115107 --- Comment #6 from Natalie Perlin --- (In reply to anlauf from comment #3) > The traceback is essentially identical to that in pr114467. >=20 > Can you please try the 14-release like the other reporter, or the upcoming > 13.3 release next week? Thank you for the comment. Yes, this indeed looks similar to pr114467.=20 I did try to use gnu/14.1.0 + openmpi/4.1.6, but was not able to build a software stack needed for building the model that produced the original err= or.=20 The issue with the gnu/14.1.0 compiler was that it produced an error where = the gnu/13.2.0 had only a warning. The error with the gnu/14.1.0 compiler was as shown below, and is related to -Wimplicit-function-declaration.=20 Could it be that a certain compiler flag helps to avoid such an error?.. And yes, I'd gladly try the upcoming v13.3 release next week! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0_gnu14/spack= /lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I. -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o jas_getopt.o jas_getopt.c: In function 'jas_getopt': jas_getopt.c:129:49: error: implicit declaration of function 'jas_eprintf';= did you mean 'vsnprintf'? [-Wimplicit-function-declaration] 129 | jas_eprintf("unknown long option %s\n", s); | ^~~~~~~~~~~ | vsnprintf make[4]: *** [Makefile:349: jas_getopt.lo] Error 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=