|Summary:||Intel-darwin specific ICE on CP2K code|
|Product:||gcc||Reporter:||Francois-Xavier Coudert <fxcoudert>|
|Component:||fortran||Assignee:||Not yet assigned to anyone <unassigned>|
|Severity:||normal||CC:||christian.joensson, gcc-bugs, Joost.VandeVondele, paul.richard.thomas|
|Build:||i386-apple-darwin8.8.1||Known to work:|
|Known to fail:||Last reconfirmed:|
|Bug Depends on:|
Testcase and module files that generate the ICE
Valgrind leak check on example code
Description Francois-Xavier Coudert 2007-06-12 17:23:03 UTC
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).
Comment 1 Francois-Xavier Coudert 2007-06-12 18:10:38 UTC
Created attachment 13692 [details] Testcase and module files that generate the ICE
Comment 2 Francois-Xavier Coudert 2007-06-12 22:03:26 UTC
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.
Comment 3 Paul Thomas 2007-06-13 07:27:06 UTC
(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
Comment 4 Francois-Xavier Coudert 2007-06-13 08:02:48 UTC
(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.)
Comment 5 Jerry DeLisle 2007-06-17 03:03:37 UTC
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,
Comment 6 Jerry DeLisle 2007-06-17 03:14:54 UTC
Created attachment 13716 [details] Valgrind leak check on example code This shows the huge memory leak. 39 Mbytes! on x86-64 (Intel)
Comment 7 Joost VandeVondele 2007-07-13 07:17:05 UTC
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.
Comment 8 Francois-Xavier Coudert 2007-07-15 00:31:07 UTC
(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.
Comment 9 Francois-Xavier Coudert 2007-08-15 10:41:13 UTC
cp2k compiles fine on i686-darwin as of today, and I can't see the memory leak any more, so I'm closing this.