[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
burnus at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Fri Oct 22 11:33:02 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
--- Comment #22 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to sandra from comment #21)
> Tobias, did your big patch fully fix this issue so that we can close it?
I checked the examples – and did run into the following ICE. I think we should
at some point compile all gfortran testcases with -fcheck= and/or
-fsanitize=undefined(,address) and with and without optimization to see whether
it triggers some ICE.
Additionally, I think we might want to do something likewise for the dg-do run
tests.
* * *
The testcase attachment 47882 of comment 3 still/now fails with:
9 | val = 2
| 1
internal compiler error: in gfc_trans_assignment_1, at
fortran/trans-expr.c:11732
It works when using 'val(:) = 2' - and only fails when compiled with both:
-fcheck=all -fsanitize=undefined
The fail is for:
11731 /* We should only get array references here. */
11732 gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
11733 || TREE_CODE (tmp) == ARRAY_REF);
(gdb) p debug(tmp)
(integer(kind=4) *) ((void *) D.4249 + (sizetype) ((S.5 + D.4250) * val->span))
(gdb) p debug_tree(tmp)
<nop_expr 0x7ffff71a3580
type <pointer_type 0x7ffff6fc9a80
...
arg:0 <pointer_plus_expr 0x7ffff6d850a0
Thus, it seems as if we need to strip the nop_expr?
More information about the Gcc-bugs
mailing list