Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002719OCamlOCaml generalpublic2004-06-14 20:092014-06-05 16:01
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.02.0+devFixed in Version4.02.0+dev 
Summary0002719: Problem in the Mac OS X compiler [PPC code generator]
DescriptionFull_Name: Sylvain Chevillard
Version: 3.07+17
OS: Mac OS X v10.3
Submission from: 132.176.250.100 (132.176.250.100)


I have noticed a bug which should be in the Mac OS X compiler of ocaml, I
think.
Here is a minimal buggy code :

open Printf

let bug () =
  let mat = [| [|false|] |]
  and test = ref false in
    printf "Value of test at the beginning : %b\n" !test; flush stdout;
    (try let _ = mat.(0).(-1) in
       (test := true;
        printf "Am I going through this block of instructions ?\n";
        flush stdout)
     with Invalid_argument _ -> printf "Value of test now : %b\n" !test
    );
    (try if mat.(0).(-1) then ()
     with Invalid_argument _ -> ()
    )

let () = bug ()

We are waiting that the program (when run) should write :
Value of test at the beginning : false
Value of test now : false

and actually, that is what you could see when you run the bytecode generated by
ocamlc or if you compile the code on an x86 architecture with native compiler.

But, with the native compiler on Mac OS X, the program writes :
Value of test at the beginning : false
Value of test now : true

Notice that this part of the code seems to be useless but is actually essential
to the bug :
    (try if mat.(0).(-1) then ()
     with Invalid_argument _ -> ()
    )

I think that it is a problem of pipeline in the processor. The instruction
test := true;
is probably pipelined in the processor and is run even when the exception is
raised.

Happy coding!

Sylvain Chevillard

TagsNo tags attached.
Attached Files

- Relationships
related to 0004892closed 'index out of bound' check too early? 

-  Notes
(0003002)
administrator (administrator)
2004-07-01 13:25

Bug in scheduling of Icheckbound. The obvious fix diminishes the usefulness of
the scheduler quite a bit. Will not fix in 3.08.
(0011679)
xleroy (administrator)
2014-06-05 16:01

Semi-obvious fix implemented in 4.02 (commit 14963) and on trunk (commit 14964): checkbound instructions are not rescheduled if they occur within a try...with block.

- Issue History
Date Modified Username Field Change
2005-11-18 10:14 administrator New Issue
2007-12-12 16:22 doligez Summary Proble in the Mac OS X compiler => Proble in the Mac OS X compiler [PPC code generator]
2007-12-12 16:22 doligez Description Updated
2009-10-15 17:38 doligez Relationship added related to 0004892
2012-07-11 17:36 doligez Target Version => 4.01.0+dev
2012-07-31 13:37 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-11 09:24 doligez Target Version 4.00.1+dev => 4.00.2+dev
2013-06-14 14:30 frisch Target Version 4.00.2+dev => 4.02.0+dev
2013-07-12 18:15 doligez Target Version 4.02.0+dev => 4.01.1+dev
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-06-04 17:01 doligez Summary Proble in the Mac OS X compiler [PPC code generator] => Problem in the Mac OS X compiler [PPC code generator]
2014-06-05 16:01 xleroy Note Added: 0011679
2014-06-05 16:01 xleroy Status acknowledged => resolved
2014-06-05 16:01 xleroy Resolution open => fixed
2014-06-05 16:01 xleroy Fixed in Version => 4.02.0+dev


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker