[m-rev.] for review: deconstruct.named_arg for java

[Ian MacLarty]

On Fri, Jul 02, 2010 at 05:43:49PM +1000, Julien Fischer wrote:
>
> On Fri, 2 Jul 2010, Ian MacLarty wrote:
>
>> On Fri, Jul 2, 2010 at 3:58 AM, Julien Fischer
>> <juliensf at csse.unimelb.edu.au> wrote:
>>>
>>> On Wed, 30 Jun 2010, Peter Wang wrote:
>>>
>>>> Branches: main
>>>
>>> Is there any reason not to include this on the 10.04 branch?
>>>
>>
>> I can think of one:  it will delay the release even further.  If we're
>> going to change to a 6 monthly release cycle, we need to *not* add new
>> features to the release branch.  New features can go in the next
>> version.
>
> This one won't delay the release, and I think the more of the stdlib
> that 10.04 supports in the java (and erlang) grade(s) the better.
>
>> BTW is there anything holding up the release at the moment?
>
> Ideally, I wanted to improve the documentation in the user's guide for
> mmc --make, but it looks like I won't have time before I head overseas.
> (So, that can go into 10.04.1)
>
> In my view the remaining tasks for 10.04 are:
>
> * I want to sort out this issue with source distribution (bug #115)
>   that came up the other day.  (There is a workaround in place, but I am
>   currently testing a proper fix.)
>
> * Bug #153 needs to be looked at.
>
> * I have a reference manual change that documents MR_word_to_float and
>   friends that nees to go in.  (I also have an addition to
>   samples/c_interface that provides a more thorough illustration of the C
>   data passing conventions.)
>
> * I think we really need some examples of how to use the Java and Erlang
>   interfaces, in samples/java_interface and samples/erlang_interface.
>
> * zs is unhappy about the number of warnings that are generated by gcc
>   when compiling things in asm_fast.  (We should identify what is going
>   on here at least.)  (Someone suggested grepping the warnings out, but
>   I don't see how you can do that with mmc --make -- particularly on
>   systems that don't have grep!)
>

What seems to be happening is that functions are being declared with
a prototype like the following:

    static void mercury__tree234__LCMCpr_insert2_1_4_0(void) __asm__("_entry_" "mercury__tree234__LCMCpr_insert2_1_4_0")

and then being referred to without being defined in C code.
The functions are in fact defined using assembly code.

It seems to be the fact that the function is declared static that is
causing gcc to expect a definition of the function in the same file.
Removing the static keyword appears to fix the problem.

Here is the hack I used to test this:

Index: runtime/mercury_goto.h
===================================================================
RCS file: /home/mercury1/repository/mercury/runtime/mercury_goto.h,v
retrieving revision 1.54
diff -u -r1.54 mercury_goto.h
--- runtime/mercury_goto.h	4 Dec 2009 02:39:47 -0000	1.54
+++ runtime/mercury_goto.h	5 Jul 2010 03:52:05 -0000
@@ -877,7 +877,7 @@
     #define MR_declare_entry(label)					\
 	extern void label(void) __asm__("_entry_" MR_STRINGIFY(label))
     #define MR_declare_static(label)					\
-	static void label(void) __asm__("_entry_" MR_STRINGIFY(label))
+	void label(void) __asm__("_entry_" MR_STRINGIFY(label))
     #define MR_define_extern_entry(label)	MR_declare_entry(label)
     #define MR_define_entry(label)					\
 		MR_ASM_ENTRY(label)					\

I ran nm on tree234.o before and after this change and there was no
difference, so this change doesn't seem to cause extra symbols to be
exported.

Does anyone see any issues with this fix?  If not I'll try and convert
my hack into a proper fix.

Ian.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------