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

[Julien Fischer]

On Mon, 5 Jul 2010, Ian MacLarty wrote:

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

Is this still the case if you disable the C compiler optimizations, e.g.
compile with gcc -O0?  If it's not, then does the number of symbols
exported from the object file increase in the case where you removed
the static?

Julien.