Created attachment 219435 [details] v1 c++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format - Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc -I/usr/ports /lang/gcc10/work/gcc-10.2.0/gcc/. -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../include -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../libcpp/include -I/usr/local/include -I/usr/ports/lang/gcc10/work/gcc-10.2 .0/gcc/../libdecnumber -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../libbacktrace -DLIBICONV_PLUG -I. -I. -I/usr/ports/lang/gc c10/work/gcc-10.2.0/gcc -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/. -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../include -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../libcpp/include -I/usr/local/include - I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../libdecnumber -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/../libbacktrace \ /usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/config/aarch64/aarch64-builtins.c /usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/config/aarch64/aarch64-builtins.c:1231:3: error: expected expression AARCH64_INIT_MEMTAG_BUILTINS_DECL (IRG, irg, irg, fntype); ^ /usr/ports/lang/gcc10/work/gcc-10.2.0/gcc/config/aarch64/aarch64-builtins.c:1227:5: note: expanded from macro 'AARCH64_INIT_MEMTAG_BUILTINS_DECL' {T, CODE_FOR_##I}; ^ aarch64-builtins.c needs to be compiled with std=gnu++11, and the rest with gnu++98...
Do you also see the error your report with lang/gcc10-devel, i.e., the current upstream state of the GCC 10 release branch? If that's the same, how about lang/gcc11-devel? Mixing different C++ standards within one project/binary is not generally going to succeed, and ideally we'd get a fix from upstream. That said I am surprised nobody else has reported this before. Which version of FreeBSD and clang (I assume?) are you using? Any non-standard settings?
(In reply to Gerald Pfeifer from comment #1) It's 13-current cc -v FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673) gcc11-devel already use std=c++11, it seems to build so far, it'll take a while before it's done: c++ -std=c++11 -fno-PIE -c -g -DIN_GCC -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/. -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../include -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../libcpp/include -I/usr/local/include -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../libdecnumber -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../libbacktrace -DLIBICONV_PLUG -I. -I. -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/. -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../include -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../libcpp/include -I/usr/local/include -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../libdecnumber -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/../libbacktrace \ /usr/ports/lang/gcc11-devel/work/gcc-11-20201101/gcc/config/aarch64/aarch64-builtins.c I'll try gcc10-devel when it's done.
lang/gcc10-devel fails with the same error.
Thanks for giving gcc10-devel a spin, too. To me this looks like clang induced breakage, and on 13-CURRENT only? Is it possible this is something clang should/could address, or should we see whether upstream GCC has an idea?
(In reply to Gerald Pfeifer from comment #4) I haven't tried an earlier FreeBSD version llvm8, llvm90, llvm10 and llvm10 all fail the same way. with gcc9, it's only a warning: gcc/config/aarch64/aarch64-builtins.c:1227:21: warning: extended initializer lists only available with '-std=c++11' or '-std=gnu++11' gcc11-devel has switched to std=c++11 so it's a gcc problem not a llvm one
I can confirm gcc10 builds on aarch64 under qemu using this patch.
I believe this is fundamentally wrong both in principle (mixing C++ standards) and in not working via upstream, but having not been able to push the latter myself and this being contained, please go ahead. Approved by: gerald (maintainer) And I'll see that I get us to a fix via upstream in time for GCC 10.3.
(In reply to Mikael Urankar from comment #0) On head -r368500 on aarch64 (and more) I recently had poudriere build updated ports ( -r558163 ). gcc10.2.0 is one of the things that built (and I later installed). But I see that: http://ampere2.nyi.freebsd.org/data/head-arm64-default/p557699_s368500/logs/errors/gcc10-10.2.0.log shows the kind of error that you report. My guess is that my options made the difference (pkg info output): Options : BOOTSTRAP : off GRAPHITE : off vs. what the ampere2 log shows: ===> The following configuration options are available for gcc10-10.2.0: BOOTSTRAP=on: Build using a full bootstrap GRAPHITE=off: Support for Graphite loop optimizations
(In reply to Mark Millard from comment #8) > My guess is that my options made the difference > [...] > BOOTSTRAP : off > GRAPHITE : off BOOTSTRAP=off means that GCC never builds itself (and hence never fully exercises itself). In that case this may have helped; in general I recommend against it.
Created attachment 221046 [details] Proposed patch for aarch64 (In reply to Gerald Pfeifer from comment #7) > Approved by: gerald (maintainer) > > And I'll see that I get us to a fix via upstream in time for GCC 10.3. Instead of the Makefile change, can you please give this patch a try? This is what likely is going to get in upstream. I could not build test this, so if there's a \ or ; or the like missing somewhere, it would be great if you could adjust.
(In reply to Gerald Pfeifer from comment #9) I'm aware of the tradeoffs with using BOOTSTRAP off. But my time preferences are such that on small arm boards and the like I normally use BOOTSTRAP off: BOOTSTRAP makes a big build-time difference in those contexts. I do sometimes do a BOOTSTRAP based build as a cross check on the status.
Created attachment 221049 [details] reworked aarch64 patch file properly reformatted file files/patch-gcc_config_aarch64_aarch64-builtins.c , currently under test.
(In reply to Gerald Pfeifer from comment #10) I'll be able to test it in early january.
(In reply to Mikael Urankar from comment #13) > I'll be able to test it in early january. I engaged with others upstream, and there's essentially this change now, which we'll get with the next update of lang/gcc10-devel that I plan for tomorrow.
A commit references this bug: Author: gerald Date: Wed Jan 6 12:56:07 UTC 2021 New revision: 560506 URL: https://svnweb.freebsd.org/changeset/ports/560506 Log: Update to the 20210102 snapshot of GCC 10.2.1. This brings two backports for the aarch64 backend and one for x86, plus three for the Fortran front end. Enable the new powerpcle architecture which this snapshot brings in via upstream, per a submission by pkubaj@. [1] This also should fix the build on aarch64 when clang is the bootstrap compiler. [2] PR: 251670 [1], 250932 [2] Changes: head/lang/gcc10-devel/Makefile head/lang/gcc10-devel/distinfo
A commit references this bug: Author: gerald Date: Thu Jan 7 19:49:12 UTC 2021 New revision: 560731 URL: https://svnweb.freebsd.org/changeset/ports/560731 Log: Back port part of r560506 | gerald | 2021-01-06 from lang/gcc10-devel by extracting the upstream patch into files/patch-aarch64-c++98-fix: This also should fix the build on aarch64 when clang is the bootstrap compiler. [2] PR: 250932 [2] Changes: head/lang/gcc10/files/patch-aarch64-c++98-fix
This should fix this for lang/gcc10 in addition to lang/gcc10-devel. In the future it'll be great if you can somewhat regularly test the gcc/*-devel ports on aarch64 so that we can identify and tackle such (hopefully rare) cases swiftly, before it hits an actual release.
(In reply to Gerald Pfeifer from comment #17) We have a builder now: http://ampere2.nyi.freebsd.org/