llvm dev - Nov 2016 - 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

----- Original Message -----
> From: "regehr via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Mehdi Amini" <mehdi.amini at apple.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Sunday, November 20, 2016 5:50:35 PM
> Subject: Re: [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.
We should first confirm that there is actually a problem. At least on some
platforms (e.g. PowerPC), valgrind's ability to accurately track uses of
undefined data is limited.

 -Hal
>  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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

> We should first confirm that there is actually a problem. At least on some
platforms (e.g. PowerPC), valgrind's ability to accurately track uses of
undefined data is limited.
Sure, I'm happy to do legwork here but not sure how to proceed.

I'll add that I still have a number (~300) of valgrind-related problems 
that show up for an LLVM built using Clang, but not for one built using 
GCC.  A typical one is below.  We should definitely get to the bottom of 
these.

John




FAIL: LLVM :: CodeGen/ARM/2011-01-19-MergedGlobalDbg.ll (4514 of 18737)
******************** TEST 'LLVM :: 
CodeGen/ARM/2011-01-19-MergedGlobalDbg.ll' FAILED ********************
Script:
--
/home/regehr/llvm/build-llvmtrunk-vgtest/./bin/llc -arm-global-merge 
-global-merge-group-by-use=false -filetype=obj < 
/home/regehr/llvm/test/CodeGen/ARM/2011-01-19-MergedGlobalDbg.ll | 
/home/regehr/llvm/build-llvmtrunk-vgtest/./bin/llvm-dwarfdump 
-debug-dump=info - | 
/home/regehr/llvm/build-llvmtrunk-vgtest/./bin/FileCheck 
/home/regehr/llvm/test/CodeGen/ARM/2011-01-19-MergedGlobalDbg.ll
--
Exit Code: 123

Command Output (stderr):
--
==10217== Conditional jump or move depends on uninitialised value(s)
==10217==    at 0x10BE9A0: 
llvm::DwarfCompileUnit::addRange(llvm::RangeSpan) (DwarfCompileUnit.cpp:212)
==10217==    by 0x1078EBA: 
llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) 
(DwarfDebug.cpp:1132)
==10217==    by 0x106221C: llvm::AsmPrinter::EmitFunctionBody() 
(AsmPrinter.cpp:982)
==10217==    by 0x87CA02: 
llvm::ARMAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) 
(ARMAsmPrinter.cpp:165)
==10217==    by 0x1184F35: 
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) 
(MachineFunctionPass.cpp:62)
==10217==    by 0x13EBF7E: 
llvm::FPPassManager::runOnFunction(llvm::Function&) 
(LegacyPassManager.cpp:1513)
==10217==    by 0x13EC1D2: 
llvm::FPPassManager::runOnModule(llvm::Module&) (LegacyPassManager.cpp:1534)
==10217==    by 0x13EC6D5: runOnModule (LegacyPassManager.cpp:1590)
==10217==    by 0x13EC6D5: 
llvm::legacy::PassManagerImpl::run(llvm::Module&) 
(LegacyPassManager.cpp:1693)
==10217==    by 0x64914C: compileModule(char**, llvm::LLVMContext&) 
(llc.cpp:524)
==10217==    by 0x6467EA: main (llc.cpp:282)
==10217=
--