The following code leads to segmentation fault with the current git version of GNU libc (and that is the case at least from 2.15). #include <math.h> #include <fenv.h> int main() { double x = 2.8532681940591602; fesetround(FE_UPWARD); pow(x, 4); }
I forgot to include the output of uname -a: Linux auxerrois 3.2.0-36-generic #57-Ubuntu SMP Tue Jan 8 21:44:52 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Are you sure you've run the new binary with the new libc (by linking with appropriate -Wl,-dynamic-linker -Wl,-rpath options, for example, or running via /some/where/lib64/ld-linux-x86-64.so.2 --library-path /some/where/lib64, or using -static to link)? I can't reproduce this with current sources; it sounds like a duplicate of bug 3976 (fixed) to me.
The preferred way to run against an uninstalled build tree is to use testrun.sh.
Indeed, I am sorry: I forgot the -static option and ld did not choose the uninstalled glibc version. Compiling with CPATH=$GLIBCGIT/include gcc --verbose -c -o test.o test.c and linking with LIBRARY_PATH=$GLIBCGIT/lib gcc --verbose -static -o test test.o leads to an executable which - exits with status 158 on Linux 3.2.0-36-generic x86_64, Ubuntu 12.04.1 LTS, Intel(R) Xeon(R) CPU E5-1620 - exits with status 158 on Linux 2.6.32-44-generic x86_64, Ubuntu 10.04.4 LTS, Intel(R) Core(TM)2 Quad CPU Q9550 - exits with success (status 0) Linux 2.6.32-5-amd64, Debian 6.0.7. while the code associated to the bug 3976 works correctly on all these computers when compiled with this glibc version.
Thierry, your last statement is confusing since you did not mention the glibc versions. Am I correct that this is fixed in current git? In that case, let's resolve this bug as WORKSFORME.
Oops. Yes, that was with the last glibc version, but it was just the "return 0;" that was missing... Thank you, I was just confused and this bug is already fixed. I am sorry for the noise!
Resolved.