From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A2F73382E804; Mon, 1 Mar 2021 02:52:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A2F73382E804 From: "hp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test Date: Mon, 01 Mar 2021 02:52:08 +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: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hp at gcc dot gnu.org X-Bugzilla-Status: NEW 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: cc cf_gcchost cf_gcctarget cf_gccbuild 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 02:52:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99307 Hans-Peter Nilsson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pault at gcc dot gnu.org Host|hppa-unknown-linux-gnu | Target|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, | |cris-elf, | |sparcv9-sun-solaris2.11, | |x86_64-pc-solaris2.11 Build|hppa-unknown-linux-gnu | --- Comment #3 from Hans-Peter Nilsson --- I was about to enter a bug-report with the following contents, most of whic= h is not redundant: Since the commit 29a5298955f7 / r11-7349 "Fortran: Fix for class defined operators [PR99124].", class_assign_4 has failed at execution for cris-elf, at all optimization levels. I see the same goes for some solaris targets: sparcv9-sun-solaris2.11 https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/661993.html and x86_64-pc-solaris2.11 https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/661992.html but apparently none of the other posted test-results I checked. Looking into a trace for cris-elf, I see a call to "free" hits an invalid memory access (the equivalent of SEGV) and the execution terminates. This hints at invalid memory management related to the allocations done in that test, like too short allocation or write-after-free. For a native x86_64-linux build, valgrind does complain when applied to the test, but as my valgrind isn't dwarf-5-aware, I can't see much besides and can't be too sure besides the relation to memory allocation. Here are the first four valgrind indications for the test as compiled at -O0 (and adding -gdwarf-2 to the build flags): =3D=3D32498=3D=3D Invalid write of size 8 =3D=3D32498=3D=3D at 0x4C32643: memmove (vg_replace_strmem.c:1252) =3D=3D32498=3D=3D by 0x4076F8: test_t1_ (class_assign_4.f90:62) =3D=3D32498=3D=3D by 0x409E69: MAIN__ (class_assign_4.f90:183) =3D=3D32498=3D=3D by 0x409EA5: main (class_assign_4.f90:185) =3D=3D32498=3D=3D Address 0x5de4bd8 is 8 bytes inside a block of size 12 a= lloc'd =3D=3D32498=3D=3D at 0x4C2DDCF: realloc (vg_replace_malloc.c:785) =3D=3D32498=3D=3D by 0x405C65: test_t1_ (class_assign_4.f90:50) =3D=3D32498=3D=3D by 0x409E69: MAIN__ (class_assign_4.f90:183) =3D=3D32498=3D=3D by 0x409EA5: main (class_assign_4.f90:185) =3D=3D32498=3D=3D =3D=3D32498=3D=3D Invalid read of size 4 =3D=3D32498=3D=3D at 0x40507B: check_t1.2 (class_assign_4.f90:104) =3D=3D32498=3D=3D by 0x407878: test_t1_ (class_assign_4.f90:63) =3D=3D32498=3D=3D by 0x409E69: MAIN__ (class_assign_4.f90:183) =3D=3D32498=3D=3D by 0x409EA5: main (class_assign_4.f90:185) =3D=3D32498=3D=3D Address 0x5de4be0 is 4 bytes after a block of size 12 al= loc'd =3D=3D32498=3D=3D at 0x4C2DDCF: realloc (vg_replace_malloc.c:785) =3D=3D32498=3D=3D by 0x405C65: test_t1_ (class_assign_4.f90:50) =3D=3D32498=3D=3D by 0x409E69: MAIN__ (class_assign_4.f90:183) =3D=3D32498=3D=3D by 0x409EA5: main (class_assign_4.f90:185) =3D=3D32498=3D=3D =3D=3D32498=3D=3D Invalid write of size 8 =3D=3D32498=3D=3D at 0x407BE8: test_t1_ (class_assign_4.f90:66) =3D=3D32498=3D=3D by 0x409E69: MAIN__ (class_assign_4.f90:183) =3D=3D32498=3D=3D by 0x409EA5: main (class_assign_4.f90:185) =3D=3D32498=3D=3D Address 0x5de4bd8 is 8 bytes inside a block of size 12 a= lloc'd =3D=3D32498=3D=3D at 0x4C2DDCF: realloc (vg_replace_malloc.c:785) =3D=3D32498=3D=3D by 0x405C65: test_t1_ (class_assign_4.f90:50) =3D=3D32498=3D=3D by 0x409E69: MAIN__ (class_assign_4.f90:183) =3D=3D32498=3D=3D by 0x409EA5: main (class_assign_4.f90:185) =3D=3D32498=3D=3D =3D=3D32498=3D=3D Invalid read of size 8 =3D=3D32498=3D=3D at 0x400886: __m_MOD___copy_m_T2 (class_assign_4.f90:3= 8) =3D=3D32498=3D=3D by 0x407EBF: test_t1_ (class_assign_4.f90:67) =3D=3D32498=3D=3D by 0x409E69: MAIN__ (class_assign_4.f90:183) =3D=3D32498=3D=3D by 0x409EA5: main (class_assign_4.f90:185) =3D=3D32498=3D=3D Address 0x5de4be0 is 4 bytes after a block of size 12 al= loc'd =3D=3D32498=3D=3D at 0x4C2DDCF: realloc (vg_replace_malloc.c:785) =3D=3D32498=3D=3D by 0x405C65: test_t1_ (class_assign_4.f90:50) =3D=3D32498=3D=3D by 0x409E69: MAIN__ (class_assign_4.f90:183) =3D=3D32498=3D=3D by 0x409EA5: main (class_assign_4.f90:185) I'm guessing there's a flaw with the test, but I don't know fortran so unfortunately I can't debug it.=