llvm dev - Jul 2016 - [3.9 Release] Release Candidate 1 has been tagged

Dear testers,

3.9.0-rc1 was just tagged from the 3.9 branch at r277207.

This took a little longer than I'd hoped, but I think the branch is in
a decent state now.

There are still open merge requests and bugs, but I'd like to get the
real testing started to see where we're at.

Please build, test, and upload binaries to the sftp. Let me know how
it goes. I'll upload source, docs, and your binaries to the
pre-release page once they're ready.

Thanks,
Hans

Hi Hans,

2016-07-30 0:57 GMT+02:00 Hans Wennborg via llvm-dev <llvm-dev at
lists.llvm.org>:
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
Just to double-check, is this bug also on people's radar? It causes
Clang to crash when trying to build a fair number of Open Source
packages/libraries. In my opinion it's a blocker for 3.9.

https://llvm.org/bugs/show_bug.cgi?id=28617

-- 
Ed Schouten <ed at nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717

On 29 July 2016 at 23:57, Hans Wennborg via Release-testers
<release-testers at lists.llvm.org> wrote:
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
First wave of testing pass on ARM. Uploaded to the FTP server.

Is it time to do the back-ports planned? I only have a very minor bug fix.

cheers,
--renato

On 31 Jul 2016, at 12:01, Ed Schouten via Release-testers <release-testers at
lists.llvm.org> wrote:
> 
> 2016-07-30 0:57 GMT+02:00 Hans Wennborg via llvm-dev <llvm-dev at
lists.llvm.org>:
>> There are still open merge requests and bugs, but I'd like to get
the
>> real testing started to see where we're at.
> 
> Just to double-check, is this bug also on people's radar? It causes
> Clang to crash when trying to build a fair number of Open Source
> packages/libraries. In my opinion it's a blocker for 3.9.
> 
> https://llvm.org/bugs/show_bug.cgi?id=28617
Added as a dependency of http://llvm.org/PR28600, the release blockers metabug.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160731/8eadf81d/attachment.sig>

Hi,
On the OpenMandriva side, x86_64 passes all checks. We're having some
problems with other architectures though (see below):

x86_64 succeeded, packages are here:
https://abf.openmandriva.org/build_lists/76792

i586 fails to build, but this seems to be an issue with 3.8.1 (which we're
using to build 3.9):

/usr/bin/clang++   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support
-I../lib/Support -Iinclude -I../include -Os  -pipe -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4  -fomit-frame-pointer -mtune=atom
-march=i586 -fasynchronous-unwind-tables -march=i686
-D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Werror=date-time -std=c++1y
-fcolor-diagnostics -ffunction-sections -fdata-sections -Os  -pipe
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4  -fomit-frame-pointer -mtune=atom
-march=i586 -fasynchronous-unwind-tables -march=i686
-D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64
-MD -MT lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o
-MF lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c
../lib/Support/PrettyStackTrace.cpp
clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t
llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong
MachineOperand accessor"' failed.
#0 0xfffffffff4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib/libLLVMSupport.so.3.8+0x95075)
#1 0xfffffffff4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7)
#2 0xfffffffff4abbbf1 llvm::sys::RunSignalHandlers()
(/usr/lib/libLLVMSupport.so.3.8+0x93bf1)
#3 0xfffffffff4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49)
#4 0xfffffffff7714d20  0xd20 __GI_raise
#5 0xfffffffff7714d20
#6 0xfffffffff7714d20 __GI_abort (+0xd20)
#7 0xfffffffff4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0)
#8 0xfffffffff46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5)
#9 0xfffffffff464b126 (/lib/libc.so.6+0x21126)
#10 0xfffffffff464b162
llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr const*) const
(/lib/libc.so.6+0x21162)
#11 0xfffffffff65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6)
#12 0xfffffffff667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d)
#13 0xfffffffff61029dc
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc)
#14 0xfffffffff6105002
llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/lib/libLLVMCodeGen.so.3.8+0x176002)
#15 0xfffffffff60ab337 llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/lib/libLLVMCodeGen.so.3.8+0x11c337)
#16 0xfffffffff50d7e6f
llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/lib/libLLVMCore.so.3.8+0x19de6f)
#17 0xfffffffff50d816b llvm::legacy::PassManager::run(llvm::Module&)
(/usr/lib/libLLVMCore.so.3.8+0x19e16b)
#18 0xfffffffff50d857f
clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&,
clang::LangOptions const&, llvm::StringRef, llvm::Module*,
clang::BackendAction, llvm::raw_pwrite_stream*)
(/usr/lib/libLLVMCore.so.3.8+0x19e57f)
#19 0xfffffffff50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734)
#20 0xfffffffff59fc72c clang::ParseAST(clang::Sema&, bool, bool)
(/usr/lib/libclangCodeGen.so.3.8+0x6972c)
#21 0xfffffffff5b2cd85 clang::ASTFrontendAction::ExecuteAction()
(/usr/lib/libclangCodeGen.so.3.8+0x199d85)
#22 0xfffffffff3b2b294 clang::CodeGenAction::ExecuteAction()
(/usr/lib/libclangParse.so.3.8+0x24294)
#23 0xfffffffff582583e clang::FrontendAction::Execute()
(/usr/lib/libclangFrontend.so.3.8+0x8783e)
#24 0xfffffffff5b2d3e1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/lib/libclangCodeGen.so.3.8+0x19a3e1)
#25 0xfffffffff5826660
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/lib/libclangFrontend.so.3.8+0x88660)
#26 0xfffffffff58029e1 cc1_main(llvm::ArrayRef<char const*>, char
const*, void*) (/usr/lib/libclangFrontend.so.3.8+0x649e1)
#27 0xfffffffff579aead main (/usr/lib/libclangFrontendTool.so.3.8+0x2ead)
#28 0x08057178 __libc_start_main (/usr/bin/clang-3.8+0x8057178)
#29 0x08052a9b _start (/usr/bin/clang-3.8+0x8052a9b)
0  libLLVMSupport.so.3.8       0xf4abd075
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  libLLVMSupport.so.3.8       0xf4abd2c7
2  libLLVMSupport.so.3.8       0xf4abbbf1 llvm::sys::RunSignalHandlers() + 60
3  libLLVMSupport.so.3.8       0xf4abbf49
4                              0xf7714d20 __kernel_sigreturn + 0
5  libc.so.6                   0xf4650ef0 gsignal + 73
6  libc.so.6                   0xf46520e5 abort + 278
7  libc.so.6                   0xf464b126 __assert_fail + 0
8  libc.so.6                   0xf464b162 __assert_perror_fail + 0
9  libLLVMX86CodeGen.so.3.8    0xf65a0db6
10 libLLVMX86CodeGen.so.3.8    0xf667640d
llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr const*) const + 365
11 libLLVMCodeGen.so.3.8       0xf61029dc
12 libLLVMCodeGen.so.3.8       0xf6105002
13 libLLVMCodeGen.so.3.8       0xf60ab337
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 169
14 libLLVMCore.so.3.8          0xf50d7e6f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 243
15 libLLVMCore.so.3.8          0xf50d816b
llvm::FPPassManager::runOnModule(llvm::Module&) + 47
16 libLLVMCore.so.3.8          0xf50d857f
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 445
17 libLLVMCore.so.3.8          0xf50d8734
llvm::legacy::PassManager::run(llvm::Module&) + 32
18 libclangCodeGen.so.3.8      0xf59fc72c
clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&,
clang::LangOptions const&, llvm::StringRef, llvm::Module*,
clang::BackendAction, llvm::raw_pwrite_stream*) + 8185
19 libclangCodeGen.so.3.8      0xf5b2cd85
20 libclangParse.so.3.8        0xf3b2b294
clang::ParseAST(clang::Sema&, bool, bool) + 624
21 libclangFrontend.so.3.8     0xf582583e
clang::ASTFrontendAction::ExecuteAction() + 182
22 libclangCodeGen.so.3.8      0xf5b2d3e1
clang::CodeGenAction::ExecuteAction() + 161
23 libclangFrontend.so.3.8     0xf5826660 clang::FrontendAction::Execute() + 88
24 libclangFrontend.so.3.8     0xf58029e1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 771
25 libclangFrontendTool.so.3.8 0xf579aead
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2953
26 clang-3.8                   0x08057178 cc1_main(llvm::ArrayRef<char
const*>, char const*, void*) + 1178
27 clang-3.8                   0x08052a9b main + 1723
28 libc.so.6                   0xf46424e7 __libc_start_main + 361
29 clang-3.8                   0x08054f80
Stack dump:
0.	Program arguments: /usr/bin/clang-3.8 -cc1 -triple
i686-pc-linux-gnu -emit-obj -disable-free -main-file-name
PrettyStackTrace.cpp -mrelocation-model pic -pic-level 2
-mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu i686
-momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb
-ffunction-sections -fdata-sections -coverage-file
/builddir/build/BUILD/llvm-3.9.0.src/build/lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o
-resource-dir /usr/bin/../lib/clang/3.8.1 -dependency-file
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d
-sys-header-deps -MT
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -D
_GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D
__STDC_LIMIT_MACROS -I lib/Support -I ../lib/Support -I include -I
../include -D _FORTIFY_SOURCE=2 -D _LARGEFILE_SOURCE=1 -D
_LARGEFILE64_SOURCE=1 -D _FILE_OFFSET_BITS=64 -D _FORTIFY_SOURCE=2 -D
_LARGEFILE_SOURCE=1 -D _LARGEFILE64_SOURCE=1 -D _FILE_OFFSET_BITS=64
-internal-isystem
/usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1
-internal-isystem
/usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1/i586-mandriva-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.8.1/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -Os -Wformat
-Werror=format-security -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Werror=date-time -Wformat -Werror=format-security -pedantic
-std=c++1y -fdeprecated-macro -fdebug-compilation-dir
/builddir/build/BUILD/llvm-3.9.0.src/build -ferror-limit 19
-fmessage-length 0 -fvisibility-inlines-hidden -stack-protector 1
-stack-protector-buffer-size 4 -stack-protector-buffer-size 4
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops
-vectorize-slp -o
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -x c++
../lib/Support/PrettyStackTrace.cpp
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module
'../lib/Support/PrettyStackTrace.cpp'.
4.	Running pass 'Prologue/Epilogue Insertion & Frame Finalization'
on
function '@_ZN4llvm21PrettyStackTraceEntryD0Ev'
clang-3.8: error: unable to execute command: Aborted (core dumped)
clang-3.8: error: clang frontend command failed due to signal (use -v
to see invocation)
clang version 3.8.1 (tags/RELEASE_381/rc1)
Target: i686-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang-3.8: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed
source, and associated run script.
clang-3.8: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.8: note: diagnostic msg: /tmp/PrettyStackTrace-74cffb.cpp
clang-3.8: note: diagnostic msg: /tmp/PrettyStackTrace-74cffb.sh
clang-3.8: note: diagnostic msg:
********************

armv7hnl fails to build libunwind, but this is likely a configuration issue:

CMake Error at projects/libunwind/src/CMakeLists.txt:76 (message):
  Compiler doesn't support generation of unwind tables if exception support
  is disabled.  Building libunwind DSO with runtime dependency on C++ ABI
  library is not supported.

aarch64 is currently untested because of problems with our only aarch64
build box, but that should be fixed soon.

We don't currently have access to sftp.

ttyl
bero

On 30 July 2016 at 00:57, Hans Wennborg via Release-testers <
release-testers at lists.llvm.org> wrote:
> Dear testers,
>
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
>
> This took a little longer than I'd hoped, but I think the branch is in
> a decent state now.
>
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the
> pre-release page once they're ready.
>
> Thanks,
> Hans
> _______________________________________________
> Release-testers mailing list
> Release-testers at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160801/53e28252/attachment.html>

The crash dump looks like it's probably PR27071.
The bug was introduced in r261387 (which was merged into 3.8) and fixed in
r264465 (which apparently wasn't).

On Sun, Jul 31, 2016 at 3:50 PM, Bernhard Rosenkränzer <
llvm-dev at lists.llvm.org> wrote:
> Hi,
> On the OpenMandriva side, x86_64 passes all checks. We're having some
> problems with other architectures though (see below):
>
> x86_64 succeeded, packages are here:
> https://abf.openmandriva.org/build_lists/76792
>
> i586 fails to build, but this seems to be an issue with 3.8.1 (which
we're
> using to build 3.9):
>
> /usr/bin/clang++   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support
-Iinclude -I../include -Os  -pipe -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 
-fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
-march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Werror=date-time -std=c++1y -fcolor-diagnostics -ffunction-sections
-fdata-sections -Os  -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
-fstack-protector --param=ssp-buffer-size=4  -fomit-frame-pointer -mtune=atom
-march=i586 -fasynchronous-unwind-tables -march=i686 -D_LARGEFILE_SOURCE=1
-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -MD -MT
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -MF
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c
../lib/Support/PrettyStackTrace.cpp
> clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t
llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong
MachineOperand accessor"' failed.
> #0 0xfffffffff4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib/libLLVMSupport.so.3.8+0x95075)
> #1 0xfffffffff4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7)
> #2 0xfffffffff4abbbf1 llvm::sys::RunSignalHandlers()
(/usr/lib/libLLVMSupport.so.3.8+0x93bf1)
> #3 0xfffffffff4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49)
> #4 0xfffffffff7714d20  0xd20 __GI_raise
> #5 0xfffffffff7714d20
> #6 0xfffffffff7714d20 __GI_abort (+0xd20)
> #7 0xfffffffff4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0)
> #8 0xfffffffff46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5)
> #9 0xfffffffff464b126 (/lib/libc.so.6+0x21126)
> #10 0xfffffffff464b162 llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr
const*) const (/lib/libc.so.6+0x21162)
> #11 0xfffffffff65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6)
> #12 0xfffffffff667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d)
> #13 0xfffffffff61029dc
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc)
> #14 0xfffffffff6105002
llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/lib/libLLVMCodeGen.so.3.8+0x176002)
> #15 0xfffffffff60ab337 llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/lib/libLLVMCodeGen.so.3.8+0x11c337)
> #16 0xfffffffff50d7e6f
llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/lib/libLLVMCore.so.3.8+0x19de6f)
> #17 0xfffffffff50d816b llvm::legacy::PassManager::run(llvm::Module&)
(/usr/lib/libLLVMCore.so.3.8+0x19e16b)
> #18 0xfffffffff50d857f
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&,
llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*)
(/usr/lib/libLLVMCore.so.3.8+0x19e57f)
> #19 0xfffffffff50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734)
> #20 0xfffffffff59fc72c clang::ParseAST(clang::Sema&, bool, bool)
(/usr/lib/libclangCodeGen.so.3.8+0x6972c)
> #21 0xfffffffff5b2cd85 clang::ASTFrontendAction::ExecuteAction()
(/usr/lib/libclangCodeGen.so.3.8+0x199d85)
> #22 0xfffffffff3b2b294 clang::CodeGenAction::ExecuteAction()
(/usr/lib/libclangParse.so.3.8+0x24294)
> #23 0xfffffffff582583e clang::FrontendAction::Execute()
(/usr/lib/libclangFrontend.so.3.8+0x8783e)
> #24 0xfffffffff5b2d3e1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/lib/libclangCodeGen.so.3.8+0x19a3e1)
> #25 0xfffffffff5826660
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/lib/libclangFrontend.so.3.8+0x88660)
> #26 0xfffffffff58029e1 cc1_main(llvm::ArrayRef<char const*>, char
const*, void*) (/usr/lib/libclangFrontend.so.3.8+0x649e1)
> #27 0xfffffffff579aead main (/usr/lib/libclangFrontendTool.so.3.8+0x2ead)
> #28 0x08057178 __libc_start_main (/usr/bin/clang-3.8+0x8057178)
> #29 0x08052a9b _start (/usr/bin/clang-3.8+0x8052a9b)
> 0  libLLVMSupport.so.3.8       0xf4abd075
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
> 1  libLLVMSupport.so.3.8       0xf4abd2c7
> 2  libLLVMSupport.so.3.8       0xf4abbbf1 llvm::sys::RunSignalHandlers() +
60
> 3  libLLVMSupport.so.3.8       0xf4abbf49
> 4                              0xf7714d20 __kernel_sigreturn + 0
> 5  libc.so.6                   0xf4650ef0 gsignal + 73
> 6  libc.so.6                   0xf46520e5 abort + 278
> 7  libc.so.6                   0xf464b126 __assert_fail + 0
> 8  libc.so.6                   0xf464b162 __assert_perror_fail + 0
> 9  libLLVMX86CodeGen.so.3.8    0xf65a0db6
> 10 libLLVMX86CodeGen.so.3.8    0xf667640d
llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr const*) const + 365
> 11 libLLVMCodeGen.so.3.8       0xf61029dc
> 12 libLLVMCodeGen.so.3.8       0xf6105002
> 13 libLLVMCodeGen.so.3.8       0xf60ab337
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 169
> 14 libLLVMCore.so.3.8          0xf50d7e6f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 243
> 15 libLLVMCore.so.3.8          0xf50d816b
llvm::FPPassManager::runOnModule(llvm::Module&) + 47
> 16 libLLVMCore.so.3.8          0xf50d857f
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 445
> 17 libLLVMCore.so.3.8          0xf50d8734
llvm::legacy::PassManager::run(llvm::Module&) + 32
> 18 libclangCodeGen.so.3.8      0xf59fc72c
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&,
llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*)
+ 8185
> 19 libclangCodeGen.so.3.8      0xf5b2cd85
> 20 libclangParse.so.3.8        0xf3b2b294 clang::ParseAST(clang::Sema&,
bool, bool) + 624
> 21 libclangFrontend.so.3.8     0xf582583e
clang::ASTFrontendAction::ExecuteAction() + 182
> 22 libclangCodeGen.so.3.8      0xf5b2d3e1
clang::CodeGenAction::ExecuteAction() + 161
> 23 libclangFrontend.so.3.8     0xf5826660 clang::FrontendAction::Execute()
+ 88
> 24 libclangFrontend.so.3.8     0xf58029e1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 771
> 25 libclangFrontendTool.so.3.8 0xf579aead
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2953
> 26 clang-3.8                   0x08057178 cc1_main(llvm::ArrayRef<char
const*>, char const*, void*) + 1178
> 27 clang-3.8                   0x08052a9b main + 1723
> 28 libc.so.6                   0xf46424e7 __libc_start_main + 361
> 29 clang-3.8                   0x08054f80
> Stack dump:
> 0.	Program arguments: /usr/bin/clang-3.8 -cc1 -triple i686-pc-linux-gnu
-emit-obj -disable-free -main-file-name PrettyStackTrace.cpp -mrelocation-model
pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu i686
-momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb
-ffunction-sections -fdata-sections -coverage-file
/builddir/build/BUILD/llvm-3.9.0.src/build/lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o
-resource-dir /usr/bin/../lib/clang/3.8.1 -dependency-file
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -sys-header-deps
-MT lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -D _GNU_SOURCE
-D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I
lib/Support -I ../lib/Support -I include -I ../include -D _FORTIFY_SOURCE=2 -D
_LARGEFILE_SOURCE=1 -D _LARGEFILE64_SOURCE=1 -D _FILE_OFFSET_BITS=64 -D
_FORTIFY_SOURCE=2 -D _LARGEFILE_SOURCE=1 -D _LARGEFILE64_SOURCE=1 -D
_FILE_OFFSET_BITS=64 -internal-isystem
/usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1
-internal-isystem
/usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1/i586-mandriva-linux-gnu
-internal-isystem
/usr/bin/../lib/gcc/i586-mandriva-linux-gnu/5.4.1/../../../../include/c++/5.4.1/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.8.1/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -Os -Wformat -Werror=format-security
-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -Wformat
-Werror=format-security -pedantic -std=c++1y -fdeprecated-macro
-fdebug-compilation-dir /builddir/build/BUILD/llvm-3.9.0.src/build -ferror-limit
19 -fmessage-length 0 -fvisibility-inlines-hidden -stack-protector 1
-stack-protector-buffer-size 4 -stack-protector-buffer-size 4 -fobjc-runtime=gcc
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-vectorize-loops -vectorize-slp -o
lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -x c++
../lib/Support/PrettyStackTrace.cpp
> 1.	<eof> parser at end of file
> 2.	Code generation
> 3.	Running pass 'Function Pass Manager' on module
'../lib/Support/PrettyStackTrace.cpp'.
> 4.	Running pass 'Prologue/Epilogue Insertion & Frame
Finalization' on function '@_ZN4llvm21PrettyStackTraceEntryD0Ev'
> clang-3.8: error: unable to execute command: Aborted (core dumped)
> clang-3.8: error: clang frontend command failed due to signal (use -v to
see invocation)
> clang version 3.8.1 (tags/RELEASE_381/rc1)
> Target: i686-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> clang-3.8: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
> clang-3.8: note: diagnostic msg:
> ********************
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang-3.8: note: diagnostic msg: /tmp/PrettyStackTrace-74cffb.cpp
> clang-3.8: note: diagnostic msg: /tmp/PrettyStackTrace-74cffb.sh
> clang-3.8: note: diagnostic msg:
> ********************
>
> armv7hnl fails to build libunwind, but this is likely a configuration
> issue:
>
> CMake Error at projects/libunwind/src/CMakeLists.txt:76 (message):
>   Compiler doesn't support generation of unwind tables if exception
support
>   is disabled.  Building libunwind DSO with runtime dependency on C++ ABI
>   library is not supported.
>
> aarch64 is currently untested because of problems with our only aarch64
> build box, but that should be fixed soon.
>
> We don't currently have access to sftp.
>
> ttyl
> bero
>
> On 30 July 2016 at 00:57, Hans Wennborg via Release-testers <
> release-testers at lists.llvm.org> wrote:
>
>> Dear testers,
>>
>> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
>>
>> This took a little longer than I'd hoped, but I think the branch is
in
>> a decent state now.
>>
>> There are still open merge requests and bugs, but I'd like to get
the
>> real testing started to see where we're at.
>>
>> Please build, test, and upload binaries to the sftp. Let me know how
>> it goes. I'll upload source, docs, and your binaries to the
>> pre-release page once they're ready.
>>
>> Thanks,
>> Hans
>> _______________________________________________
>> Release-testers mailing list
>> Release-testers at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160801/95f09974/attachment.html>

On Sun, Jul 31, 2016 at 12:38 PM, Renato Golin <renato.golin at
linaro.org> wrote:
> On 29 July 2016 at 23:57, Hans Wennborg via Release-testers
> <release-testers at lists.llvm.org> wrote:
>> There are still open merge requests and bugs, but I'd like to get
the
>> real testing started to see where we're at.
>
> First wave of testing pass on ARM. Uploaded to the FTP server.
>
> Is it time to do the back-ports planned? I only have a very minor bug fix.
Sure!

Cheers,
Hans

On Fri, Jul 29, 2016 at 3:57 PM, Hans Wennborg <hans at chromium.org>
wrote:
> Dear testers,
>
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
>
> This took a little longer than I'd hoped, but I think the branch is in
> a decent state now.
>
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the
> pre-release page once they're ready.
Windows looked good. Binaries (sha1):
7f350f8a4903965ea9f3800f6d30a782ce86b0df  LLVM-3.9.0-rc1-win32.exe
0b40f11a8d6c1f1fb69dcf213916cf439bb326c0  LLVM-3.9.0-rc1-win64.exe

On 07/29/2016 11:57 PM, Hans Wennborg via Release-testers
wrote:
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the
> pre-release page once they're ready.
Uploaded clang+llvm-3.9.0-rc1-x86_64-linux-gnu-ubuntu-16.04.tar.xz

I had this error:

Using configuration variant: libcxxabi
-- Testing: 35960 tests, 8 threads --
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. *** stack smashing 
detected ***: 
/home/ben/development/llvm/3.9.0/rc1/Phase3/Release/llvmCore-3.9.0-rc1.obj/projects/compiler-rt/test/safestack/Output/canary.c.tmp.ssp
terminated
80.. 90..
Testing Time: 1695.83s
   Expected Passes    : 34915
   Expected Failures  : 212
   Unsupported Tests  : 833
[100%] Built target check-all

LNT was fine.

Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160802/37224822/attachment.html>

On 30 Jul 2016, at 00:57, Hans Wennborg via Release-testers <release-testers
at lists.llvm.org> wrote:
> 
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
After fixing two compiler-rt test failures (see r277297 and r277300) and one
openmp test link failure (see https://reviews.llvm.org/D23084), I'm left
with only two failing tests:

Failing Tests (2):
    ThreadSanitizer-x86_64 :: inlined_memcpy_race2.cc
    ThreadSanitizer-x86_64 :: signal_reset.cc

  Expected Passes    : 28511
  Expected Failures  : 155
  Unsupported Tests  : 1080
  Unexpected Failures: 2

These both fail because they hang indefinitely, and have to be killed for
check-all to continue.

Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and
higher, due to a conflict of initialization order with our jemalloc.  So I am
not extremely keen on fixing this before the release.

I uploaded the following:

SHA256 (clang+llvm-3.9.0-rc1-amd64-unknown-freebsd10.tar.xz) =
8d3b1d50c00901d235c110a84afa5c16f0e80683928a47e31f8c189a41268698
SHA256 (clang+llvm-3.9.0-rc1-i386-unknown-freebsd10.tar.xz) =
602373772b4ff2fc70c97f5483db33e3ecfd24122aed96d6fe083bae3ea0e6f6

For i386 and amd64, this contains llvm, clang, compiler-rt and lldb, while on
amd64 there is also openmp.  We cannot yet build libc++, libcxxabi and
libunwind, due to some missing functionality in our system unwinder.  Maybe if
test-release.sh supported building libc++ separately, I could add it for the
next RC.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160803/73508c37/attachment.sig>

On 3 August 2016 at 19:24, Dimitry Andric via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and
higher, due to a conflict of initialization order with our jemalloc.  So I am
not extremely keen on fixing this before the release.
This sounds really serious. Do we have a bug for that?

--renato

Testsuite is green on both Fedora and openSUSE. Both x86 distros are
failing to find i686.so of compiler_rt.

There's one check-all failure on Fedora x64:
FAIL: libc++ ::
std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp
(31305 of 35085)
In hard_link_count_for_directory():54 Assertion
TEST_CHECK(hard_link_count(StaticEnv::Dir) == DirExpect) failed.
    in file:
/home/nikola/rc1/llvm.src/projects/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp

In hard_link_count_for_directory():55 Assertion
TEST_CHECK(hard_link_count(StaticEnv::Dir3) == Dir3Expect) failed.
    in file:
/home/nikola/rc1/llvm.src/projects/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp

In hard_link_count_for_directory():58 Assertion
TEST_CHECK(hard_link_count(StaticEnv::Dir, ec) == DirExpect) failed.
    in file:
/home/nikola/rc1/llvm.src/projects/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp

In hard_link_count_for_directory():59 Assertion
TEST_CHECK(hard_link_count(StaticEnv::Dir3, ec) == Dir3Expect) failed.
    in file:
/home/nikola/rc1/llvm.src/projects/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.hard_lk_ct/hard_link_count.pass.cpp

I've uploaded the binaries without LLDB because I was using the old version
of test-release, I'll fix this before rc2.

On Sat, Jul 30, 2016 at 8:57 AM, Hans Wennborg via Release-testers <
release-testers at lists.llvm.org> wrote:
> Dear testers,
>
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
>
> This took a little longer than I'd hoped, but I think the branch is in
> a decent state now.
>
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the
> pre-release page once they're ready.
>
> Thanks,
> Hans
> _______________________________________________
> Release-testers mailing list
> Release-testers at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160806/4c35d1e9/attachment.html>

[earlier I had accidentally sent this message to only Hans, re-sending as
reply-all now]

When I tried rc1 on sles11.3 x86_64, msan's getrlimit test fails to build
for lack of prlimit().  SLES11.3 has glibc 2.11.3.  Is there a minimum
required glibc?  I think this test implementation previously used
getrlimit(), which is present on glibc2.11.3.



On Fri, Jul 29, 2016 at 5:57 PM, Hans Wennborg via Release-testers <
release-testers at lists.llvm.org> wrote:
> Dear testers,
>
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
>
> This took a little longer than I'd hoped, but I think the branch is in
> a decent state now.
>
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the
> pre-release page once they're ready.
>
> Thanks,
> Hans
> _______________________________________________
> Release-testers mailing list
> Release-testers at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


-- 
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160810/5c2ec963/attachment.html>