[mercury-users] 3 new questions

[Fergus Henderson]

On 20-Feb-2004, Dieter Büttner <judisun at t-online.de> wrote:
> maybe the more experienced mercury user can help:
> I am using mercury 0.11.1_beta_2004_02_12-1, installed via rpm on SuSE 
> professional 9.0.
> 
> 1. Is it true, that with Mercury I don't need to pay attention for
> programming tail-recursive, because the compiler will rearrange the
> code and make it tail-recursive?  

In general, no.  If you want to be sure that your loops will run in constant
space, then you do need to take some care in the way that you write them
in order to ensure that they will be tail recursive.

> 2. Sometimes , when compiling via mmake  --use-subdirs I get a lot of warnings
> "dereferencing type-punned pointer will break strict-aliasing rules"
> What does it mean? What was wrong with the code?

The C code generated by the Mercury compiler in the low-level C grades,
e.g. asm_fast.gc, essentially treats memory as an array of "words",
where a "word" is a pointer-sized unit of data which in C we represent
using our "MR_Word" data type, which is a typedef for an unsigned integral
type of the appropriate size.

In some places the generated code casts a pointer of one type to a
word pointer ("MR_Word *") or vice versa, and then dereferences the
resulting pointer.  Technically this may violate a provision of the
ANSI/ISO C standard, which only allow this kind of type punning if
the pointer being dereferenced is a pointer to a character type.
The specific requirement in question is C99 section 6.5 paragraph 7.
The GCC warning is not a definite indication that the code violates
that provision, because there are some false positives with this warning,
but it does indicate that the code might violate that provision.

C compilers are allowed to use that provision to optimize the generated
code, for example by assuming that pointers to different types will not
alias each other.  There have been several changes in recent versions of
GNU C related to this:

	- Firstly, GNU C 3.0 and later now take advantage of the ANSI/ISO
	  C requirement for optimization, unless the -fno-strict-aliasing
	  option is used.

	- Secondly, GNU C 3.something (3.4??) and later will issue
	  warnings when the C compiler notices that the code it is
	  compiling violates this requirement.

	- Thirdly, GNU C 3.3 provides a new attribute "may_alias", which
	  you can put on a type.  This tells C compiler that it should
	  this type like a character type for the purposes of aliasing,
	  in other words that it should allow pointers to this type to
	  alias with pointers to any other type.

So, the upshot of all this is as follows:

	- We should modify the Mercury header files so that the "MR_Word"
	  type is declared with the "may_alias" attribute, for GCC versions
	  3.3 and later.

	- If you are compiling Mercury code with recent versions of GCC
	  (those that support the "-fno-strict-aliasing" option), and
	  you are using Mercury's low-level C back-end, then you should
	  use the "-fno-strict-aliasing" option.  Currently this must
	  be done manually.  In future, we should modify the Mercury
	  distribution so that "mmc" and "mgnuc" do this automatically,
	  for GCC versions that support "-fno-strict-aliasing" but which
	  do not support the "may_alias" attribute.

	- If you are compiling Mercury code with a C compiler other
	  than GCC, and this compiler performs optimizations that
	  rely on the C standard's type-based aliasing restrictions,
	  then you should use the Mercury compiler's high-level C grades,
	  or disable your C compiler's optimizations, or use its
	  equivalent to GCC's "-fno-strict-aliasing" if it has one.

> 3. To debug, I put the following statement in a file Mmakefile: 
> GRADEFLAGS=--debug, then mmake --use-subdirs prog.depend,
> then mmake --use-subdirs prog. But the last step provides the message 
> "cannot find -ltermcap". But termcap is installed!

My guess is that you are linking statically (this currently the default
when using mmake on Linux, for reasons explained in the README.Linux file),
but you only have the shared version of the termcap library installed,
not the static version.

Either install the package which contains the static (.a) version of
libtermcap -- I think this might be named "termcapdev" or something like
that? -- or enable shared linking, as described in README.Linux.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------