As mentioned in the CP2K PR 29975 comment 112 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975#c112 on the source made available as http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz gfortran -O1 -fbounds-check all.f90 fails with f951: out of memory allocating 2408 bytes after a total of 1146208256 bytes this is happening with current trunk (but also earlier versions). The opteron this is running on has 16Gb of RAM, and can compile the same code at all other optimisation levels (not involving -fbounds-check) I tried. Watching top, the above processes dies at about 3Gb of virtual memory (all other options typically peak at around 2.5Gb), so this is a bit strange. Unfortunately, this out of memory message comes after about 35min of compilation time, but let me know if this is some simple additional info I can provide
Can you run the compile inside gdb and check periodically where it wastes its time?
(In reply to comment #1) > Can you run the compile inside gdb and check periodically where it wastes its > time? > I have a few gdb backtraces, but it looks like it is just writing the .s file. At the point where f951 dies the .s file is about 53Mb in size. The last few gdb traces I collected are: #0 shorten_branches (first=0x2ad9a29700) at /scratch/vondele/gcc_trunk/gcc/gcc/final.c:1081 #1 0x000000000056fca1 in rest_of_handle_shorten_branches () at /scratch/vondele/gcc_trunk/gcc/gcc/final.c:4046 #2 0x000000000061b396 in execute_one_pass (pass=0xcfa400) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #3 0x000000000061b55c in execute_pass_list (pass=0xcfa400) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1178 #4 0x000000000061b56e in execute_pass_list (pass=0xcfaae0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #5 0x000000000061b56e in execute_pass_list (pass=0xcfaa80) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #6 0x00000000006e6358 in tree_rest_of_compilation (fndecl=0x2a96cf2300) at /scratch/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:406 #7 0x000000000082ba30 in cgraph_expand_function (node=0x2a96cf2500) at /scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1073 #8 0x000000000082de12 in cgraph_optimize () at /scratch/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1142 #0 0x000000000061d09d in pointer_set_insert (pset=0x26b622f0, p=0x2ae2aebea0) at /scratch/vondele/gcc_trunk/gcc/gcc/pointer-set.c:68 #1 0x0000000000698881 in verify_stmts () at /scratch/vondele/gcc_trunk/gcc/gcc/tree-cfg.c:3573 #2 0x000000000079c317 in verify_ssa (check_modified_stmt=1 '\001') at /scratch/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:614 #3 0x000000000061b1a5 in execute_function_todo (data=Variable "data" is not available. ) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:972 #4 0x000000000061aeef in execute_todo (flags=Variable "flags" is not available. ) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:996 #5 0x000000000061b3ee in execute_one_pass (pass=0xcfcd40) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1147 #6 0x000000000061b55c in execute_pass_list (pass=0xcfcd40) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1178 #7 0x000000000061b56e in execute_pass_list (pass=0xcfc1a0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1179 #0 0x0000000000669b9e in refers_to_regno_p (regno=17, endregno=18, x=0x2aba886640, loc=0x0) at /scratch/vondele/gcc_trunk/gcc/gcc/rtlanal.c:1285 #1 0x000000000099c4e9 in record_value_for_reg (reg=0x2aba8864e0, insn=0x2ad6f2db40, value=0x2aba886640) at /scratch/vondele/gcc_trunk/gcc/gcc/combine.c:11194 #2 0x00000000009ae29a in rest_of_handle_combine () at /scratch/vondele/gcc_trunk/gcc/gcc/combine.c:1069 #3 0x000000000061b396 in execute_one_pass (pass=0xcfed60) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #0 0x00000000004ff2f0 in df_lr_bb_local_compute (bb_index=64) at /scratch/vondele/gcc_trunk/gcc/gcc/df-problems.c:1379 #1 0x0000000000500bbf in df_lr_verify_transfer_functions () at /scratch/vondele/gcc_trunk/gcc/gcc/df-problems.c:1905 #2 0x00000000004fbcde in df_verify () at /scratch/vondele/gcc_trunk/gcc/gcc/df-core.c:1514 #3 0x00000000004fc809 in df_analyze () at /scratch/vondele/gcc_trunk/gcc/gcc/df-core.c:1106 #4 0x00000000009d5757 in move_loop_invariants () at /scratch/vondele/gcc_trunk/gcc/gcc/loop-invariant.c:641 #5 0x00000000009d3d57 in rtl_move_loop_invariants () at /scratch/vondele/gcc_trunk/gcc/gcc/loop-init.c:238 #6 0x000000000061b396 in execute_one_pass (pass=0xcff4e0) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125 #0 0x000000000063ed17 in init_subregs_of_mode () at /scratch/vondele/gcc_trunk/gcc/gcc/regclass.c:2410 #1 0x000000000061b396 in execute_one_pass (pass=0xcfb340) at /scratch/vondele/gcc_trunk/gcc/gcc/passes.c:1125
I ran the compilation now on a machine with 64Gb of memory, and it still failed. According to 'top' the memory used by f951 was about 4Gb. The error message: f951: out of memory allocating 4064 bytes after a total of 1148219392 bytes also seems to suggest that much less than 64Gb (in fact, just 1Gb) of memory was allocated. So, it looks like something inside gcc is hard-coded to just 1Gb of memory, instead of the available memory.
Subject: Re: hard-coded memory limit ? f951: out of memory with '-O1 -fbounds-check' On 26 Jun 2007 14:59:27 -0000, jv244 at cam dot ac dot uk <gcc-bugzilla@gcc.gnu.org> wrote: > f951: out of memory allocating 4064 bytes after a total of 1148219392 bytes Ignore the second number, it just is total count of memory allocated via xmalloc and not the amount of memory used at the time of the crash. Why we print it out I have no idea, it is not very useful any more really. -- Pinski
could be similar to PR32514
(In reply to comment #3) > So, it looks like something inside gcc is hard-coded to just 1Gb > of memory, instead of the available memory. That's probably a stupid thing to ask, but you don't have any shell limits (as reported per "ulimit -a") that would match this number, do you?
(In reply to comment #6) > (In reply to comment #3) > > So, it looks like something inside gcc is hard-coded to just 1Gb > > of memory, instead of the available memory. > > That's probably a stupid thing to ask, but you don't have any shell limits (as > reported per "ulimit -a") that would match this number, do you? > I don't think so. We run large memory jobs on that machine (that's why we have it in the first place). I get the following output: > ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 529920 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 529920 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
closing as magically fixed