On 2019-05-20, sylvain.bertr...@gmail.com <sylvain.bertr...@gmail.com> wrote: > Sadly, gcc-4.7 does not have an aarch64 backend and it's a pain to > configure > without breaking anything.
I wonder what the state of ARM/aarch64-4.7-branch is: https://gcc.gnu.org/viewcvs/gcc/branches/ARM/aarch64-4.7-branch/ It doesn't look like this branch is exported in the git mirror, but maybe if I can figure out git-svn, I can merge it into my branch. > Last time I tried to bootstrap, gcc 8 was not compiling with gcc 4.7 on > x86_64, > did you test it with gcc 9? Yes, I tested building gcc-9.1 with gcc-4.7.4 built by my compiler. I have not tried gcc-8. > What you say is good news, I may be able to add again a "gnu C" bootstrap to > my > custom distro (may burn some sh scripts to kill the GNU autotools in gcc > 4.7 > then). At least gcc tracks the autotools-generated files in the repository, so you don't actually need them installed to build. > You can replace inline asm: > - machine code from an independant assembler, for big asm chunks. > - with many extension keywords ("intrinsics"). A good idea is to make > addition of a keyword with their "machine code conversion" kind of > pluggable: I know it would have many limitations (llvm is literally > brain diarhea on this) but it can circumvent many inline asm snippets > this way. linux would be the primary target for this. > - to a certain extend, you could patch the target source code if > its authors are fine with it, (asm->plain and simple C, or > C11->simpler C). The issue is for lower level code that can't be written in C, for example making system calls. I don't think inline asm will be too difficult to implement in QBE. For the most part I think it can be treated similarly to a function call, but with a special calling convention. > I really need to check Quentin's QBE again. Yes, it has improved a lot in the past few months. > What you do is great work, keep going while real life let you. Thanks!
