https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115477
Bug ID: 115477 Summary: compiling with gcc flips the sign of a float return value Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: s00na at protonmail dot com Target Milestone: --- ############## Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/14.1.0/lto-wrapper Target: x86_64-linux-gnu Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu --disable-multilib --enable-languages=c,c++,fortran,go Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.1.0 (GCC) ############## A little context. I was playing around with the fast inverse square root algorithm (https://en.wikipedia.org/wiki/Fast_inverse_square_root) and found that compiling my own version of it returns the correct answer, but with the wrong sign. I ecountered this behavior first on my archlinux system with gcc 14.1.1. To verify that it wasn't anything wrong with my setup I also spun up docker containers for the latest versions of ubuntu, arch, gcc itself and alpine. It happened on all of these except for the alpine container (gcc 13.2.1). Using clang to compile produces the correct/expected result except for the gcc container where clang also produces the wrong result. In all cases I compiled with: gcc test.c and ran the resulting file with: ./a.out The expected result is: 0.447141 0.447141 The actual result with gcc is: 0.447141 -0.447141 Below is the code that produces the error. test.c: #include <stdio.h> float bug(float number) { long i; float y = number; i = * ( long * ) &y; i = 0x5f3759df - ( i >> 1 ); y = * ( float * ) &i; return (1.5F * y) + (-0.5F * number * y * y * y); } int main() { const float test = 5; printf("%f\n",bug(test)); printf("%f\n",bug(test)); return 0; }