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

Ian MacLarty maclarty at csse.unimelb.edu.au
Mon Jul 5 14:45:09 AEST 2010


On Mon, Jul 5, 2010 at 2:04 PM, Ian MacLarty
<maclarty at csse.unimelb.edu.au> wrote:
> 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.
>

In fact the .o files are byte-for-byte equivalent with/without the
static keyword.

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
--------------------------------------------------------------------------



More information about the reviews mailing list