English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Caml on intel-OSX
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-06-12 (06:58)
From: John Skaller <skaller@u...>
Subject: Re: [Caml-list] Caml on intel-OSX
On Sat, 2005-06-11 at 20:03 +0100, Jon Harrop wrote:
> On Saturday 11 June 2005 19:39, John Skaller wrote:
> > It would help if someone tried to replicate the problem,
> > to be sure it exists -- if could just be my machine.
> Sorry, I forgot to say that I did what you asked on my AMD64 and got a 
> segfault. I haven't checked to see if it is a stack overflow though.

OK, so you replicated the problem. If you set


in the file


and rebuild by something like

make virgin

you'll be running the bytecode version, and it should
all work, indicating the problem isn't a source code bug.

I tried to build the CVS Ocaml under Godi, but the build
fails at the moment (I should try direct CVS build next).

It is a bit of a pain for me because I'm trying to build
a Debian package, and there is a dependency on Ocaml,
but not native code compiler package. However, that
should be a 'build-recommends', and if installed,
as it is on my box, the native code compiler is automatically
detected and used. Debian knows the platform architecture,
but the configure script is Python, and supposed to work
on all platforms, and I have no idea of how to discover
the platform architecture in general.

We have this code where the
error occurs, and according the PR#3640, if the process_function
debug print is included, the segfault goes away .. 

.. it looks to me like adding debug prints changes inlining
behaviour (adding the debug print prevents inlining) and somehow
after inlining the result triggers the code generation bug.

I would guess inlining is higher level than code generation,
so it isn't the inlining algorithm that is the problem.
The AMD64 code generator sounds more likely, and this
assumption is also supported by the fact it is newer code.

Of course these are all GUESSES on my part. 
and process_function syms bbdfns hvarmap ref_insts1 index sr argtypes ret exes
ts =
  print_endline ("Process function " ^ si index);
  process_exes syms bbdfns ref_insts1 ts hvarmap e

and process_exes syms bbdfns ref_insts1 ts hvarmap exes = 
     put some debug print here too ..
  iter (process_exe syms bbdfns ref_insts1 ts hvarmap) exes

and process_exe syms bbdfns ref_insts1 ts hvarmap (exe:bexe_t) =
  let ue sr e = process_expr syms bbdfns ref_insts1 hvarmap sr e in
  let uis i ts = add_inst syms ref_insts1 (i,ts) in
  let ui i = uis i ts in
  print_endline ("processing exe " ^ string_of_bexe syms.dfns 0 exe);

John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net