Gcc compile error with 2GB of data
stackoverflow.com
stackoverflow.com
the error is returned by the linker rather than compiler itself. It is not a bug, just size limitation of the default memory model. Linux x86_64 provides `large model' -- as pointed out by VJo, but it is not supported by GCC before 4.6, http://stackoverflow.com/questions/6296837/gcc-compile-error...
> Btw, I didn't try to hide behind "this is scientific computing -- no way to optimize". It's just that the basis for this code is something that comes out of a "black box" where I have no real access to
Black box != science.
The ability to make predictions.
That's not science by any useful definition of the term.
Its called the human body and the black box is known as Medical Science..:)
http://www.ornl.gov/sci/techresources/Human_Genome/home.shtm...
Unfortunately, "no way to optimize" is basically a statement that the questioner is not interested in an algorithmic way to make the problem go away.
If the data is part of the problem, I wonder if he can write a new linker script to rearrange the sections in the file so all code is below the signed 32-bit (~2GB) boundary. Though that raises the question... will it be able to address the data? Does initialized data access use 32- or 64-bit offsets in the small/medium models?
At any rate, it seems gcc 4.6 supports the x86_64 "large model", which should solve the problem without code/data changes.
It has very good double precision floating point, and it looks like SSE/SIMD were not used directly from the code.
LuaJIT should garbage collect unused code, if not it always regenerates it. It should be able to compile and execute tons of code as he has (and it looks like all his stuff is generated, but for C++).