Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004813OCamlOCaml generalpublic2009-06-04 19:382011-05-29 12:14
Reportershinwell 
Assigned Toxleroy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.11.1+rc0 
Target VersionFixed in Version3.11.2+dev 
Summary0004813: incorrect parsing of floating point literals
DescriptionThe GNU assembler contains a nasty bug in its parsing of floating point literals (http://sourceware.org/bugzilla/show_bug.cgi?id=10241 [^]). Create test.s thus:

    .data
    .double 0e0e-4
        .double 0
    .double 0e-4
    .double 0
        .double -4.0
    .double 0

Assemble with the equivalent of the following on your favourite target:
$ ./install/bin/x86_64-pc-linux-gnu-as -o test.o test.s && ./install/bin/x86_64-pc-linux-gnu-objdump -Dr test.o

Note that, most seriously, 0e-4 has been assembled as -4 (!) and even 0e0e-4 is accepted. This still exists in the latest released version of binutils (2.19.1), and has probably been around for some time.

Since the O'Caml compiler passes the string representation of floating point literals directly to the assembler, we are exposed in O'Caml to the bug where 0e-4 parses as -4. (The 0e0e-4 case should be prevented by O'Caml's lexical analysis, as will be any of the other potential failure cases in the assembler when the second character of the literal is a letter of the alphabet but not 'e'.) As a consequence, the following program produces the surprising result of "a = -4.000000" under native code compilation:

type foo = Foo of float
let a = Foo 0e-4
let _ =
  match a with
  | Foo a ->
      Printf.printf "a = %f" a

I suggest that the O'Caml compiler should be modified such that it never emits a string literal starting with "0e"; instead it should just emit a zero literal. This is safe even if the assembler concerned is not the GNU assembler. Unfortunately, this will necessitate a lot of tedious little changes throughout the asmcomp/ directory.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0004980)
mottl (reporter)
2009-06-04 20:34

The link seems to include a superfluous ')'. It should be:

  http://sourceware.org/bugzilla/show_bug.cgi?id=10241 [^]
(0004981)
shinwell (developer)
2009-06-05 13:42

So it turns out that this is expected assembler behaviour (see the node Flonums in the info documentation for gas). It seems pretty crazy to me. Anyway, I still suggest a compiler patch is in order. It occurs to me that one other option is to alter the O'Caml lexer so it doesn't permit literals starting with "0e", although personally I think it would be better to accept such literals.
(0004982)
pzimmer (reporter)
2009-06-05 16:46

If I understand correctly, one easy way to fix it would be for the OCaml compiler to output 0Ex instead of x for every float (or any letter other than E). This would lead to strange output like "0E1e-4" but should be correct in all cases. I agree the gas convention is very confusing...
(0004983)
shinwell (developer)
2009-06-05 16:59

I think the problem with pzimmer's suggestion is that it would result in having to determine whether a GNU assembler was being used, which it might not be on some targets.
(0005005)
xleroy (administrator)
2009-06-23 18:22

What a mess in the GNU assembler :-) Thanks for reporting it. I guess the simplest portable workaround is to emit float literals in the generated .s files as 64-bit integers, doing the string -> binary IEEE float conversion within Caml. Some ports already do this; it's a "small matter of programming" to do it systematically.
(0005020)
xleroy (administrator)
2009-07-15 14:23

Tentative fix in 3.11 release branch. Float literals are converted to IEEE representation by OCaml, then emitted as 32- or 64-bit integers. Tested on amd64/linux. Needs testing on other platforms.

- Issue History
Date Modified Username Field Change
2009-06-04 19:38 shinwell New Issue
2009-06-04 20:34 mottl Note Added: 0004980
2009-06-05 13:42 shinwell Note Added: 0004981
2009-06-05 16:46 pzimmer Note Added: 0004982
2009-06-05 16:59 shinwell Note Added: 0004983
2009-06-23 18:22 xleroy Note Added: 0005005
2009-06-23 18:22 xleroy Assigned To => xleroy
2009-06-23 18:22 xleroy Status new => assigned
2009-07-15 14:23 xleroy Note Added: 0005020
2009-07-15 14:23 xleroy Status assigned => resolved
2009-07-15 14:23 xleroy Resolution open => fixed
2009-07-15 14:23 xleroy Fixed in Version => 3.11.2+dev
2011-05-29 12:14 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker