[m-rev.] for review: drop support for lcc

Julien Fischer jfischer at opturion.com
Mon Sep 29 17:19:36 AEST 2014


On Mon, 29 Sep 2014, Peter Wang wrote:

> On Mon, 29 Sep 2014 15:52:00 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> For review by anyone.
>>
>> ---------------------
>>
>> Drop support for lcc.
>>
>> Drop support for lcc as a C compiler.  lcc itself does not seem to have been
>> updated since around 2010 and Mercury's support for it has not been updated for
>> quite a while before that.
>>
>> Derivatives of lcc, for example lcc-win32, would almost certainly need to be
>> treated separately anyway, so this change doesn't affect them (i.e. they are
>> already not supported).
>>
>> configure.ac:
>>  	Do not recognise lcc as a C compiler.
>>
>>  	Unrelated change: remove residual support for a.out executables on Linux.
>>
>> scripts/mgnuc_file_opts.sh-subr:
>>  	Do not define the macros __EXTENSIONS__ and _GNU_SOURCE if the mgnuc script
>>  	is invoked with --no-ansi.  This was originally done to support lcc on Linux.
>>  	Doing so on *all* systems as this code actually does is not a good idea.
>>  	(If it becomes necessary to reinstate this behaviour on some system, it
>>  	should be controlled from the configure script not here.)
>>
>> scripts/mgnuc.in:
>> scripts/ml.in:
>> compiler/compile_target_code.m:
>> compiler/handle_options.m:
>> compiler/globals.m:
>>  	Delete support for lcc.
>>
>> README.lcc:
>>  	Delete this file.
>
> It looks fine.  git grep 'lcc' reveals a few more mentions and
> workarounds that could be removed.

I've also removed the following.  I think that the code generated
by the high-level C backed does actually confrom to standard C,
so that XXX could be removed -- I'll check this before doing so though.

I don't want to remove the other workarounds just yet since I suspect
that some of them probably affect MSVC as well -- when this is looked
into the comments can be updated.

Cheers,
Julien.


diff --git a/compiler/ml_code_gen.m b/compiler/ml_code_gen.m
index 7118d5e..84246bc 100644
--- a/compiler/ml_code_gen.m
+++ b/compiler/ml_code_gen.m
@@ -419,7 +419,7 @@
  %   - XXX define compare & unify preds for RTTI types
  %   - XXX need to generate correct layout information for closures
  %     so that tests/hard_coded/copy_pred works.
-%   - XXX fix ANSI/ISO C conformance of the generated code (i.e. port to lcc)
+%   - XXX fix ANSI/ISO C conformance of the generated code
  %
  % UNIMPLEMENTED FEATURES:
  %   - test --det-copy-out
diff --git a/m4/mercury.m4 b/m4/mercury.m4
index 12282d7..85516cb 100644
--- a/m4/mercury.m4
+++ b/m4/mercury.m4
@@ -657,7 +657,6 @@ mercury_cv_gcc_version=`$CC -dumpversion | tr . ' ' | {

  # Work out the C compiler type using a stronger test than AC_PROG_CC to
  # distinguish between clang and gcc.
-# (We don't handle lcc here - I don't think that it's possible to.)

  AC_DEFUN([MERCURY_CC_TYPE], [
  AC_REQUIRE([AC_PROG_CC])
diff --git a/runtime/mercury_wrapper.c b/runtime/mercury_wrapper.c
index 78411ea..89c8791 100644
--- a/runtime/mercury_wrapper.c
+++ b/runtime/mercury_wrapper.c
@@ -785,17 +785,7 @@ mercury_runtime_init(int argc, char **argv)
      ** current context of the engine.
      */
  #ifndef MR_HIGHLEVEL_CODE
-  #ifndef __LCC__
      MR_save_context(&(MR_ENGINE(MR_eng_context)));
-  #else
-    {
-      /* XXX Work around lcc bug -- lcc 4.1 miscompiles the original code */
-      size_t offset = offsetof(MercuryEngine, MR_eng_context);
-      char *tmp = (char *) MR_cur_engine();
-      MR_Context *eng_context = (tmp += offset, (MR_Context *) tmp);
-      MR_save_context(eng_context);
-    }
-  #endif
  #endif

  #ifdef  MR_USE_MINIMAL_MODEL_OWN_STACKS



>
> Peter
>



More information about the reviews mailing list