This is the mail archive of the
mailing list for the GDB project.
Re: many unused function warnings in gdb 7.9 on darwin
- From: Jack Howarth <howarth dot mailing dot lists at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Thu, 26 Feb 2015 14:41:32 -0500
- Subject: Re: many unused function warnings in gdb 7.9 on darwin
- Authentication-results: sourceware.org; auth=none
- References: <CADtEn-0a2XqyNySrYL-OrC=yYvBs_uuVFNnJE5KdHt_-7FHsaA at mail dot gmail dot com> <54EEF2D4 dot 2000602 at redhat dot com> <CADtEn-3Bg+ByB0bWyBodqa6V8QwHCoYsoFY_Eemmh0nNAwwLgw at mail dot gmail dot com>
The clang developers have comments on this issue in
http://llvm.org/bugs/show_bug.cgi?id=22712#c1. They ask (as I did
originally) why we aren't wrapping these functions to keep them from
being declared on darwin if they aren't used.
On Thu, Feb 26, 2015 at 11:26 AM, Jack Howarth
> Filed http://llvm.org/bugs/show_bug.cgi?id=22712 on this issue.
> On Thu, Feb 26, 2015 at 5:17 AM, Pedro Alves <firstname.lastname@example.org> wrote:
>> On 02/24/2015 04:33 PM, Jack Howarth wrote:
>>> Building the gdb 7.9 release on x86_64-apple-darwin14 produces many
>>> warnings of the form...
>>> remote.c:2567:1: warning: unused function
>>> 'VEC_thread_item_t_embedded_size' [-Wunused-function]
>>> ./common/vec.h:435:20: note: expanded from macro 'DEF_VEC_O'
>>> VEC_T(T); \
>>> ./common/vec.h:863:22: note: expanded from macro '\
>>> static inline size_t VEC_OP (T,embedded_size) \
>>> ./common/vec.h:399:22: note: expanded from macro 'VEC_OP'
>>> #define VEC_OP(T,OP) VEC_##T##_##OP
>>> <scratch space>:55:1: note: expanded from here
>>> Shouldn't those VEC declarations use a wrapper to avoid them on
>>> targets not supporting that code?
>> AFAIK, -Wunused-function is supposed to be suppressed for
>> "static inline" functions:
>> Warn whenever a static function is declared but not defined
>> or a non-inline static function is unused. This warning is
>> enabled by -Wall.
>> Looks like a clang bug here?
>> (I suspect marking the function with attribute used would
>> work around this.)
>> Pedro Alves