Stack Exchange
Use of uninitialised value of size 8 Valgrind
I'm getting 
==56903== Use of uninitialised value of size 8
==56903==    at 0x1000361D1: checkMSB (in ./UnittestCSA)
==56903==    by 0x10003732A: S_derive_k1_k2 (in ./UnittestCSA)

Code is as follows:
int32_t checkMSB(uint8_t *pKey){
    int8_t msb = 0;
    int32_t ret = 0;
    msb = 1 << (8 - 1);
    /* Perform bitwise AND with msb and num */
    if(pKey[0] & msb){
        ret = 1;
    } else {
        ret = 0;
    }
    return ret;
}

Not sure what is causing the issue.
If this
#define BITS (sizeof(int8_t) * 8)

is changed to this
#define BITS (sizeof(int) * 8)

it doesn't complain. I have #include <stdint.h> header file.
UPDATE
uint8_t localK1[BLOCKSIZE];
for(index = 0; index < inputLen; index++){
    localK1[index] = pInputText[index];
}

result = checkMSB(localK1);


It seems odd to me that you're using an int32_t type for a mask into an int8_t array.

BITS seems rather overkill.  On any conforming C implementation that provides int8_t at all, its size cannot be anything other than 1.

You need to show the call, since this is referencing memory at pKey.

pKey is not initialized that obvious.

Yeah, probably pKey.  Where is the code where this function is called?

I'd venture a guess that the alternative definition of BITS stops causing different behavior of you compile with all optimizations disabled.

Well... 1 << 31 would have undefined behaviour or perhaps result in 0 in the LSB, therefore the value needs not be checked and the pointer is not referenced.

Ideally, what we need is a [MCVE].  Snippets here and there can sometimes get the job done if there's something glaringly obvious that sticks out, but it is always best to have a complete example that can be compiled (or not, I suppose, in the instances where someone's question involves a compile-error).

Compile your code with debugging turned on (-g in gcc) and valgrind will give you a lot more information about the problem.

You might also take the opportunity to work with some static code analysis tools.  The clang static analysis tool is pretty nice and will step you through the steps that leads to the errors it detects.  cppcheck is also a nice one that seeks out undefined behavior, though it doesn't have the backing of a compiler for full context sensitivity.  Flawfinder is also pretty good for finding unsafe code, though it has a fair amount of false positives.

Your checkMSB function declares only two local variables and one function parameter.  The variables both have initializers, and the parameter (a pointer) will receive a value as a result of the function call, supposing that a correct prototype for it is in scope at the point of the call.  Thus, none of these is used uninitialized.
The only other data that are used (not counting constants), are those pointed to by the argument, pKey.  Of those, your code uses pKey[0].  That it is Valgrind reporting the issue supports the conclusion that that's the data it is complaining about: valgrind's default memcheck service watches dynamically allocated memory, and that's the only thing involved that might be dynamically allocated.
That the error disappears when you change the definition of BITS could be explained by the expression pKey[0] & msb being optimized away when BITS evaluates to a value larger than 8.
As far as your update, which purports to show that the function's argument in fact points to initialized data, I'm inclined to think that you're looking in the wrong place, or else in the right place but at the wrong code.  That is, there probably is either a different call to checkMSB that causes Valgrind to complain, or else the binary being tested was built from a different version of the code.  I'm not prepared to believe that everything you've presented in the question is true, or at least not that it fits together the way you seem to be saying it does.
