This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- From: Florian Weimer <fweimer at redhat dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: neleai at seznam dot cz, eggert at cs dot ucla dot edu, libc-alpha at sourceware dot org
- Date: Thu, 09 Apr 2015 08:05:14 +0200
- Subject: Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- Authentication-results: sourceware.org; auth=none
- References: <550C37F7 dot 10504 at redhat dot com> <20150403162531 dot GA25408 at domone> <55258979 dot 7090405 at redhat dot com> <20150408 dot 225641 dot 1204595664948399536 dot davem at davemloft dot net>
On 04/09/2015 04:56 AM, David Miller wrote:
> The first problem is that 1ULL << 32 doesn't fit in a size_t,
> therefore gcc complains about the value being implicitly
> truncated to an unsigned type.
>
> For that, I think these >=1<<32 value tests should simply be elided on
> 32-bit systems.
It's just a matter of adding a cast to size_t, at least on i386 with GCC
4.9.2.
> Secondly I get inlining failure warnings for the scratch_buffer_free
> calls in do_test(). I do not have a recommendation for how to solve
> that. Frankly I think if something can't be inlined, in many cases
> that's fine and opaque details of gcc's inlining heuristics shouldn't
> fail the build ever.
What's the exact failure? Does it refuse to inline because it's not a
hot path?
I could add __always_inline, which should address, at the cost of worse
code. Or I could move scratch_buffer_free out of line.
> These warnings failing the build are generally very frustrating, and
> they have been so for those of us who have limited time to work on
> glibc arch maintainence. We come in to attack a specific problem and
> find that we can't even begin to do so because the tree doesn't even
> build due to some obscure warning that the developer who installed the
> warning causing change doesn't even see.
Yes, I cautioned against enabling optimizer-dependent warnings (which
includes certain inline failure warnings) for -Werror because they are a
pain to deal with.
--
Florian Weimer / Red Hat Product Security