On Wed, Feb 10, 2016 at 08:32:51PM +0000, Christian Weisgerber wrote: > On 2016-02-09, Jonathan Gray <j...@jsg.id.au> wrote: > > > /usr/xenocara/lib/mesa/src/mesa/main/format_pack.c:6890: internal compiler > > error: in extract_insn, at recog.c:2077 > > Our usual workaround for these types of errors is to compile the > affected source file (and only that file, and only on that arch) > without any optimization. Did this still fail? >
Yes that was the 1st thing I tried of course.
Juest retried to be sure:
/share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1697: error:
unrecognizable insn:
(insn 57 56 58 3
/share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1583 (set
(reg:DI 188)
(ashift:DI (zero_extend:DI (const_int 1 [0x1]))
(ashift:DI (reg/f:DI 183)
(const_int 3 [0x3])))) -1 (nil)
(nil))
/share/OpenBSD/xenocara/lib/mesa/src/glsl/glsl_parser_extras.cpp:1697: internal
compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Looking closer this is an atomic sync operation:
1582: if (ctx->Const.GenerateTemporaryNames)
1583: (void) p_atomic_cmpxchg(&ir_variable::temporaries_allocate_names,
1584: false, true);
Anyone has an idea to implement support for this ?
PS: I also had a look at trying to on;y build the indirect glx part of the
lib (since direct rendering part is useless without an X server, and
the error so far is in a file only used for direct rendering, but the
new Mesa build system doesn't provide support for that.
--
Matthieu Herrb
signature.asc
Description: PGP signature
