Question

编辑：对于那些寻找问题答案的人，如标准所述，标准会限制编译时嵌套循环的数量。在运行时，这是一个不同的问题，因为唯一的限制是程序段的大小。

解决了：我在构建过程中看得太早。 c文件进一步应用于它的预处理。关闭后续步骤。

我对使用perl从应用生成发音规则的语言生成的c代码有疑问。在本质上，输入是一个庞大的发音规则例外字典。代码充满了gotos，直到其中一个异常字典达到23K规则为止。

代码基本上是不可读的但是我已经设法在删除看似第6200个嵌套循环之后编译c代码：

for (dictionionary1=seed1;dicitonary1<limit1;dictionary1++)
{
    for (dictionionary2=seed2;dicitonary2<limit2;dictionary2++)
    {
           /* .... */
        for (dictionionary6199=seed6199;dicitonary6199<limit6199;dictionary6199++)
        {
               /* two hundred more removed adding one makes it not compile */

        }

    }
}

gcc和xlC都能够处理这些问题，但是aCC 3.73（在H11.23 PA RISC上）正在发挥作用。

Compiling /home/ojblass/exception_dictionary_a.c...
Loading the kernel...
Pid 18324 killed due to text modification or page I/O error
/bin/ksh: 28004 Bus error(coredump)
*** Error exit code 138

我找到了这个link并尝试了许多建议的修复但没有成功。

由于遗留原因，我必须编译32位（它使用32位库，我没有64位对应的）。

maxdsiz = 256 MB (x10000000) tried up to 4 GB
maxssiz = 16 MB (x1000000) tried up to 100MB
maxtsiz = 256 MB (x10000000) tried up to 1 GB

编译器设置的任何建议或aCC 3.73的文档的良好链接？我淹没在搜索结果中。

我编写了一个解决方法，将字典分成两部分，导致dictionary_an.c和dictionary_az.c。我不得不触摸一些核心逻辑，我感觉不舒服以便将其拉下来，我希望能够回到最初的配置。

Answer 1

哇 - 我知道这对你没有帮助，但是嵌套6199级深度远远超过C或C ++要求（C90为15，C99为127，C ++为256）。

我很好奇的是这个东西的运行情况 - 如果你的字典是任何大小的，循环迭代次数必须是天文数字。假设每个字典大小为10：（10 ^ 6199）是相当大的数字。即使每个字典只有2个项目，（2 ^ 6199）也令人印象深刻。

Answer 2

Pid 18324由于文本修改或页面I / O错误而被杀死

听起来像stackoverflow ^ Wmemory错误给我。这意味着它是编译器中的一个错误。我不会说HPUX所以我可能错了，但是打开惠普机票可能会产生更多信息。

是什么限制了c中嵌套循环的数量？

2 个答案: