It had been suggested to me that this problem might not be ppc specific; I've two comments on that:

1. The same code will not have the same problem on x86, because on x86 the bit fields are laid out low-bit first (and so the undefined bits will be the high bits and not the low bits as on ppc.

2. I wrote a simple test in an attempt to reproduce the problem on x86: valgrind does not report a false positive on the following code when compiled with Clang trunk on x86 (even though the optimizers do the same optimization that proves problematic to valgrind on ppc):

#include <stdio.h>

struct s {
#if defined(__ppc__) || defined(__ppc64__)
  unsigned h : 3;
  unsigned l : 5;
#else
  unsigned l : 5;
  unsigned h : 3;
#endif
};

void __attribute__ ((noinline)) init(struct s *v) {
  v->h = 0;
}

void __attribute__ ((noinline)) foo(struct s *v) {
  if (v->h == 0) {
    printf("yep, it is zero\n");
  }
}

int main() {
  struct s v;
  init(&v);
  foo(&v);
  return 0;
}

On the other hand, when run on pp64, valgrind does (incorrectly) complain:

==45300== Conditional jump or move depends on uninitialised value(s)
==45300==    at 0x10000578: foo (bf2.c:18)
==45300==    by 0x100005D7: main (bf2.c:26)

Julian, would you (or someone else knowledgeable with memcheck) have any pointers on where to start looking at this?  Thanks.

> 2. I wrote a simple test in an attempt to reproduce the problem on x86:
> valgrind does not report a false positive on the following code when
> compiled with Clang trunk on x86 (even though the optimizers do the same
> optimization that proves problematic to valgrind on ppc):

On x86_64 it generates a test instruction (AND, set the flags, throw
away the result of the AND) which tests just the bits in question.
That's why.

0000000000400580 <foo>:
  400580:       f6 07 e0                testb  $0xe0,(%rdi)
  400583:       74 01                   je     400586 <foo+0x6>
  400585:       c3                      retq   
  400586:       bf 70 06 40 00          mov    $0x400670,%edi
  40058b:       e9 c0 fe ff ff          jmpq   400450 <puts@plt>

gcc-4.7.2 that is installed on gcc110.fsffrance.org generates this:

0000000010000610 <.foo>:
    10000610:   81 23 00 00     lwz     r9,0(r3)
    10000614:   75 2a 07 00     andis.  r10,r9,1792
    10000618:   4c 82 00 20     bnelr   

which is the same scheme as clang uses for x86_64.  Hence no complaint.

I don't have access to a ppc box with clang installed, so I can't repro the
problem.  Hmm.

Changing foo thusly does trigger it on ppc64 though:

void __attribute__ ((noinline)) foo(struct s *v) {
  unsigned char* p = (unsigned char*)v;
  if (*p < 32) { printf("yep, it is zero\n"); }
}

giving

0000000010000610 <.foo>:
    10000610:   89 23 00 00     lbz     r9,0(r3)
    10000614:   2b 89 00 1f     cmplwi  cr7,r9,31
    10000618:   4d 9d 00 20     bgtlr   cr7

post-cleanup, uninstrumented IR looks like this:

   # t2 holds value of R3
   ------ IMark(0x10000610, 4, 0) ------
   t20 = 8Uto64(LDbe:I8(t2))    # t20 = *(unsigned char*)(R3)
   PUT(88) = t20                # R9 = t20
   ------ IMark(0x10000614, 4, 0) ------
   t22 = 32to8(CmpORD32U(64to32(t20),0x1F:I32))
                                # t22<3:1> = "t20 <u 31"

In memcheck/mc_translate.c, there is already special-casing for the
definedness-flow instrumentation for CmpORD{32,64}{U,S}, which is how
V internally represents the PPC comparison operations.  It is special
cased for the the 2nd argument being zero.  Look for this

/* --------- Semi-accurate interpretation of CmpORD. --------- */

It might be possible to extend the special-casing to situations where
the 2nd argument is exactly a power of 2.  That would cover this case.

Note that we have repeatedly said that Memcheck's definedness tracking
may be confused by highly optimised code, even if in practice it does
pretty well.  Official advice is not to use it on code generated at
-O2 or above.

(In reply to comment #3)
> 
> > 2. I wrote a simple test in an attempt to reproduce the problem on x86:
> > valgrind does not report a false positive on the following code when
> > compiled with Clang trunk on x86 (even though the optimizers do the same
> > optimization that proves problematic to valgrind on ppc):
> 
> On x86_64 it generates a test instruction (AND, set the flags, throw
> away the result of the AND) which tests just the bits in question.
> That's why.
> 
> 0000000000400580 <foo>:
>   400580:       f6 07 e0                testb  $0xe0,(%rdi)
>   400583:       74 01                   je     400586 <foo+0x6>
>   400585:       c3                      retq   
>   400586:       bf 70 06 40 00          mov    $0x400670,%edi
>   40058b:       e9 c0 fe ff ff          jmpq   400450 <puts@plt>

When I compile the test on x86_64 using clang trunk r200705, I get this:

init:                                   # @init
	.cfi_startproc
# BB#0:                                 # %entry
	andb	$31, (%rdi)
	retq
...
foo:                                    # @foo
	.cfi_startproc
# BB#0:                                 # %entry
	movzbl	(%rdi), %eax
	cmpl	$31, %eax
	ja	.LBB1_1
# BB#2:                                 # %if.then
	movl	$.Lstr, %edi
	jmp	puts                    # TAILCALL
.LBB1_1:                                # %if.end
	retq

which, as best that I can tell, is really the same thing that clang is doing on ppc (except that valgrind is fine with the x86_64 version).

> Note that we have repeatedly said that Memcheck's definedness tracking
> may be confused by highly optimised code, even if in practice it does
> pretty well.  Official advice is not to use it on code generated at
> -O2 or above.

As far as I can tell, Clang/LLVM perform this transformation at all optimization levels. (-O1 does the same thing, on both ppc and x86_64).

Properly fixing bug 352364 (https://bugs.kde.org/show_bug.cgi?id=352364)
will go a long way to fixing this one too.  They are not exact duplicates, though.