A commit causes cl-denorms-are-zero is added to char_rtn_float test where gForceFTZ is false.

[haonanya]

The change https://github.com/KhronosGroup/OpenCL-CTS/blob/main/test_conformance/conversions/basic_test_conversions.cpp#L1543 is from https://github.com/KhronosGroup/OpenCL-CTS/commit/b6941b6c61137b95bfe652ec1c0294f6f17be361. Without the commit cl-denorms-are-zero is not added for char_rtn_float test. With the commit for char_rtn_float test gForceFTZ is false and gForceHalfFTZ is true and then cl-denorms-are-zero is added.

opencl test is like: convert_char_rtn(-0x1.fffffcp-127)

adding the cl-denorms-are-zero option causes output is 0, while host expects -1. opencl spec doesn't explicitly mention flush to zero for input or output or both. There are no cl-denorms-are-zero for cc1 options since https://github.com/llvm/llvm-project/commit/a4451d88ee456304c. Currently intel opencl-clang treats cl-denorms-are-zero as https://github.com/intel/opencl-clang/blob/main/options_compile.cpp#L106 which means flush to zero for input and output https://github.com/llvm/llvm-project/blob/main/llvm/docs/LangRef.rst#L2424. opencl spec mention that This is intended to be a performance hint and the OpenCL compiler can choose not to flush denorms to zero if the device supports single precision (or double precision) denormalized numbers. But this is not very same as denormal-fp-math which say If the input mode is "preserve-sign", or "positive-zero", a floating-point operation must treat any input denormal value as zero. @bashbaug , @svenvh , do you have any comments for this? Thanks very much.