GCC strcmp optimizations causing valgrind uninitialized conditional jumps

[William Kennington]

Is there a bug tracking the issue? Also, unless your malloc is
guaranteed to be zeroing out the data or have a strcmp that is writing
doubleworld aligned data to the string, the strcmp implementation is
branching based on data existing after the null terminating character
that may be uninitialized. Both sides of the branch do the right thing
though, and locate the null terminator, throwing away the calculations
done on the uninitialized data.

-fno-builtin-strcmp or -mstring-compare-inline-limit=0 do work fine
but we don't control the binaries we are linking against in all cases
and are seeing the issue pop up there.
On Tue, Jul 3, 2018 at 11:46 AM Segher Boessenkool
<segher at kernel.crashing.org> wrote:
>
> Hi!
>
> On Tue, Jul 03, 2018 at 11:26:55AM -0700, William Kennington wrote:
> > I've noticed while trying to do some valgrind testing on code linked
> > against system libraries that have inlined strcmps that valgrind is
> > unhappy about branches depending on uninitialized memory. I've read
>
> The branches here do *not* depend on uninitialised memory.  Valgrind
> does not realise that however.  The valgrind people are aware of this
> problem.
>
> > Any ideas on how to workaround / fix this?
>
> Does -fno-builtin-strcmp do the trick?
>
>
> Segher