This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Initialize the entire obstack struct [BZ #17919]
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org, bug-gnulib at gnu dot org
- Date: Tue, 03 Feb 2015 11:49:26 -0500
- Subject: Re: [PATCH] Initialize the entire obstack struct [BZ #17919]
- Authentication-results: sourceware.org; auth=none
- References: <20150203145649 dot GG1528 at spoyarek dot pnq dot redhat dot com> <54D0F799 dot 2030204 at redhat dot com> <20150203163831 dot GL1528 at spoyarek dot pnq dot redhat dot com>
On 02/03/2015 11:38 AM, Siddhesh Poyarekar wrote:
> [Also looping in bug-gnulib]
> On Tue, Feb 03, 2015 at 11:30:17AM -0500, Carlos O'Donell wrote:
>> Is this a valgrind bug, false positive in valgrind, or bug in glibc?
>> It clearly says we have a move that depends on an uninitizlied value,
>> so something read the value and tried to do something with it.
> It is a combination of multiple things actually. The uninitialized
> value here is the padding in the structure and we have fixed such
> warnings in the past; see the nscd stats warning for example.
That case was not as performance sensitive as creating and using
> This warning doesn't trigger on x86 though due to the code that gcc
> generates for it - it explicitly ANDs the bit field in the struct
> before testing it. On s390, the optimizer does away with the AND
> operation and tests the entire thing for some reason - I haven't
> figured out why but the instruction combiner RTL pass does away with
> the AND operation.
> This is also why I started out filing a gcc bug, but then changed my
> mind and fixed it in glibc instead, since I presumed that the compiler
> can assume that the padding is also appropriately initialized. But
> then, I am not completely sure if the compiler is allowed to make that
Thanks for the clarification.
IMO zero-initialized padding, for this case, isn't something you can
expect. Therefore I think it's a compiler bug.
I think it's OK to work around this in glibc, but it needs a comment
with a reference to the filed gcc bug. I do not think it is valid
for gcc on s390x to use the entire bit field along with padding and
I believe it could result in incorrect operation.