Bug #26914 type_float test fails: Intel icc on ia64 does not support 1e-308
Submitted: 7 Mar 2007 11:01 Modified: 20 Apr 2007 7:01
Reporter: Daniel Fischer Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Tests Severity:S3 (Non-critical)
Version:5.0.37 and up OS:Linux (Linux IA64)
Assigned to: Daniel Fischer CPU Architecture:Any

[7 Mar 2007 11:01] Daniel Fischer
Description:
The type_float test case fails on Linux IA64, mysql built with icc.

type_float                     [ fail ]  
           
Errors are (from /PATH/mysqltest-time) :
mysqltest: Result length mismatch
(the last lines may be the most important ones)
Below are the diffs between actual and expected results:
-------------------------------------------------------
*** r/type_float.result
--- r/type_float.reject
***************
*** 264,270
  drop table t1,t2,t3;
  select 1e-308, 1.00000001e-300, 100000000e-300;
  1e-308        1.00000001e-300 100000000e-300
! 1e-308        1.00000001e-300 1e-292
  select 10e307;
  10e307
  1e+308
--- 264,270
  drop table t1,t2,t3;
  select 1e-308, 1.00000001e-300, 100000000e-300;
  1e-308        1.00000001e-300 100000000e-300
! 0     1.00000001e-300 1e-292
  select 10e307;
  10e307
  1e+308
-------------------------------------------------------

How to repeat:
Build 5.0.37 on rx2620b and run test.
[9 Mar 2007 10:59] Sveta Smirnova
Thank you for the report.

I can not repeat it with current BK sources compiled with help of script BUILD/compile-amd64-debug-max Please provide configure options you used to compile.
[9 Mar 2007 13:19] Sveta Smirnova
Thank you for the report.

I can not repeat it with current bk sources.
[12 Mar 2007 11:23] Sveta Smirnova
I've just tried with mysql-5.0-community tree. Error still exists.
[22 Mar 2007 20:01] Joerg Bruehe
Error still present in 5.0.38.

Error is tightly coupled to using the Intel compiler on an IA64 CPU:
- it does not occur on any other CPU,
  even if using the Intel compiler (x86, x86_64);
- it does not occur with HP-UX on ia64, where we use the HP compiler.

It seems to be tied to the optimization level,
as it seems not to occur in the "debug" part of a tar.gz build.

According to our rules, I set this report to P1 as it is a test failure.
[10 Apr 2007 17:56] Alexey Kopytov
This is a duplicate of bug #22129.
[17 Apr 2007 13:33] Alexey Kopytov
The problem occurs when the source is complied by icc with -O3 *and* -mp. Decreasing the optimization level to -O2 and removing -mp give a binary which does not have this bug.
[17 Apr 2007 14:24] Alexey Kopytov
From the Intel documentation on icc command-line options:

"
-ftz

This option flushes denormal results to zero when the application is in the gradual
underflow mode. It may improve performance if the denormal values are not critical to
your application's behavior.
This option only has an effect when the main program is being compiled. It sets the FTZ
mode for the process. The initial thread and any threads subsequently created by that
process will operate in FTZ mode.
On ItaniumĀ®-based systems, optimization option O3 sets -ftz (Linux) or /Qftz
(Windows). Optimization option O2 sets the -no-ftz (Linux) or /Qftz- (Windows)
option.
If this option produces undesirable results of the numerical behavior of your program,
you can turn the FTZ mode off by using -no-ftz or /Qftz- in the command line while
still benefiting from the O3 optimizations.
"

The conclusion is that we should add "-no-ftz" to CFLAGS on Itanium systems in order to fix this bug.
[20 Apr 2007 7:01] Daniel Fischer
This will be fixed in future builds; we will be using -no-ftz for builds on this platform.
[25 Apr 2007 11:20] Joerg Bruehe
Fix was too late for 5.0.40, bug is still present there.
[7 Jan 2008 9:45] Kristian Nielsen
It seems the 'fix' for this bug was to manually use -no-ftz in certain builds?

I think that is the wrong fix. Instead, a ./configure check should be made for this bug and the work-around.

Ie. compile a small test program that displays the bug; if it fails compile it again with -no-ftz, and if that works (compile succeeds and the bug disappears), add -no-ftz to CFLAGS...

Well, I'll leave it up to Danny whether to reopen, but this seems a really poor solution, requiring everyone who build themselves to remember to add this option.