2

I am attempting to compile a C++ code using gcc/5.3 on Scientific Linux release 6.7. I keep getting the following errors whenever I run my Makefile though:

/tmp/ccjZqIED.s: Assembler messages:
/tmp/ccjZqIED.s:768: Error: no such instruction: `shlx %rax,%rdx,%rdx'
/tmp/ccjZqIED.s:1067: Error: no such instruction: `shlx %rax,%rdx,%rdx'
/tmp/ccjZqIED.s: Assembler messages:
/tmp/ccjZqIED.s:6229: Error: no such instruction: `mulx %r10,%rcx,%rbx'
/tmp/ccjZqIED.s:6248: Error: no such instruction: `mulx %r13,%rcx,%rbx'
/tmp/ccjZqIED.s:7109: Error: no such instruction: `mulx %r10,%rcx,%rbx'
/tmp/ccjZqIED.s:7128: Error: no such instruction: `mulx %r13,%rcx,%rbx'

I've attmpted to follow the advice from this question with no change to my output: Compile errors with Assembler messages

My compiler options are currently:

CXXFLAGS        = -g -Wall -O0 -pg -std=c++11

Does anyone have any idea what could be causing this?

Community
  • 1
  • 1
D.Brandyberry
  • 21
  • 1
  • 1
  • 3

2 Answers2

5

This means that GCC is outputting an instruction that your assembler doesn't support. Either that's coming from inline asm in the source code, or that shouldn't happen, and suggests that you have compiled GCC on a different machine with a newer assembler, then copied it to another machine where it doesn't work properly.

Assuming those instructions aren't used explicitly in an asm statement you should be able to tell GCC not to emit those instructions with a suitable flag such as -mno-avx (or whatever flag is appropriate to disable use of those particular instructions).

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
5

@jonathan-wakely's answer is correct in that the assembler, which your compiler invokes, does not understand the assembly code, which your compiler generates.

As to why that happens, there are multiple possibilities:

  1. You installed the newer compiler by hand without also updating your assembler
  2. Your compiler generates 64-bit instructions, but assembler is limited to 32-bit ones for some reason

Disabling AVX (-mno-avx) is unlikely to help, because it is not explicitly requested either -- there is no -march in the quoted CXXFLAGS. If it did help, then you did not show us all of the compiler flags -- it would've been best, if you simply included the entire compiler command-line.

If my suspicion is correct in 1. above, then you should build and/or install the latest binutils package, which will provide as aware of AVX instructions, among other things. You would then need to rebuild the compiler with the --with-as=/path/to/the/updated/as flag passed to configure.

If your Linux installation is 32-bit only (suspicion 2.), then you should not be generating 64-bit binaries at all. It is possible, but not trivial...

Do post the output of uname -a and your entire compiler command-line leading to the above error-messages.

Mikhail T.
  • 3,043
  • 3
  • 29
  • 46
  • 1
    I've installed `gcc-10.0.0` onto my Mac OS X 10.7.5 manually i.e. from source and it works fine. Right now as I tried to compile a package it gave the error **x86-64-arch.c no such instruction: xgetbv** which is probably related to the **as** not having been updated because the `/usr/bin/as` is symbolic linked to `/Applications/Xcode-4.6.2.app/Contents/Developer/usr/bin/as` which is the older and/or unupdated version. So it looks like I need to update the **as** but how to do it on Mac OS X? In the past I remember trying to update it without avail. So which way to go? – Terry Jan 05 '21 at 19:10
  • I think, you need to build/install the `binutils` from source first, then rebuild gcc with the `--with-as` flag as I wrote two years ago. – Mikhail T. Jan 05 '21 at 19:14
  • Thank you for the quick reply. I've just built and installed some newer version of `binutils` the version `2.34` but even though all the configuration and compilation went smoothly, the `as` somehow just didn't get built and that was the case when I tried to update it one or two years ago too. I also remember on Mac OS X, only the `as` s provided by the Apple over the XCode suite, could be used reliably i.e. the ones provided by the **binutils** were of no use (I need to reconfirm this detail) So I think I need to do some more research about updating the **as** on Mac OS X. – Terry Jan 05 '21 at 19:27
  • You may, actually, be running into another problem -- your existing compiler-suit is Xcode, which is Apple-branded clang. You're trying to add GNU C. If you simply want newer compiler, try building newer clang (version 10.x or 11.x). If you must have GNU C/C++, do figure out, why your newer `as` is not used by it. – Mikhail T. Jan 05 '21 at 19:35