riscv-none-embed-gcc 10.2.0 on Apple Silicon?

[ilg-ul]

Based on the comments in #49 (comment), I did a first run to build riscv-none-embed-gcc.

For now I applied only the 8 patches I already used for the arm-none-eabi-gcc toolchain (https://github.com/xpack-dev-tools/riscv-gcc/commits/v2020.12.0-xpack).

Building the first step (gcc) passed, but the second step (the libraries) failed with:

/Users/ilg/Work/riscv-none-embed-gcc-10.2.0-1.3/darwin-arm64/build/gcc-10.2.0-final/./gcc/xgcc -B/Users/ilg/Work/riscv-none-embed-gcc-10.2.0-1.3/darwin-arm64/build/gcc-10.2.0-final/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/Users/ilg/Work/riscv-none-embed-gcc-10.2.0-1.3/darwin-arm64/sources/riscv-gcc-10.2.0-1.3/gcc/testsuite/selftests
-fself-test: 89859 pass(es) in 0.367724 seconds
echo timestamp > s-selftest-c
/Users/ilg/Work/riscv-none-embed-gcc-10.2.0-1.3/darwin-arm64/build/gcc-10.2.0-final/./gcc/xgcc -B/Users/ilg/Work/riscv-none-embed-gcc-10.2.0-1.3/darwin-arm64/build/gcc-10.2.0-final/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=/Users/ilg/Work/riscv-none-embed-gcc-10.2.0-1.3/darwin-arm64/sources/riscv-gcc-10.2.0-1.3/gcc/testsuite/selftests
/dev/null:1: internal compiler error: in darwin_gt_pch_use_address, at config/host-darwin.c:50
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/sifive/freedom-tools/issues/> for instructions.
make[1]: *** [/Users/ilg/Work/riscv-none-embed-gcc-10.2.0-1.3/darwin-arm64/sources/riscv-gcc-10.2.0-1.3/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 1
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod
make[1]: Leaving directory '/Users/ilg/Work/riscv-none-embed-gcc-10.2.0-1.3/darwin-arm64/build/gcc-10.2.0-final/gcc'
make: *** [Makefile:4388: all-gcc] Error 2
ilg@xbbma ~ % 

This is a bit weird, since it looks to be related to PCH, but I have --disable-libstdcxx-pch.

Before trying to apply all the patches you mentioned in the other issue, do you have any specific advice?

[iains]

hmm .. can you point me at the actual source used for the riscv toolchain ?
I'm not clear on exactly what your base point is / the patch set applied.

disabling PCH with --disable-libstdcxx-pch only disables the building of libstdc++ PCH, it does not actually remove the PCH code from the compiler.

The startup code still calls the PCH memory allocator, to allow it to free any memory put aside for PCH (since we are obviously not going to use it) - it would seem that something is not honouring the aarch64 16384 pagesize (I'm guessing from the rough location given above).

[ilg-ul]

hmm .. can you point me at the actual source used for the riscv toolchain ?

Sure, here is the fork:

• https://github.com/xpack-dev-tools/riscv-gcc/tree/v10.2.0-1.3

[ilg-ul]

Ah, I forgot to mention, I also overwrite config.sub with:

• https://github.com/xpack-dev-tools/build-helper/blob/master/config.sub

[iains]

yeah... you are missing the base patch(es) that updated to be able to handle Darwin20 &c.

static char pch_address_space[1024*1024*1024] __attribute__((aligned (4096)));
^^^^ this has the wrong page alignment for aarch64.

TBH, in the name of stability - you are probably introducing more unknowns than using the backports - the change to Darwin 20 was major, it needs to be catered for.

[ilg-ul]

Hmmm... then how can we approach this issue? First to make the build pass, and then to minimise the risk?

[iains]

start with the backports branch - that contains the code that has already been applied to master - ergo it has been quite well tested (not so good as using it in a distribution, but ... ).

Then, if you are concerned - we might identify a sub-set of the patches as 'non-essential for a cross-compiler'.

[ilg-ul]

start with the backports branch

I'm trying to digest this, but I don't know which branch you are referring to. In this repo I identified gcc-10-3-extra-backports and gcc-10-coros-backports.

Then I'm not sure in which order to apply the patches, to avoid damaging the RISC-V code.

[iains]

this:
https://github.com/iains/gcc-11-branch/tree/gcc-11-2-darwin-nov21-backports
^^ this contains (on top of 10.2) all the patches that I intend to apply before 10.3.

(at least, up to this week, hence the nov21)
those patches are on top of pristine 10.2 - you should be able to see that if you have a client that can view the trees.
I would expect that branch to apply on top of any riscv-specific patches (since the Darwin patches have no riscv component) - or vice-versa (if there are not many riscv patches, might be easier that way)

[ilg-ul]

those patches are on top of pristine 10.2 - you should be able to see that if you have a client that can view the trees.

As graphical Git clients, I'm using Sourcetree, and Fork; after playing with filtering branches, I see the releases/gcc-10 branch from GNU and your gcc-11-2-darwin-nov21-backports branch, but it is not on top of gcc-10, but on top of gcc-11. The common ancestor is c416c52bcdb120db5e8c53a51bd78c4360daf79b, from 30 Apr 2020.

There are lots of commits on the gcc-10 branch since the split, and even more on your branch.

Attempts to merge your branch into gcc-10 leads to 277 conflicts. :-(

I'm either doing something terribly wrong, or there is a misunderstanding somewhere. :-(

[iains]

yeah, the misunderstanding is the base ...
.. I have not done the back ports to 10.x yet - that's going to take more time ..

[iains]

those patches are on top of pristine 10.2 - you should be able to see that if you have a client that can view the trees.

I meant 11.2 :-)

[ilg-ul]

I meant 11.2 ... I have not done the back ports to 10.x yet

ah, ok, that explains it.

so, for now I see no other way out than to add to those 8 patches several more and try to fix the pch issue, otherwise I won't have a RISC-V toolchain on my new Mac M1. :-(

[ilg-ul]

the change to Darwin 20 was major

did this happen between 10.2 and 10.3? is there a way to identify those commits?

[iains]

1. the time that the change occurred is not necessarily the important thing - it depends when/if fixes for it were back ported.
2. I assume you would actually want to base off the most recent release on 10.x? (i.e. 10.3 not 10.2)?
3. have too much $dayjob work to do before the weekend - but will take a look when time permits (I do have a back port queue for 10.x but it needs some recent patches adding).

[ilg-ul]

the time that the change occurred is not necessarily the important thing - it depends when/if fixes for it were back ported.

I thought to use it as a hint to delve into the see of commits, hoping to find something that fixed the pch issue.

I assume you would actually want to base off the most recent release on 10.x? (i.e. 10.3 not 10.2)?

I don't know. For the Arm toolchain, which was based on GCC 10.3, your patches worked beautifully.

For the RISC-V toolchain, which includes references to 10.2, I don't know what would be a minimal set of patches to make it work on Apple Silicon.

have too much $dayjob work to do before the weekend - but will take a look when time permits (I do have a back port queue for 10.x but it needs some recent patches adding).

Sure, when possible. I'll try to identify and cherry pick some previous commits mentioning pch, but, realistically, even if I make the build pass, I don't think it'll be a safe combination.

Basing your branch on top of 10.2 would be ideal (for 10.3, the patches were minimal anyway), but perhaps for the large community it would be beneficial to have separate backport branches for 10.2 and 10.3. If you end up with such a solution, I can redo the Arm toolchain, to test your branch.

Anyway, when ready, try to merge your new 10.x backport branch on top of 10.2 and see how many conflicts result. If there are not many, I can try to solve them myself.

[iains]

the PCH handling has been reworked - so that this should be moot for trunk.
do you still have a problem here?
if not, please can we close this issue?

[iains]

the current branch (on Apple Silicon) or upstream trunk (on x86_64) should build cross-compilers with no issues (at least, it does for me).

can we close this issue now?