https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #10 from DIL <liakhdi at ornl dot gov> --- Sorry, just wanted to clarify few things. I am still struggling with this issue I reported. However I am not sure if you could every reproduce it (it seemed like you observed a different issue)? Namely, if by running the binary built from here "https://gitlab.com/DmitryLyakh/GFC.git"; you could see that the allocate() statement in gfc_base.F90:343 fails to allocate a dissociated pointer (dissociated in the previous line)? For convenience I removed few unneeded things from the code, so the code now directly proceeds to the problematic path and explicitly (manually) crashes (via divide by zero) to reveal the callstack when allocate() fails. I reproduced the problem on multiple Linux machines with GNU 5.3.0, 5.4.0, and 6.3.1. The problems shows up non-deterministically, so the binary needs to be executed 5-10 times. If I build the binary with -O3, the problem shows up much less often. Also, another big complication is that I could never reproduce the failing behavior inside gdb (it always works fine in gdb). Additionally, as I mentioned before, the binary seems to be VALGRIND clean. I am running out of ideas how to figure out what is going on wrong in that allocate() statement. We tried to look in the GFORTRAN source "gcc-5.4.0/gcc/fortran/trans-stmt.c:6132", but it seems like allocate() is actually parsed to something and not called as a runtime function, so there is no way for us to understand why allocate() sees an explicitly dissociated pointer as already allocated (and why this is happening only occasionally and not every time). Any ideas from you guys would be appreciated. Thanks! Dmitry
