I'm working towards reducing this, but it's coming slowly :( The code attached leads to an ICE with: $ gfortran -c -O0 qs_mo_types.f90 gfortran: Internal error: Illegal instruction (program f951) The backtrace for the ICE is: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xbf7fffec 0x000688fd in gfc_free_equiv_lists (l=Cannot access memory at address 0xbf7ffff0 0x44567150) at /tmp/gfortran-20070611/ibin/../gcc/gcc/fortran/symbol.c:2621 2621 gfc_free_equiv_lists (l->next); (gdb) where #0 0x000688fd in gfc_free_equiv_lists (l=0x44567150) at /tmp/gfortran-20070611/ibin/../gcc/gcc/fortran/symbol.c:2621 I wonder if this was introduced by Paul's patch recent for multiple equivalences. Paul, do you have any idea (I know you have no access to darwin, but I can debug for you if you so wish). I could not reproduce this on i386-linux (even with valgrind).
Created attachment 13692 [details] Testcase and module files that generate the ICE
I can't reduce that any more, it depends on the module files being huge: if you trim them down to a lower number of symbols, they ICE disapears. And I can't reproduced it either on x86_64-linux.
(In reply to comment #2) > I can't reduce that any more, it depends on the module files being huge: if you > trim them down to a lower number of symbols, they ICE disapears. And I can't > reproduced it either on x86_64-linux. FX, Are there any equivalences in the the sources for the modules and do they have any data statements? Even if they do, I am not sure that I believe that the PR29786 patch is involved - how would the module files be compiled if this were the case? Paul
(In reply to comment #3) > Are there any equivalences in the the sources for the modules and do they have > any data statements? Even if they do, I am not sure that I believe that the > PR29786 patch is involved - how would the module files be compiled if this were > the case? I think you're right, I'm sorry for the red herring. I just am completely puzzled by this ICE. (Just to make sure, I rebuilt a compiler from scratch and it still fails.)
With valgrind, I am detecting a huge memory leak on x86-64. I am reruning and will post a log shortly. It takes a while to run the example in comment #1,
Created attachment 13716 [details] Valgrind leak check on example code This shows the huge memory leak. 39 Mbytes! on x86-64 (Intel)
is this still failing ? Yesterday, I ran a valgrinded compilation of CP2K, and it showed no errors (didn't check memory leaks). This has been on x86_64 though.
(In reply to comment #7) > is this still failing ? Yesterday, I ran a valgrinded compilation of CP2K, and > it showed no errors (didn't check memory leaks). This has been on x86_64 > though. Apparently, the ICE on darwin is related to a leak check, that can also be seen on x86_64 (using valgrind --tool=leakcheck, IIRC). I won't have time to check if it's still there before the beginning of August.
cp2k compiles fine on i686-darwin as of today, and I can't see the memory leak any more, so I'm closing this.