GNOME Bugzilla – Bug 743082
orc: test-limits fails: no temporary registers available
Last modified: 2016-05-31 21:17:03 UTC
Windows NT 6.1.7601 x86_64, i686-w64-mingw32-gcc-4.9.2 orc 0.4.23 (same failure did occur with 0.4.21 too, back in the day), compiled with -g -O2 -fno-omit-frame-pointer, default configuration. Configure enabled backends: altivec, c64x, mips, mmx, neon, see Orc 0.4.23 - integrated testing tool Active backend: sse L1 cache: 32768 L2 cache: 262144 L3 cache: 8388608 Family/Model/Stepping: 6/42/7 CPU name: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz Compiler options: sse2 sse3 ssse3 sse41 sse42 Opcode test: No errors detected. test-limits fails (specifically - the last test_simple (ORC_MAX_ACCUM_VARS, orc_program_add_accumulator); test). orc_compiler_error_valist (args=0x28fcd8 "?u?eA\002", fmt=fmt@entry=0x658df7ec <__PRETTY_FUNCTION__.6126+754> "no temporary register available", compiler=0x530048) at ../../orc-0.4.23/orc/orccompiler.c:1214 1214 compiler->result = ORC_COMPILE_RESULT_UNKNOWN_COMPILE; (gdb) l 1209 1210 s = malloc (ORC_COMPILER_ERROR_BUFFER_SIZE); 1211 vsprintf (s, fmt, args); 1212 compiler->error_msg = s; 1213 compiler->error = TRUE; 1214 compiler->result = ORC_COMPILE_RESULT_UNKNOWN_COMPILE; 1215 } 1216 1217 void 1218 orc_compiler_error (OrcCompiler *compiler, const char *fmt, ...) (gdb) p compiler->error_msg $16 = 0x5467b8 "no temporary register available" (gdb) bt
+ Trace 234561
Works here with the SSE backend on latest orc master, Linux.
Not quite sure what to make of this. Nothing obviously wrong in the code at first glance. How does it "fail" exactly? Is it crashing? Is it erroring out with an unexpected return value? Obviously these compiler failures are all expected. Does it still happen with latest release?
"fails" means that the test does not succeed. orc_program_compile (p) returns ORC_COMPILE_RESULT_UNKNOWN_COMPILE, and test_simple() sets error to TRUE, thus the testcase fails. 0.4.25 is not affected.
> 0.4.25 is not affected. So it's fixed in 0.4.25? Can we close this then?
Yes.
Great, thanks.