llvm dev - Nov 2016 - uninitialized values in Attributes.cpp

Well, it looks like almost all of the problems go away when I build 
using trunk instead of 3.9.  So, that was scary but I'm going to forget 
it ever happened.  >8000 test cases failed under Valgrind!!

John



On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote:
> Hi John,
>
> This is probably somewhat of a stretch, but since the problem does not
> happen with a Debug build, could it be due to loop unswitching (or
> optimizations like that) kicking in when building LLVM?  That is, due
> to speculating the branch out of loops like
>
>   val = *uninitialized_loc
>   for (; false;) {
>     if (val)
>       foo();
>     else
>       bar();
>   }
>
> ?
>
> What compiler are you building with?
>
> -- Sanjoy
>
> On Sat, Nov 19, 2016 at 9:00 PM, regehr via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> I did a RelWithDebInfo + asserts build of LLVM just now and, when
running
>> "make check" under Valgrind, am seeing a lot of uses of
uninitialized memory
>> like the one below.  Anyone know offhand what's likely to be the
root cause?
>> Unfortunately a Debug build doesn't give these errors.  Thanks,
>>
>> John
>>
>>
>> FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)
>> ******************** TEST 'LLVM :: Analysis/BasicAA/pr18573.ll'
FAILED
>> ********************
>> Script:
>> --
>> /home/regehr/llvm/build-vg/./bin/opt
>> /home/regehr/llvm/test/Analysis/BasicAA/pr18573.ll -O2 -S |
>> /home/regehr/llvm/build-vg/./bin/FileCheck
>> /home/regehr/llvm/test/Analysis/BasicAA/pr18573.ll
>> --
>> Exit Code: 123
>>
>> Command Output (stderr):
>> --
>> ==29299== Conditional jump or move depends on uninitialised value(s)
>> ==29299==    at 0x13FCF12: hasAttribute (Attributes.cpp:421)
>> ==29299==    by 0x13FCF12: hasAttribute (Attributes.cpp:186)
>> ==29299==    by 0x13FCF12: operator() (Attributes.cpp:627)
>> ==29299==    by 0x13FCF12: operator()<const std::pair<unsigned
int,
>> llvm::Attribute> *> (predefined_ops.h:234)
>> ==29299==    by 0x13FCF12: __find_if<const std::pair<unsigned
int,
>> llvm::Attribute> *, __gnu_cxx::__ops::_Iter_pred<(lambda at
>> ../lib/IR/Attributes.cpp:627:3)> > (stl_algo.h:140)
>> ==29299==    by 0x13FCF12: __find_if<const std::pair<unsigned
int,
>> llvm::Attribute> *, __gnu_cxx::__ops::_Iter_pred<(lambda at
>> ../lib/IR/Attributes.cpp:627:3)> > (stl_algo.h:161)
>> ==29299==    by 0x13FCF12: find_if<const std::pair<unsigned int,
>> llvm::Attribute> *, (lambda at ../lib/IR/Attributes.cpp:627:3)>
>> (stl_algo.h:3815)
>> ==29299==    by 0x13FCF12: none_of<const std::pair<unsigned int,
>> llvm::Attribute> *, (lambda at ../lib/IR/Attributes.cpp:627:3)>
>> (stl_algo.h:526)
>> ==29299==    by 0x13FCF12:
none_of<llvm::ArrayRef<std::pair<unsigned int,
>> llvm::Attribute> > &, (lambda at
../lib/IR/Attributes.cpp:627:3)>
>> (STLExtras.h:607)
>> ==29299==    by 0x13FCF12:
llvm::AttributeSet::get(llvm::LLVMContext&,
>> llvm::ArrayRef<std::pair<unsigned int, llvm::Attribute> >)
>> (Attributes.cpp:627)
>> ==29299==    by 0x13FD62B:
llvm::AttributeSet::get(llvm::LLVMContext&,
>> unsigned int, llvm::ArrayRef<llvm::Attribute::AttrKind>)
>> (Attributes.cpp:712)
>> ==29299==    by 0x146F9AC:
>> llvm::Intrinsic::getAttributes(llvm::LLVMContext&,
llvm::Intrinsic::ID)
>> (Intrinsics.gen:20104)
>> ==29299==    by 0x146F3A0:
llvm::Function::Function(llvm::FunctionType*,
>> llvm::GlobalValue::LinkageTypes, llvm::Twine const&, llvm::Module*)
>> (Function.cpp:277)
>> ==29299==    by 0x1CD2B36: Create (Function.h:106)
>> ==29299==    by 0x1CD2B36:
>> llvm::LLParser::ParseFunctionHeader(llvm::Function*&, bool)
>> (LLParser.cpp:4766)
>> ==29299==    by 0x1CCE2C2: llvm::LLParser::ParseDeclare()
(LLParser.cpp:444)
>> ==29299==    by 0x1CCC15A: llvm::LLParser::ParseTopLevelEntities()
>> (LLParser.cpp:276)
>> ==29299==    by 0x1CCBFBF: llvm::LLParser::Run() (LLParser.cpp:74)
>> ==29299==    by 0x1CC59D8:
llvm::parseAssemblyInto(llvm::MemoryBufferRef,
>> llvm::Module&, llvm::SMDiagnostic&, llvm::SlotMapping*)
(Parser.cpp:31)
>> ==29299==    by 0x1CC5C16: llvm::parseAssembly(llvm::MemoryBufferRef,
>> llvm::SMDiagnostic&, llvm::LLVMContext&, llvm::SlotMapping*)
(Parser.cpp:41)
>> ==29299==    by 0x158C59E: llvm::parseIR(llvm::MemoryBufferRef,
>> llvm::SMDiagnostic&, llvm::LLVMContext&) (IRReader.cpp:89)
>> ==29299==    by 0x158CA61: llvm::parseIRFile(llvm::StringRef,
>> llvm::SMDiagnostic&, llvm::LLVMContext&) (IRReader.cpp:102)
>> ==29299=>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>

If 3.9 shipped with these issues (assuming these are not false positive), it
would be interesting to 1) know why the sanitizers didn’t catch it, and 2) add
valgrind to the release qualification process (CC Hans).

— 
Mehdi
> On Nov 20, 2016, at 3:36 PM, regehr via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Well, it looks like almost all of the problems go away when I build using
trunk instead of 3.9.  So, that was scary but I'm going to forget it ever
happened.  >8000 test cases failed under Valgrind!!
> 
> John
> 
> 
> 
> On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote:
>> Hi John,
>> 
>> This is probably somewhat of a stretch, but since the problem does not
>> happen with a Debug build, could it be due to loop unswitching (or
>> optimizations like that) kicking in when building LLVM?  That is, due
>> to speculating the branch out of loops like
>> 
>>  val = *uninitialized_loc
>>  for (; false;) {
>>    if (val)
>>      foo();
>>    else
>>      bar();
>>  }
>> 
>> ?
>> 
>> What compiler are you building with?
>> 
>> -- Sanjoy
>> 
>> On Sat, Nov 19, 2016 at 9:00 PM, regehr via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> I did a RelWithDebInfo + asserts build of LLVM just now and, when
running
>>> "make check" under Valgrind, am seeing a lot of uses of
uninitialized memory
>>> like the one below.  Anyone know offhand what's likely to be
the root cause?
>>> Unfortunately a Debug build doesn't give these errors.  Thanks,
>>> 
>>> John
>>> 
>>> 
>>> FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)
>>> ******************** TEST 'LLVM ::
Analysis/BasicAA/pr18573.ll' FAILED
>>> ********************
>>> Script:
>>> --
>>> /home/regehr/llvm/build-vg/./bin/opt
>>> /home/regehr/llvm/test/Analysis/BasicAA/pr18573.ll -O2 -S |
>>> /home/regehr/llvm/build-vg/./bin/FileCheck
>>> /home/regehr/llvm/test/Analysis/BasicAA/pr18573.ll
>>> --
>>> Exit Code: 123
>>> 
>>> Command Output (stderr):
>>> --
>>> ==29299== Conditional jump or move depends on uninitialised
value(s)
>>> ==29299==    at 0x13FCF12: hasAttribute (Attributes.cpp:421)
>>> ==29299==    by 0x13FCF12: hasAttribute (Attributes.cpp:186)
>>> ==29299==    by 0x13FCF12: operator() (Attributes.cpp:627)
>>> ==29299==    by 0x13FCF12: operator()<const
std::pair<unsigned int,
>>> llvm::Attribute> *> (predefined_ops.h:234)
>>> ==29299==    by 0x13FCF12: __find_if<const std::pair<unsigned
int,
>>> llvm::Attribute> *, __gnu_cxx::__ops::_Iter_pred<(lambda at
>>> ../lib/IR/Attributes.cpp:627:3)> > (stl_algo.h:140)
>>> ==29299==    by 0x13FCF12: __find_if<const std::pair<unsigned
int,
>>> llvm::Attribute> *, __gnu_cxx::__ops::_Iter_pred<(lambda at
>>> ../lib/IR/Attributes.cpp:627:3)> > (stl_algo.h:161)
>>> ==29299==    by 0x13FCF12: find_if<const std::pair<unsigned
int,
>>> llvm::Attribute> *, (lambda at
../lib/IR/Attributes.cpp:627:3)>
>>> (stl_algo.h:3815)
>>> ==29299==    by 0x13FCF12: none_of<const std::pair<unsigned
int,
>>> llvm::Attribute> *, (lambda at
../lib/IR/Attributes.cpp:627:3)>
>>> (stl_algo.h:526)
>>> ==29299==    by 0x13FCF12:
none_of<llvm::ArrayRef<std::pair<unsigned int,
>>> llvm::Attribute> > &, (lambda at
../lib/IR/Attributes.cpp:627:3)>
>>> (STLExtras.h:607)
>>> ==29299==    by 0x13FCF12:
llvm::AttributeSet::get(llvm::LLVMContext&,
>>> llvm::ArrayRef<std::pair<unsigned int, llvm::Attribute>
>)
>>> (Attributes.cpp:627)
>>> ==29299==    by 0x13FD62B:
llvm::AttributeSet::get(llvm::LLVMContext&,
>>> unsigned int, llvm::ArrayRef<llvm::Attribute::AttrKind>)
>>> (Attributes.cpp:712)
>>> ==29299==    by 0x146F9AC:
>>> llvm::Intrinsic::getAttributes(llvm::LLVMContext&,
llvm::Intrinsic::ID)
>>> (Intrinsics.gen:20104)
>>> ==29299==    by 0x146F3A0:
llvm::Function::Function(llvm::FunctionType*,
>>> llvm::GlobalValue::LinkageTypes, llvm::Twine const&,
llvm::Module*)
>>> (Function.cpp:277)
>>> ==29299==    by 0x1CD2B36: Create (Function.h:106)
>>> ==29299==    by 0x1CD2B36:
>>> llvm::LLParser::ParseFunctionHeader(llvm::Function*&, bool)
>>> (LLParser.cpp:4766)
>>> ==29299==    by 0x1CCE2C2: llvm::LLParser::ParseDeclare()
(LLParser.cpp:444)
>>> ==29299==    by 0x1CCC15A: llvm::LLParser::ParseTopLevelEntities()
>>> (LLParser.cpp:276)
>>> ==29299==    by 0x1CCBFBF: llvm::LLParser::Run() (LLParser.cpp:74)
>>> ==29299==    by 0x1CC59D8:
llvm::parseAssemblyInto(llvm::MemoryBufferRef,
>>> llvm::Module&, llvm::SMDiagnostic&, llvm::SlotMapping*)
(Parser.cpp:31)
>>> ==29299==    by 0x1CC5C16:
llvm::parseAssembly(llvm::MemoryBufferRef,
>>> llvm::SMDiagnostic&, llvm::LLVMContext&,
llvm::SlotMapping*) (Parser.cpp:41)
>>> ==29299==    by 0x158C59E: llvm::parseIR(llvm::MemoryBufferRef,
>>> llvm::SMDiagnostic&, llvm::LLVMContext&) (IRReader.cpp:89)
>>> ==29299==    by 0x158CA61: llvm::parseIRFile(llvm::StringRef,
>>> llvm::SMDiagnostic&, llvm::LLVMContext&) (IRReader.cpp:102)
>>> ==29299=>>>
_______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> 
>> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> If 3.9 shipped with these issues (assuming these are not false positive),
it would be interesting to 1) know why the sanitizers didn’t catch it, and 2)
add valgrind to the release qualification process (CC Hans).
Yes, I'd be interested to see some corroboration.  Note that the issue 
here is pretty specific: it only happens during optimized compile using 
Clang-3.9.

This is all I did:

1. checkout LLVM/clang trunk

2. make sure clang in path is clang-3.9

3.

cmake .. -GNinja -DCMAKE_BUILD_TYPE=RelWithDebInfo 
-DLLVM_ENABLE_ASSERTIONS=On -DCMAKE_CXX_COMPILER=clang++ 
-DCMAKE_C_COMPILER=clang -DLLVM_LIT_ARGS="-v --vg"

4.

ninja check

John

I don't want to add any build configurations to the release process
that we don't have buildbots for. AFAIK, we don't have any Valgrind
buildbots.

On Sun, Nov 20, 2016 at 3:46 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> If 3.9 shipped with these issues (assuming these are not false positive),
it would be interesting to 1) know why the sanitizers didn’t catch it, and 2)
add valgrind to the release qualification process (CC Hans).
>
> —
> Mehdi
>
>> On Nov 20, 2016, at 3:36 PM, regehr via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> Well, it looks like almost all of the problems go away when I build
using trunk instead of 3.9.  So, that was scary but I'm going to forget it
ever happened.  >8000 test cases failed under Valgrind!!
>>
>> John
>>
>>
>>
>> On 11/20/2016 03:03 AM, Sanjoy Das via llvm-dev wrote:
>>> Hi John,
>>>
>>> This is probably somewhat of a stretch, but since the problem does
not
>>> happen with a Debug build, could it be due to loop unswitching (or
>>> optimizations like that) kicking in when building LLVM?  That is,
due
>>> to speculating the branch out of loops like
>>>
>>>  val = *uninitialized_loc
>>>  for (; false;) {
>>>    if (val)
>>>      foo();
>>>    else
>>>      bar();
>>>  }
>>>
>>> ?
>>>
>>> What compiler are you building with?
>>>
>>> -- Sanjoy
>>>
>>> On Sat, Nov 19, 2016 at 9:00 PM, regehr via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>>> I did a RelWithDebInfo + asserts build of LLVM just now and,
when running
>>>> "make check" under Valgrind, am seeing a lot of uses
of uninitialized memory
>>>> like the one below.  Anyone know offhand what's likely to
be the root cause?
>>>> Unfortunately a Debug build doesn't give these errors. 
Thanks,
>>>>
>>>> John
>>>>
>>>>
>>>> FAIL: LLVM :: Analysis/BasicAA/pr18573.ll (2093 of 18733)
>>>> ******************** TEST 'LLVM ::
Analysis/BasicAA/pr18573.ll' FAILED
>>>> ********************
>>>> Script:
>>>> --
>>>> /home/regehr/llvm/build-vg/./bin/opt
>>>> /home/regehr/llvm/test/Analysis/BasicAA/pr18573.ll -O2 -S |
>>>> /home/regehr/llvm/build-vg/./bin/FileCheck
>>>> /home/regehr/llvm/test/Analysis/BasicAA/pr18573.ll
>>>> --
>>>> Exit Code: 123
>>>>
>>>> Command Output (stderr):
>>>> --
>>>> ==29299== Conditional jump or move depends on uninitialised
value(s)
>>>> ==29299==    at 0x13FCF12: hasAttribute (Attributes.cpp:421)
>>>> ==29299==    by 0x13FCF12: hasAttribute (Attributes.cpp:186)
>>>> ==29299==    by 0x13FCF12: operator() (Attributes.cpp:627)
>>>> ==29299==    by 0x13FCF12: operator()<const
std::pair<unsigned int,
>>>> llvm::Attribute> *> (predefined_ops.h:234)
>>>> ==29299==    by 0x13FCF12: __find_if<const
std::pair<unsigned int,
>>>> llvm::Attribute> *, __gnu_cxx::__ops::_Iter_pred<(lambda
at
>>>> ../lib/IR/Attributes.cpp:627:3)> > (stl_algo.h:140)
>>>> ==29299==    by 0x13FCF12: __find_if<const
std::pair<unsigned int,
>>>> llvm::Attribute> *, __gnu_cxx::__ops::_Iter_pred<(lambda
at
>>>> ../lib/IR/Attributes.cpp:627:3)> > (stl_algo.h:161)
>>>> ==29299==    by 0x13FCF12: find_if<const
std::pair<unsigned int,
>>>> llvm::Attribute> *, (lambda at
../lib/IR/Attributes.cpp:627:3)>
>>>> (stl_algo.h:3815)
>>>> ==29299==    by 0x13FCF12: none_of<const
std::pair<unsigned int,
>>>> llvm::Attribute> *, (lambda at
../lib/IR/Attributes.cpp:627:3)>
>>>> (stl_algo.h:526)
>>>> ==29299==    by 0x13FCF12:
none_of<llvm::ArrayRef<std::pair<unsigned int,
>>>> llvm::Attribute> > &, (lambda at
../lib/IR/Attributes.cpp:627:3)>
>>>> (STLExtras.h:607)
>>>> ==29299==    by 0x13FCF12:
llvm::AttributeSet::get(llvm::LLVMContext&,
>>>> llvm::ArrayRef<std::pair<unsigned int,
llvm::Attribute> >)
>>>> (Attributes.cpp:627)
>>>> ==29299==    by 0x13FD62B:
llvm::AttributeSet::get(llvm::LLVMContext&,
>>>> unsigned int, llvm::ArrayRef<llvm::Attribute::AttrKind>)
>>>> (Attributes.cpp:712)
>>>> ==29299==    by 0x146F9AC:
>>>> llvm::Intrinsic::getAttributes(llvm::LLVMContext&,
llvm::Intrinsic::ID)
>>>> (Intrinsics.gen:20104)
>>>> ==29299==    by 0x146F3A0:
llvm::Function::Function(llvm::FunctionType*,
>>>> llvm::GlobalValue::LinkageTypes, llvm::Twine const&,
llvm::Module*)
>>>> (Function.cpp:277)
>>>> ==29299==    by 0x1CD2B36: Create (Function.h:106)
>>>> ==29299==    by 0x1CD2B36:
>>>> llvm::LLParser::ParseFunctionHeader(llvm::Function*&, bool)
>>>> (LLParser.cpp:4766)
>>>> ==29299==    by 0x1CCE2C2: llvm::LLParser::ParseDeclare()
(LLParser.cpp:444)
>>>> ==29299==    by 0x1CCC15A:
llvm::LLParser::ParseTopLevelEntities()
>>>> (LLParser.cpp:276)
>>>> ==29299==    by 0x1CCBFBF: llvm::LLParser::Run()
(LLParser.cpp:74)
>>>> ==29299==    by 0x1CC59D8:
llvm::parseAssemblyInto(llvm::MemoryBufferRef,
>>>> llvm::Module&, llvm::SMDiagnostic&, llvm::SlotMapping*)
(Parser.cpp:31)
>>>> ==29299==    by 0x1CC5C16:
llvm::parseAssembly(llvm::MemoryBufferRef,
>>>> llvm::SMDiagnostic&, llvm::LLVMContext&,
llvm::SlotMapping*) (Parser.cpp:41)
>>>> ==29299==    by 0x158C59E: llvm::parseIR(llvm::MemoryBufferRef,
>>>> llvm::SMDiagnostic&, llvm::LLVMContext&)
(IRReader.cpp:89)
>>>> ==29299==    by 0x158CA61: llvm::parseIRFile(llvm::StringRef,
>>>> llvm::SMDiagnostic&, llvm::LLVMContext&)
(IRReader.cpp:102)
>>>> ==29299=>>>>
_______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>