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))")

Reply via email to