[prev in list] [next in list] [prev in thread] [next in thread] 

List:       llvm-dev
Subject:    Re: [llvm-dev] uninitialized values in Attributes.cpp
From:       Mehdi Amini via llvm-dev <llvm-dev () lists ! llvm ! org>
Date:       2016-11-28 17:50:20
Message-ID: A454453D-055B-48D5-B865-14782BC6EE01 () apple ! com
[Download RAW message or body]

That makes sense! If Valgrind was deemed useful, then we should have a builedbot for \
it.

Right now the conclusion of the thread is that Valgrind seems to lead to many false \
positive though.

— 
Mehdi

> On Nov 28, 2016, at 9:47 AM, Hans Wennborg <hans@chromium.org> wrote:
> 
> 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@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@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@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@lists.llvm.org
> > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > > > 
> > > > 
> > > > 
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > 

_______________________________________________
LLVM Developers mailing list
llvm-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic