Bug 1255135 - Fix handling of float literals in assembler output
Fix handling of float literals in assembler output
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ocaml (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Richard W.M. Jones
qe-baseos-tools
:
Depends On:
Blocks: PPCTracker F-ExcludeArch-ppc64le/PPC64LETracker 1252074
  Show dependency treegraph
 
Reported: 2015-08-19 13:56 EDT by Richard W.M. Jones
Modified: 2016-11-29 05:00 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-20 09:56:55 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)
0001-ppc64-ppc64le-Fix-handling-of-float-literals.patch (1.87 KB, patch)
2015-08-19 13:58 EDT, Richard W.M. Jones
no flags Details | Diff
float_bits.ml (640 bytes, text/plain)
2015-08-19 17:46 EDT, Richard W.M. Jones
no flags Details

  None (edit)
Description Richard W.M. Jones 2015-08-19 13:56:01 EDT
Description of problem:

On both ppc64 and ppc64le, the way we handle float literals is
broken.  They are emitted as literals in the assembler output,
but truncated.  A simple reproducer and description of the problem
can be found here:

http://caml.inria.fr/mantis/view.php?id=6963

Version-Release number of selected component (if applicable):

ocaml-4.01.0-22.6.el7

How reproducible:

100%

Steps to Reproduce:
1. The reproducer can be found here:
http://caml.inria.fr/mantis/view.php?id=6963

Additional info:

I have a patch to fix this, coming shortly.
Comment 1 Richard W.M. Jones 2015-08-19 13:58:50 EDT
Created attachment 1064963 [details]
0001-ppc64-ppc64le-Fix-handling-of-float-literals.patch
Comment 2 Richard W.M. Jones 2015-08-19 17:46:10 EDT
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
Comment 3 Richard W.M. Jones 2015-08-19 20:41:35 EDT
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.
Comment 4 Václav Kadlčík 2015-08-20 09:03:25 EDT
(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
Comment 5 Rafael Fonseca 2015-08-20 09:10:41 EDT
But Fedora is still affected, right? Maybe we could just change the product to Fedora instead.
Comment 6 Richard W.M. Jones 2015-08-20 09:56:55 EDT
(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.

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