(Reuses results of previous computations instead of recomputing them.)
(Cherry-picked from branch backend-optim.)
Tested on amd64/linux and i386/linux.
Other back-ends compile (after assorted updates) but are untested.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14688 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Constant propagation for floats can be turned off with option
-no-float-const-prop, for codes that change FP rounding modes at
run-time.
- Clambda / C-- / Mach: represent float constants as FP numbers of type
float rather than literals of type string.
- Tested for AMD64; other archs need testing.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14673 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
An ISO C99-compliant C compiler and standard library is now assumed.
(Plus special exceptions for MSVC.) In particular, emulation code for
64-bit integer arithmetic was removed, the C compiler must support a
64-bit integer type.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14607 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Patch by Pierre Chambart)
Followup for trunk@14267:
bound checking bug with caml_string_{get,set}{16,32,64}: fix the runtime C code
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14556 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(patch by Josh Watzman)
Add absolute directory names to bytecode format for ocamldebug to use
The need for a long list of -I directives makes interactively using
ocamldebug a pain in the butt. Many folks have solved this with various
`find` invocations or even Python wrappers, but those lead to other
problems when it might include files you weren't expecting (or miss
things you were). But all of this is really annoying since the tooling
should be able to figure out itself, even heuristically, where your
source files are -- gdb gets this right, why can't we?
This patch implements one of the more important heuristics from gdb: you
typically debug on the same machine you built on, so looking for the
source files and built artifacts in the absolute paths where they were
during compilation is a good first try. We write out absolute paths into
a new structure at the beginning of the debug section and then
automatically append those directories into the load path.
This means mean that if you happen to be debugging on a machine
where the original source and build artifacts are *not* available in
their original absolute locations, things will work as before, using the
standard load path mechanism. You can also explicitly use -I to prepend
directories to the load path and override the defaults located by this
new mechanism.
I personally find this makes using ocamldebug much more pleasant :)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14533 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
There seems to be a problematic interaction with backtrace collection. To test this,
make world.opt
cd testsuite
make one DIR=tests/backtrace/
This needs to be sorted out before the patch can go in again.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14510 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
There was a bug with "external _pipe = ..." in
otherlibs/threads/unix.ml where the identifier _pipe was wrongly
detected as infix and reprinted as "external ( _pipe ) = ...", causing
a syntax error.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14503 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Noticed that I had to bootstrap to test on ARM, so I commit a new bootstrap
compiler.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14479 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Patch by Jeremy Yallop)
Functor parameters can occur in three contexts:
(1) in functor bindings:
module M (X : S) (Y : T) = ...
(2) in anonymous functor expressionms:
functor (X : S) (Y : T) -> ...
(3) in signature expressions
module type T = functor (X : S) (Y : T) -> ...
This patch simplifies the grammar by using common productions
(functor_arg, functor_args) to handle all three contexts, and by
combining the productions for named and unnamed parameters.
As a side effect, unnamed functor arguments are now available in
functor bindings:
module M (_ : S) (_ : T) = ...
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14478 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02