|
From: Dennis L. <pla...@tz...> - 2005-05-05 22:22:26
|
Hi, while trying and playing with valgrind3 from cvs I ran with emulation warnings enabled and encountered this message : ==18820== Emulation warning: unsupported action: ==18820== Selection of non-80-bit x87 FP precision What exactly does this mean ? Does valgrind/vex not yet support 32Bit floating point ? Will it ever ? greets Dennis PS: What further information do you need to resolve this error "m_debuglog.c:129:3: #error Unknown platform" ? (Im running on x86 linux...) -- Dennis Lubert <pla...@tz...> |
|
From: Julian S. <js...@ac...> - 2005-05-06 11:10:01
|
> while trying and playing with valgrind3 from cvs I ran with emulation > warnings enabled and encountered this message : > > ==18820== Emulation warning: unsupported action: > ==18820== Selection of non-80-bit x87 FP precision > > What exactly does this mean ? Does valgrind/vex not yet support 32Bit > floating point ? Will it ever ? Vex/valgrind-3 simulates the x87 FPU in much more detail than the 2.4 line. In order to reduce the complexity of this simulation, vex does all floating point at 64-bits (IEEE double) regardless of the FPU's control-word settings, but it "pretends" to the program to be running the FPU in its default 80-bit mode. I've tested this extensively on a large amount of FP code, and it appears that the differences between 64-bit and 80-bit precision are pretty minimal for real applications. For one thing, any program which actually relies on 80-bit precision to get the right answer is inherently unportable and will not work on (eg) PowerPC; nor will it work if recompiled on x86 to use SSE-based floating point. If, later in the day, the lack of genuine 80-bit FP support turns out to be a critical problem, then perhaps it can be added. Note that 80-bit loads/stores (fldt/fstpt) behave as you would expect, correctly reading/writing an 80-bit image. So, to answer your question, if your code is attempting to set the FPU's precision level to 64 or 32-bits, V ignores this and shows the above message. I don't believe this should cause you any problems in practice. > PS: What further information do you need to resolve this error > "m_debuglog.c:129:3: #error Unknown platform" ? (Im running on x86 > linux...) Uh, I don't see how you got that. Are your valgrind and vex trees up to date? One thing is, since both are works-in-progress, you really need to 'svn up' both of them at once and rebuild both. J |
Julian Seward wrote: > Vex/valgrind-3 simulates the x87 FPU in much more detail than > the 2.4 line. In order to reduce the complexity of this simulation, > vex does all floating point at 64-bits (IEEE double) regardless > of the FPU's control-word settings, but it "pretends" to the > program to be running the FPU in its default 80-bit mode. > > I've tested this extensively on a large amount of FP code, and it > appears that the differences between 64-bit and 80-bit precision > are pretty minimal for real applications. For one thing, > any program which actually relies on 80-bit precision to get > the right answer is inherently unportable and will not work on > (eg) PowerPC; nor will it work if recompiled on x86 to use > SSE-based floating point. Depends on what you call "real applications." Some serious engineering, analysis, chemistry+physics, and statistics codes won't work properly under such a vex/valgrind-3. Such codes care about precision, track it before+during+after the calculations, and make dynamic choices based on observed trends in numerical error. They will get a different answer under vex/valgrind-3, and execute different code while doing so. This will cause a very large "false negative" report from memcheck. IEEE double extended precision (C/gcc long double) also provides a larger exponent range than plain double, and this can be the most important reason for using long double; the extra precision may be "don't care." Some PowerPC compilers implement long double as two ordinary doubles, with a usual implied value of (hi + lo * 2**d) with d <= -53. Although this does not provide all of the expected benefits for IEEE arithmetic (no expanded exponent range, no strict adherence to rounding rules, confuses software that expects -53==d, ...), in many "real applications" it does provide enough additional precision to justify the costs. So there are important practical exceptions to the claim that x86 80-bit FP (expressed in C as long double) is not portable to PowerPC. -- John Reiser, jreiser@BitWagon.com |
|
From: Robert W. <rj...@du...> - 2005-05-06 21:08:24
|
> Depends on what you call "real applications." Some serious engineering, > analysis, chemistry+physics, and statistics codes won't work properly > under such a vex/valgrind-3. Such codes care about precision, track > it before+during+after the calculations, and make dynamic choices > based on observed trends in numerical error. They will get a different > answer under vex/valgrind-3, and execute different code while doing so. BLAS does this, and a lot of scientific codes use BLAS (and/or LAPACK, which is based on BLAS.) Regards, Robert. |
|
From: Patrick <pg...@et...> - 2006-07-19 14:10:28
|
I've also the same problem on an HP Proliant (Linux etbf125 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:00:54 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux): Emulation warning: unsupported action: Selection of non-80-bit x87 FP precision in an Oracle 10 library. at 0x7B21CC6: sslsetprec (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x7B9C6AD: slfpinit (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x7B9A7F2: lfpinit (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x70C9B13: kpuuini (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x70C8A09: kpuinit0 (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x70C9C7F: kpuinit (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x71666B3: OCIEnvInit (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x6FFC9A8: sqgctx (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x6FFC3CE: sqgrct (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x6FF8F92: sqlcmex (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) by 0x6FF95F3: sqlcxt (in /oracle/product/10.2.0/lib/libclntsh.so.10.1) My application runs correctly in the valgrind environment until it connects to the oracle database... Is a fix of valgrid required or are they are some magic parameters ? |