This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

c/1098: inconsisten fp behavior i386 vs. most others



>Number:         1098
>Category:       c
>Synopsis:       inconsisten fp behavior i386 vs. most others
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 19 16:06:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     brian j. green
>Release:        egcs-2.91.66
>Organization:
>Environment:
i386-redhat-linux
>Description:
On most systems ( alpha, mips for example ) floating
point binary operations are performed at the
highest precision of the operands.  For example,
a float * float is performed at 32 bits.  On i386,
the precision of the operands is ignored and the
operation is performed according to the current
setting of the control word.  This makes it extremely
difficult to create exact matches within programs
that use both float and double types.

A compiler option that forces operation precision
to match the highest precision of the operands
would be very helpful.
>How-To-Repeat:
On alpha or mips systems the attached test program
should produce the following output:

0x3d733334
0x3d733333


the first number is the correct 32 bit answer,
the second is the correct 64 bit answer.

on i386 the output will be:

0x3d733333
0x3d733333

I.e. the operation is performed according to the
setting of the control word.

Setting the control word to single precision will
produce the single precision answer in both cases
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="test.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.c"

I2luY2x1ZGUgPHN0ZGlvLmg+Cgp2b2lkIHRvZih1bnNpZ25lZCBpbnQgYml0cywgZmxvYXQqIHJW
YWwpIHsKICBtZW1jcHkoclZhbCwgJmJpdHMsIHNpemVvZihmbG9hdCkpOwp9CgppbnQgbWFpbigp
IHsKICBmbG9hdCBBLCBCLCBDLCBELCBhbnM7CiAgdG9mKDB4YmQ4MDAwMDAsJkEpOyAvKiAtMC4w
NjI1ICovCiAgdG9mKDB4YmRjMjhmNWMsJkIpOyAvKiAtMC4wOTQ5OTk5OTg4MDc5MDcxMDQ0OTIx
ODc1ICovCiAgdG9mKDB4M2YxMDAwMDAsJkMpOyAvKiAwLjU2MjUgKi8KICB0b2YoMHgzZGMyOGY1
YywmRCk7IC8qIDAuMDk0OTk5OTk4ODA3OTA3MTA0NDkyMTg3NSAqLwogIGFucyA9IEEgKiBCICsg
QyAqIEQ7CiAgcHJpbnRmKCIweCV4XG4iLCAqKHVuc2lnbmVkIGludCopJmFucyk7CiAgYW5zID0g
KGRvdWJsZSkgQSAqIEIgKyAoZG91YmxlKSBDICogRDsKICBwcmludGYoIjB4JXhcbiIsICoodW5z
aWduZWQgaW50KikmYW5zKTsKfQo=

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]