For picreg, this is only the first half of the change; it deletes code
that generates references to this grade component. When this diff has been
installed on all our machines, will come the second half, which will delete
the code that understands references to picreg. The delay is needed because
your current installed compiler is still generating such references.
runtime/mercury_grade.h:
Remove both regparm and picreg as grade components.
doc/user_guide.texi:
Remove the (commented out) documentation of picreg; regparm had
no documentation to delete.
runtime/mercury_std.h:
Remove the small bit of code that implemented regparm.
runtime/mercury_conf_param.h:
Don't define MR_PIC_REG.
runtime/machdeps/i386_regs.h:
runtime/mercury_conf_bootstrap.h:
Remove references to picreg.
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/parse_grade_options.sh-subr:
Keep in place the code that accepts picreg grade components,
but make them do nothing. Mark such do-nothing code so that
it can be deleted when this first-half diff has been bootstrapped.
configure.ac:
Delete the autoconfigured variable EXT_FOR_LINK_WITH_PIC_OBJECTS,
which could be set to either 'lpic_o' or just 'o', because it is now
*always* the latter.
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
Remove code that transmitted the value of EXT_FOR_LINK_WITH_PIC_OBJECTS
to the compiler via the --link-with-pic-object-file-extension option.
compiler/options.m:
Keep the --link-with-pic-object-file-extension and --pic-reg options,
but mark them for deletion in the second half of this change.
compiler/compile_target_code.m:
Change the code that dealt with the value of the
--link-with-pic-object-file-extension and --pic-reg options to assume
that the former is always the same as the non-pic file extension,
and that --pic-reg is never needed. The former means that we don't need
to handle link_with_pic as a separate category of object files from
just plain non_pic.
compiler/compute_grade.m:
Keep accepting picreg grades, but mark the code that does this
for deletion.
compiler/make.program_target.m:
compiler/make.module_target.m:
compiler/make.program_target.m:
compiler/make.util.m:
Conform to the changes above.
Currently, the compiler's top-level module is the module 'top_level'. This
means that the executable (or Java archive, or assembly) we generate is named
after that. However, the rest of the system requires that the compiler
executable be named 'mercury_compile', so we currently rename it after it is
generated. (At least, we do in C grades, in non-C grades the compiler
"executable" currently has the "wrong" name.) Making this scheme work across
multiple backends and platforms leads to quite a bit of complication in the
build system. This change simplifies matters by repurposing the
'mercury_compile' module to be the new top-level module; this means that the
executable is generated with the correct name to begin with.
compiler/mercury_compile.m:
Shift the existing contents of this module to new module,
mercury_compile_main.
Shift this module out of the top_level package and export main/2 from it.
compiler/mercury_compile_main.m:
New module that contains the old contents of mercury_compile.m.
compiler/top_level.m:
Conform to the above changes.
Delete the definition of main/2 from this module.
compiler/make.m:
compiler/make.module_target.m:
Conform to the above changes.
compiler/Mmakefile:
Conform to the change in the name of the top-level module.
Delete the rule for renaming the compiler executable.
Mmakefile:
Update the dep_compiler target.
compiler/notes/compiler_design.html:
Update this document.
scripts/mercury_compile.sh-csharp:
scripts/mercury_compile.sh-java:
Update these scripts.
compiler/.gitignore:
Conform to the above changes and generally update
this file.
configure.ac:
tools/binary_step:
tools/bootcheck:
Update the top-level module.
scripts/mercury_compile.sh-csharp:
Add a script script that runs an installed compiler built in the C#
grade using Mono. As with compilers built in the Java grade, the
wrapper script we generate in the compiler directory only works
in situ and we require a separate script for the installed version.
XXX TODO: we will need to handle .NET differently, probably by simply
renaming top_level.exe -> mercury_compile.exe.
scripts/Mmakefile:
Install the new script if the compiler was built in the C# grade.
Lots of Mercury types have a name that is also the name of one of the type's
function symbols, like this:
:- type allow_lco
---> do_not_allow_lco
; allow_lco.
When jumping to a tag that has two definitions, the type name and one of that
type's function symbols, it doesn't really matter which one we jump to, since
they are next to each other. It is therefore annoying having vim ask us
to *choose* which one we want to jump to.
A while ago, I added code to mtags to fix this annoyance, but it worked
only when the functor had no arguments.
scripts/mtags.in:
Make the fix work even when the functor has arguments, by making the
test work on a version of the tag AFTER, not BEFORE, the argument list
following non-zero-arity function symbols is stripped off.
Feedback of the upgrade of Boehm GC indicated that including the
libatomic_ops submodule in the top-level was inconvenient, and I agree.
This change, along with a corresponding change to the boehm_gc repository,
will instead included it as a nested submodule of boehm_gc.
.gitmodules:
libatomic_ops:
Remove libatomic_ops submodule.
boehm_gc
Update to the most recent revision that adds a libatomic_ops submodule.
prepare.sh:
Update submodules recursively.
Mmakefile:
scripts/prepare_install_dir.in:
tools/bootcheck:
Remove code in build tools that links or copies the libatomic_ops
directory from Mercury's top-level,
tools/build_srcdist:
De-initialise the git submodules prior to building the source
distribution. They are then setup again, with clean working
directories, by the call to ./prepare.sh.
Mmakefile:
Handle the the new location of libatomic_opss in the "tar" target.
scripts/prepare_install_dir.in:
Handle both usage in the source distribution where
boehm_gc/libatomic_ops is a directory, and usage in a development
workspace where boehm_gc/libatomic_ops is a symlink.
This is the 7.4.2 release plus some bug fixes, such as fixes for the TSX
bug.
.gitmodules:
Update to the release-7_4 branch
boehm_gc:
libatomic_ops:
Update submodules.
compiler/notes/upgrade_boehm_gc.html:
Update documentation.
scripts/prepare_install_dir.in:
Conform to changes in the boehm_gc repository.
GC_stackbottom, GC_gc_no and GC_dont_gc are now deprecated. These changes
use new options in the API where possible.
Update scripts to copy the boehm_gc and libatomic_ops directories correctly.
Pass Boehm GC the correct flags for thread support
Update documentation regarding the version of Boehm GC.
runtime/mercury_wrapper.c:
Don't use the deprecated GC_dont_gc variable.
library/benchmarking.m:
Use GC_get_stackbottom() to get the bottom of stack and GC_get_gc_no()
to get the number of collections so far.
util/mkinit.c:
Do not explicitly set GC_stackbottom anymore, except on AIX where it
cannot be found automatically.
scripts/prepare_install_dir.in:
tools/bootcheck:
tools/build_srcdist:
Add some missing files present in Boehm GC 7.4.2 that wern't present
earlier and remove some old ones.
Coby and link the libatomic_ops directory correctly.
.README.in:
bindist/bindist.README:
Update documentation regarding the version of Boehm GC.
configure.ac:
Something in Boehm GC's build system has changed and we must now pass
-DGC_THREADS whenever building threadsafe versions of BOehm GC. This is now
done using the BOEHM_MISC_CFLAGS_FOR_THREADS autoconf variable, which has
been renamed to BOEHM_CFLAGS_FOR_THREADS now that it is more generally used.
Boehm GC no longer (or perhaps never did) require developers to specify the
type of threading to use, eg -DGC_LINUX_THREADS rather than -DGC_THREADS.
With the exception of win32-pthreads. We now pass -DGC_THREADS whereever
possible.
Mmake.common.in:
Rename BOEHM_MISC_CFLAGS_FOR_THREADS.
Lots of Mercury types have a name that is also the name of one of the type's
function symbols, like this:
:- type allow_lco
---> do_not_allow_lco
; allow_lco.
When jumping to a tag that has two definitions, the type name and one of that
type's function symbols, it doesn't really matter which one we jump to, since
they are next to each other. It is therefore annoying having vim ask us
to *choose* which one we want to jump to.
scripts/mtags.in:
Avoid this annoyance by not generating a tag file entry for function
symbols whose name is the same as the name of their containing type.
compiler/mlds_to_il.m:
compiler/mlds_to_ilasm.m:
compiler/mlds_to_managed.m:
compiler/il_peephole.m:
compiler/ilasm.m:
compiler/ilds.m:
Delete the modules making up the MLDS->IL code generator.
compiler/globals.m:
compiler/prog_data.m:
Delete IL as a target and foreign language.
compiler/prog_io_pragma.m:
Delete the max_stack_size/1 foreign proc attribute. This was only
ever required by the IL backend.
compiler/options.m
Delete options used for the IL backend.
compiler/write_deps_file.m:
Don't generate mmake targets for .il files etc.
compiler/*.m:
Conform to the above changes.
compiler/notes/compiler_design.html
compiler/notes/work_in_progress.html
Conform to the above changes.
library/*.m:
Delete IL foreign_proc and foreign_export pragmas.
README.DotNet:
Delete this file.
browser/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
mdbcomp/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
runtime/Mmakefile:
slice/Mmakefile:
Conform the above changes.
configure.ac:
Don't check that IL is a supported foreign language when performing the
up-to-date check.
Delete the '--enable-dotnet-grades' option.
scripts/Mmake.vars.in:
Delete variables used for the IL backend (and in on case by the Aditi
backend).
scripts/Mercury.config.bootstrap.in:
scripts/Mercury.config.in:
scripts/Mmake.rules:
scripts/canonical_grade.sh-subr:
tools/bootcheck:
Delete stuff related to the 'il' and 'ilc' grades.
doc/reference_manual.texi:
Delete the documentation of the 'max_stack_size' option.
doc/user_guide.texi:
Delete stuff related to the IL backend.
tests/hard_coded/csharp_test.{m,exp}:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/valid/csharp_hello.m:
Delete these tests: they are no longer relevant.
tests/hard_coded/equality_pred_which_requires_boxing.m:
tests/hard_coded/foreign_import_module.m:
tests/hard_coded/foreign_import_module_2.m:
tests/hard_coded/foreign_type.m:
tests/hard_coded/foreign_type2.m:
tests/hard_coded/foreign_type3.m:
tests/hard_coded/intermod_foreign_type2.m:
tests/hard_coded/lp.m:
tests/hard_coded/user_compare.m:
tests/invalid/foreign_type_2.m:
tests/invalid/foreign_type_missing.{m,err_exp}:
tests/invalid/foreign_type_visibility.m:
tests/invalid/illtyped_compare.{m,err_exp}:
tests/submodules/external_unification_pred.m
tests/valid/big_foreign_type.m
tests/valid/solver_type_bug.m
tests/valid_seq/foreign_type_spec.m
tests/valid_seq/intermod_impure2.m
Delete IL foreign_procs where necessary.
tests/hard_coded/Mmakefile
tests/invalid/Mercury.options
tests/invalid/Mmakefile
tests/submodules/Mmakefile
tests/valid/Mercury.options
tests/valid/Mmake.valid.common
tests/valid/Mmakefile
tests/valid_seq/Mmakefile
tests/valid_seq/Mercury.options
Conform to the above changes.
scripts/mercury_compile.sh-java:
Bump up the stack size to 32M since the default is too low to build the
Mercury compiler.
configure.ac:
Workaround a problem that causes the configure check for an installed
Mercury compiler to fail if the installed Mercury compiler is built in
a non-C grade, specifically the non-C backends do not provide an equivalent
of MR_RTTI_VERSION.
Make it possible to run the installed Java version of the compiler by
installing versions of the wrapper scripts for 'mercury_compile' and
'mfilterjavac' that have the CLASSPATH set to point to the installed versions
of the standard library Java archives.
The wrapper script generated in the compiler directory is not suitable for this
because as generated it sets the CLASSPATH relative to the compiler directory,
not the installation directory. Modifying that file is not a good idea since
that will mean that then the compiler cannot be executed in situ. Instead we
provide a handwritten version of the wrapper script in the scripts directory
that is installed in place of the generated one. Ditto for mfilterjavac.
While this does create a small maintenance problem, I think that any other
approach, for example, modifying the generation of wrapper scripts to account
for this, is going to be a larger maintenance problem.
TODO:
- handle batch file launchers for Windows.
- handle other executables in the Mercury system (although most of these
are not so important in this context).
compiler/Mmakefile:
mfilterjavac/Mmakefile:
Do not install generated wrapper scripts from these directories in the Java
grade.
scripts/mercury_compile.sh-java:
scripts/mfilterjavac.sh-java:
Java wrappers scripts for the installed versions of the compiler
and mfilterjavac.
scripts/Mmakefile:
In the Java grade install the wrapper scripts for the compiler and
mfilterjavac from this directory.
scripts/final_grade_options.sh-subr:
Print an error and exit with a non-zero exit status for
various invalid grade component combinations.
Implicitly disable the .par component for the non-C backends.
This doesn't affect the support for threads in grades that
use these backends.
The default configuration of Mercury on Windows breaks when using the Java
grade due to the argument we pass to the Java compiler's '-J' option, in order
to set the maximum heap size, not being quoted in the @file we pass to the Java
compiler when '--restricted-command-line' is enabled.
What should be placed in the @file is:
-J"-Xmx1024m"
What we currently put in it is:
-J-Xmx1024m
The reason for this is that the setting of JAVAC_FLAGS_FOR_HEAP_SIZE in
scripts/Mercury.config does not escape the double quotes, consequently they do
not get passed through the Mercury compiler to the aforementioned @file. This
problem was already correctly identified and documented in the comments
accompanying the MERCURY_CHECK_JAVAC_HEAP_SIZE macro in m4/mercury.m4, but the
actual behaviour of that macro is incorrect. In particular, it fails to
account for the fact that the value of JAVAC_FLAGS_FOR_HEAP_SIZE should differ
depending on whether mmake or 'mmc --make' is using that value. The current
value will work for mmake but not with 'mmc --make'
(and '--restricted-command-line').
The fix is to separate the handling of the mmake and 'mmc --make' cases and
correctly escape the version that is put in Mercury.config.
configure.ac:
m4/mercury.m4:
Define separate configuration variables for mmake and 'mmc --make' to
set the Java compiler's maximum heap size.
scripts/Mercury.config.in:
scripts/Mercury.config.bootstrap.in:
scripts/Mmake.vars.in:
Conform to the above change.
This file-specific setting will override a default setting of expandtabs
in $HOME/.vimrc.
*/Makefile:
*/Mmakefile:
As above.
tests/hard_coded/.gitignore:
Don't ignore the purity subdir. This ignore must have been left over
from when purity.m was a test in hard_coded, not hard_coded/purity,
and it ignored an executable, not a directory.
It was intended that the C compiler type string for MSVC would eventually have
the form "msvc_<n>" (where <n> is the version number). The configure script is
still generating the older form of string, "cl_<n>"; we want to avoid this
because it's too easy to confuse with clang. Make configure generate the new
kind of C compiler type string.
configure.ac:
Generate the new sort of compiler type strings for MSVC.
scripts/mgnuc.in:
compiler/globals.m:
Do not recognise the old sort any longer.
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:
m4/mercury.m4:
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.)
runtime/mercury_wrapper.c:
Delete a workaround for lcc.
scripts/mgnuc.in:
scripts/ml.in:
compiler/compile_target_code.m:
compiler/handle_options.m:
compiler/globals.m:
compiler/ml_code_gen.m:
Delete support for lcc.
README.lcc:
Delete this file.
Passing -ansi to GCC restricts us to the C90 dialect of C and prevents us from
using C99 library features with GCC. Since every version of GCC we support
provides the relevant C99 features there is not much point to imposing this
restriction. As already noted in the configure script the use of -ansi was
also causing problems with the header files on MinGW systems. Finally, I do
think it is reasonable to require users to use the C90 dialect of C in
foreign_proc and foreign_code pragma bodies by default.
NOTE: this is *not* an invitation to start using C99 language features
throughout the runtime and library -- at this point, we (unfortunately) still
maintain compatibility with older versions of MSVC that don't support these
features.
configure.ac:
Do not pass -ansi to GCC. Add an explanation of why.
scripts/mgnuc.in:
Update the description of the what the --no-ansi option does.
(XXX there's _a lot_ of out-of-date stuff in this script.)
As Tomas By's recent emails suggest, this support is doing more harm than good,
by falsely implying to people that MPS is a viable alternative to the Boehm
collector. The MPS collector was only ever experimental, and never performed
as well as Boehm. MPS isn't even in the git repository on git hub. It was
stored in a separate CVS repository on mundula, and (as far as I know)
wasn't carried over to github. The code of MPS was last touched a long time
ago; I would be surprised if it worked on today's systems without changes.
Mmake.common.in:
Mmake.workspace:
RESERVED_MACRO_NAMES:
boehm_gc/Mmakefile:
compiler/add_pragma.m:
compiler/compile_target_code.m:
compiler/globals.m:
compiler/handle_options.m:
compiler/mercury_compile_mlds_back_end.m:
compiler/mlds_to_c.m:
compiler/options.m:
compiler/peephole.m:
doc/user_guide.texi:
library/benchmarking.m:
runtime/Mmakefile.m:
runtime/mercury.h:
runtime/mercury_conf_param.h:
runtime/mercury_grade.h:
runtime/mercury_heap.h:
runtime/mercury_init.h:
runtime/mercury_memory.h:
runtime/mercury_wrapper.[ch]:
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/ml.in:
scripts/parse_grade_options.sh-subr:
util/mkinit.c:
Remove all references to MPS.
IRIX itself is more or less dead and the Mercury support for it has not been
tested for many years.
configure.ac:
compiler/notes/overall_design.m:
doc/user_guide.texi:
scripts/mgnuc.in:
As above.
NEWS:
Announce the above.
configure.ac:
Pass -x to strip when linking an executable against Mercury shared
libraries on Mac OS X.
Make the up-to-date check require {14.01.-beta,rotd}-2014-05-05
or later.
scripts/Mercury.config.in:
Set the default values of --strip-executable-{shared,static}-flags.
Some versions of the MinGW system headers rely on the types off_t and off64_t
being defined, but they will not be defined if -ansi is enabled.
(This seems to affect MinGW systems using GCC 4.8; I haven't checked other
GCC versions yet.)
configure.ac:
scripts/mgnuc.in:
Do not compile with -ansi on MinGW systems.
Currently we use the C89 definitions of MR_STATIC_INLINE and friends with
clang, which is less than ideal in a couple of ways, firstly we might not get
as much inlining as we would like and secondly, for clang, it causes large
numbers of warnings about unused functions to be generated.
Using GNU C style inlining does not work because we enable the -ansi option
when using clang and the (current) behaviour of the -ansi option with clang is
to enforce strict C89 conformance (i.e. disable any GNU C extensions.).
This change avoids all of the above by (1) adding C99 style definitions of
MR_STATIC_INLINE etc for clang and (2) not passing -ansi to clang (i.e. putting
clang into c99, or technically gnu99, mode). We fall back on the C89 style
definitions if the user does something odd like setting -ansi or -std=c89
themselves.
runtime/mercury_std.h:
Define MR_STATIC_INLINE and friends for clang in the case where clang
is in C99 (or equivalent) mode.
configure.ac:
Set CFLAGS_FOR_ANSI for clang to empty. Add an explanation of why
we do this.
scripts/mgnuc.in:
Don't pass -ansi to clang.
We had stopped passing the linker strip flag on Mac OS X because it had
become deprecated and useless there, but we can still strip the binary
with the `strip' tool.
This commit changes compile_target_code.m to do so, but NOT the
`ml' shell script.
compiler/options.m:
doc/user_guide.texi:
Add option --strip-executable-command.
configure.ac:
scripts/Mercury.config.in:
Set --strip-executable-command="strip" on Darwin platforms,
or an empty string elsewhere.
compiler/compile_target_code.m:
Invoke the --strip-executable-command separately after linking
an executable if necessary.
scripts/ml.in:
Fix a bug: use configured value of LD_STRIP_FLAG instead of
assuming "-s".
In the mgnuc script, do not use the name of the C compiler to determine its
type since on OS X with Xcode 5 the executable "gcc" is actually clang.
Instead use the value of C_COMPILER_TYPE determined by the configure script to
set C compiler type, as elsewhere in the Mercury system.
Incorrectly identifying the C compiler type was resulting in lots of
compilation warnings because we were using the warning flags intended for GCC
with clang. Further warnings were being generated because GCC-only
optimization flags would also be passed to clang.
scripts/mgnuc.in:
As above.
Fix some problems that were preventing the system from compiling properly with
MSVC.
(1) Visual Studio 2013 no longer includes the files NtWin32.Mak and Win32.Mak
which are required for building the Boehm GC with MSVC. (This appears to be an
issue with upstream Boehm as well.) The workaround here is to reference the
copies of this files included with the Windows 7 SDK. (This appears to be the
official Microsoft workaround for dealing with this problem for now.)
(2) Disable support for `--c-debug' when using MSVC. Using this option causes
MSVC to emit .pdb (Program Data Base), that contain the symbol information for
an object files. This causes a variety of problems:
(i) parallel builds are contending for the vc*.pdb file shared by all the
object files in a directory causing compilation to abort. (Compiling with
the -FS option is another solution to this -- it causes the compiler to
serialize access to the .pdb file -- but at the cost of slowing down
compilation.)
(ii) .pdb files are not cleaned up by realclean; compilation will abort
if a pdb file generated by a different version of MSVC is encountered.
(iii) we don't install the .pdb files alongside the libraries anyway.
This can be a source of linker warnings. (And shutting up the Microsoft
linker seems to be very difficult indeed ...)
(iv) compiling with -Zi (apparently) inhibits some C compiler optimizations.
Compiling with the older -Z7 (MSVC 7 style debugging info) option is another
alternative. Using that option causes MSVC to include symbol information in
the object files, instead of in a separate file.
For now (i.e. the 14.01 release), disabling `--c-debug' for MSVC is the
simplest way of addressing the above issues.
README.MS-VisualC:
Describe the problem with NtWin32.Mak and Visual Studio 2013 and
provide two possible workarounds.
Mention that `--c-debug' is not currently supported with MSVC and how
to re-enable it.
Simplify some of the instructions for setting up the build environment.
configure.ac:
scripts/mgnuc.in:
Disable `--c-debug' with MSVC.
scripts/prepare_install_dir.in:
Copy all makefile fragments for nmake into the boehm_gc directory for
the library grade installation. (This is in case the user copies
NtWin32.Mak etc into the boehm_gc directory as per the second of
the workarounds in README.MS-VisualC.)
slice/Mmakefile:
compiler/Mmakefile:
deep_profiler/Mmakefile:
mfilterjavac/Mmakefile:
profiler/Mmakefile:
slice/Mmakefile:
Clean up any .pdb files. Note that one is generated for each
executable (regardless of whether -Zi is given to cl or not).
In addition, if -Zi is given to cl, there will be file named
vc<version>.pdb generated (where <version> is the version of MSVC being
used.)
We encounter internal errors in GCC 4.8.2 on i686 Linux when compiling
runtime/mercury_ho_call.c in grades that use global registers when -fpic is
enabled. Compile that module at -O0 in the above circumstances; doing so
avoids tickling the bug.
scripts/mgnuc.in:
As above.
scripts/Mercury.config.in:
scripts/Mercury.config.boostrap.in:
Add the environment variable MERCURY_TARGET_ARCH, which allows
the compiler's target architecture to be overridden in the
environment.
compiler/options.m:
Add the option --target-arch as a synonym (and eventually, replacement)
for the --fullarch option.
A number of patterns and filenames where missing from .gitignore files,
especially in the tests/ directory.
.gitignore:
boehm_gc/.gitignore:
boehm_gc/libatomic_ops/pkgconfig/.gitignore:
runtime/.gitignore:
scripts/.gitignore:
tests/.gitignore:
tests/analysis/table/.gitignore:
tests/analysis/trail/.gitignore:
tests/benchmarks/.gitignore:
tests/debugger/.gitignore:
tests/invalid/.gitignore:
tests/mmc_make/.gitignore:
tests/mmc_make/lib/.gitignore:
Add new patterns to .gitignore files.
Remove some patterns that are implicit because they're in a parent
directory's file.
tests/analysis/.gitignore:
After removing superfluous patterns this file was empty. I've deleted
it.
Use -R instead of -r with cp by default.
Fix some documentation errors.
compiler/options.m:
Enable library grade detection by default.
Document the --no-detect-libgrades option.
Make the default install command dir option, -R,
rather than -r. The former is more portable.
scripts/Mercury.config.in:
Do not hardcode the set of library grades at configuration time.
compiler/mercury_compile.m:
Do not clear the library grade set before adding any detected
grades since doing so also prevents additional grades being
specified via the LIBGRADES variable.
doc/user_guide.texi:
Document --no-detect-libgrades.
Replace some uses of `:' as a module qualifier.
Fix a typo: s/outut/output/.
On Solaris, the 'which' utility does not return a non-zero exit status
to indicate that the program (in this case, "mfiltercc") was not found,
so we ended up treating its error message output as a path.
scripts/mgnuc.in:
Don't use 'which'. Simply try to run any copy of mfiltercc on
the PATH, with empty input.
Add a `pregen' grade component and associated option `--pregenerated-dist',
intended for use in the pre-generated C files in the source distribution
ONLY.
Traditionally, by forcing the use of 2 tag bits and boxed floats, we
could provide one set of pre-generated C files, nominally targeting
32-bit platforms but also working on 64-bit platforms.
This became insufficient after I made two data representation changes.
The same constructor may have different layouts of its arguments
for --bits-per-word=32 and --bits-per-word=64:
- double-precision `float' arguments can be stored across two
words on 32-bit, whereas only one word is required on 64-bit;
- consecutive enum arguments can be packed into a single word
but the number of arguments that can be packed differs.
As a result, data structures created in a user module could be
misinterpreted when passed to a pre-generated standard library module,
and vice versa. (The enum case probably does not occur in practice.)
The solution adopted here is to allow configure to detect normal 64-bit
settings (3 tag bits, unboxed floats) irrespective of whether a usable
Mercury installation already exists. When present, the `pregen' grade
component causes the compiler and scripts to override the configuration
and enforce settings for portable C source files. The source
distribution should supply C source files from a `pregen' grade.
During installation, if required, the pre-generated C source files are
used to build and install a Mercury compiler _in a .pregen grade_.
Then it is used to install the libraries _in non-.pregen grades_,
so that configured settings have their usual effect.
Another benefit is that a user on a 64-bit system will get the "optimal"
installation using 3 tag bits and unboxed floats without additional
effort.
A small disadvantage is that a minimal installation of Mercury takes
slightly longer, as the default library grade no longer comes from the
pre-generated C source files.
compiler/options.m:
Add `--pregenerated-dist' option (same as `pregen' grade component).
Add `--arg-pack-bits <n>' internal option.
`--allow-argument-packing' is obsolete.
Add `--allow-double-word-fields' internal option.
compiler/handle_options.m:
Add `pregen' grade component. `pregen' implies boxed floats and
`spf' (single-prec float) implies unboxed floats, so we consider
them incompatible. There should be no need to use both at once.
In `pregen' grades, override settings to create portable C
source files.
Handle the internal `--arg-pack-bits <n>' option.
compiler/make_hlds_passes.m:
Pack only as many consecutive arguments as will fit into the
number of bits specified by `--arg-pack-bits', rather than into
the number of word bits. `pregen' implies --arg-pack-bits=32
Use `--allow-double-word-fields' to decide whether to store
floats across two words. `pregen' disables it.
compiler/compile_target_code.m:
Define MR_PREGENERATED_DIST when compiling C files in a `pregen'
grade.
compiler/c_util.m:
Write PREGENERATED_DIST={yes,no} into the grade info header at
the top of C files. This is checked by configure.
runtime/mercury_conf_param.h:
Make MR_PREGENERATED_DIST force the same settings as the
`--pregenerated-dist' option.
runtime/mercury_grade.h:
Add "_pregen" to the MR_GRADE macro so that `pregen' and
non-`pregen' object files are not accidentally mixed.
configure.ac:
As above, do NOT force 2 tag bits and unboxed floats when there
is no usable Mercury compiler installed.
BOOTSTRAP_GRADE is now a grade containing `.pregen'.
Make a minimal installation install $BEST_GRADE_FOR_COMPILER as
the default grade, not the grade that the compiler happens to be
built in, which might be a `pregen' grade.
scripts/canonical_grade.sh-subr:
scripts/init_grade_options.sh-subr:
scripts/mgnuc.in:
scripts/parse_grade_options.sh-subr:
Support `pregen' grade component and `--pregenerated-dist'
in shell scripts.
tools/test_mercury:
Add a note.
As discussed in the recent Mercury meeting, remove support for the GCC backend.
It was very much out of date and supporting it proprerly would means having to
track changes to GCC's internals. Furthermore, its presence complicates
building the compiler.
The main thing this change does not address is the fact that we invoke
the compiler through C code, e.g. main.c in the top-level of the source
tree. This was required by the GCC backend and can now be removed, but
I will do that as a separate change.
configure.ac:
Mmake.common.in:
scripts/Mmake.rules:
compiler/Mercury.options:
compiler/Mmakefile:
compiler/gcc.m:
compiler/maybe_mlds_to_gcc.pp:
compiler/mlds_to_gcc.m:
Delete the files containing the GCC backend.
compiler/options.m:
compiler/handle_options.m:
Delete support for `--target asm' and `--pic'.
(The latter was only used by the GCC backend.)
compiler/*.m:
doc/user_guide.texi:
compiler/notes/comiler_design.html:
compiler/notes/work_in_progress.m:
Conform to the above change.
README.gcc-backend.m:
Delete this file.
configure.in:
Rename this to configure.ac which is what current versions
of autotools expect and also doesn't cause warnings to be
emitted by aclocal.
Mmakefile:
scripts/ml.in:
Conform to the above change.
Delete the empty lazy_evaluation directory from extras.
*/.cvsignore:
Make this into .gitignore files.
(Update them where necessary.)
extra/lazy_evalution:
Delete this directory; its former contents were moved
elsewhere some time ago.
Estimated hours taken: 2
Branches: main, 12.08
Sign the all the assemblies in the csharp grade.
mercury.snk:
The strong name key used for signing.
analysis/ANALYSIS_FLAGS.in:
browser/MDB_FLAGS.in:
compiler/COMP_FLAGS.in:
deep_profiler/DEEP_FLAGS.in:
library/LIB_FLAGS.in:
mdbcomp/MDBCOMP_FLAGS.in:
profiler/PROF_FLAGS.in:
slice/SLICE_FLAGS.in:
ssdb/SSDB_FLAGS.in:
Pass the signing key to the c# compiler.
scripts/prepare_install_dir.in:
Copy mercury.snk to the install dir.
