[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