0005758: Compiler bug when matching on floats

(0008049)
garrigue (manager)
2012-09-10 16:23

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

(0008050)
garrigue (manager)
2012-09-10 16:31

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 ?

(0008051)
pzimmer (reporter)
2012-09-10 20:16

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).

(0008052)
frisch (developer)
2012-09-11 08:03

> 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).

(0008105)
garrigue (manager)
2012-09-19 09:10

Fix committed in trunk revision 12937.

(0008169)
maranget (manager)
2012-09-27 14:29

Checked fix, looks ok.
--Luc

(0008171)
garrigue (manager)
2012-09-27 15:30

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

Issue History
Date Modified	Username	Field	Change
2012-09-10 15:37	dwu	New Issue
2012-09-10 16:23	garrigue	Note Added: 0008049
2012-09-10 16:31	garrigue	Note Added: 0008050
2012-09-10 16:31	garrigue	Assigned To	=> garrigue
2012-09-10 16:31	garrigue	Status	new => confirmed
2012-09-10 20:16	pzimmer	Note Added: 0008051
2012-09-10 23:30	frisch	Target Version	=> 4.00.1+dev
2012-09-11 08:03	frisch	Note Added: 0008052
2012-09-19 09:10	garrigue	Note Added: 0008105
2012-09-19 09:10	garrigue	Status	confirmed => resolved
2012-09-19 09:10	garrigue	Fixed in Version	=> 4.01.0+dev
2012-09-19 09:10	garrigue	Resolution	open => fixed
2012-09-27 14:28	maranget	Assigned To	garrigue => maranget
2012-09-27 14:28	maranget	Status	resolved => assigned
2012-09-27 14:29	maranget	Note Added: 0008169
2012-09-27 14:31	maranget	Status	assigned => closed
2012-09-27 15:30	garrigue	Note Added: 0008171
2012-10-03 12:07	doligez	Fixed in Version	4.01.0+dev => 4.00.1+dev

Notes
(0008049) garrigue (manager) 2012-09-10 16:23	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

(0008050) garrigue (manager) 2012-09-10 16:31	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 ?

(0008051) pzimmer (reporter) 2012-09-10 20:16	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).

(0008052) frisch (developer) 2012-09-11 08:03	> 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).

(0008105) garrigue (manager) 2012-09-19 09:10	Fix committed in trunk revision 12937.

(0008169) maranget (manager) 2012-09-27 14:29	Checked fix, looks ok. --Luc

(0008171) garrigue (manager) 2012-09-27 15:30	Committed in 4.00 too, since this was the point of this quick fix. At revision 12961.

Relationships