regehr via llvm-dev
2016-Nov-20 05:00 UTC
[llvm-dev] uninitialized values in Attributes.cpp
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==
Sanjoy Das via llvm-dev
2016-Nov-20 10:03 UTC
[llvm-dev] uninitialized values in Attributes.cpp
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
--
Sanjoy Das
http://playingwithpointers.com
regehr via llvm-dev
2016-Nov-20 15:58 UTC
[llvm-dev] uninitialized values in Attributes.cpp
Hi Sanjoy, I'm building with Clang-3.9. I'll give MSan a try and see what it says. 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 > > >
regehr via llvm-dev
2016-Nov-20 23:36 UTC
[llvm-dev] 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 > > >