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 > > >
Mehdi Amini via llvm-dev
2016-Nov-20 23:46 UTC
[llvm-dev] uninitialized values in Attributes.cpp
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
regehr via llvm-dev
2016-Nov-20 23:50 UTC
[llvm-dev] uninitialized values in Attributes.cpp
> 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
Hans Wennborg via llvm-dev
2016-Nov-28 17:47 UTC
[llvm-dev] uninitialized values in Attributes.cpp
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 >