Bug 250932 - lang/gcc10: fails to build on aarch64
Summary: lang/gcc10: fails to build on aarch64
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm64 Any
: --- Affects Some People
Assignee: Gerald Pfeifer
Depends on:
Blocks: 246700
  Show dependency treegraph
Reported: 2020-11-07 20:10 UTC by Mikael Urankar
Modified: 2021-01-08 12:27 UTC (History)
3 users (show)

See Also:

v1 (1.27 KB, patch)
2020-11-07 20:10 UTC, Mikael Urankar
no flags Details | Diff
Proposed patch for aarch64 (810 bytes, patch)
2020-12-28 10:43 UTC, Gerald Pfeifer
no flags Details | Diff
reworked aarch64 patch file (706 bytes, patch)
2020-12-28 12:06 UTC, Mark Linimon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Urankar freebsd_committer 2020-11-07 20:10:22 UTC
Created attachment 219435 [details]

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: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...
Comment 1 Gerald Pfeifer freebsd_committer 2020-11-07 22:29:55 UTC
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?
Comment 2 Mikael Urankar freebsd_committer 2020-11-08 14:39:40 UTC
(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  \

I'll try gcc10-devel when it's done.
Comment 3 Mikael Urankar freebsd_committer 2020-11-08 17:03:10 UTC
lang/gcc10-devel fails with the same error.
Comment 4 Gerald Pfeifer freebsd_committer 2020-11-13 21:30:14 UTC
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?
Comment 5 Mikael Urankar freebsd_committer 2020-11-14 08:54:59 UTC
(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
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2020-11-17 17:19:25 UTC
I can confirm gcc10 builds on aarch64 under qemu using this patch.
Comment 7 Gerald Pfeifer freebsd_committer 2020-12-24 10:05:48 UTC
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.
Comment 8 Mark Millard 2020-12-24 11:20:50 UTC
(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:


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
Comment 9 Gerald Pfeifer freebsd_committer 2020-12-28 10:38:07 UTC
(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.
Comment 10 Gerald Pfeifer freebsd_committer 2020-12-28 10:43:44 UTC
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.
Comment 11 Mark Millard 2020-12-28 11:11:08 UTC
(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.
Comment 12 Mark Linimon freebsd_committer freebsd_triage 2020-12-28 12:06:18 UTC
Created attachment 221049 [details]
reworked aarch64 patch file

properly reformatted file files/patch-gcc_config_aarch64_aarch64-builtins.c , currently under test.
Comment 13 Mikael Urankar freebsd_committer 2020-12-28 17:12:59 UTC
(In reply to Gerald Pfeifer from comment #10)
I'll be able to test it in early january.
Comment 14 Gerald Pfeifer freebsd_committer 2021-01-05 15:44:18 UTC
(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
Comment 15 commit-hook freebsd_committer 2021-01-06 12:56:39 UTC
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

  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]

Comment 16 commit-hook freebsd_committer 2021-01-07 19:49:24 UTC
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

  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]

Comment 17 Gerald Pfeifer freebsd_committer 2021-01-07 19:52:56 UTC
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.
Comment 18 Mikael Urankar freebsd_committer 2021-01-08 12:27:36 UTC
(In reply to Gerald Pfeifer from comment #17)
We have a builder now: http://ampere2.nyi.freebsd.org/