https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307
Hans-Peter Nilsson <hp at gcc dot gnu.org> 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 <hp at gcc dot gnu.org> ---
I was about to enter a bug-report with the following contents, most of which 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):
==32498== Invalid write of size 8
==32498== at 0x4C32643: memmove (vg_replace_strmem.c:1252)
==32498== by 0x4076F8: test_t1_ (class_assign_4.f90:62)
==32498== by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498== by 0x409EA5: main (class_assign_4.f90:185)
==32498== Address 0x5de4bd8 is 8 bytes inside a block of size 12 alloc'd
==32498== at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==32498== by 0x405C65: test_t1_ (class_assign_4.f90:50)
==32498== by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498== by 0x409EA5: main (class_assign_4.f90:185)
==32498==
==32498== Invalid read of size 4
==32498== at 0x40507B: check_t1.2 (class_assign_4.f90:104)
==32498== by 0x407878: test_t1_ (class_assign_4.f90:63)
==32498== by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498== by 0x409EA5: main (class_assign_4.f90:185)
==32498== Address 0x5de4be0 is 4 bytes after a block of size 12 alloc'd
==32498== at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==32498== by 0x405C65: test_t1_ (class_assign_4.f90:50)
==32498== by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498== by 0x409EA5: main (class_assign_4.f90:185)
==32498==
==32498== Invalid write of size 8
==32498== at 0x407BE8: test_t1_ (class_assign_4.f90:66)
==32498== by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498== by 0x409EA5: main (class_assign_4.f90:185)
==32498== Address 0x5de4bd8 is 8 bytes inside a block of size 12 alloc'd
==32498== at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==32498== by 0x405C65: test_t1_ (class_assign_4.f90:50)
==32498== by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498== by 0x409EA5: main (class_assign_4.f90:185)
==32498==
==32498== Invalid read of size 8
==32498== at 0x400886: __m_MOD___copy_m_T2 (class_assign_4.f90:38)
==32498== by 0x407EBF: test_t1_ (class_assign_4.f90:67)
==32498== by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498== by 0x409EA5: main (class_assign_4.f90:185)
==32498== Address 0x5de4be0 is 4 bytes after a block of size 12 alloc'd
==32498== at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==32498== by 0x405C65: test_t1_ (class_assign_4.f90:50)
==32498== by 0x409E69: MAIN__ (class_assign_4.f90:183)
==32498== 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.
