svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc

[Mark Millard]

On 2017-Apr-28, at 3:27 PM, Mark Millard <markmi at dsl-only.net> wrote:

> Just FYI:
> 
> https://reviews.freebsd.org/D10537 may help with powerpc64-gcc
> slave ports (and powerpc64-gcc itself) when they are built on
> the type of machine that they target.
> 
> As of devel/*binutils -r436732 and -r432733 (the update
> to 2.28) many things are broken for linking with debug
> information that were not before (for example). It turns
> out to be because of a change in return code for reporting
> issues for the cases I know about: the new return code
> stops the build (and the return code is likely appropriate
> long term as I understand). For example a formerly ignored
> debug information issue now blocks various builds when a
> (modern) binutils is involved.
> 
> [Because of this I've been reverting devel/*binutils
> to -r436731 each time I update the revision of
> /usr/ports.]
> 
> As of ports head -r439263 with reverting
> devel/*binutils to -r436731 and the patch
> from D10537 I tested building the following
> earlier today as part of reviewing D10537:
> 
> amd64: built amd64-gcc powerpc64-gcc aarch64-gcc
> powerpc64: built powerpc64-gcc
> aarch64: built aarch64-gcc
> (Note: aarch64 is using -mcpu=cortex-a53 explicitly.)
> 
> Context: head -r317015 in each case.
> (WITH_LLD_IS_LD= was used on aarch64.)
> (powerpc64 is system-clang/libc++ based, used
> devel/*binutils)
> 
> If the information would be useful I could try
> some other combinations under the patch and
> the older binutils for comparison. (That does
> not say when anyone might use the information.)
> 
> I also have access to armv7. (In this context
> I normally use -mcpu=cortex-a7 explicitly.)
> So I could try that type of host as well.
> 
> I do not have access to mips, mips64, riscv, sparc64
> so they could be targets but not hosts in my tests:
> always cross-builds.
> 
> I have access to powerpc but currently am not well
> set up to use it without rebuilding it as gcc 4.2.1
> based for buildworld, not just buildkernel. (clang
> generates bad stack handling for some contexts for
> 32-bit powerpc.)

I tried building devel/amd64-gcc on a powerpc64
head -r317015 system that was built with clang
and libc++ and has clang as its system compiler.
/usr/ports as of -r439263 but devel/*binutils as
of -r436731 (so 2.27 instead of 2.2.8). The result
was the "=a" problem for the clang based build:

/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/cpuid.h:223:3: error: invalid output constraint '=a' in asm
  __cpuid (__ext, __eax, __ebx, __ecx, __edx);
  ^
/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/cpuid.h:165:7: note: expanded from macro '__cpuid'
           : "=a" (a), "=b" (b), "=c" (c), "=d" (d)     \
. . . (other such messages) . . .
In file included from /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/cppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/driver-i386.c:554::225: error: invalid output constraint '=a' in asm
. . .
          : "=a" (eax), "=d" (edx)
           ^
. . .

So this system-clang context on powerpc64 is like -r439595
reports for building devel/amd64-gcc on aarch64:

+BROKEN_aarch64=		error: invalid output constraint '=a' in asm

head/devel/amd64-gcc/Makefile only says:

 BROKEN_powerpc64=	Does not build

but it is like on aarch64 --at least when system-clang
compiler that is in use.

The compiler command lines were:

c++ -std=gnu++98 -fno-PIE -c   -O2 -pipe -B/usr/local/bin/ -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/  -DLIBICONV_PLUG -DIN_GCC    -fno-strict-aliasing -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/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/. -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../include -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcpp/include -I/usr/local/include  -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libdecnumber -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libbacktrace  -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT driver-i386.o -MMD -MP -MF ./.deps/driver-i386.TPo /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/driver-i386.c

c++ -std=gnu++98 -fno-PIE -c   -O2 -pipe -B/usr/local/bin/ -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/  -DLIBICONV_PLUG -DIN_GCC    -fno-strict-aliasing -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. -Ic-family -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../include -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcpp/include -I/usr/local/include  -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libdecnumber -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libbacktrace  -B/usr/local/bin/ -DLIBICONV_PLUG -o c-family/cppspec.o -MT c-family/cppspec.o -MMD -MP -MF c-family/.deps/cppspec.TPo /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/cppspec.c

It will be a fairly long time before the aarch64
context gets to this point in a devel/adm64-gcc
build, although I expect a replication of the
reported behavior for building devel/amd64-gcc .

===
Mark Millard
markmi at dsl-only.net