This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: fix build errors with -DNDEBUG
- From: Martin Sebor <msebor at gmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Andreas Schwab <schwab at linux-m68k dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 20 Jul 2015 21:39:26 -0600
- Subject: Re: fix build errors with -DNDEBUG
- Authentication-results: sourceware.org; auth=none
- References: <55A83361 dot 6010506 at gmail dot com> <20150717020539 dot GF5641 at vapier> <87pp3r9lco dot fsf at igel dot home> <20150720072047 dot GO5641 at vapier> <55ACF099 dot 4050301 at redhat dot com>
On 07/20/2015 06:59 AM, Carlos O'Donell wrote:
On 07/20/2015 03:20 AM, Mike Frysinger wrote:
On 17 Jul 2015 11:36, Andreas Schwab wrote:
Mike Frysinger <vapier@gentoo.org> writes:
we have __attribute_used__ ...
That's actually obsolete now that we require gcc >= 4.6.
right, for internal source files. __attribute_used__ is kept around though for
public headers since we don't require newer gcc versions to build against glibc.
which leads to me forgetting and always using the defines both in internal and
in public code (better than forgetting and never using the defines even in the
public headers?).
-mike
Yes it is better :-)
We should make our internal headers cause a warning to be emitted if you use
obsolete attributes given the newly required gcc to build glibc, but we haven't
gotten around to it.
I'm not sure what guidance to take from this discussion.
Is the request to replace __attribute__ ((unused)) with
__attribute_used__ in this patch or is it okay to commit
as is?
FWIW: I chose __attribute__((used)) based on its prevalent
number of occurrences in GLIBC .c and .h files: I counted
322 instances of it, versus only 17 of __attribute_used__.
I have no problem changing it to __attribute_used__ for
this patch, and I would also be happy to submit a followup
patch to replace existing occurrences of __attribute__
((used)) with __attribute_used__ if that's viewed as useful
(I can see how having the same name expand to the appropriate
attribute given the GCC version used to compile each file,
either internal to GLIBC or public, would simplify its use).
Martin