Created attachment 77987 [details] test code When Clang compiles source code including valgrind/memcheck.h and using VALGRIND_MAKE_MEM_DEFINED and VALGRIND_MAKE_MEM_NOACCESS, it issues -Wunused-value warning like this: In file included from vm/capi/handle.cpp:3: vm/gc/baker.hpp:274:7: error: expression result unused [-Werror,-Wunused-value] VALGRIND_MAKE_MEM_NOACCESS(next->start().as_int(), next->size()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/valgrind/memcheck.h:110:5: note: expanded from: VALGRIND_DO_CLIENT_REQUEST_EXPR(0 /* default return */, \ ^ /usr/include/valgrind/valgrind.h:383:5: note: expanded from: _zzq_result; \ ^~~~~~~~~~~ This shouldn't happen. Maybe, this is related to https://bugs.kde.org/show_bug.cgi?id=284384 There may be more additional macros which should be converted to VALGRIND_DO_CLIENT_REQUEST_STMT than just mentioned above. I attached a test code for this. To test it, run like this and Clang should issue a warning: $ clang -Wunused-value /tmp/unused-warning.c For your information, experienced this while building Rubinius.
For your information, I also just commited workaround fixes to Rubinius itself: https://github.com/rubinius/rubinius/commit/3981b1d0152b5a1bd0e6fb7a6ad01256ba415335
VALGRIND_MAKE_MEM_NOACCESS is an expression that returns a value (probably an indication whether the client call was successful or not). We cannot change these macros to use VALGRIND_DO_CLIENT_REQUEST_STMT (which does not return a value). That would break the ABI and existing code. I'm afraid, you'll have to silence the clang warnings yourself.
Thanks for detailed explanation. I'm really happy with your quick reply! If these macros return a status-like value, I want to check it avoiding warnings. But I think there is inconsistency between your explanation and the official documentation (http://valgrind.org/docs/manual/mc-manual.html), which I've read: VALGRIND_MAKE_MEM_NOACCESS, VALGRIND_MAKE_MEM_UNDEFINED and VALGRIND_MAKE_MEM_DEFINED. These mark address ranges as completely inaccessible, accessible but containing undefined data, and accessible and containing defined data, respectively. There is no explit statement about the return value of these macros. So I thought they return nothing just like other related macros (for example, VALGRIND_CHECK_VALUE_IS_DEFINED), which have explicit statement for nothing returned. Is that just a missing documentation, or else? Could you clarify about this? Thanks alot!
Sorry for repeated comments, but guessing from your comment, I just noticed that the macros return 0 when succedded probably, looking at memcheck.h again: #define VALGRIND_MAKE_MEM_NOACCESS(_qzz_addr,_qzz_len) \ VALGRIND_DO_CLIENT_REQUEST_EXPR(0 /* default return */, \ VG_USERREQ__MAKE_MEM_NOACCESS, \ (_qzz_addr), (_qzz_len), 0, 0, 0) You are right. I thought "0 /* default return */" is implementation details. I should have investigated about this more... Maybe, could you update the official documentation a bit about return value for other people?
There should be no warning from a compiler about VALGRIND_MAKE_MEM_NOACCESS when its return value is not assigned or used to initialise something. The reason is that the macro expands to this thing here: __extension__ ({ volatile unsigned long long int _zzq_args[6]; volatile unsigned long long int _zzq_result; _zzq_args[0] = (unsigned long long int)(VG_USERREQ__MAKE_MEM_UNDEFINED); _zzq_args[1] = (unsigned long long int)((&X)); _zzq_args[2] = (unsigned long long int)((sizeof X)); _zzq_args[3] = (unsigned long long int)(0); _zzq_args[4] = (unsigned long long int)(0); _zzq_args[5] = (unsigned long long int)(0); __asm__ volatile("rolq $3, %%rdi ; rolq $13, %%rdi\n\t" "rolq $61, %%rdi ; rolq $51, %%rdi\n\t" "xchgq %%rbx,%%rbx" : "=d" (_zzq_result) : "a" (&_zzq_args[0]), "0" (0) : "cc", "memory" ); _zzq_result; }); and the value of the statement expression is the value of _zzq_result which is a volatile qualifed variable. So fetching its value constitutes a side effect the details of which are unknown to the compiler. So it should shut up.... And stock clang 3.4.2 issues no warning here (with -Wunused-value). An BTW, that macro returns -1, not 0.... I updated the documentation in revision 14089.