gcc compiling .c with .s file - .bss confusion (bug?) - c

Question

Using gcc 4.6.3 under Ubuntu 12.04 on an IA32 architecture, I ran into an issue relating to compiling C files with assembly files using storage on the .bss segment with both .comm and .lcomm directives.
Between a .comm and a .lcomm buffer, the assembly file foo.s uses close to the maximum space gas lets me allocate in this segment (foo calculates prime factorization of long longs). With an assembly file bar.s handling i/o and such, everything compiles and links fine (and fast), and works well.
When I then use a C file bar.c to handle i/o, gcc does not terminate - or at least not in less than 5 minutes. The .bss request is close to my small notebook memory, but as the .bss segment does not get compile-time initialized, and as it works with bar.s, I don't see why this happens.
When I reduce the .bss size requested in foo.s, gcc compiles and links fine, and everything executes as it should. Also, as expected, the file size of the executable created in each case using
gcc bar.c foo.s -Wall
does not depend on the size in .bss requested (I compiled varying sizes which were all much smaller than the original, failing size). The executable is very small (maybe 10k) in all cases - in fact, of identical size - except, obviously, the original case which does not successfully compile and gets hung up.
Is this a gcc bug? Is there a command line option to use to prevent this from happening? Or what is going on?
Edit: per a comment, here is the part with the .bss segment allocation:
# Sieve of Eratosthenes
# Create list of prime numbers smaller than n
#
# Note: - no input error (range) check
# - n <= 500,000,000 (could be changed) - in assembly
# compiling it with gcc: trouble. make n <= 50,000,000
# Returns: pointer to array of ints of prime numbers
# (0 sentinel at end)
#
# Registers: %esi: sentinel value (n+1)
# %edx: n
# %ecx: counting variable (2 - n)
# %ebx: pointer into array of primes
# (position next to be added)
# %eax: inner pointer to A. tmp array
.section .bss
# .lcomm tmp_Arr, 2000000008 # 500,000,000 plus sentinel & padding
# .comm prime_Arr, 500000008 # asymptotically, primes aren't dense
.lcomm tmp_Arr, 200000008 # 50,000,000 plus sentinel & padding
.comm prime_Arr, 50000008 # asymptotically, primes aren't dense
.section .text
.globl sieve
.type sieve, #function
sieve:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %edx
pushl %esi
pushl %ebx
# create Eratosthenes tmp array
movl $0, %ecx
loop_sieve_Tmp_:
movl %ecx, tmp_Arr(, %ecx, 4)
addl $1, %ecx
cmp %ecx, %edx
jge loop_sieve_Tmp_
# initialize registers used in algorithm
movl $2, %ecx # outer loop counting var
movl %ecx, %eax # inner loop counting var
xor %ebx, %ebx # pointer to prime array
movl %edx, %esi
incl %esi # sentinel (or placeholder for 'not prime')
loop_sieve_Outer_:
movl %ecx, prime_Arr(, %ebx, 4) # record prime
incl %ebx
loop_sieve_Inner_:
addl %ecx, %eax
movl %esi, tmp_Arr(, %eax, 4)
cmp %eax, %edx
jge loop_sieve_Inner_
find_Next_: # find minimum in Erist. tmp array
addl $1, %ecx
cmp %ecx, %edx
jl lbl_sieve_done_
cmp tmp_Arr(, %ecx, 4), %esi
je find_Next_
movl %ecx, %eax
jmp loop_sieve_Outer_
lbl_sieve_done_:
movl $0, prime_Arr(, %ebx, 4) # sentinel
movl $prime_Arr, %eax
popl %ebx
popl %esi
movl %ebp, %esp
popl %ebp
ret
# end sieve

Answer 1

I've replicated your problem with gcc 4.7.2 on Debian. It doesn't hang for me, but it does take a substantial length of time (10 seconds).
It appears that the linker actually allocates and zeros "comm" memory during it's processing. If the machine is sufficiently memory limited (as it seems yours is) this will cause the linker to thrash the swap even though the final executable will be tiny. For me the memory allocation was around 2.3Gb.
I tried a couple of variations (.space, .zero, .org) and they all seem to give the same effect.
With an up to date version on the compiler (4.9) this no longer happens.