| Summary: | Data corruption for returned from function long double | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Petr Ovtchenkov <abominable-snowman> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | njn |
| Priority: | NOR | ||
| Version: | 3.5 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Problem illustration | ||
Intel machines support 96-bit floats? I thought they only went up to 80 bits. And Valgrind only supports up to 64-bits. Are you sure it's not the 80 vs 64 issue you are seeing? (In reply to comment #1) > Are you sure it's not the 80 vs 64 issue you are seeing? If it is, this should be marked as a dup of bug 197915. > I thought they only went up to 80 bits. Yes. This is 'long double' in C (gcc). But it stored in 12 bytes (or 16 bytes for 64-bit addressing), not in 10, due to alignment issue. See also http://en.wikipedia.org/wiki/Extended_precision and http://en.wikipedia.org/wiki/Long_double > And Valgrind only supports up to 64-bits. > Are you sure it's not the 80 vs 64 issue you are seeing? See attachment: sample how to reproduce problem. > If it is, this should be marked as a dup of bug 197915. Looks like it mean the same issue. Well, bug 197915 is a duplicate of this bug ;), see report date. Here simple test present (attached to this ticket), for clear reference. > (bug 197915) ... programs that rely on 80-bit precision are not portable. What about C99, where 'long double' present? Or you mean that 80-bit float not conform to IEEE 754-1985/IEEE 754-2008? I know this bug predates bug 197915, but I'm marking this as a duplicate because that's the tracking bug we're using for this problem. *** This bug has been marked as a duplicate of bug 197915 *** |
Created attachment 32665 [details] Problem illustration Linux localhost 2.6.27.18 #1 SMP Thu Feb 19 22:58:17 MSK 2009 i686 i686 i386 GNU/Linux (glibc 2.7) valgrind-3.5 SVN trunk (r9408). gcc 4.2.4. For 96-bit float (extended precision, long double for GCC) on Intel platform functions that return long double, fill only 80 bits. This not a problem, because last 16 bit not used in this long double format. But under valgrind returned data filled with zeroes and report about error. For attached test: ==23432== Memcheck, a memory error detector. ==23432== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==23432== Using LibVEX rev 1885, a library for dynamic binary translation. ==23432== Copyright (C) 2004-2009, and GNU GPL'd, by OpenWorks LLP. ==23432== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework. ==23432== Copyright (C) 2000-2009, and GNU GPL'd, by Julian Seward et al. ==23432== For more details, rerun with: -v ==23432== ==23432== Use of uninitialised value of size 4 ==23432== at 0x4093EF1: _itoa_word (in /lib/libc-2.7.so) ==23432== by 0x4095E29: vfprintf (in /lib/libc-2.7.so) ==23432== by 0x409DF92: printf (in /lib/libc-2.7.so) ==23432== by 0x8048447: main (test.c:23) ==23432== ==23432== Conditional jump or move depends on uninitialised value(s) ==23432== at 0x4093EF7: _itoa_word (in /lib/libc-2.7.so) ==23432== by 0x4095E29: vfprintf (in /lib/libc-2.7.so) ==23432== by 0x409DF92: printf (in /lib/libc-2.7.so) ==23432== by 0x8048447: main (test.c:23) ==23432== ==23432== Conditional jump or move depends on uninitialised value(s) ==23432== at 0x4095B4D: vfprintf (in /lib/libc-2.7.so) ==23432== by 0x409DF92: printf (in /lib/libc-2.7.so) ==23432== by 0x8048447: main (test.c:23) 00000000000000000000a4be ==23432== ==23432== ERROR SUMMARY: 8 errors from 3 contexts (suppressed: 15 from 1) ==23432== malloc/free: in use at exit: 0 bytes in 0 blocks. ==23432== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==23432== For counts of detected errors, rerun with: -v ==23432== Use --track-origins=yes to see where uninitialised values come from ==23432== All heap blocks were freed -- no leaks are possible. But without valgrind it print something like 00000000000000800100d5bf as expected (last four digits may vary, of cause --- it uninitialized).