Bug 1000991 - fmaf() function get a wrong rounded result
fmaf() function get a wrong rounded result
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc (Show other bugs)
6.4
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Patsy Franklin
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-26 05:25 EDT by Dmitry
Modified: 2016-11-24 10:56 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-16 14:36:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test example and Makefile (769 bytes, application/x-rar)
2013-08-26 05:25 EDT, Dmitry
no flags Details

  None (edit)
Description Dmitry 2013-08-26 05:25:32 EDT
Created attachment 790358 [details]
test example and Makefile

Description of problem:
fmaf() function get a wrong rounded result when arguments are passed through variables
There are three variants.
First. Arguments are passed to fmaf() by pointers referenced to floating point single precision numbers placed in int32 type variables (0x007ffffa, 0x4ea00000, 0x00000001) 
The result is wrong and equal 0x0f9ffff8.
Second. 
Arguments are passed to fmaf() by pointers referenced to floating point single precision numbers placed in float type variables (a=0x0.fffff4p-126, b=0x1.400000p30, c=0x0.000002p-126). The result is also wrong and equal 0x0f9ffff8.
Third.
Floating point numbers are passed as immediate values(0x0.fffff4p-126, 0x1.400000p30, 0x0.000002p-126). Result is correct and equal 0x0f9ffff9.
The difference between wrong and correct results is one ulp.

Version-Release number of selected component (if applicable):
glibc version 2.12, gnu_get_libc_version()
Red Hat Enterprise Linux 6.4

How reproducible:
make -f Makefile_bug
main_bug

Steps to Reproduce:
1.
2.
3.

Actual results:
0x0f9ffff8

Expected results:
0x0f9ffff9

Additional info:
Comment 2 Dmitry 2013-08-30 10:36:22 EDT
Carlos, are you going to look at the bug?
Comment 3 Carlos O'Donell 2013-09-02 11:35:20 EDT
Dmitry,

Thanks for submitting this bug.

Your example is unfortunately illegal since it violates ISO C strict aliasing. For example you assign a pointer to int/unsigned int and float to the same address, all of this needs to be done through unions to be safe. Please make sure that `-Wall -pedantic' don't produce any errors when you compile.

To learn more about strict aliasing please read:
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

One of our developers looked into this and I'll let her update the issue.

We are not going to include this in rhel-6.5, but we may consider it for rhel-6.6.
Comment 5 Patsy Franklin 2013-09-16 11:04:29 EDT
Dmitry,

I was able to confirm that your test program produces the correct results on a RHEL 6.5 system with FMA support.

I will be closing this bug report.

Please reopen this bug report if you continue to see incorrect results on RHEL 6.5.

Thank You,
Patsy

Note You need to log in before you can comment on or make changes to this bug.