Re: 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
On 2017-Apr-28, at 8:40 PM, Mark Millard wrote: > On 2017-Apr-28, at 7:15 PM, Mark Millard wrote: > >> On 2017-Apr-28, at 6:10 PM, Mark Millard wrote: >> >>> On 2017-Apr-28, at 5:24 PM, Mark Millard wrote: >>> On 2017-Apr-28, at 3:27 PM, Mark Millard 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
Re: 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
On 2017-Apr-28, at 7:15 PM, Mark Millard wrote: > On 2017-Apr-28, at 6:10 PM, Mark Millard wrote: > >> On 2017-Apr-28, at 5:24 PM, Mark Millard wrote: >> >>> On 2017-Apr-28, at 3:27 PM, Mark Millard 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 >>>
Re: 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
On Fri, Apr 28, 2017 at 07:15:05PM -0700, Mark Millard wrote: > The armv7 attempt at devel/amd64-gcc also got > the "=a" problem, such as: > > /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/driver-i386.c:608:2: > error: invalid output constraint '=a' in asm > __cpuid (0x8002, name, 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) \ > ^ > > Note that this is different from -r439595's > report, which said for devel/amd64-gcc: > > +BROKEN_armv6=fails to package The latest build log seems to confirm this: http://beefy8.nyi.freebsd.org/data/head-armv6-default/p438916_s317177/logs/errors/amd64-gcc-6.3.0.log It's likely I simply made a mistake in transcription. mcl ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 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
On Fri, Apr 28, 2017 at 05:24:27PM -0700, Mark Millard wrote: > BROKEN_powerpc64=Does not build I'm attempting builds now. The message is from the last time it was tried, many months ago. mcl ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 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
On 2017-Apr-28, at 6:10 PM, Mark Millard wrote: > On 2017-Apr-28, at 5:24 PM, Mark Millard wrote: > >> On 2017-Apr-28, at 3:27 PM, Mark Millard 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/../libba c > kt >> race -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT driver-i386.o >> -MMD -MP -MF ./.deps/driver-i386.TPo >>
Re: 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
On 2017-Apr-28, at 5:24 PM, Mark Millard wrote: > On 2017-Apr-28, at 3:27 PM, Mark Millard 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/../libbac kt > race -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 >
Re: 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
On 2017-Apr-28, at 3:27 PM, Mark Millard 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/../libbackt race -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
