Bug 1255135 - Fix handling of float literals in assembler output
Summary: Fix handling of float literals in assembler output
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ocaml
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: qe-baseos-tools
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: PPCTracker F-ExcludeArch-ppc64le, PPC64LETracker 1252074
TreeView+ depends on / blocked
 
Reported: 2015-08-19 17:56 UTC by Richard W.M. Jones
Modified: 2016-11-29 10:00 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-08-20 13:56:55 UTC


Attachments (Terms of Use)
0001-ppc64-ppc64le-Fix-handling-of-float-literals.patch (1.87 KB, patch)
2015-08-19 17:58 UTC, Richard W.M. Jones
no flags Details | Diff
float_bits.ml (640 bytes, text/plain)
2015-08-19 21:46 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2015-08-19 17:56:01 UTC
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 17:58:50 UTC
Created attachment 1064963 [details]
0001-ppc64-ppc64le-Fix-handling-of-float-literals.patch

Comment 2 Richard W.M. Jones 2015-08-19 21:46:10 UTC
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-20 00:41:35 UTC
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 13:03:25 UTC
(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 13:10:41 UTC
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 13:56:55 UTC
(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.