[Bug fortran/56008] [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56008

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2013-01-16
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org
     Ever Confirmed|0                           |1
            Summary|[F03] lhs-allocation        |[F03] wrong code with
                   |invoking the                |lhs-realloc on assignment
                   |array-constructor on DDTs   |with derived types having
                   |causes memory error         |allocatable components

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-01-16 22:50:40 UTC ---
Seems to be similar to PR 47517.


(In reply to comment #0)
> (Btw. what is the appropriate Fortran expression/terminology for DDT
> member-variables)

"components". (Besides data and procedure-pointer components, a derived type
can also contain type-bound procedures.)


(In reply to comment #2)
> Created attachment 29185 [details]
> valgrind -v --track-origins=yes ./a.out

Two side remarks:

a) GCC 4.8 ships with -fsanitize=address,thread - and "address" ("ASAN")
roughly matches valgrind. Cf. http://gcc.gnu.org/gcc-4.8/changes.html - Though,
for that example, it doesn't seem to work. On the other hand, for stack-memory
issues, valgrind doesn't work and while ASAN might.

b) To track what goes wrong, one can also look at a C-like dump of the internal
representation using -fdump-tree-original (-fdump-tree-all, ...)


For:
   conc = [ xx, yy ]
one gets the following -ftree-dump-original:

                conc.data = (void * restrict) __builtin_malloc (96);
...
                    if ((void *) (*(struct test_typ[2] * restrict)
atmp.6.data)[S.9].a.data != 0B)


Either we have to use calloc instead of malloc - or we have to modify the
intrinsic assignment to assume unallocated memory in this case. In terms of
performance, the latter would be better. Using "calloc" is the quicker fix.



Side note 2: If one uses the GLIBC (i.e. Linux) and has MALLOC_PERTURB_ set,*
one gets a segfault when one tries to run the code. [MALLOC_PERTURB_ sets the
value returned by "malloc" to non-NUL.] (* e.g. "export
MALLOC_PERTURB_=$(($RANDOM % 255 + 1))")