Opened 3 years ago

Closed 3 years ago

#62072 closed defect (fixed)

gcc5 @5.5.0_6: build fails on 10.7: error: invalid operand for instruction movabsq 34359738368, %rax

Reported by: kencu (Ken) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: lion Cc:
Port: gcc5, cctools

Description

On the 10.7.5 buildbot, during the build of gcc5, we see this error:

<https://build.macports.org/builders/ports-10.7_x86_64-builder/builds/38858/steps/install-port/logs/stdio>

/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/build/./prev-gcc/xg++ -B/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/build/./prev-gcc/ -B/opt/local/x86_64-apple-darwin11/bin/ -nostdinc++ -B/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/build/prev-x86_64-apple-darwin11/libstdc++-v3/src/.libs -B/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/build/prev-x86_64-apple-darwin11/libstdc++-v3/libsupc++/.libs  -isystem /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/build/prev-x86_64-apple-darwin11/libstdc++-v3/include/x86_64-apple-darwin11  -isystem /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/build/prev-x86_64-apple-darwin11/libstdc++-v3/include  -isystem /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/gcc-5.5.0/libstdc++-v3/libsupc++ -L/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/build/prev-x86_64-apple-darwin11/libstdc++-v3/src/.libs -L/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/build/prev-x86_64-apple-darwin11/libstdc++-v3/libsupc++/.libs -c   -g -O2   -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/gcc-5.5.0/gcc -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/gcc-5.5.0/gcc/. -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/gcc-5.5.0/gcc/../include -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/gcc-5.5.0/gcc/../libcpp/include -I/opt/local/include -I/opt/local/include -I/opt/local/include  -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/gcc-5.5.0/gcc/../libdecnumber -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/gcc-5.5.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/gcc-5.5.0/gcc/../libbacktrace -I/opt/local/libexec/isl18/include -I/opt/local/include -o tree-ssa-threadupdate.o -MT tree-ssa-threadupdate.o -MMD -MP -MF ./.deps/tree-ssa-threadupdate.TPo 

/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc5/gcc5/work/.tmp/ccywe8yj.s:5325:10: error: invalid operand for instruction
        movabsq 34359738368, %rax
                ^
make[3]: *** [tree-ssa-threadupdate.o] Error 1
make[3]: *** Waiting for unfinished jobs....

This is no doubt caused by our modifications to cctools to force the use of the system "clang" as the assembler on 10.7.5 instead of using the built-in "gas" driver.

To confirm this, we know that if a version of macports-clang >= 5.0 is installed, then cctools' as driver will use that as assembler instead of the system clang, and in fact 10.7.5 builds gcc5 if macports-clang-9.0 is installed:

port -v installed gcc5
The following ports are currently installed:
  gcc5 @5.5.0_6 (active) platform='darwin 11' archs='x86_64' date='2021-01-17T09:45:39-0800'

As almost 100% of users of 10.7.5 have macports-clang-9.0 installed, most likely they are all building gcc5 on their own systems now, as I just did.

So, to fix this more robustly, and for the buildbot -- we could do any of these (and there might be other workarounds):

  • add a build dep on a macports-clang >= 5.0 for gcc5, which is a blunt but simple work-around...most 10.7.5 users need clang-9.0 installed anyway
  • change our cctools port to not use /usr/bin/clang as assembler on 10.7.5. That is actually not a bad idea, as it is not a great assembler at that point in time anyway, and we'd probably be losing very little by doing that.
  • force our cctools "as" driver to use the old "gas" assembler during the build of gcc5 by using a custom MacPorts-only ENV VAR that we came up with, but that does require patching gcc5 as by default it does not respect most ENV VARs set in the environment. This is probably the best idea.
  • There is supposed to be a way to drop a symlink somewhere in the build tree for the assember (and other tools) that you want to be used during the gcc build, and if that worked we could symlink in Apple's "/usr/bin/as" driver instead, but that has never worked when I tried it, although if it did work, it is simple indeed.

Change History (6)

comment:1 Changed 3 years ago by kencu (Ken)

Port: cctools added

comment:2 Changed 3 years ago by kencu (Ken)

In b1a8fdb2159f8712c96f3fbe597fae26a9d0ee4d/macports-ports (master):

gcc5: force clang-9.0 as assembler on Lion

work around a hiccup building this due to MacPort's cctools modifications
that forces the use of /usr/bin/clang as assembler, which doesn't work for gcc5 on 10.7.5
any clang >= 5.0 would work, but at present, all 10.7.5 users will have clang-9.0

see: #62072

comment:3 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

The build does succeed on 10.7 after that change, but I don't understand why. All you did was add a dependency on clang-9.0. You didn't do anything to tell the build to use any part of clang-9.0 and I don't see anything in the log that suggests any part of clang-9.0 is being used.

we know that if a version of macports-clang >= 5.0 is installed, then cctools' as driver will use that as assembler instead of the system clang

How do we know this? How does this happen?

comment:4 Changed 3 years ago by kencu (Ken)

the code Josh added makes a list of clang names to look for, starting with the newest macports-clang and working backwards to clang-5.0, then adds "clang" on 10.7+.

The assembler driver calls the first one it finds.

line 181 here <https://github.com/macports/macports-ports/blob/master/devel/cctools/Portfile>

(my old ipad here won't let me copy the permalink for you)

Last edited 3 years ago by kencu (Ken) (previous) (diff)

comment:5 Changed 3 years ago by kencu (Ken)

here's another example of where the clang assembler on 10.7 is too old, it appears <https://github.com/macports/macports-ports/pull/9905>.

comment:6 Changed 3 years ago by kencu (Ken)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.