大家一起来。
我尝试使用gcc9.3在aarch 64服务器上构建CPU 2017 intrate和fprate测试集。除510.parest_r外，所有基准构建均成功。然后我尝试使用gcc9.4构建，遇到相同的错误。我使用Example-gcc-linux-aarch64.cfg作为配置文件，只需编辑gcc路径。
以下是失败的信息：
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/synthetic_data.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/synthetic_data.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/multigrid/mg_base.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/multigrid/mg_base.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/measurements.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/measurements.cc
init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
during GIMPLE pass: forwprop
source/me-tomography/measurements.cc: In constructor 'METomography::Measurements::ReferencedMeasurements::RatioMinusRatio<dim, number>::RatioMinusRatio(const libparest::Slave::Stationary::ProblemDescription&, const dealii::Function<dim>&, const std::set<unsigned char>&) [with int dim = 3; number = double]':
source/me-tomography/measurements.cc:1739:7: internal compiler error: Aborted
1739 | RatioMinusRatio<dim,number>::
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
0xafbd97 crash_signal
../.././gcc/toplev.c:326
0xffff9e304d78 __GI_raise
../sysdeps/unix/sysv/linux/raise.c:51
0xffff9e2f1aab __GI_abort
/build/glibc-RIFKjK/glibc-2.31/stdlib/abort.c:79
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
specmake: *** [/home/spec/cpu2017_aarch64/benchspec/Makefile.defaults:356: source/me-tomography/measurements.o] Error 1
specmake: *** Waiting for unfinished jobs....失败的信息似乎是由MPRF浮点精度设置引起的？
我尝试用llvm-10构建510.parest_r，构建成功。
顺便说一下，我在x86_64服务器上构建了同样的gcc9.3，成功构建了510.parest_r。
1条答案
按热度按时间nqwrtyyt1#
你在GCC的旧版本中发现了一个bug（或者你的系统内存可能出了故障，但如果它总是在同一个地方崩溃的话，这种可能性不大），或者MPFR中有bug，但这种可能性不大。
如果您对该源代码进行预处理（将
-E或-save-temps添加到崩溃的命令行）并将其放在https://godbolt.org/上，它是否仍会以与 current ARM64 GCC相同的方式崩溃，例如，每晚构建的trunk？（https://godbolt.org/z/K6GnrYrj1是ARM64 GCC trunk，带有您的命令行参数，但没有预处理器内容，这在编译CPP输出时无关紧要。）如果它仍然崩溃与当前的GCC，然后文件的错误报告https://gcc.gnu.org/bugzilla/，理想的是与MCVE的部分源代码，触发错误.（删除尽可能多的部分，你可以同时保留崩溃行为.例如，取出吨的东西，撤销，如果这使它编译.）
如果它在更新的GCC中没有崩溃，那么它可能是一个已知的bug，或者是意外修复的，或者是不同的MPFR或其他库版本。也许不值得向上游报告。或者如果你确实要确保包括受影响版本的范围不包括GCC12或当前 Backbone.js 的事实。也许这个堆栈溢出问答足以让未来的用户知道它是“这是一个已知的错误。