Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re: assertion failed in compiler. #2458

Closed
vicuna opened this issue Apr 15, 2004 · 2 comments
Closed

Re: assertion failed in compiler. #2458

vicuna opened this issue Apr 15, 2004 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Apr 15, 2004

Original bug ID: 2458
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hi,

an example that produces the compiler bug in 3.07+2 on Linux is:

class bug = object
method my_array= [|0;0;0;10;-1;-2|]
end;;

this renders a:
$> ocamlc -c bug.ml
Fatal error: exception Assert_failure("bytecomp/translcore.ml",612,14)
$>

have fun,

Romain Slootmaekers

--------------- Original post follows below -------------------------

Hi,

when I try to compile my ocaml program under Linux (Mandrake) with Ocaml
3.07+2 I get an assertion failure in the compiler:

Fatal error: exception Assert_failure("bytecomp/translcore.ml",612,14)

The same program compiles and works fine under Ocaml 3.06 (cygwin)

I couldn't find anything similar on the bug web site
(http://caml.inria.fr/bin/caml-bugs) But I didn't venture deeply into
the french bug reports ;)

I can provide a code sample that produces this on demand.

So my question is:
is it something known, or something new ?
and if so, is there a workaround ?

TIA,

Romain Slootmaekers

@vicuna
Copy link
Author

vicuna commented Apr 16, 2004

Comment author: administrator

From: romain@zzict.nl

an example that produces the compiler bug in 3.07+2 on Linux is:

class bug = object
method my_array= [|0;0;0;10;-1;-2|]
end;;

this renders a:
$> ocamlc -c bug.ml
Fatal error: exception Assert_failure("bytecomp/translcore.ml",612,14)

Interesting. This is now fixed in CVS.
Here is the patch:
Index: bytecomp/typeopt.ml

RCS file: /net/pauillac/caml/repository/csl/bytecomp/typeopt.ml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- typeopt.ml 2003/07/02 09:14:29 1.9
+++ typeopt.ml 2004/04/16 00:50:23 1.10
@@ -87,7 +87,8 @@
let array_kind_gen ty env =
let array_ty = Ctype.expand_head env (Ctype.correct_levels ty) in
match (Ctype.repr array_ty).desc with

  • Tconstr(p, [elt_ty], _) when Path.same p Predef.path_array ->
  • Tconstr(p, [elt_ty], _) | Tpoly({desc = Tconstr(p, [elt_ty], _)}, _)
  • when Path.same p Predef.path_array ->
    array_element_kind env elt_ty
    | _ ->
    (* This can happen with e.g. Obj.field *)

Aux developpeurs: la correction est simple mais sale.
Le probleme est du a` la coercion de ty vers Tpoly(ty,vars) dans les
methodes, qui se fait sans introduction de nouveau noeud dans l'arbre
syntaxique.
Les autres alternatives sont:

  • ajouter un noeud Texp_constraint lorsqu'on change le type.
    mais il faut se le taper dans tout le compilo.

  • utiliser une pseudo application d'une fonction definie comme %ident.
    Mais il me semble que cette application sera eliminer trop tard, et
    que ca conduirait a un code moins efficace. A l'heure actuelle les optimisations liees au typage sont tres
    limitees, donc le quick hack ci-dessus suffit, mais a` long term la
    question se pose.

       Jacques
    

@vicuna
Copy link
Author

vicuna commented Apr 18, 2004

Comment author: administrator

Fixed by JG 2004-04-16

@vicuna vicuna closed this as completed Apr 18, 2004
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant