[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 Keno Fischer changed: What|Removed |Added CC||keno at juliacomputing dot com --- Comment #8 from Keno Fischer --- Is there a list of all the things that need doing? I don't know very much about how GCC is architected (but am familiar with LLVM,MachO,Aarch64 ISA, etc), but from my naive point of view, at least - Add all the ARM64 MachO relocations - Add special cases for the Aarch64 ABI differences on Apple platforms - Implement parsing/(& printing?) for Apple's assembly dialect - Add CPU models for the relevant chips The good news is that I don't think there's currently any proprietary ISA extensions that we would have to worry about, so most of the code generation should just go through. I unfortunately don't have very much time myself either, but might able able to pick up a small piece. Perhaps we can subdivide the work and prioritize what's on the "critical path". I think the biggest reason people are clamoring for GCC support at the moment is that the platform otherwise has no fortran compiler, which is blocking a lot of the scientific computing stack. I think identifying a minimal "fortran-complete" path would be helpful and encourage people to help out :).
[Bug other/82704] New: GCC fails to download prerequisites on busybox distro (unrecognized sha512sum --check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82704 Bug ID: 82704 Summary: GCC fails to download prerequisites on busybox distro (unrecognized sha512sum --check) Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: keno at juliacomputing dot com Target Milestone: --- The contrib/download_prerequisites script uses `sha512sum --check` to verify the integrity of the downloaded prerequisites. This is an alias for `-c` in coreutils, but busybox does not recognize this alias, leading to the below failure (on an Alpine Linux based system). The solution is simply to replace `--check`, by `-c` which should work on both coreutils and busybox. I have verified that with that change, everything else goes through as usual. ``` Connecting to gcc.gnu.org (209.132.180.131:21) gmp-6.1.0.tar.bz2 0% | | 12132 0:03:15 ETA gmp-6.1.0.tar.bz2 23% |***| 544k 0:00:06 ETA gmp-6.1.0.tar.bz2 77% |***| 1795k 0:00:00 ETA gmp-6.1.0.tar.bz2100% |***| 2327k 0:00:00 ETA Connecting to gcc.gnu.org (209.132.180.131:21) mpfr-3.1.4.tar.bz2 6% |* | 82228 0:00:14 ETA mpfr-3.1.4.tar.bz255% |* | 693k 0:00:01 ETA mpfr-3.1.4.tar.bz2 100% |***| 1249k 0:00:00 ETA Connecting to gcc.gnu.org (209.132.180.131:21) mpc-1.0.3.tar.gz 26% | | 172k 0:00:02 ETA mpc-1.0.3.tar.gz 100% |***| 654k 0:00:00 ETA Connecting to gcc.gnu.org (209.132.180.131:21) isl-0.16.1.tar.bz2 4% |* | 70096 0:00:22 ETA isl-0.16.1.tar.bz235% |** | 559k 0:00:03 ETA isl-0.16.1.tar.bz295% |* | 1517k 0:00:00 ETA isl-0.16.1.tar.bz2 100% |***| 1588k 0:00:00 ETA sha512sum: unrecognized option: check BusyBox v1.26.2 (2017-06-11 06:38:32 GMT) multi-call binary. Usage: sha512sum [-c[sw]] [FILE]... Print or check SHA512 checksums -c Check sums against list in FILEs -s Don't output anything, status code shows success -w Warn about improperly formatted checksum lines error: Cannot verify integrity of possibly corrupted file gmp-6.1.0.tar.bz2 ```
[Bug other/82708] New: libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 Bug ID: 82708 Summary: libmpx fails to compile due to PATH_MAX Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: keno at juliacomputing dot com Target Milestone: --- In trying to build gcc on musl-based Alpine linux, I encountered the following error: ``` /src/gcc-7.2.0/libmpx/mpxrt/mpxrt-utils.c:72:23: error: ‘PATH_MAX’ undeclared here (not in a function); did you mean ‘INT8_MAX’? #define MAX_FILE_NAME PATH_MAX ^ /src/gcc-7.2.0/libmpx/mpxrt/mpxrt-utils.c:95:22: note: in expansion of macro ‘MAX_FILE_NAME’ static char out_name[MAX_FILE_NAME]; ^ ``` I was confused by this at first because musl defines PATH_MAX in limits.h which appears to be included from that file, but looking at the `-E` output it turns out that it uses `include-fixed/limits.h` instead, which doesn't have that definition. I don't know enough about GCC's build system to determine what's at fault here (maybe it shouldn't be using that limits.h?) In searching the internet, there are a number of reports of this error from various other system configurations as well, so this like a fairly common problem when building gcc.
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 --- Comment #2 from Keno Fischer --- It looks like different parts of the build system may be disagreeing on that. I see checking limits.h usability... yes in the log in one place and then checking limits.h usability... no later in the same log. Are there different usability checks for this header?
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 --- Comment #4 from Keno Fischer --- Ah, ok sorry I was confused. I probably should have mentioned that I'm doing a cross compile to a glibc based system, so I'm building the compiler, then building glibc, and then going back and building the runtime libraries. The exact script I'm using is here: https://github.com/staticfloat/julia-docker/blob/master/workerbase/lib/build_crosscompiler.sh So at the compiler build stage, the limits.h header indeed does not exist, but it does exist once we go back to build the rest of the runtime libraries (because we built glibc in the meantime). Is there something I should be running to regenerate these files before building the runtime libraries?
[Bug other/82708] libmpx fails to compile due to PATH_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708 Keno Fischer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Keno Fischer --- I have unsuccessfully tried to make that option work. I am able to build glibc with the bootstrap compiler, but the second stage build invariably fails. I ran into a bunch of problems. First, the build process looking for the headers in /sys-include rather than /include where glibc installs them. Leads to the same symptoms as reported in this issue. Then, I tried using --with-sysroot which I wasn't using before, but then I got confusion between /usr/include and /include (most parts of the build system looking in usr/include, but others such as when building libgcc seem to be looking in /include/). If I symlink those paths together things progress farther but eventually fail to link. I also tried replicating the glibc script you pointed to, without much luck (some mixture of the above symptoms). Given that I get a well functioning cross compiler, using the original recipe with a simple patch to mpxrt-utils.c to bypass the broken limits.h file, I'm tempted to move on and leave this be. I'll note at this point that e.g. http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass2.html also suggests patching the limits.h file manually, so at least I'm not the only one. I guess I had hoped that there was something that could be done in the gcc build system to make this experience less frustrating for the next person. If not that, a modern guide on how to do this by somebody who knows how it's supposed to be would be great, since all the guides out there seem to have some step of "and this is where we hack around gcc/glibc's broken build systems". It sounds like things have improved since those guides were written, which is great, but I have no idea what the right commands are. I am grateful you took the time to answer my questions here.
[Bug other/82704] GCC fails to download prerequisites on busybox distro (unrecognized sha512sum --check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82704 --- Comment #2 from Keno Fischer --- Well, the script has a separate code path for Darwin anyway, since Darwin's sha512sum is spelled `shasum -a 512`, but `shasum` also supports `-c` (as well as `--check`).
[Bug libgcc/105708] New: libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708
Bug ID: 105708
Summary: libgcc: aarch64: init_lse_atomics can race with
user-defined constructors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: keno at juliacomputing dot com
Target Milestone: ---
Recent gcc versions provide the `-moutline-atomics` option that outlines
aarch64 atomics into calls to libgcc that dispatch to either lse atomics or
legacy ll/sc atomics depending on the availability of the feature on the target
platform.
This is useful for performance (since lse atomics have better performance
characteristics), but also for projects like the rr (https://rr-project.org/)
userspace record-and-replay debugger, which emulates an aarch64 machine without
ll/sc intrinsics (because ll/sc introduces non-deterministic control flow
divergences that rr cannot record).
The feature detection uses the following function in libgcc
(config/aarch64/lse-init.c):
```
static void __attribute__((constructor))
init_have_lse_atomics (void)
{
unsigned long hwcap = __getauxval (AT_HWCAP);
__aarch64_have_lse_atomics = (hwcap & HWCAP_ATOMICS) != 0;
}
```
Unfortunately, the order of this `init_have_lse_atomics` is not defined with
respect to other uses of `__attribute__((constructor))`. As a result, other
constructors using atomics may end up using ll/sc instructions, even if lse
atomics are supported on the target (usually only a performance penalty, but as
mentioned above, a significant concern for projects like rr).
Worse, the initialization order can change, with minor changes in the
environment. E.g. recent binary builds of debian testing initialize lse too
late in libpthread, breaking rr. Earlier builds had the opposite initialization
order allowing rr to work without issue.
I can see two possibilities to introduce more determinism here:
1. Use `__attribute__((constructor(100)))` (100 being the system library
priority used e.g. in libstdc++ as well) for `init_have_lse_atomics`, forcing a
deterministic initialization order wrt user (or libc)-defined constructors.
There are still ordering concerns wrt libstdc++ which also uses init_order 100,
but as far as I can tell does not use atomics in these constructors. If this
changes, the priority here could be further reduced in future iterations of
libgcc.
2. Switch the outlined atomics to probe lse support on first use rather than
using a constructor. If this is possible, I think it would be preferable to
avoid any possibility of initialization order problems, but I understand that
there may be code size and performance concerns.
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 --- Comment #3 from Keno Fischer --- > I am going to close it as won't fix as the problem is with the rr emulator > which needs to emulate ll/sc for correctness. No currently shipping aarch64 chip provides hardware support that would allow such a capability (believe me, we've tried and have and many conversations with the hardware vendors about it). I would like to strongly request that the WONTFIX be reconsidered here. It's a relatively simple fix, that should not have any downsides. If this is not fixed upstream in libgcc then distributions that want to provide rr will need to start patching libgcc downstream or find another solution, which will just be a huge mess.
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 --- Comment #5 from Keno Fischer --- Yes, rr cannot record ll/sc. I'm happy to go into depth here, but this is not really an aarch64 issue. rr doesn't work on ppc64le either for this reason. The introduction of lse has made rr feasible on aarch64, and there has been a substantial effort to get to this point where rr is working on the architecture. We're now working through the distribution issues, where this cropped up (as mentioned, we didn't notice earlier, because the initialization is not deterministic). For the moment, we're telling downstream users to avoid manual use of ll/sc in programs that they want to record under rr. Obviously this is a significant effort, but for many people it's worth it, because rr is a critical tool. Perhaps in future hardware iterations, we'll get the ability to fault on stxr abort or similar, which would allow rr to support ll/sc, but until then we need to make due with what we have. The issue here is that `-moutline-atomics` now introduces extra ll/sc instructions even in software where the implementer was careful to avoid manual uses of ll/sc and in particular also in system libraries like libc and rtld that the user may have little control over. Of course we can keep telling people to build their distribution images with `-march=armv8.3-a -mno-outline-atomics` and avoid this issue or have them patch libgcc downstream, but that really seems to defeat the point of `-moutline-atomics`, which was exactly to avoid this kind of split.
[Bug libgcc/105708] libgcc: aarch64: init_lse_atomics can race with user-defined constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105708 --- Comment #7 from Keno Fischer --- I'm probably talking in circles at this point, but let me try just one more time. I just want to clarify that I understand that this is not technically a libgcc bug. But it's not really an rr bug either. Existing hardware already barely supports rr and we're still working with a number of silicon vendors to address microarchitecture bugs that are causing issues. We'll also keep advocating for hardware support for ll/sc emulation/trapping, but as you can imagine that's a big lift. It's not a matter of rr just fixing some code - the hardware support required for this does not currently exist. These limitations are proactively communicated to the user and there are appropriate error messages for unsupported situations (e.g. use of a broken microarchitecture or recording of an application that used ll/sc). I was hoping by making this change in libgcc we could increase the number of situations where rr does work, without putting significant extra burden on the distribution maintainers. That said, if this really is a hard WONTFIX here, then we'll work with the distribution maintainers to start carrying a libgcc patch as necessary :(. It's gonna be messy and I'm not looking forward to it, but I don't really know what else to say to make my case here.
[Bug tree-optimization/121115] [15/16 regression] GCC 15+ miscompiles Julia programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121115 --- Comment #6 from Keno Fischer --- > I can retry with tip-of-trunk. Tip-of-trunk fails for me with the provided reproduction steps.
[Bug tree-optimization/121115] New: GCC 15+ miscompiles Julia programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121115 Bug ID: 121115 Summary: GCC 15+ miscompiles Julia programming language Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: keno at juliacomputing dot com Target Milestone: --- As mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115236#c7 (and originally reported in https://github.com/JuliaLang/julia/issues/58466), building the Julia programming language with GCC 15 results in a crashing build. This was bisected on the Julia issue tracker to https://gcc.gnu.org/cgit/gcc/commit/?id=c08b0d3f7b3539b26031de31d88dea6b94474577. I have attempted to come up with a minimal reproducer, but the bug is somewhat fragile. As a result, the reduced reproducer I have still depends on the julia/llvm libraries, but it should be standalone enough to not require a lot of setup. For completeness, I am also providing reproduction instructions for the original issue below. # Instructions for reduced reproducer The attached reproducer.expanded.cpp is a preprecossor-expanded and manually reduced version of Julia's aotcompile.cpp. However, running it depends on the julia/llvm external libraries, but not particularly closely, so the easiest way is to grab these from any recent nightly build of julia: ``` $ curl -LO https://julialangnightlies-s3.julialang.org/bin/linux/x86_64/julia-latest-linux-x86_64.tar.gz $ tar --strip-components=1 --wildcards -xf julia-latest-linux-x86_64.tar.gz '*LLVM.so*' '*libjulia*.so*' '*libunwind.so*' '*libopenlibm.so*' $ g++-15 -mprefer-vector-width=256 -std=c++17 -fno-exceptions -funwind-tables -fno-rtti -Llib -Llib/julia -lLLVM -ljulia-internal -ljulia -Wl,-rpath lib -Wl,-rpath lib/julia -O3 reproducer.expanded.cpp [snip warnings] $ ./a.out Unreachable reached at 0x4022b9 [3424449] signal 4 (2): Illegal instruction in expression starting at none:0 jl_emit_native_impl.cold at ./a.out (unknown line) main at ./a.out (unknown line) unknown function (ip: 0x746dbbe2a1c9) at /lib/x86_64-linux-gnu/libc.so.6 __libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line) _start at ./a.out (unknown line) Allocations: 1 (Pool: 1; Big: 0); GC: 0 Illegal instruction $ g++-15 -mprefer-vector-width=256 -std=c++17 -fno-exceptions -funwind-tables -fno-rtti -Llib -Llib/julia -lLLVM -ljulia-internal -ljulia -Wl,-rpath lib -Wl,-rpath lib/julia -O0 reproducer.expanded.cpp [snip warnings] $ ./a.out [no crash] ``` The `Illegal instruction` here is a `__builtin_trap` that marks the bug - the original reproducer segfaults on the next line instead. The `-mprefer-vector-width=256` is not required on current GCC, but I've included it to facilitate bisect, since the regression commit range includes a commit that switches the default for this flag (and it affects the presence of the bug). # Instructions for upstream reproducer To test upstream, ``` $ git clone https://github.com/JuliaLang/julia.git $ cd julia $ cat > Make.user <
[Bug tree-optimization/121115] [15/16 regression] GCC 15+ miscompiles Julia programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121115 --- Comment #3 from Keno Fischer --- Created attachment 61882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61882&action=edit Preprocessor expanded reduced test case
[Bug tree-optimization/121115] [15/16 regression] GCC 15+ miscompiles Julia programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121115 --- Comment #4 from Keno Fischer --- > There's a chance this is related to PR120358 then. Could you try on trunk > please (or the branch releases/gcc-15)? I have tested with 598455fd73b2061e461c54c18fae8bcc2b4b6d72 (trunk from 3 days ago) and it is failing. I can retry with tip-of-trunk. > Looks like it's missing. Maybe needs compressing (try xz -9e) if it's too big. Yes, it was too big. I have uploaded the xz compressed version.
[Bug tree-optimization/121115] [15/16 regression] GCC 15+ miscompiles Julia programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121115 --- Comment #5 from Keno Fischer --- > tar --strip-components=1 -xf julia-latest-linux-x86_64.tar.gz Actually, for the untar, run `tar --strip-components=1 -xf julia-latest-linux-x86_64.tar.gz` to just extract the full thing. I was trying to be clever and filter libraries, but I missed some (because I had accidentally already extracted them locally), and it's not really worth bothering.
