Closed Bug 835293 Opened 8 years ago Closed 8 years ago
Build failures: intel-gcm
.s Error: `foo` is not supported on `opteron'
Today I updated my build and I'm getting build failures: ... intel-gcm.s:1282: Error: `vmovdqu' is not supported on `opteron' intel-gcm.s:1286: Error: `vpshufb' is not supported on `opteron' intel-gcm.s:1287: Error: `vpshufb' is not supported on `opteron' intel-gcm.s:1288: Error: `vmovdqu' is not supported on `opteron' intel-gcm.s:1289: Error: `vmovdqu' is not supported on `opteron' intel-gcm.s:1306: Error: `vpclmulqdq' is not supported on `opteron' intel-gcm.s:1307: Error: `vpclmulqdq' is not supported on `opteron' intel-gcm.s:1309: Error: `vpshufd' is not supported on `opteron' intel-gcm.s:1310: Error: `vpshufd' is not supported on `opteron' intel-gcm.s:1311: Error: `vpxor' is not supported on `opteron' intel-gcm.s:1312: Error: `vpxor' is not supported on `opteron' intel-gcm.s:1314: Error: `vpclmulqdq' is not supported on `opteron' intel-gcm.s:1315: Error: `vpxor' is not supported on `opteron' intel-gcm.s:1316: Error: `vpxor' is not supported on `opteron' intel-gcm.s:1318: Error: `vpslldq' is not supported on `opteron' intel-gcm.s:1319: Error: `vpsrldq' is not supported on `opteron' intel-gcm.s:1321: Error: `vpxor' is not supported on `opteron' intel-gcm.s:1322: Error: `vpxor' is not supported on `opteron' intel-gcm.s:1324: Error: `vpclmulqdq' is not supported on `opteron' intel-gcm.s:1325: Error: `vpshufd' is not supported on `opteron' intel-gcm.s:1326: Error: `vpxor' is not supported on `opteron' intel-gcm.s:1328: Error: `vpclmulqdq' is not supported on `opteron' intel-gcm.s:1329: Error: `vpshufd' is not supported on `opteron' intel-gcm.s:1330: Error: `vpxor' is not supported on `opteron' intel-gcm.s:1332: Error: `vpxor' is not supported on `opteron' clang: error: assembler command failed with exit code 1 (use -v to see invocation) and more. My system: Ubuntu 12.04 LTS. Debian clang version 3.1-8~precise1 (branches/release_31) (based on LLVM 3.1) Target: x86_64-pc-linux-gnu Thread model: posix The cpu I have is: Intel Core i7-2860QM. What can I do to get Firefox to build? This is preventing me from doing work. Thank you!
Same here on debian. as --version GNU assembler (GNU Binutils for Debian) 2.22
Thank you for the bug report. According to bug 805604 comment 24, GNU assembler 2.19 or later should be able to assemble intel-gcm.s. It is possible that you are running into bug 835050. Does security/nss/TAG-INFO say NSS_3_14_2_BETA2 or NSS_3_14_2_BETA3? If NSS_3_14_2_BETA2, then please update the source tree. If NSS_3_14_2_BETA3, could you try removing -march=opteron from this line? http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/Makefile&rev=1.125&mark=183#180
Assignee: nobody → wtc
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 3.14.2
Removing -march=opteron apparently works.
(In reply to Wan-Teh Chang from comment #2) > If NSS_3_14_2_BETA3, could you try removing -march=opteron from this line? I see NSS_3_14_2_BETA3.
I have Clang 3.0, and I don't need this patch. But two persons reported in this bug report that they need this patch. In any case, in year 2013 Opteron is not the right processor to optimize for.
(In reply to Wan-Teh Chang from comment #5) > In any case, in year 2013 Opteron is not the right processor > to optimize for. I'm not the one to a judgement about that, but http://en.wikipedia.org/wiki/Opteron#Models claims that the latest new Operon processor was released last month (Seoul, Dec 2012).
Attachment #707961 - Flags: feedback?(mh+mozilla) → feedback+
Kai: thank you for correcting me. I thought AMD changed the branding of their server CPUs. My apologies. The -march=opteron flag is only used on assembly code files. Here is an excerpt of the 'as' man page on Linux: -march=CPU[+EXTENSION...] This option specifies the target processor. The assembler will issue an error message if an attempt is made to assemble an instruction which will not execute on the target processor. The following processor names are recognized: "i8086", "i186", "i286", "i386", "i486", "i586", "i686", "pentium", "pentiumpro", "pentiumii", "pentiumiii", "pentium4", "prescott", "nocona", "core", "core2", "corei7", "l1om", "k1om", "k6", "k6_2", "athlon", "opteron", "k8", "amdfam10", "bdver1", "bdver2", "generic32" and "generic64". In addition to the basic instruction set, the assembler can be told to accept various extension mnemonics. For example, "-march=i686+sse4+vmx" extends i686 with sse4 and vmx. The following extensions are currently supported: 8087, 287, 387, "no87", "mmx", "nommx", "sse", "sse2", "sse3", "ssse3", "sse4.1", "sse4.2", "sse4", "nosse", "avx", "avx2", "noavx", "vmx", "smx", "xsave", "xsaveopt", "aes", "pclmul", "fsgsbase", "rdrnd", "f16c", "bmi2", "fma", "movbe", "ept", "lzcnt", "invpcid", "clflush", "lwp", "fma4", "xop", "syscall", "rdtscp", "3dnow", "3dnowa", "sse4a", "sse5", "svme", "abm" and "padlock". Note that rather than extending a basic instruction set, the extension mnemonics starting with "no" revoke the respective functionality. When the ".arch" directive is used with -march, the ".arch" directive will take precedent. So the -march assembler flag seems to be just a sanity check. We should be able to omit it safely.
I can't reproduce this assembler error in my environment, so my ability to come up with the best fix will be limited. Here are the versions of my clang and GNU as: $ clang -v clang version 3.3 (trunk 170392) Target: x86_64-unknown-linux-gnu Thread model: posix $ as --version GNU assembler (GNU Binutils for Ubuntu) 2.22 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'.
Comment on attachment 707961 [details] [diff] [review] Remove -march=opteron Wan-Teh, thanks for looking into it and your explanations. If I understand correctly, this is about the assemble flags for 64bit architecture on Linux, in general, with the intention to produce general purpose code for most processors. It seems the -march flags asks to produce special code for just one processor. I'd conclude that removing the flag is the right approach, because it will allow the assembler to make a choice which code to generate, and the assembler will probably generate code that works in most environments. Given this specialization flag causes trouble on some system, removing the flag seems to be a good approach. r=kaie
Attachment #707961 - Flags: review?(kaie) → review+
Kai: both the compiler and the assembler have the -march flag. For the compiler, the -march flag affects code generation. For the assembler, I believe the -march flag does not affect code generation because the assembler does not need to generate code. (The assembly code is already in the assembly code files.) The GNU as man page I quoted in comment 7 also supports my understanding. It seems that the -march assembler flag is just a sanity check, to ensure that the assembly code file does not use any instruction not supported by the specified CPU. Patch checked in on the NSS trunk (NSS 3.14.2). Checking in Makefile; /cvsroot/mozilla/security/nss/lib/freebl/Makefile,v <-- Makefile new revision: 1.127; previous revision: 1.126 done
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Thank you for the fix! How/when do we get this fix in mozilla-central?
We are planning to push a new NSS update to mozilla-central soon. It will include this fix.
Comment on attachment 707961 [details] [diff] [review] Remove -march=opteron r+ relyea
Attachment #707961 - Flags: superreview?(rrelyea) → superreview+
You need to log in before you can comment on or make changes to this bug.