Bump LLVM to v19.1.7+1

[Zentrik]

Including #55650 till that's merged.

[Zentrik]

The /home/rag/Documents/Code/julia/usr/include/llvm/ADT/StringRef.h:871:20: warning: 'int __builtin_memcmp_eq(const void*, const void*, long unsigned int)' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overread] warning seems to be a gcc bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101361

EDIT: gcc is giving a slightly different warning on CI but likely a bug as well

[giordano]

In that case you can guard the offending line with something like

#pragma GCC diagnostic push
#if defined(_COMPILER_GCC_) && __GNUC__ >= 12 // if this is version-dependent
// Explain why this is being ignored...
#pragma GCC diagnostic ignored "-Wstringop-overflow"
#endif
...
#pragma GCC diagnostic pop

[giordano]

Also, all tests are passing already on aarch64-darwin 🥳

[Zentrik]

Looks like the only two issues are a incorrect warning during the build (mose's suggestion doesn't seem to work though #pragma GCC diagnostic ignored "-Wstringop-overflow" by itself does) and /cache/build/tester-demeter6-13/julialang/julia-master/tmp/test-asan/asan/usr/bin/julia: error while loading shared libraries: libclang_rt.asan-x86_64.so: cannot open shared object file: No such file or directory. (I'll push the analyzegc fix in a bit).

[Zentrik]

Guessing the asan problem is clang -print-runtime-dir is returning toolchain/usr/lib/clang/19/lib/x86_64-unknown-linux-gnu instead of toolchain/usr/lib/clang/19/lib/linux so we don't find libclang_rt.asan... to copy to the build folder.

[giordano]

though #pragma GCC diagnostic ignored "-Wstringop-overflow" by itself does

Without the push-and-pop, that becomes closer to just adding -Wstringop-overflow to

julia/src/Makefile

Lines 23 to 25 in 80e60c8

	ifeq ($(USEGCC),1) # GCC bug #25509 (void)__attribute__((warn_unused_result))
	FLAGS += -Wno-unused-result
	endif

(please always add a comment to explain why the warning is being skipped) but it'd be nicer to keep the ignore as local as possible, if feasible.

[Zentrik]

Looks like remaining issue is some failures in analyzegc that I guess weren't caught by previous versions of clang.

[Zentrik]

Second analyzegc failure looks incorrect, it seems to incorrectly think uv_dup could return 0 when dupfd is set to -1 (minimal reproducer https://godbolt.org/z/4Wo99v1nv, llvm/llvm-project#43015 looks to be the same issue).

[Zentrik]

@nanosoldier runbenchmarks(ALL, vs=":master")

[giordano]

Need to rebase on master now that #56133 has been merged.

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[vtjnash]

First analyzegc failure looks incorrect, it seems to incorrectly think uv_dup could return 0 when dupfd is set to -1 (minimal reproducer https://godbolt.org/z/4Wo99v1nv, llvm/llvm-project#43015 looks to be the same issue).

FWIW, the standard way to deal with this is to add an assert and a comment, as that will make both reviewers and bots happy

[Zentrik]

The union.array.(perf_sum, Float32, 0) regression is due to SIMD not occurring. This is due to a change in the result from the instcombine pass. See https://godbolt.org/z/qqdzM7oxh,
The change from

%12 = select i1 %exactly_isa.not, float -0.000000e+00, float %immutable_union.sroa.0.0.copyload, !dbg !77
%value_phi6 = fadd float %value_phi, %12, !dbg !77

to

%12 = fadd float %value_phi, %immutable_union.sroa.0.0.copyload, !dbg !77
%value_phi6 = select i1 %exactly_isa.not, float %value_phi, float %12, !dbg !77

prevents the loopvectorize pass from SIMDing the code.

I suspect the other regression for the union.array benchmarks are similar.

[Zentrik]

I'll try rebasing on top of #52850 and see if that fixes the regressions.

[Zentrik]

@nanosoldier runtests()

[nanosoldier]

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

[oscardssmith]

@nanosoldier runbenchmarks(ALL, vs=":gb/pipeline-fun")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[oscardssmith]

looks like there are a few 8x (vectorization probably) regressions here.