Hi Andreas,
Thomas Koenig <tkoe...@netcologne.de> writes:
PR fortran/54833
* trans.c (gfc_call_free): Do not wrap the
call to __builtin_free in check for NULL.
(gfc_deallocate_with_status): For automatic deallocation without
status for non-coarrays, don't wrap call to __builtin_free in
check for NULL.
spawn /home/andreas/src/gcc/m68k/gcc/testsuite/gfortran/../../gfortran
-B/home/andreas/src/gcc/m68k/gcc/testsuite/gfortran/../../
-B/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/
/home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90
-fno-diagnostics-show-caret -Os -pedantic-errors
-B/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs
-L/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs
-L/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs -lm -o
./alloc_comp_assign_1.exe
/home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90: In
function 'main':
/home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90:57:0:
internal compiler error: in cselib_record_set, at cselib.c:2379
0x1029ac87 cselib_record_set
../../gcc/gcc/cselib.c:2379
Strange, this looks more like a bug that is exposed through the patch.
I also don't see how such a change to the Fortran front end can
result in something invalid in postreload.
Does not happen on the architectures that I used, and I do not
have access to that architecture.
Does a (rougly) equivalent C case compile?
Thomas
