1830216 Members
1591 Online
109999 Solutions
New Discussion

cc compiler limitations

 
Jake Posey_1
Occasional Advisor

cc compiler limitations

I have a user that is having a problem with the cc compiler. The user is compiling a program with 529,000 lines of code and it fails with the following:

hpadm1[57]% gnumake
rm -f -rf .m_elec/m_elec_sl/src
gnumake -C . slcode
gnumake[1]: Entering directory `/project/sw/fsl/scm8/elec/m_elec_8/R3_0'
gnumake[1]: Leaving directory `/project/sw/fsl/scm8/elec/m_elec_8/R3_0'
gnumake -C ./m_elec_sl/simulink/hs_elec_sys_iac_model_ert_rtw -f hs_elec_sys_iac_model.mk ADD_CFLAGS=
gnumake[1]: Entering directory `/project/sw/fsl/scm8/elec/m_elec_8/R3_0/m_elec_sl/simulink/hs_elec_sys_iac_model_ert_rtw'
cc -c -DHPUX +DA1.1 +DS1.1 -D_HPUX_SOURCE -Aa -DMODEL=hs_elec_sys_iac_model -DNUMST=2 -DNCSTATES=0 -DUNIX -DMAT_FILE=0 -DINTEGER_CODE=0 -DONESTEPFCN=1 -DTERMFCN=1 -DHAVESTDIO -DMULTI_INSTANCE_CODE=0 -DADD_MDL_NAME_TO_GLOBALS=1 -DMT=0 -I. -I.. -I/site/sw/matlab701/rtw/c/ert -I/site/sw/matlab701/extern/include -I/site/sw/matlab701/simulink/include -I/site/sw/matlab701/rtw/c/src -I/site/sw/matlab701/rtw/c/libsrc -I/site/sw/matlab701/rtw/c/src/ext_mode/common -I.. -ohs_elec_sys_iac_model_data.o hs_elec_sys_iac_model_data.c
cc: procedure @(): error 5217: Not enough user virtual memory (5217)
cc: error 1405: "/opt/ansic/lbin/ccom" terminated abnormally with signal 11.
gnumake[1]: *** [hs_elec_sys_iac_model_data.o] Error 9
gnumake[1]: Leaving directory `/project/sw/fsl/scm8/elec/m_elec_8/R3_0/m_elec_sl/simulink/hs_elec_sys_iac_model_ert_rtw'
gnumake: *** [src] Error 2
hpadm1[58]%

Is there a limit for the cc compiler to compile this many lines of code? If so is there a switch or patch to get beyond the limitation?

Thanks for your help,
Jake
8 REPLIES 8
A. Clay Stephenson
Acclaimed Contributor

Re: cc compiler limitations

I can't imagine a single source file with that many lines of code and I would have a very long talk with the developer but you can try increasing maxdsiz.
If it ain't broke, I can fix that.
James R. Ferguson
Acclaimed Contributor

Re: cc compiler limitations

Hi Jake:

"Not enough user virtual memory" and SEGV (signal-11) may suggest that you may have insufficient swap space.

As compilation proceeds, check with:

# swapinfo -tam

Regards!

...JRF...
A. Clay Stephenson
Acclaimed Contributor

Re: cc compiler limitations

In this particular case, this could be a stack overflow so I would look at maxssiz as well.
If it ain't broke, I can fix that.
Jake Posey_1
Occasional Advisor

Re: cc compiler limitations

I guess I did not relay this correctly but the user's exact words were this is a data table with 529,000 lines and I assume this was code.

I was thinking along the same lines so I increased both maxdsiz from (2040109465 to 2063835136), maxdsiz_64bit (2040109465 to 4396972769279) and maxssiz (268435455 to 401604608), maxssiz_64bit (268435455 to 1073741824) which is the max and it still failed. I then added 6GB of swap but I couldn't until I increased maxswapchunks and then I was able to add the additional swap but it still failed. I didn't add any more swap, I guess it's possible I need even more swap than that?

Any suggestions?

Thanks for the help, much appreciated.
Jake
TwoProc
Honored Contributor

Re: cc compiler limitations

I think I'd ask the programmer to starting using malloc and parse the file into memory at run time instead of defining such a large (presumed) array, instead of fixing the kernel for a single developer.

You could even parse it with a separate program and store it as a memory structure and save that memory structure as a binary file. This would allow the binary file to be read in a single data pull, and not have to spend the time to have the file "parsed" each time the program is started.

Of course you/he/she may certainly have valid reasons for wanting to do it as a defined array and compiled into the data segment - but I'd at least discuss the options first.
We are the people our parents warned us about --Jimmy Buffett
A. Clay Stephenson
Acclaimed Contributor

Re: cc compiler limitations

By definition, anything that the compiler handles is source code so this 529,000 lines whether or not it is data initialization is source code. I can't even imagine the difficulty is fixing one or two values in something like that. This almost has to be generated code. I would seriously look at loading this data at run-time. In the case of very large static data sets, one technique I have used which greatly reduces the initization time required to load large chunks of data at run-time is to initialize the data block and store it in shared memory. This is a one-time run and then subsequent invokations of the same program examine shared memory to see if the data is already loaded. If so, they simply attach. The idea is that the first load might take many minutes but subsequent startups of other processes bypass this step.

Even so, I haven't found any hard limits that releate to the number of lines of code. There are hard limits for things like the maximum identifier length, maximum number of dimensions of an array. I also notice that this is 32-bit code so you may have exceeded a barrier that would not exist in 64-bit compiles. When a process receives a SIGSEGV (11), the error message may not really describe the event.

You should really examine the compiler options (e.g +Onolimit) to see if anything looks as though it might help but since you didn't bother to mention compiler version, it's difficult to look for specific options or patches.
If it ain't broke, I can fix that.
Jake Posey_1
Occasional Advisor

Re: cc compiler limitations

Sorry, here is the compiler version: hpadm1.root /root$ swlist -l product | grep -i ansi
C-ANSI-C B.11.11.06 HP C/ANSI C Compiler
PHSS_28706 1.0 ANSI C compiler B.11.11.06 cumulative patch
hpadm1.root /root$
hpadm1.root /root$ what /usr/bin/cc
/usr/bin/cc:
$Revision: 92453-07 linker linker crt0.o B.11.30 020412 $
LINT B.11.11.28706.GP CXREF B.11.11.28706.GP
HP92453-01 B.11.11.28706.GP HP C Compiler
$ Sep 8 2000 23:13:51 $
hpadm1.root /root$
Dennis Handly
Acclaimed Contributor

Re: cc compiler limitations

You don't appear to be using any optimization options so that using +Onolimit won't help. In fact is, it will hurt if you did optimize.

Setting maxssiz larger will only reduce maxdsiz, so immediately put maxssiz back!

Also increasing maxdsiz above 1 Gb will not help ccom/ctcom/ecom.

For your "data table" how many entries do you have and what are their sizes?