C++ 如何在编译时修复GCC编译错误>；2GB的代码？

我有大量的函数，总共有大约2.8GB的目标代码（不幸的是，没有办法，科学计算…）

当我尝试链接它们时，我得到（预期的）

重新定位被截断以适应：R_X86_64_32S

错误，我希望通过指定编译器标志

-mcmodel=medium

来避免这些错误。我控制的所有链接库都使用

-fpic

标志编译

尽管如此，错误仍然存在，我假设我链接到的一些库不是用PIC编译的

以下是错误：

/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x12): relocation truncated to fit: R_X86_64_32S against symbol `__libc_csu_fini'     defined in .text section in /usr/lib64/libc_nonshared.a(elf-init.oS)
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x19): relocation truncated to fit: R_X86_64_32S against symbol `__libc_csu_init'    defined in .text section in /usr/lib64/libc_nonshared.a(elf-init.oS)
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o: In function    `call_gmon_start':
(.text+0x7): relocation truncated to fit: R_X86_64_GOTPCREL against undefined symbol      `__gmon_start__'
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbegin.o: In function `__do_global_dtors_aux':
crtstuff.c:(.text+0xb): relocation truncated to fit: R_X86_64_PC32 against `.bss' 
crtstuff.c:(.text+0x13): relocation truncated to fit: R_X86_64_32 against symbol `__DTOR_END__' defined in .dtors section in /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o
crtstuff.c:(.text+0x19): relocation truncated to fit: R_X86_64_32S against `.dtors'
crtstuff.c:(.text+0x28): relocation truncated to fit: R_X86_64_PC32 against `.bss'
crtstuff.c:(.text+0x38): relocation truncated to fit: R_X86_64_PC32 against `.bss'
crtstuff.c:(.text+0x3f): relocation truncated to fit: R_X86_64_32S against `.dtors'
crtstuff.c:(.text+0x46): relocation truncated to fit: R_X86_64_PC32 against `.bss'
crtstuff.c:(.text+0x51): additional relocation overflows omitted from the output
collect2: ld returned 1 exit status
make: *** [testsme] Error 1

和我链接的系统库：

-lgfortran -lm -lrt -lpthread

在哪里可以找到问题的线索

编辑：

首先，感谢您的讨论

为了澄清一点，我有数百个函数（每个函数在单独的对象文件中大小约为1MB），如下所示：

double func1(std::tr1::unordered_map<int, double> & csc, 
             std::vector<EvaluationNode::Ptr> & ti, 
             ProcessVars & s)
{
    double sum, prefactor, expr;

    prefactor = +s.ds8*s.ds10*ti[0]->value();
    expr =       ( - 5/243.*(s.x14*s.x15*csc[49300] + 9/10.*s.x14*s.x15*csc[49301] +
           1/10.*s.x14*s.x15*csc[49302] - 3/5.*s.x14*s.x15*csc[49303] -
           27/10.*s.x14*s.x15*csc[49304] + 12/5.*s.x14*s.x15*csc[49305] -
           3/10.*s.x14*s.x15*csc[49306] - 4/5.*s.x14*s.x15*csc[49307] +
           21/10.*s.x14*s.x15*csc[49308] + 1/10.*s.x14*s.x15*csc[49309] -
           s.x14*s.x15*csc[51370] - 9/10.*s.x14*s.x15*csc[51371] -
           1/10.*s.x14*s.x15*csc[51372] + 3/5.*s.x14*s.x15*csc[51373] +
           27/10.*s.x14*s.x15*csc[51374] - 12/5.*s.x14*s.x15*csc[51375] +
           3/10.*s.x14*s.x15*csc[51376] + 4/5.*s.x14*s.x15*csc[51377] -
           21/10.*s.x14*s.x15*csc[51378] - 1/10.*s.x14*s.x15*csc[51379] -
           2*s.x14*s.x15*csc[55100] - 9/5.*s.x14*s.x15*csc[55101] -
           1/5.*s.x14*s.x15*csc[55102] + 6/5.*s.x14*s.x15*csc[55103] +
           27/5.*s.x14*s.x15*csc[55104] - 24/5.*s.x14*s.x15*csc[55105] +
           3/5.*s.x14*s.x15*csc[55106] + 8/5.*s.x14*s.x15*csc[55107] -
           21/5.*s.x14*s.x15*csc[55108] - 1/5.*s.x14*s.x15*csc[55109] -
           2*s.x14*s.x15*csc[55170] - 9/5.*s.x14*s.x15*csc[55171] -
           1/5.*s.x14*s.x15*csc[55172] + 6/5.*s.x14*s.x15*csc[55173] +
           27/5.*s.x14*s.x15*csc[55174] - 24/5.*s.x14*s.x15*csc[55175] +
           // ...
           ;

        sum += prefactor*expr;
    // ...
    return sum;
}

就这样。最后一步就是调用所有的

func[i]

并将结果相加

关于这是一个相当特殊和不寻常的情况：是的，它是。这就是人们在尝试为粒子物理进行高精度计算时必须处理的问题

EDIT2:

我还应该补充一点，x12、x13等并不是真正的常量。将它们设置为特定值，运行所有这些函数并返回结果，然后选择一组新的x12、x13等来生成下一个值。这需要做105到106次

EDIT3:

谢谢你的建议和到目前为止的讨论。。。我会尝试在代码生成时以某种方式滚动循环，老实说，我不知道如何准确地进行循环，但这是最好的选择

顺便说一句，我没有试图隐藏在“这是科学计算——没有优化的方法”后面 只是这段代码的基础是我无法真正访问的“黑盒子”中的一些东西，而且，通过简单的示例，整个代码运行得非常好，我主要对现实世界应用程序中发生的事情感到不知所措

EDIT4:

因此，通过简化计算机代数系统中的表达式（），我成功地将

csc

定义的代码大小减少了约四分之一。我现在也看到了一些方法，通过在生成代码之前应用一些其他技巧（这将使这一部分降低到大约100MB），可以将其减少一个数量级左右，我希望这个想法能够奏效

现在与您的答案相关：

我正在尝试在

func

s中再次回滚循环，在那里CAS不会有多大帮助，但我已经有了一些想法。例如，通过变量对表达式进行排序，如

x12、x13、…

，使用Python解析

csc

s，并生成相互关联的表。然后我至少可以将这些部分生成为循环。由于这似乎是迄今为止最好的解决方案，我认为这是最好的答案

然而，我也要赞扬VJo。GCC4.6确实工作得更好，生成的代码更小，速度更快。使用大型模型可以按原样运行代码。所以从技术上来说，这是正确的答案，但是改变整个概念是一个更好的方法

谢谢大家的建议和帮助。如果有人感兴趣，我会在准备好后尽快发布最终结果

备注：

只是对其他一些答案的一些评论：我试图运行的代码并不是源于简单函数/算法的扩展和愚蠢的不必要的展开。实际发生的是，我们从非常复杂的数学对象开始，将它们转化为数值计算形式，就会生成这些表达式。问题实际上在于潜在的物理理论。众所周知，中间表达式的复杂性是按阶乘扩展的，但当将所有这些东西结合到物理上可测量的东西上时——一个可观察的东西——它只会归结为构成表达式基础的少数非常小的函数。（在这方面，一般的和唯一可用的称为“微扰理论”的理论肯定有“错误”）我们试图把这个安萨兹带到另一个层次，这在分析上不再可行，所需函数的基础未知。所以我们试着像这样对它进行暴力。这不是最好的方法，但希望最终能帮助我们理解手头的物理

上次编辑：

多亏了你的建议，我使用Mathematica和对

func

s的代码生成器进行了修改，大大减少了代码的大小，这在某种程度上与最上面的答案一致：）

我用Mathematica简化了

csc

函数，将其降低到92MB。这是不可约的部分。第一次尝试花了很长时间，但经过一些优化后，现在只需在一个CPU上运行大约10分钟

对

func

s的影响是巨大的：它们的整个代码大小降低到大约9MB，因此代码现在总计在100MB范围内。现在打开优化是有意义的，而且执行速度相当快

再次感谢大家的建议，我学到了很多。

定义了一个“大型模型”，专门用于避免此类大小限制，其中包括GOT和PLT的64位重新定位类型。（见第4.4.2节中的表格和第3.5.5节中的指令序列，其中说明了如何使用它们。）

由于您的函数占用2.8GB的空间，因此您运气不佳，因为gcc不支持大型模型。您可以做的是，以这样一种方式重新组织代码，允许您将其拆分为共享库，并动态链接这些库

如果这是不可能的，就像有人建议的那样，不要把你的数据放到

void cscs132(std::tr1::unordered_map<int,double> & csc, ProcessVars & s)
{
    {
    double csc19295 =       + s.ds0*s.ds1*s.ds2 * ( -
           32*s.x12pow2*s.x15*s.x34*s.mbpow2*s.mWpowinv2 -
           32*s.x12pow2*s.x15*s.x35*s.mbpow2*s.mWpowinv2 -
           32*s.x12pow2*s.x15*s.x35*s.x45*s.mWpowinv2 -
           32*s.x12pow2*s.x25*s.x34*s.mbpow2*s.mWpowinv2 -
           32*s.x12pow2*s.x25*s.x35*s.mbpow2*s.mWpowinv2 -
           32*s.x12pow2*s.x25*s.x35*s.x45*s.mWpowinv2 +
           32*s.x12pow2*s.x34*s.mbpow4*s.mWpowinv2 +
           32*s.x12pow2*s.x34*s.x35*s.mbpow2*s.mWpowinv2 +
           32*s.x12pow2*s.x34*s.x45*s.mbpow2*s.mWpowinv2 +
           32*s.x12pow2*s.x35*s.mbpow4*s.mWpowinv2 +
           32*s.x12pow2*s.x35pow2*s.mbpow2*s.mWpowinv2 +
           32*s.x12pow2*s.x35pow2*s.x45*s.mWpowinv2 +
           64*s.x12pow2*s.x35*s.x45*s.mbpow2*s.mWpowinv2 +
           32*s.x12pow2*s.x35*s.x45pow2*s.mWpowinv2 -
           64*s.x12*s.p1p3*s.x15*s.mbpow4*s.mWpowinv2 +
           64*s.x12*s.p1p3*s.x15pow2*s.mbpow2*s.mWpowinv2 +
           96*s.x12*s.p1p3*s.x15*s.x25*s.mbpow2*s.mWpowinv2 -
           64*s.x12*s.p1p3*s.x15*s.x35*s.mbpow2*s.mWpowinv2 -
           64*s.x12*s.p1p3*s.x15*s.x45*s.mbpow2*s.mWpowinv2 -
           32*s.x12*s.p1p3*s.x25*s.mbpow4*s.mWpowinv2 +
           32*s.x12*s.p1p3*s.x25pow2*s.mbpow2*s.mWpowinv2 -
           32*s.x12*s.p1p3*s.x25*s.x35*s.mbpow2*s.mWpowinv2 -
           32*s.x12*s.p1p3*s.x25*s.x45*s.mbpow2*s.mWpowinv2 -
           32*s.x12*s.p1p3*s.x45*s.mbpow2 +
           64*s.x12*s.x14*s.x15pow2*s.x35*s.mWpowinv2 +
           96*s.x12*s.x14*s.x15*s.x25*s.x35*s.mWpowinv2 +
           32*s.x12*s.x14*s.x15*s.x34*s.mbpow2*s.mWpowinv2 -
           32*s.x12*s.x14*s.x15*s.x35*s.mbpow2*s.mWpowinv2 -
           64*s.x12*s.x14*s.x15*s.x35pow2*s.mWpowinv2 -
           32*s.x12*s.x14*s.x15*s.x35*s.x45*s.mWpowinv2 +
           32*s.x12*s.x14*s.x25pow2*s.x35*s.mWpowinv2 +
           32*s.x12*s.x14*s.x25*s.x34*s.mbpow2*s.mWpowinv2 -
           32*s.x12*s.x14*s.x25*s.x35pow2*s.mWpowinv2 -
           // ...
    
       csc.insert(cscMap::value_type(192953, csc19295));
    }

    {
       double csc19296 =      // ... ;

       csc.insert(cscMap::value_type(192956, csc19296));
    }

    // ...
}

prefactor = +s.ds8*s.ds10*ti[0]->value();
expr = ( - 5/243.*(s.x14*s.x15*csc[49300] + 9/10.*s.x14*s.x15*csc[49301] +
       1/10.*s.x14*s.x15*csc[49302] - 3/5.*s.x14*s.x15*csc[49303] -...

double csc19295 =       + s.ds0*s.ds1*s.ds2 * ( -
       32*s.x12pow2*s.x15*s.x34*s.mbpow2*s.mWpowinv2 -
       32*s.x12pow2*s.x15*s.x35*s.mbpow2*s.mWpowinv2 -
       32*s.x12pow2*s.x15*s.x35*s.x45*s.mWpowinv2 -...