Comment author: @garrigue

Try using ocaml -dlambda.
It looks like a problem in pattern-matching compilation.
For some mysterious reason, we get two branches, for 1. and 1.0

Comment author: @garrigue

Actually, it is pretty bad: floats are compared as strings during pattern-matching compilation, so that you can create an arbitrary number of branches...
Why do we have Const_float of string rather than Const_float of float in asttypes.mli ?

Comment author: pzimmer

Here is a simpler example (you need to turn off errors on warnings):

match 0. with 0. -> 0 | 0.0 -> 1 | 0. -> 2;;

This returns 1, i.e. the compiler does not respect the ordering of the branches.

Another sign of what is going on is this:

match 0. with 0. -> 0 | 0.0 -> 1 | _ -> 2;;

This does not raise a warning about unused match case (while replacing 0.0 with 0. does).

I am sure similar examples would work with other styles of redundant float representations (i.e. 0.01 vs 1e-2).

Comment author: @alainfrisch

Why do we have Const_float of string rather than Const_float of float in asttypes.mli ?

I'm not sure. I guess the rationale is to avoid generating different .cmo for the same source when the libc version of float_of_string behaves in a non-standard way. The interpretation of floats is delegated to runtime (for bytecode) and to the assembler (native). But this does not really work, because some parts in the pattern matching compiler already use float_of_string at compile time to check equality of floats represented as strings (but not everywhere).

Comment author: @garrigue

Fix committed in trunk revision 12937.

Comment author: @maranget

Checked fix, looks ok.
--Luc

Comment author: @garrigue

Committed in 4.00 too, since this was the point of this quick fix.
At revision 12961.