Bug 32310

Summary: Intel-darwin specific ICE on CP2K code
Product: gcc Reporter: Francois-Xavier Coudert <fxcoudert>
Component: fortranAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED WORKSFORME    
Severity: normal CC: christian.joensson, gcc-bugs, Joost.VandeVondele, paul.richard.thomas
Priority: P3 Keywords: ice-on-valid-code
Version: 4.3.0   
Target Milestone: ---   
Host: i386-apple-darwin8.8.1 Target: i386-apple-darwin8.8.1
Build: i386-apple-darwin8.8.1 Known to work:
Known to fail: Last reconfirmed:
Bug Depends on:    
Bug Blocks: 29975    
Attachments: 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.