[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