caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Skaller <skaller@users.sourceforge.net>
To: Jon Harrop <jon@ffconsultancy.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Caml on intel-OSX
Date: Sun, 12 Jun 2005 16:58:24 +1000	[thread overview]
Message-ID: <1118559504.7152.77.camel@rosella.wigram> (raw)
In-Reply-To: <200506112003.33778.jon@ffconsultancy.com>

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

NATIVE_CODE_COMPILER=0

in the file

config/ocaml_config.py

and rebuild by something like

make virgin
./configure
make

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);
A
  *)
.....


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


  reply	other threads:[~2005-06-12  6:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-09  5:33 John Skaller
2005-06-09  8:23 ` [Caml-list] " Agustín Valverde
2005-06-09 14:00 ` james woodyatt
2005-06-09 15:27   ` John Skaller
2005-06-09 16:20     ` padiolea
2005-06-09 22:51       ` John Skaller
2005-06-10  0:02         ` Jonathan Bryant
2005-06-10  2:55           ` John Skaller
2005-06-10  7:10             ` Florian Hars
2005-06-10  0:41         ` Jacques Garrigue
2005-06-10  1:57           ` John Skaller
2005-06-14  0:28           ` Sven Luther
2005-06-10  6:35         ` Stefano Zacchiroli
2005-06-10  9:07           ` John Skaller
2005-06-10 23:39         ` Jon Harrop
2005-06-11 18:39           ` John Skaller
2005-06-11 19:03             ` Jon Harrop
2005-06-12  6:58               ` John Skaller [this message]
2005-06-13 19:19             ` [Caml-list] AMD64 ocamlopt bug Xavier Leroy
2005-06-13 19:32               ` John Skaller
2005-06-13 20:18                 ` Damien Doligez
2005-06-13 20:27                 ` John Skaller
2005-06-13 21:01                   ` Anil Madhavapeddy
2005-06-09 23:44       ` [Caml-list] Caml on intel-OSX Jonathan Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1118559504.7152.77.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@yquem.inria.fr \
    --cc=jon@ffconsultancy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).