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

[Ian MacLarty]

On Mon, Jul 05, 2010 at 03:18:38PM +1000, Paul Bone wrote:
> On Mon, Jul 05, 2010 at 02:35:32PM +1000, Ian MacLarty wrote:
> > On Mon, Jul 5, 2010 at 2:21 PM, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > > On Mon, Jul 05, 2010 at 02:04:23PM +1000, Ian MacLarty wrote:
> > >>
> > >> 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:
> > >
> > > Why is there a static definition but no declaration?  In other words, are these
> > > symbols really indented to be static?
> > >
> > 
> > There is a static declaration.  It is the definition that is missing.
> > I'm not sure if the static keyword makes any difference if the
> > function is defined in assembler.  It doesn't appear to (running nm on
> > the .o files yields the same results).
> >
> > > If this is true then they should be created using a different preprocessor
> > > macro, rather than making a static macro create non-static declarations.
> > >
> > 
> > Yes I know.  That was just a hack I used to test my theory.
> 
> Ah, okay.
> 
> > > Alternativly, is there a missing (static) definition of these symbols?  I
> > > wouldn't think so otherwise the linker wuld fail to link the executable.  Can
> > > GCC see the static definitions if they exist?
> > 
> > The definition, as far as I can tell, is done with some inline
> > assembler.  There is no C code definition of the function, which is
> > why gcc complains.
> 
> In that case I'm happy to use a new macro that doesn't make the definition
> static.
> 

I don't want to change the compiler code to emit a different macro
depending on whether we're using asm labels or not, because,
as I understand it, the compiler should emit the same code for
all the low level grades and the differences between the grades should
be hidden behind macros.  This allows us to build in none.gc, reg.gc or
asm_fast.gc from the same source distribution.  I could change the name
of the MR_decl_static and MR_declare_static macros, but what to?
(MR_decl_local is already used for something else).

Here is my current proposal for a fix:

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 05:25:15 -0000
@@ -876,8 +876,12 @@
   #if defined(MR_USE_ASM_LABELS)
     #define MR_declare_entry(label)					\
 	extern void label(void) __asm__("_entry_" MR_STRINGIFY(label))
+    /* When using asm labels, we don't create a static declaration, */
+    /* because the lack of a C implementation for the function will */
+    /* cause GCC 4.x to issue warnings about the function being used */
+    /* and not defined. */
     #define MR_declare_static(label)					\
-	static void label(void) __asm__("_entry_" MR_STRINGIFY(label))
+	MR_declare_entry(label)
     #define MR_define_extern_entry(label)	MR_declare_entry(label)
     #define MR_define_entry(label)					\
 		MR_ASM_ENTRY(label)					\
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------