Bug 1255135
| Summary: | Fix handling of float literals in assembler output | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Richard W.M. Jones <rjones> | ||||||
| Component: | ocaml | Assignee: | Richard W.M. Jones <rjones> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-tools-bugs | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 7.2 | CC: | rdossant, vkadlcik | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-08-20 13:56:55 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1071880, 1051573, 1252074 | ||||||||
| Attachments: |
|
||||||||
|
Description
Richard W.M. Jones
2015-08-19 17:56:01 UTC
Created attachment 1064963 [details]
0001-ppc64-ppc64le-Fix-handling-of-float-literals.patch
Created attachment 1065017 [details]
float_bits.ml
Steps to reproduce and verify this bug:
(1) Download the attachment float_bits.ml
(2) Compile it using the native code compiler:
ocamlopt float_bits.ml -o float_bits
(3) Run the binary:
./float_bits
(4) Buggy output is [bug is reproduced]:
read_bits_from_constant: 3ff0060504033f5a ERROR
read_bits_from_string: 3ff0060504030201 OK
(5) Correct output is [bug fix is verified]:
read_bits_from_constant: 3ff0060504030201 OK
read_bits_from_string: 3ff0060504030201 OK
I probably should have tested these myself before filing the bugs, but it appears that RHEL versions of OCaml are *not* affected. I tested: ocaml-4.01.0-22.2.el7.ppc64 ocaml-4.01.0-22.2.ael7b.ppc64le using the procedure in comment 2 and could not reproduce the problem. So probably we're not affected by this bug as we were in Fedora. (In reply to Richard W.M. Jones from comment #3) > I probably should have tested these myself before filing the bugs, > but it appears that RHEL versions of OCaml are *not* affected. > > I tested: > > ocaml-4.01.0-22.2.el7.ppc64 > ocaml-4.01.0-22.2.ael7b.ppc64le > > using the procedure in comment 2 and could not reproduce the problem. > > So probably we're not affected by this bug as we were in Fedora. RHEL RPMs are not affected, definitely. I verified 4.01.0-22.6 (present in RHBA-2015:20374) on x86_64, ppc64, and ppc64le [1]. Results from aarch64 aren't there yet due to shortage of test machines but I suppose just ppc64* are interesting here. I think we can close it as invalid or so... [1] https://beaker.engineering.redhat.com/jobs/1055590 But Fedora is still affected, right? Maybe we could just change the product to Fedora instead. (In reply to Václav Kadlčík from comment #4) > (In reply to Richard W.M. Jones from comment #3) > > I probably should have tested these myself before filing the bugs, > > but it appears that RHEL versions of OCaml are *not* affected. > > > > I tested: > > > > ocaml-4.01.0-22.2.el7.ppc64 > > ocaml-4.01.0-22.2.ael7b.ppc64le > > > > using the procedure in comment 2 and could not reproduce the problem. > > > > So probably we're not affected by this bug as we were in Fedora. > > > RHEL RPMs are not affected, definitely. I verified 4.01.0-22.6 (present in > RHBA-2015:20374) on x86_64, ppc64, and ppc64le [1]. Results from aarch64 > aren't there yet due to shortage of test machines but I suppose just ppc64* > are interesting here. > > I think we can close it as invalid or so... > > [1] https://beaker.engineering.redhat.com/jobs/1055590 Yup, good to have that confirmed, so I'm closing the BZ. (In reply to Rafael Fonseca from comment #5) > But Fedora is still affected, right? Maybe we could just change the product > to Fedora instead. It is, but I'm going to switch Fedora to use the new upstream combined-ppc code generator (https://github.com/ocaml/ocaml/pull/225) which is known to not suffer from this problem. |