|
From: <sv...@va...> - 2010-07-29 07:54:05
|
Author: bart
Date: 2010-07-29 08:53:57 +0100 (Thu, 29 Jul 2010)
New Revision: 11238
Log:
Avoid that gcc 4.5.x reports the warning "taking address of expression of type void".
Modified:
trunk/coregrind/pub_core_dispatch.h
trunk/coregrind/pub_core_trampoline.h
Modified: trunk/coregrind/pub_core_dispatch.h
===================================================================
--- trunk/coregrind/pub_core_dispatch.h 2010-07-29 07:52:37 UTC (rev 11237)
+++ trunk/coregrind/pub_core_dispatch.h 2010-07-29 07:53:57 UTC (rev 11238)
@@ -68,8 +68,8 @@
following somewhat bogus decls. At least on x86 and amd64. ppc32
and ppc64 use straightforward bl-blr to get from dispatcher to
translation and back and so do not need these labels. */
-extern void VG_(run_innerloop__dispatch_unprofiled);
-extern void VG_(run_innerloop__dispatch_profiled);
+extern void VG_(run_innerloop__dispatch_unprofiled)( void );
+extern void VG_(run_innerloop__dispatch_profiled)( void );
#endif
@@ -86,7 +86,7 @@
/* We need to a label inside VG_(run_a_noredir_translation), so that
Vex can add branches to them from generated code. Hence the
following somewhat bogus decl. */
-extern void VG_(run_a_noredir_translation__return_point);
+extern void VG_(run_a_noredir_translation__return_point)( void );
#endif
Modified: trunk/coregrind/pub_core_trampoline.h
===================================================================
--- trunk/coregrind/pub_core_trampoline.h 2010-07-29 07:52:37 UTC (rev 11237)
+++ trunk/coregrind/pub_core_trampoline.h 2010-07-29 07:53:57 UTC (rev 11238)
@@ -53,32 +53,32 @@
readable, at least. Otherwise Memcheck complains we're jumping to
invalid addresses. */
-extern void VG_(trampoline_stuff_start);
-extern void VG_(trampoline_stuff_end);
+extern void VG_(trampoline_stuff_start)( void );
+extern void VG_(trampoline_stuff_end)( void );
#if defined(VGP_x86_linux)
-extern void VG_(x86_linux_SUBST_FOR_sigreturn);
-extern void VG_(x86_linux_SUBST_FOR_rt_sigreturn);
+extern void VG_(x86_linux_SUBST_FOR_sigreturn)( void );
+extern void VG_(x86_linux_SUBST_FOR_rt_sigreturn)( void );
extern Char* VG_(x86_linux_REDIR_FOR_index) ( const Char*, Int );
#endif
#if defined(VGP_amd64_linux)
-extern void VG_(amd64_linux_SUBST_FOR_rt_sigreturn);
-extern void VG_(amd64_linux_REDIR_FOR_vgettimeofday);
-extern void VG_(amd64_linux_REDIR_FOR_vtime);
+extern void VG_(amd64_linux_SUBST_FOR_rt_sigreturn)( void );
+extern void VG_(amd64_linux_REDIR_FOR_vgettimeofday)( void );
+extern void VG_(amd64_linux_REDIR_FOR_vtime)( void );
extern UInt VG_(amd64_linux_REDIR_FOR_strlen)( void* );
#endif
#if defined(VGP_ppc32_linux)
-extern void VG_(ppc32_linux_SUBST_FOR_sigreturn);
-extern void VG_(ppc32_linux_SUBST_FOR_rt_sigreturn);
+extern void VG_(ppc32_linux_SUBST_FOR_sigreturn)( void );
+extern void VG_(ppc32_linux_SUBST_FOR_rt_sigreturn)( void );
extern UInt VG_(ppc32_linux_REDIR_FOR_strlen)( void* );
extern UInt VG_(ppc32_linux_REDIR_FOR_strcmp)( void*, void* );
extern void* VG_(ppc32_linux_REDIR_FOR_strchr)( void*, Int );
#endif
#if defined(VGP_ppc64_linux)
-extern void VG_(ppc64_linux_SUBST_FOR_rt_sigreturn);
+extern void VG_(ppc64_linux_SUBST_FOR_rt_sigreturn)( void );
extern UInt VG_(ppc64_linux_REDIR_FOR_strlen)( void* );
extern void* VG_(ppc64_linux_REDIR_FOR_strchr)( void*, Int );
/* A label (sans dot) marking the ultra-magical return stub via which
@@ -88,7 +88,7 @@
restore the thread's LR and R2 registers from a small stack in the
ppc64 guest state structure, and then branch to LR. Convoluted?
Confusing? You betcha. Could I think of anything simpler? No. */
-extern void VG_(ppctoc_magic_redirect_return_stub);
+extern void VG_(ppctoc_magic_redirect_return_stub)( void );
#endif
#if defined(VGP_arm_linux)
@@ -105,22 +105,22 @@
then it cleans up the register state to be more what it really
should be at client startup, and finally it jumps to the client's
real entry point. */
-extern void VG_(ppc32_aix5_do_preloads_then_start_client);
+extern void VG_(ppc32_aix5_do_preloads_then_start_client)( void );
/* See comment for VG_(ppctoc_magic_redirect_return_stub) above. */
-extern void VG_(ppctoc_magic_redirect_return_stub);
+extern void VG_(ppctoc_magic_redirect_return_stub)( void );
#endif
#if defined(VGP_ppc64_aix5)
/* See comment for VG_(ppctoc_magic_redirect_return_stub) above. */
-extern void VG_(ppctoc_magic_redirect_return_stub);
+extern void VG_(ppctoc_magic_redirect_return_stub)( void );
/* See comment for ppc32_aix5 equivalent above. */
-extern void VG_(ppc64_aix5_do_preloads_then_start_client);
+extern void VG_(ppc64_aix5_do_preloads_then_start_client)( void );
#endif
#if defined(VGP_x86_darwin)
-extern void VG_(x86_darwin_SUBST_FOR_sigreturn);
+extern void VG_(x86_darwin_SUBST_FOR_sigreturn)( void );
extern SizeT VG_(x86_darwin_REDIR_FOR_strlen)( void* );
extern SizeT VG_(x86_darwin_REDIR_FOR_strcmp)( void*, void* );
extern void* VG_(x86_darwin_REDIR_FOR_strcat)( void*, void * );
@@ -130,7 +130,7 @@
#endif
#if defined(VGP_amd64_darwin)
-extern void VG_(amd64_darwin_SUBST_FOR_sigreturn);
+extern void VG_(amd64_darwin_SUBST_FOR_sigreturn)( void );
extern SizeT VG_(amd64_darwin_REDIR_FOR_strlen)( void* );
extern SizeT VG_(amd64_darwin_REDIR_FOR_strcmp)( void*, void* );
extern void* VG_(amd64_darwin_REDIR_FOR_strcat)( void*, void * );
|
|
From: Julian S. <js...@ac...> - 2010-07-29 08:07:09
|
This might (or might not) break ppc64-linux, since on that platform, &function does not return the entry point of the function's code, but instead the address of the descriptor. Hence the change from "&label" to "&function" may change the meaning of the resulting address. J On Thursday, July 29, 2010, sv...@va... wrote: > Author: bart > Date: 2010-07-29 08:53:57 +0100 (Thu, 29 Jul 2010) > New Revision: 11238 > > Log: > Avoid that gcc 4.5.x reports the warning "taking address of expression of > type void". > > > Modified: > trunk/coregrind/pub_core_dispatch.h > trunk/coregrind/pub_core_trampoline.h > > > Modified: trunk/coregrind/pub_core_dispatch.h > =================================================================== > --- trunk/coregrind/pub_core_dispatch.h 2010-07-29 07:52:37 UTC (rev 11237) > +++ trunk/coregrind/pub_core_dispatch.h 2010-07-29 07:53:57 UTC (rev 11238) > @@ -68,8 +68,8 @@ > following somewhat bogus decls. At least on x86 and amd64. ppc32 > and ppc64 use straightforward bl-blr to get from dispatcher to > translation and back and so do not need these labels. */ > -extern void VG_(run_innerloop__dispatch_unprofiled); > -extern void VG_(run_innerloop__dispatch_profiled); > +extern void VG_(run_innerloop__dispatch_unprofiled)( void ); > +extern void VG_(run_innerloop__dispatch_profiled)( void ); > #endif > > > @@ -86,7 +86,7 @@ > /* We need to a label inside VG_(run_a_noredir_translation), so that > Vex can add branches to them from generated code. Hence the > following somewhat bogus decl. */ > -extern void VG_(run_a_noredir_translation__return_point); > +extern void VG_(run_a_noredir_translation__return_point)( void ); > #endif > > > > Modified: trunk/coregrind/pub_core_trampoline.h > =================================================================== > --- trunk/coregrind/pub_core_trampoline.h 2010-07-29 07:52:37 UTC (rev > 11237) +++ trunk/coregrind/pub_core_trampoline.h 2010-07-29 07:53:57 UTC > (rev 11238) @@ -53,32 +53,32 @@ > readable, at least. Otherwise Memcheck complains we're jumping to > invalid addresses. */ > > -extern void VG_(trampoline_stuff_start); > -extern void VG_(trampoline_stuff_end); > +extern void VG_(trampoline_stuff_start)( void ); > +extern void VG_(trampoline_stuff_end)( void ); > > #if defined(VGP_x86_linux) > -extern void VG_(x86_linux_SUBST_FOR_sigreturn); > -extern void VG_(x86_linux_SUBST_FOR_rt_sigreturn); > +extern void VG_(x86_linux_SUBST_FOR_sigreturn)( void ); > +extern void VG_(x86_linux_SUBST_FOR_rt_sigreturn)( void ); > extern Char* VG_(x86_linux_REDIR_FOR_index) ( const Char*, Int ); > #endif > > #if defined(VGP_amd64_linux) > -extern void VG_(amd64_linux_SUBST_FOR_rt_sigreturn); > -extern void VG_(amd64_linux_REDIR_FOR_vgettimeofday); > -extern void VG_(amd64_linux_REDIR_FOR_vtime); > +extern void VG_(amd64_linux_SUBST_FOR_rt_sigreturn)( void ); > +extern void VG_(amd64_linux_REDIR_FOR_vgettimeofday)( void ); > +extern void VG_(amd64_linux_REDIR_FOR_vtime)( void ); > extern UInt VG_(amd64_linux_REDIR_FOR_strlen)( void* ); > #endif > > #if defined(VGP_ppc32_linux) > -extern void VG_(ppc32_linux_SUBST_FOR_sigreturn); > -extern void VG_(ppc32_linux_SUBST_FOR_rt_sigreturn); > +extern void VG_(ppc32_linux_SUBST_FOR_sigreturn)( void ); > +extern void VG_(ppc32_linux_SUBST_FOR_rt_sigreturn)( void ); > extern UInt VG_(ppc32_linux_REDIR_FOR_strlen)( void* ); > extern UInt VG_(ppc32_linux_REDIR_FOR_strcmp)( void*, void* ); > extern void* VG_(ppc32_linux_REDIR_FOR_strchr)( void*, Int ); > #endif > > #if defined(VGP_ppc64_linux) > -extern void VG_(ppc64_linux_SUBST_FOR_rt_sigreturn); > +extern void VG_(ppc64_linux_SUBST_FOR_rt_sigreturn)( void ); > extern UInt VG_(ppc64_linux_REDIR_FOR_strlen)( void* ); > extern void* VG_(ppc64_linux_REDIR_FOR_strchr)( void*, Int ); > /* A label (sans dot) marking the ultra-magical return stub via which > @@ -88,7 +88,7 @@ > restore the thread's LR and R2 registers from a small stack in the > ppc64 guest state structure, and then branch to LR. Convoluted? > Confusing? You betcha. Could I think of anything simpler? No. */ > -extern void VG_(ppctoc_magic_redirect_return_stub); > +extern void VG_(ppctoc_magic_redirect_return_stub)( void ); > #endif > > #if defined(VGP_arm_linux) > @@ -105,22 +105,22 @@ > then it cleans up the register state to be more what it really > should be at client startup, and finally it jumps to the client's > real entry point. */ > -extern void VG_(ppc32_aix5_do_preloads_then_start_client); > +extern void VG_(ppc32_aix5_do_preloads_then_start_client)( void ); > > /* See comment for VG_(ppctoc_magic_redirect_return_stub) above. */ > -extern void VG_(ppctoc_magic_redirect_return_stub); > +extern void VG_(ppctoc_magic_redirect_return_stub)( void ); > #endif > > #if defined(VGP_ppc64_aix5) > /* See comment for VG_(ppctoc_magic_redirect_return_stub) above. */ > -extern void VG_(ppctoc_magic_redirect_return_stub); > +extern void VG_(ppctoc_magic_redirect_return_stub)( void ); > > /* See comment for ppc32_aix5 equivalent above. */ > -extern void VG_(ppc64_aix5_do_preloads_then_start_client); > +extern void VG_(ppc64_aix5_do_preloads_then_start_client)( void ); > #endif > > #if defined(VGP_x86_darwin) > -extern void VG_(x86_darwin_SUBST_FOR_sigreturn); > +extern void VG_(x86_darwin_SUBST_FOR_sigreturn)( void ); > extern SizeT VG_(x86_darwin_REDIR_FOR_strlen)( void* ); > extern SizeT VG_(x86_darwin_REDIR_FOR_strcmp)( void*, void* ); > extern void* VG_(x86_darwin_REDIR_FOR_strcat)( void*, void * ); > @@ -130,7 +130,7 @@ > #endif > > #if defined(VGP_amd64_darwin) > -extern void VG_(amd64_darwin_SUBST_FOR_sigreturn); > +extern void VG_(amd64_darwin_SUBST_FOR_sigreturn)( void ); > extern SizeT VG_(amd64_darwin_REDIR_FOR_strlen)( void* ); > extern SizeT VG_(amd64_darwin_REDIR_FOR_strcmp)( void*, void* ); > extern void* VG_(amd64_darwin_REDIR_FOR_strcat)( void*, void * ); > > > --------------------------------------------------------------------------- > --- The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Bart V. A. <bva...@ac...> - 2010-07-29 09:37:10
|
That was unintended, so I have reverted r11238. Would changing the declaration type from void to Addr be safe ? As far as I know gcc 4.5.0 does not allow to suppress the warning "taking address of expression of type void". Bart. On Thu, Jul 29, 2010 at 10:09 AM, Julian Seward <js...@ac...> wrote: > > This might (or might not) break ppc64-linux, since on that > platform, &function does not return the entry point of the > function's code, but instead the address of the descriptor. > Hence the change from "&label" to "&function" may change the > meaning of the resulting address. > > J > > On Thursday, July 29, 2010, sv...@va... wrote: > > Author: bart > > Date: 2010-07-29 08:53:57 +0100 (Thu, 29 Jul 2010) > > New Revision: 11238 > > > > Log: > > Avoid that gcc 4.5.x reports the warning "taking address of expression of > > type void". > > > > > > Modified: > > trunk/coregrind/pub_core_dispatch.h > > trunk/coregrind/pub_core_trampoline.h > > > > > > Modified: trunk/coregrind/pub_core_dispatch.h > > =================================================================== > > --- trunk/coregrind/pub_core_dispatch.h 2010-07-29 07:52:37 UTC > (rev > 11237) > > +++ trunk/coregrind/pub_core_dispatch.h 2010-07-29 07:53:57 UTC > (rev > 11238) > > @@ -68,8 +68,8 @@ > > following somewhat bogus decls. At least on x86 and amd64. ppc32 > > and ppc64 use straightforward bl-blr to get from dispatcher to > > translation and back and so do not need these labels. */ > > -extern void VG_(run_innerloop__dispatch_unprofiled); > > -extern void VG_(run_innerloop__dispatch_profiled); > > +extern void VG_(run_innerloop__dispatch_unprofiled)( void ); > > +extern void VG_(run_innerloop__dispatch_profiled)( void ); > > #endif > > > > > > @@ -86,7 +86,7 @@ > > /* We need to a label inside VG_(run_a_noredir_translation), so that > > Vex can add branches to them from generated code. Hence the > > following somewhat bogus decl. */ > > -extern void VG_(run_a_noredir_translation__return_point); > > +extern void VG_(run_a_noredir_translation__return_point)( void ); > > #endif > > > > > > > > Modified: trunk/coregrind/pub_core_trampoline.h > > =================================================================== > > --- trunk/coregrind/pub_core_trampoline.h 2010-07-29 07:52:37 UTC > (rev > > 11237) +++ trunk/coregrind/pub_core_trampoline.h 2010-07-29 07:53:57 > UTC > > (rev 11238) @@ -53,32 +53,32 @@ > > readable, at least. Otherwise Memcheck complains we're jumping to > > invalid addresses. */ > > > > -extern void VG_(trampoline_stuff_start); > > -extern void VG_(trampoline_stuff_end); > > +extern void VG_(trampoline_stuff_start)( void ); > > +extern void VG_(trampoline_stuff_end)( void ); > > > > #if defined(VGP_x86_linux) > > -extern void VG_(x86_linux_SUBST_FOR_sigreturn); > > -extern void VG_(x86_linux_SUBST_FOR_rt_sigreturn); > > +extern void VG_(x86_linux_SUBST_FOR_sigreturn)( void ); > > +extern void VG_(x86_linux_SUBST_FOR_rt_sigreturn)( void ); > > extern Char* VG_(x86_linux_REDIR_FOR_index) ( const Char*, Int ); > > #endif > > > > #if defined(VGP_amd64_linux) > > -extern void VG_(amd64_linux_SUBST_FOR_rt_sigreturn); > > -extern void VG_(amd64_linux_REDIR_FOR_vgettimeofday); > > -extern void VG_(amd64_linux_REDIR_FOR_vtime); > > +extern void VG_(amd64_linux_SUBST_FOR_rt_sigreturn)( void ); > > +extern void VG_(amd64_linux_REDIR_FOR_vgettimeofday)( void ); > > +extern void VG_(amd64_linux_REDIR_FOR_vtime)( void ); > > extern UInt VG_(amd64_linux_REDIR_FOR_strlen)( void* ); > > #endif > > > > #if defined(VGP_ppc32_linux) > > -extern void VG_(ppc32_linux_SUBST_FOR_sigreturn); > > -extern void VG_(ppc32_linux_SUBST_FOR_rt_sigreturn); > > +extern void VG_(ppc32_linux_SUBST_FOR_sigreturn)( void ); > > +extern void VG_(ppc32_linux_SUBST_FOR_rt_sigreturn)( void ); > > extern UInt VG_(ppc32_linux_REDIR_FOR_strlen)( void* ); > > extern UInt VG_(ppc32_linux_REDIR_FOR_strcmp)( void*, void* ); > > extern void* VG_(ppc32_linux_REDIR_FOR_strchr)( void*, Int ); > > #endif > > > > #if defined(VGP_ppc64_linux) > > -extern void VG_(ppc64_linux_SUBST_FOR_rt_sigreturn); > > +extern void VG_(ppc64_linux_SUBST_FOR_rt_sigreturn)( void ); > > extern UInt VG_(ppc64_linux_REDIR_FOR_strlen)( void* ); > > extern void* VG_(ppc64_linux_REDIR_FOR_strchr)( void*, Int ); > > /* A label (sans dot) marking the ultra-magical return stub via which > > @@ -88,7 +88,7 @@ > > restore the thread's LR and R2 registers from a small stack in the > > ppc64 guest state structure, and then branch to LR. Convoluted? > > Confusing? You betcha. Could I think of anything simpler? No. */ > > -extern void VG_(ppctoc_magic_redirect_return_stub); > > +extern void VG_(ppctoc_magic_redirect_return_stub)( void ); > > #endif > > > > #if defined(VGP_arm_linux) > > @@ -105,22 +105,22 @@ > > then it cleans up the register state to be more what it really > > should be at client startup, and finally it jumps to the client's > > real entry point. */ > > -extern void VG_(ppc32_aix5_do_preloads_then_start_client); > > +extern void VG_(ppc32_aix5_do_preloads_then_start_client)( void ); > > > > /* See comment for VG_(ppctoc_magic_redirect_return_stub) above. */ > > -extern void VG_(ppctoc_magic_redirect_return_stub); > > +extern void VG_(ppctoc_magic_redirect_return_stub)( void ); > > #endif > > > > #if defined(VGP_ppc64_aix5) > > /* See comment for VG_(ppctoc_magic_redirect_return_stub) above. */ > > -extern void VG_(ppctoc_magic_redirect_return_stub); > > +extern void VG_(ppctoc_magic_redirect_return_stub)( void ); > > > > /* See comment for ppc32_aix5 equivalent above. */ > > -extern void VG_(ppc64_aix5_do_preloads_then_start_client); > > +extern void VG_(ppc64_aix5_do_preloads_then_start_client)( void ); > > #endif > > > > #if defined(VGP_x86_darwin) > > -extern void VG_(x86_darwin_SUBST_FOR_sigreturn); > > +extern void VG_(x86_darwin_SUBST_FOR_sigreturn)( void ); > > extern SizeT VG_(x86_darwin_REDIR_FOR_strlen)( void* ); > > extern SizeT VG_(x86_darwin_REDIR_FOR_strcmp)( void*, void* ); > > extern void* VG_(x86_darwin_REDIR_FOR_strcat)( void*, void * ); > > @@ -130,7 +130,7 @@ > > #endif > > > > #if defined(VGP_amd64_darwin) > > -extern void VG_(amd64_darwin_SUBST_FOR_sigreturn); > > +extern void VG_(amd64_darwin_SUBST_FOR_sigreturn)( void ); > > extern SizeT VG_(amd64_darwin_REDIR_FOR_strlen)( void* ); > > extern SizeT VG_(amd64_darwin_REDIR_FOR_strcmp)( void*, void* ); > > extern void* VG_(amd64_darwin_REDIR_FOR_strcat)( void*, void * ); > > > > > > > --------------------------------------------------------------------------- > > --- The Palm PDK Hot Apps Program offers developers who use the > > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > > of $1 Million in cash or HP Products. Visit us here for more details: > > http://p.sf.net/sfu/dev2dev-palm > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |