This simplify the code, would have prevented GPR#205 and prepare ground
for upcoming improved backtrace generation.
From: Frédéric Bour <frederic.bour@lakaban.net>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16367 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
And share backtrace.c between asmrun and byterun.
From: Frédéric Bour <frederic.bour@lakaban.net>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16365 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Pierre Chambart)
When allocating this kind of blocks to the minor heap, they are
added to 'caml_finalize_table' which is traversed on
'caml_empty_table' to check if any of such block is dead.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16357 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
There is currently a GC bug in the bytecode debug-info handling, due
to the fact that
void read_main_debug_info(struct debug_info *di)
is passed a internal pointer in the middle of a custom block inside
the OCaml heap. I could only observe the bug when such custom blocks
are allocated on the minor heap -- which does not happen with the
current implementation, but becomes possible after GPR#92 for example
(which let custom blocks with finalizer be allocated in the
minor heap).
This commit fixes this issue by moving debug_info chunks from the
OCaml heap to the C land, stored in a dynamic table. They are
allocated when caml_add_debug_info is called, and removed when
caml_remove_debug_info is called.
(Another approach would be to keep the debug_info inside the OCaml
heap, but make sure that there are no dangling internal pointers. See
GPR#228 for an attack of this by Mark Shinwell.)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16356 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Hashtbl.iter used to be deterministic, but it's now an observable
source of randomness.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16351 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Simon Cruanes and Gabriel Scherer)
Use one of
-color auto
-color always
-color never
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16348 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Simon Cruanes)
We use bold magenta for warnings, because it works on terminals with
white background.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16347 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The risk of breakage of 3rd-party libraries is too high.
There might be cleaner ways to achieve this effect, e.g. split BYTECCCOMPOPTS into BYTECCCOMPOPTS and BYTECCEXTRAWARNINGS.
git-svn-id: http://caml.inria.fr/svn/ocaml/branches/cc-optim@16337 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
yacc/reader.c:922:9: warning: Value stored to 'value' is never read
value = UNDEFINED;
^ ~~~~~~~~~
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16334 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The intent is to produce fewer warnings when configuring with -verbose.
Note that the warning on "implicit declaration of function" remains,
for relatively good reasons.
git-svn-id: http://caml.inria.fr/svn/ocaml/branches/cc-optim@16330 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Auxiliary changes:
- Put GCC in gnu99 mode (= C99 + GNU extensions).
- Check C99 conformance, warn if not.
- Reject if gcc is too old ( < 3.0 )
- Stop C compilation on warnings if this is a development version of OCaml.
(I'm tired of C warnings being ignored.)
git-svn-id: http://caml.inria.fr/svn/ocaml/branches/cc-optim@16329 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
In the case HAS_GETHOSTBYNAME_R == 6, hp may point into h or into buffer,
so don't end the scope of h and buffer before hp is used.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16327 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Xavier Leroy
Gabriel Scherer
Mark Shinwell
Damien Doligez