ziglang/zig
261
5.9k
Fork
You've already forked zig
764

math: fix acosh for x < 1 (including negative inputs) #35616

Open
arshidkv12 wants to merge 6 commits from arshidkv12/zig:acosh-1 into master
pull from: arshidkv12/zig:acosh-1
merge into: ziglang:master
ziglang:master
ziglang:elfv2
ziglang:spork8
ziglang:restricted
ziglang:0.16.x
ziglang:panic-rewrite
ziglang:parking-futex-lockfree
ziglang:windows-Io-cleanup
ziglang:Io-watch
ziglang:ParseCommandLineOptions
ziglang:windows-async-files
ziglang:poll-ring
ziglang:debug-file-leaks-differently
ziglang:debug-file-leaks
ziglang:ProcessPrng
ziglang:elfv2-dyn
ziglang:jobserver
ziglang:threadtheft
ziglang:io-threaded-no-queue
ziglang:0.15.x
ziglang:Io.net
ziglang:comptime-allocator
ziglang:restricted-function-pointers
ziglang:cli
ziglang:wasm-linker-writer
ziglang:wrangle-writer-buffering
ziglang:sha1-stream
ziglang:async-await-demo
ziglang:fixes
ziglang:0.14.x
ziglang:ast-node-methods
ziglang:macos-debug-info
ziglang:make-vs-configure
ziglang:fuzz-macos
ziglang:sans-aro
ziglang:ArrayList-reserve
ziglang:incr-bug
ziglang:llvm-ir-nosanitize-metadata
ziglang:ci-tarballs
ziglang:ci-scripts
ziglang:threadpool
ziglang:0.12.x
ziglang:new-pkg-hash
ziglang:json-diagnostics
ziglang:more-doctests
ziglang:rework-comptime-mutation
ziglang:0.11.x
ziglang:ci-perf-comment
ziglang:stage2-async
ziglang:0.10.x
ziglang:autofix
ziglang:0.9.x
ziglang:aro
ziglang:hcs
ziglang:0.8.x
ziglang:0.7.x
Contributor
Copy link
https://codeberg.org/ziglang/zig/issues/35315
math: fix acosh for x < 1 (including negative inputs)
Some checks failed
ci / aarch64-macos-release (pull_request) Failing after 38m28s
ci / x86_64-netbsd-release (pull_request) Failing after 29m27s
ci / x86_64-freebsd-release (pull_request) Failing after 29m33s
ci / aarch64-macos-debug (pull_request) Failing after 1h1m46s
ci / x86_64-netbsd-debug (pull_request) Failing after 38m40s
ci / x86_64-freebsd-debug (pull_request) Failing after 40m57s
ci / x86_64-openbsd-release (pull_request) Failing after 41m7s
ci / x86_64-openbsd-debug (pull_request) Failing after 46m21s
ci / x86_64-linux-debug (pull_request) Failing after 1h24m27s
ci / x86_64-windows-release (pull_request) Failing after 42m52s
ci / aarch64-linux-release (pull_request) Failing after 1h16m9s
ci / powerpc64le-linux-release (pull_request) Failing after 1h47m26s
ci / x86_64-windows-debug (pull_request) Failing after 1h2m39s
ci / aarch64-linux-debug (pull_request) Failing after 1h51m38s
ci / s390x-linux-release (pull_request) Failing after 1h26m22s
ci / x86_64-linux-debug-llvm (pull_request) Failing after 3h23m47s
ci / s390x-linux-debug (pull_request) Failing after 2h12m13s
ci / powerpc64le-linux-debug (pull_request) Failing after 3h58m42s
ci / x86_64-linux-release (pull_request) Failing after 2h49m27s
ci / aarch64-freebsd-debug (pull_request) Has been cancelled
ci / aarch64-freebsd-release (pull_request) Has been cancelled
ci / aarch64-netbsd-debug (pull_request) Has been cancelled
ci / aarch64-netbsd-release (pull_request) Has been cancelled
ci / loongarch64-linux-debug (pull_request) Has been cancelled
ci / loongarch64-linux-release (pull_request) Has been cancelled
ci / riscv64-linux-debug (pull_request) Has been cancelled
ci / riscv64-linux-release (pull_request) Has been cancelled
2228dac54b
Author
Contributor
Copy link
No description provided.
tiehuis left a comment
Copy link

I don't think this is the fix we want here.

Specifically, I expect the x < 1.0 case to be handled in the first branch:

return math.log1p(x - 1 + @sqrt((x - 1) * (x - 1) + 2 * (x - 1)));

This handles the cases implicitly by the behaviour of log1p and sqrt. Either the argument to sqrt will be negative (-1 < x < 1), or the argument to log1p will be negative (x < -1) ), as x will grow faster relative to sqrt argument in all other cases. Both of which will propagate a nan through as the acosh return value.

If you run these tests against master, we can see that f32 already produces the correct values according to the tests, suggesting that only acosh64 is an issue.

Based on your debugging, perhaps look at why the second branch is being taken for these negative instead of the first (which should handle the domain issue). Notably the exponent check differs a little.

See also upstream musl which this code was derived from: https://git.musl-libc.org/cgit/musl/tree/src/math/acosh.c

I don't think this is the fix we want here. Specifically, I expect the `x < 1.0` case to be handled in the first branch: ``` return math.log1p(x - 1 + @sqrt((x - 1) * (x - 1) + 2 * (x - 1))); ``` This handles the cases implicitly by the behaviour of log1p and sqrt. Either the argument to sqrt will be negative (`-1 < x < 1`), or the argument to `log1p` will be negative (`x < -1`) ), as x will grow faster relative to `sqrt` argument in all other cases. Both of which will propagate a nan through as the acosh return value. If you run these tests against master, we can see that `f32` already produces the correct values according to the tests, suggesting that only `acosh64` is an issue. Based on your debugging, perhaps look at why the second branch is being taken for these negative instead of the first (which should handle the domain issue). Notably the exponent check differs a little. See also upstream musl which this code was derived from: https://git.musl-libc.org/cgit/musl/tree/src/math/acosh.c
Author
Contributor
Copy link

@tiehuis wrote in #35616 (comment):

I don't think this is the fix we want here.

Specifically, I expect the x < 1.0 case to be handled in the first branch:

return math.log1p(x - 1 + @sqrt((x - 1) * (x - 1) + 2 * (x - 1)));

This handles the cases implicitly by the behaviour of log1p and sqrt. Either the argument to sqrt will be negative (-1 < x < 1), or the argument to log1p will be negative (x < -1) ), as x will grow faster relative to sqrt argument in all other cases. Both of which will propagate a nan through as the acosh return value.

If you run these tests against master, we can see that f32 already produces the correct values according to the tests, suggesting that only acosh64 is an issue.

Based on your debugging, perhaps look at why the second branch is being taken for these negative instead of the first (which should handle the domain issue). Notably the exponent check differs a little.

See also upstream musl which this code was derived from: https://git.musl-libc.org/cgit/musl/tree/src/math/acosh.c

Yes, the acosh32 is working properly. But I think, musl c code also not working.

#include <stdio.h>#include <math.h>#include <stdint.h>
double acosh(double x)
{
	union {double f; uint64_t i;} u = {.f = x};
	unsigned e = u.i >> 52 & 0x7ff;
	/* x < 1 domain error is handled in the called functions */
	if (e < 0x3ff + 1)
		/* |x| < 2, up to 2ulp error in [1,1.125] */
		return log1p(x-1 + sqrt((x-1)*(x-1)+2*(x-1)));
	if (e < 0x3ff + 26)
		/* |x| < 0x1p26 */
		return log(2*x - 1/(x+sqrt(x*x-1)));
	/* |x| >= 0x1p26 or nan */
	return log(x) + 0.693147180559945309417232121458176568;
}
int main(){
 double x = -1.9e4;
 double z = acosh(x);
 printf("out x %f \n", z);
 double y = -2e4;
 double k = acosh(x);
 printf("out x %f \n", k);
}

Out

gcc z.c && ./a.out 
out x -7.288321 
out x -7.288321 

Note: x < 1 domain error is handled in the called functions.

@tiehuis wrote in https://codeberg.org/ziglang/zig/pulls/35616#issuecomment-16530128: > I don't think this is the fix we want here. > > Specifically, I expect the `x < 1.0` case to be handled in the first branch: > > ```text > return math.log1p(x - 1 + @sqrt((x - 1) * (x - 1) + 2 * (x - 1))); > ``` > > This handles the cases implicitly by the behaviour of log1p and sqrt. Either the argument to sqrt will be negative (`-1 < x < 1`), or the argument to `log1p` will be negative (`x < -1`) ), as x will grow faster relative to `sqrt` argument in all other cases. Both of which will propagate a nan through as the acosh return value. > > If you run these tests against master, we can see that `f32` already produces the correct values according to the tests, suggesting that only `acosh64` is an issue. > > Based on your debugging, perhaps look at why the second branch is being taken for these negative instead of the first (which should handle the domain issue). Notably the exponent check differs a little. > > See also upstream musl which this code was derived from: https://git.musl-libc.org/cgit/musl/tree/src/math/acosh.c Yes, the `acosh32` is working properly. But I think, `musl c` code also not working. ```c #include <stdio.h> #include <math.h> #include <stdint.h> double acosh(double x) { union {double f; uint64_t i;} u = {.f = x}; unsigned e = u.i >> 52 & 0x7ff; /* x < 1 domain error is handled in the called functions */ if (e < 0x3ff + 1) /* |x| < 2, up to 2ulp error in [1,1.125] */ return log1p(x-1 + sqrt((x-1)*(x-1)+2*(x-1))); if (e < 0x3ff + 26) /* |x| < 0x1p26 */ return log(2*x - 1/(x+sqrt(x*x-1))); /* |x| >= 0x1p26 or nan */ return log(x) + 0.693147180559945309417232121458176568; } int main(){ double x = -1.9e4; double z = acosh(x); printf("out x %f \n", z); double y = -2e4; double k = acosh(x); printf("out x %f \n", k); } ``` Out ```bash gcc z.c && ./a.out out x -7.288321 out x -7.288321 ``` Note: x < 1 domain error is handled in the called functions.
math: fix acosh for x < 1 (including negative inputs)
Some checks failed
ci / aarch64-freebsd-debug (pull_request) Has been cancelled
ci / aarch64-freebsd-release (pull_request) Has been cancelled
ci / aarch64-linux-debug (pull_request) Has been cancelled
ci / aarch64-linux-release (pull_request) Has been cancelled
ci / aarch64-netbsd-debug (pull_request) Has been cancelled
ci / aarch64-netbsd-release (pull_request) Has been cancelled
ci / loongarch64-linux-debug (pull_request) Has been cancelled
ci / loongarch64-linux-release (pull_request) Has been cancelled
ci / powerpc64le-linux-debug (pull_request) Has been cancelled
ci / powerpc64le-linux-release (pull_request) Has been cancelled
ci / riscv64-linux-debug (pull_request) Has been cancelled
ci / riscv64-linux-release (pull_request) Has been cancelled
ci / s390x-linux-debug (pull_request) Has been cancelled
ci / s390x-linux-release (pull_request) Has been cancelled
ci / x86_64-freebsd-debug (pull_request) Has been cancelled
ci / x86_64-freebsd-release (pull_request) Has been cancelled
ci / x86_64-linux-debug (pull_request) Has been cancelled
ci / x86_64-linux-debug-llvm (pull_request) Has been cancelled
ci / x86_64-linux-release (pull_request) Has been cancelled
ci / x86_64-netbsd-debug (pull_request) Has been cancelled
ci / x86_64-netbsd-release (pull_request) Has been cancelled
ci / x86_64-openbsd-debug (pull_request) Has been cancelled
ci / x86_64-openbsd-release (pull_request) Has been cancelled
ci / x86_64-windows-debug (pull_request) Has been cancelled
ci / x86_64-windows-release (pull_request) Has been cancelled
ci / aarch64-macos-release (pull_request) Has been cancelled
ci / aarch64-macos-debug (pull_request) Has been cancelled
e90b3bfd4f
math: fix acosh for x < 1 (including negative inputs)
Some checks failed
ci / aarch64-macos-release (pull_request) Failing after 41m39s
ci / x86_64-netbsd-release (pull_request) Failing after 30m37s
ci / x86_64-freebsd-release (pull_request) Failing after 39m49s
ci / aarch64-macos-debug (pull_request) Failing after 1h32m21s
ci / x86_64-freebsd-debug (pull_request) Failing after 44m21s
ci / x86_64-netbsd-debug (pull_request) Failing after 40m25s
ci / aarch64-linux-release (pull_request) Failing after 1h18m10s
ci / aarch64-linux-debug (pull_request) Failing after 1h51m0s
ci / x86_64-openbsd-release (pull_request) Failing after 45m44s
ci / x86_64-openbsd-debug (pull_request) Failing after 1h2m15s
ci / powerpc64le-linux-release (pull_request) Failing after 1h55m44s
ci / powerpc64le-linux-debug (pull_request) Failing after 2h48m46s
ci / x86_64-windows-release (pull_request) Failing after 1h14m27s
ci / x86_64-linux-debug (pull_request) Failing after 49m16s
ci / x86_64-windows-debug (pull_request) Failing after 1h26m46s
ci / s390x-linux-release (pull_request) Failing after 1h10m46s
ci / s390x-linux-debug (pull_request) Failing after 2h36m21s
ci / x86_64-linux-release (pull_request) Failing after 3h14m53s
ci / x86_64-linux-debug-llvm (pull_request) Failing after 3h46m53s
ci / aarch64-freebsd-debug (pull_request) Has been cancelled
ci / aarch64-freebsd-release (pull_request) Has been cancelled
ci / aarch64-netbsd-debug (pull_request) Has been cancelled
ci / aarch64-netbsd-release (pull_request) Has been cancelled
ci / loongarch64-linux-debug (pull_request) Has been cancelled
ci / loongarch64-linux-release (pull_request) Has been cancelled
ci / riscv64-linux-debug (pull_request) Has been cancelled
ci / riscv64-linux-release (pull_request) Has been cancelled
eb87e0f45a
math: fix acosh for x < 1 (including negative inputs)
All checks were successful
ci / aarch64-macos-release (pull_request) Successful in 49m27s
ci / x86_64-netbsd-release (pull_request) Successful in 59m16s
ci / x86_64-freebsd-release (pull_request) Successful in 1h4m20s
ci / x86_64-freebsd-debug (pull_request) Successful in 1h6m40s
ci / x86_64-linux-debug (pull_request) Successful in 1h8m41s
ci / x86_64-netbsd-debug (pull_request) Successful in 1h13m47s
ci / x86_64-openbsd-debug (pull_request) Successful in 1h17m50s
ci / x86_64-openbsd-release (pull_request) Successful in 1h8m27s
ci / s390x-linux-release (pull_request) Successful in 1h27m13s
ci / aarch64-linux-release (pull_request) Successful in 1h32m57s
ci / x86_64-windows-debug (pull_request) Successful in 1h27m11s
ci / x86_64-windows-release (pull_request) Successful in 1h28m10s
ci / aarch64-macos-debug (pull_request) Successful in 1h59m11s
ci / powerpc64le-linux-release (pull_request) Successful in 1h59m58s
ci / aarch64-linux-debug (pull_request) Successful in 2h23m43s
ci / s390x-linux-debug (pull_request) Successful in 2h42m18s
ci / x86_64-linux-release (pull_request) Successful in 3h19m34s
ci / x86_64-linux-debug-llvm (pull_request) Successful in 3h59m47s
ci / powerpc64le-linux-debug (pull_request) Successful in 5h14m59s
ci / loongarch64-linux-release (pull_request) Successful in 2h2m0s
ci / loongarch64-linux-debug (pull_request) Successful in 3h30m6s
ci / aarch64-freebsd-debug (pull_request) Has been skipped
ci / aarch64-freebsd-release (pull_request) Has been skipped
ci / aarch64-netbsd-debug (pull_request) Has been skipped
ci / aarch64-netbsd-release (pull_request) Has been skipped
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
8be54d5dac
First-time contributor
Copy link

Given we are have some inherent issues with the implementation's accuracy itself, I would be keen to replace the implementation and check that against the libc-test you've got set up. We would feel a bit more confident in the results instead of just handling the 0 case here. This would also help your other pr and we could enable the tests in that PR.

The FreeBSD implementation suggested in the issue is worth a first look.

Given we are have some inherent issues with the implementation's accuracy itself, I would be keen to replace the implementation and check that against the libc-test you've got set up. We would feel a bit more confident in the results instead of just handling the 0 case here. This would also help your other pr and we could enable the tests in that PR. The FreeBSD implementation suggested in the issue is worth a first look.
Fixed acosh -ve value issue
All checks were successful
ci / x86_64-netbsd-release (pull_request) Successful in 44m32s
ci / x86_64-freebsd-debug (pull_request) Successful in 45m18s
ci / x86_64-freebsd-release (pull_request) Successful in 46m47s
ci / x86_64-netbsd-debug (pull_request) Successful in 48m33s
ci / x86_64-openbsd-release (pull_request) Successful in 49m1s
ci / x86_64-windows-release (pull_request) Successful in 52m27s
ci / x86_64-openbsd-debug (pull_request) Successful in 55m23s
ci / aarch64-macos-release (pull_request) Successful in 58m12s
ci / x86_64-windows-debug (pull_request) Successful in 59m29s
ci / aarch64-macos-debug (pull_request) Successful in 1h13m13s
ci / aarch64-linux-release (pull_request) Successful in 1h27m39s
ci / x86_64-linux-debug (pull_request) Successful in 1h28m31s
ci / s390x-linux-release (pull_request) Successful in 1h39m33s
ci / s390x-linux-debug (pull_request) Successful in 2h27m41s
ci / x86_64-linux-release (pull_request) Successful in 2h44m43s
ci / aarch64-linux-debug (pull_request) Successful in 2h52m29s
ci / x86_64-linux-debug-llvm (pull_request) Successful in 3h20m46s
ci / powerpc64le-linux-release (pull_request) Successful in 3h31m7s
ci / powerpc64le-linux-debug (pull_request) Successful in 4h38m35s
ci / loongarch64-linux-release (pull_request) Successful in 2h24m46s
ci / loongarch64-linux-debug (pull_request) Successful in 3h40m12s
ci / aarch64-freebsd-debug (pull_request) Has been skipped
ci / aarch64-freebsd-release (pull_request) Has been skipped
ci / aarch64-netbsd-debug (pull_request) Has been skipped
ci / aarch64-netbsd-release (pull_request) Has been skipped
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
6fbedd9cd7
Author
Contributor
Copy link

Thank you. I changed it based on FreeBSD.

Thank you. I changed it based on FreeBSD.
All checks were successful
ci / x86_64-netbsd-release (pull_request) Successful in 44m32s
Required
Details
ci / x86_64-freebsd-debug (pull_request) Successful in 45m18s
Required
Details
ci / x86_64-freebsd-release (pull_request) Successful in 46m47s
Required
Details
ci / x86_64-netbsd-debug (pull_request) Successful in 48m33s
Required
Details
ci / x86_64-openbsd-release (pull_request) Successful in 49m1s
Required
Details
ci / x86_64-windows-release (pull_request) Successful in 52m27s
Required
Details
ci / x86_64-openbsd-debug (pull_request) Successful in 55m23s
Required
Details
ci / aarch64-macos-release (pull_request) Successful in 58m12s
Required
Details
ci / x86_64-windows-debug (pull_request) Successful in 59m29s
Required
Details
ci / aarch64-macos-debug (pull_request) Successful in 1h13m13s
Required
Details
ci / aarch64-linux-release (pull_request) Successful in 1h27m39s
Required
Details
ci / x86_64-linux-debug (pull_request) Successful in 1h28m31s
Required
Details
ci / s390x-linux-release (pull_request) Successful in 1h39m33s
Required
Details
ci / s390x-linux-debug (pull_request) Successful in 2h27m41s
Required
Details
ci / x86_64-linux-release (pull_request) Successful in 2h44m43s
Required
Details
ci / aarch64-linux-debug (pull_request) Successful in 2h52m29s
Required
Details
ci / x86_64-linux-debug-llvm (pull_request) Successful in 3h20m46s
Required
Details
ci / powerpc64le-linux-release (pull_request) Successful in 3h31m7s
Required
Details
ci / powerpc64le-linux-debug (pull_request) Successful in 4h38m35s
Required
Details
ci / loongarch64-linux-release (pull_request) Successful in 2h24m46s
ci / loongarch64-linux-debug (pull_request) Successful in 3h40m12s
ci / aarch64-freebsd-debug (pull_request) Has been skipped
ci / aarch64-freebsd-release (pull_request) Has been skipped
ci / aarch64-netbsd-debug (pull_request) Has been skipped
ci / aarch64-netbsd-release (pull_request) Has been skipped
ci / riscv64-linux-debug (pull_request) Has been skipped
ci / riscv64-linux-release (pull_request) Has been skipped
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u acosh-1:arshidkv12-acosh-1
git switch arshidkv12-acosh-1
Sign in to join this conversation.
No reviewers
Labels
Clear labels
abi/f32
abi/ilp32
abi/sf
accepted
This proposal is planned.
arch/21k
arch/6502
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/bfin
arch/bpf
arch/colossus
arch/cris
arch/csky
arch/dlx
arch/epiphany
arch/fr30
arch/frv
arch/hexagon
arch/hppa
arch/hppa64
arch/ia64
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/mcore
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/ns32k
arch/nvptx
arch/or1k
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390x
arch/sh
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/tricore
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/x86
arch/x86_64
arch/xcore
arch/xtensa
autodoc
The web application for interactive documentation and generation of its assets.
backend/c
The C backend outputs C source code.
backend/llvm
The LLVM backend outputs an LLVM bitcode module.
backend/self-hosted
The self-hosted backends produce machine code directly.
binutils
Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.
breaking
Implementing this issue could cause existing code to no longer compile or have different behavior.
build system
The Zig build system - zig build, std.Build, the build runner, and package management.
debug info
An issue related to debug information (e.g. DWARF) produced by the Zig compiler.
docs
An issue with documentation, e.g. the language reference or standard library doc comments.
error message
This issue points out an error message that is unhelpful and should be improved.
frontend
Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.
fuzzing
An issue related to Zig's integrated fuzz testing.
incremental
Reuse of internal compiler state for faster compilation.
lib/c
This issue relates to Zig's libc implementation and/or vendored libcs.
lib/compiler-rt
This issue relates to Zig's compiler-rt library.
lib/cxx
This issue relates to Zig's vendored libc++ and/or libc++abi.
lib/std
This issue relates to Zig's standard library.
lib/tsan
This issue relates to Zig's vendored libtsan.
lib/ubsan-rt
This issue relates to Zig's ubsan-rt library.
lib/unwind
This issue relates to Zig's vendored libunwind.
linking
Zig's integrated object file and incremental linker.
miscompilation
The compiler reports success but produces semantically incorrect code.
os/android
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/tvos
os/uefi
os/visionos
os/wasi
os/watchos
os/windows
proposal
This issue suggests language modifications. If it also has the "accepted" label then it is planned.
release notes
This issue or pull request should be mentioned in the release notes.
testing
This issue is related to testing the compiler, standard library, or other parts of Zig.
zig cc
Zig as a drop-in C-family compiler.
zig fmt
The Zig source code formatter.
zig reduce
The Zig source code reduction tool.
bounty
https://ziglang.org/news/announcing-donor-bounties
bug
Observed behavior contradicts documented or intended behavior.
contributor-friendly
This issue is limited in scope and/or knowledge of project internals.
downstream
An issue with a third-party project that uses this project.
enhancement
Solving this issue will likely involve adding new logic or components to the codebase.
infra
An issue related to project infrastructure, e.g. continuous integration.
optimization
A task to improve performance and/or resource usage.
question
No questions on the issue tracker; use a community space instead.
regression
Something that used to work in a previous version stopped working
upstream
An issue with a third-party project that this project uses.
use case
Describes a real use case that is difficult or impossible, but does not propose a solution.
No labels
abi/f32
abi/ilp32
abi/sf
accepted
arch/21k
arch/6502
arch/aarch64
arch/alpha
arch/amdgcn
arch/arc
arch/arc32
arch/arc64
arch/arm
arch/avr
arch/bfin
arch/bpf
arch/colossus
arch/cris
arch/csky
arch/dlx
arch/epiphany
arch/fr30
arch/frv
arch/hexagon
arch/hppa
arch/hppa64
arch/ia64
arch/kalimba
arch/kvx
arch/lanai
arch/lm32
arch/loongarch32
arch/loongarch64
arch/m32r
arch/m68k
arch/m88k
arch/mcore
arch/microblaze
arch/mips
arch/mips64
arch/mmix
arch/moxie
arch/mrisc32
arch/msp430
arch/nds32
arch/ns32k
arch/nvptx
arch/or1k
arch/powerpc
arch/powerpc64
arch/propeller
arch/riscv32
arch/riscv64
arch/rl78
arch/rx
arch/s390x
arch/sh
arch/sparc
arch/sparc64
arch/spirv
arch/spu
arch/tricore
arch/v850
arch/vax
arch/vc4
arch/ve
arch/wasm
arch/x86
arch/x86_64
arch/xcore
arch/xtensa
autodoc
backend/c
backend/llvm
backend/self-hosted
binutils
breaking
build system
debug info
docs
error message
frontend
fuzzing
incremental
lib/c
lib/compiler-rt
lib/cxx
lib/std
lib/tsan
lib/ubsan-rt
lib/unwind
linking
miscompilation
os/android
os/contiki
os/dragonfly
os/driverkit
os/emscripten
os/freebsd
os/fuchsia
os/haiku
os/hermit
os/hurd
os/illumos
os/ios
os/linux
os/maccatalyst
os/macos
os/managarm
os/netbsd
os/ohos
os/openbsd
os/plan9
os/redox
os/rtems
os/serenity
os/tvos
os/uefi
os/visionos
os/wasi
os/watchos
os/windows
proposal
release notes
testing
zig cc
zig fmt
zig reduce
bounty
bug
contributor-friendly
downstream
enhancement
infra
optimization
question
regression
upstream
use case
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ziglang/zig!35616
Reference in a new issue
ziglang/zig
No description provided.
Delete branch "arshidkv12/zig:acosh-1"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?