llvm dev - Dec 2017 - 5.0.1-rc2 has been tagged

Hi,

I've tagged the 5.0.1-rc2 release, go ahead and start testing and report
your results.

-Tom

On Wed, Nov 29, 2017 at 4:19 PM, Tom Stellard via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hi,
>
> I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
> your results.
Windows is ready:
$ sha1sum LLVM-5.0.1-rc2-win*
4b0b50374fe201e1da32fba5ce9b579663ba99a4  LLVM-5.0.1-rc2-win32.exe
8bfebc0330999a01d451ed50a87f9f124e86bc75  LLVM-5.0.1-rc2-win64.exe


>
> -Tom
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

W dniu śro, 29.11.2017 o godzinie 16∶19 -0800, użytkownik Tom Stellard
via Release-testers napisał:
> I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
> your results.
I've run Gentoo tests on the current git release_50 branch, and found
two issues:

a. LLDB is still randomly completely broken on my x86 (32-bit) chroot.
This is not a regression, and I really have no clue what's wrong with
it. Fact is, I had the same problem on amd64 and it seems that it
miraculously started working while I've been trying to figure it out.

b. Four sanitizer tests fail on my x86 chroot:

Failing Tests (4):                                                   
    LeakSanitizer-AddressSanitizer-i386 ::
TestCases/large_allocation_leak.cc
    LeakSanitizer-AddressSanitizer-i386 :: TestCases/stale_stack_leak.cc
    LeakSanitizer-Standalone-i386 :: TestCases/large_allocation_leak.cc
    LeakSanitizer-Standalone-i386 :: TestCases/stale_stack_leak.cc

Curious enough, the same tests work fine as part of amd64 build. I'm not
sure if it's a regression; it is possible that I've skipped x86
sanitizer tests previously assuming that they're tested as part of amd64
build anyway. I will try 5.0.0 for comparison shortly.

-- 
Best regards,
Michał Górny

On Wed, Nov 29, 2017 at 6:19 PM, Tom Stellard via Release-testers <
release-testers at lists.llvm.org> wrote:
> Hi,
>
> I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
> your results.
>
>
>
SLES11 uploaded.

1312db7bdfd05c82dd52983f8c5df1a6819df79f
clang+llvm-5.0.1-rc2-linux-x86_64-sles11.3.tar.xz
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171130/08bbfa62/attachment.html>

Uploaded ARM & AArch64, both look ok.

d5d0db7e1b8c6965d02ac4e808b06d557692f65a
clang+llvm-5.0.1-rc2-aarch64-linux-gnu.tar.xz
9c60961ad7417f5e296330428e1f2bf4863b07e7
clang+llvm-5.0.1-rc2-armv7a-linux-gnueabihf.tar.xz

Cheers,
Diana

On 1 December 2017 at 03:05, Brian Cain via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
> On Wed, Nov 29, 2017 at 6:19 PM, Tom Stellard via Release-testers
> <release-testers at lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
>> your results.
>>
>>
>
>
> SLES11 uploaded.
>
> 1312db7bdfd05c82dd52983f8c5df1a6819df79f
> clang+llvm-5.0.1-rc2-linux-x86_64-sles11.3.tar.xz
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

On 30/11/2017 01:19, Tom Stellard via Release-testers
wrote:
> Hi,
> 
> I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
> your results.
Besides an intermittent issue with mips64el (not a recent regression), looks
great!
Thanks
S

On 30 Nov 2017, at 01:19, Tom Stellard via Release-testers <release-testers
at lists.llvm.org> wrote:
> I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
> your results.
Built and uploaded for FreeBSD 10:

SHA256 (clang+llvm-5.0.1-rc2-amd64-unknown-freebsd10.tar.xz) =
0a0e62f346558ef7d63557836feba3510e2d4c1178abe5b1805ceaa395d316b7
SHA256 (clang+llvm-5.0.1-rc2-i386-unknown-freebsd10.tar.xz) =
1172be40df1f8051535443b0374472fa58900879752aa150ac8286f140cc6b1e

-Dimitry

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

Hi, Tom,

I have a BPF backend bug which is pretty noxious which is introduced
in 5.0 and fixed in 6.0 trunk.
The detailed of the backport commit is at the end of this email, which
is slightly different from
6.0 fix to adjust the asm output format. Is there a way for this bug
fix into 5.0.1 release and if yes,
what is the process?

I have applied the commit below to latest release_50 branch in my
local repo and run through all BPF tests
and they are fine.

Thanks!

Yonghong

===== Commit to backport Details ====commit
a115edb82180f0c94d692c4abfd631984ada156b
Author: Yonghong Song <yhs at fb.com>
Date:   Mon Oct 16 04:14:53 2017 +0000

    bpf: fix bug on silently truncating 64-bit immediate

    We came across an llvm bug when compiling some testcases that 64-bit
    immediates are silently truncated into 32-bit and then packed into
    BPF_JMP | BPF_K encoding.  This caused comparison with wrong value.

    This bug looks to be introduced by r308080 (llvm 5.0). The
Select_Ri pattern is
    supposed to be lowered into J*_Ri while the latter only support 32-bit
    immediate encoding, therefore Select_Ri should have similar immediate
    predicate check as what J*_Ri are doing.

    The bug is fixed by
    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 315889
91177308-0d34-0410-b5e6-96231b3b80d8
    in llvm 6.0.

    This patch is largely the same as the fix in llvm 6.0 except
    one minor adjustment ("; CHECK:  r{{[0-9]+}} = 8589934591 ll" in
the original commit
    to "; CHECK:  r{{[0-9]+}} = 8589934591ll" in this patch) for the
test case.

    Reported-by: John Fastabend <john.fastabend at gmail.com>
    Reported-by: Jakub Kicinski <jakub.kicinski at netronome.com>
    Signed-off-by: Jiong Wang <jiong.wang at netronome.com>
    Reviewed-by: Yonghong Song <yhs at fb.com>

diff --git a/lib/Target/BPF/BPFISelLowering.cpp
b/lib/Target/BPF/BPFISelLowering.cpp
index 81b0aa7..5740b49 100644
--- a/lib/Target/BPF/BPFISelLowering.cpp
+++ b/lib/Target/BPF/BPFISelLowering.cpp
@@ -578,11 +578,15 @@
BPFTargetLowering::EmitInstrWithCustomInserter(MachineInstr &MI,
         .addReg(LHS)
         .addReg(MI.getOperand(2).getReg())
         .addMBB(Copy1MBB);
-  else
+  else {
+    int64_t imm32 = MI.getOperand(2).getImm();
+    // sanity check before we build J*_ri instruction.
+    assert (isInt<32>(imm32));
     BuildMI(BB, DL, TII.get(NewCC))
         .addReg(LHS)
-        .addImm(MI.getOperand(2).getImm())
+        .addImm(imm32)
         .addMBB(Copy1MBB);
+  }

   // Copy0MBB:
   //  %FalseValue = ...
diff --git a/lib/Target/BPF/BPFInstrInfo.td b/lib/Target/BPF/BPFInstrInfo.td
index f683578..56f0f9c 100644
--- a/lib/Target/BPF/BPFInstrInfo.td
+++ b/lib/Target/BPF/BPFInstrInfo.td
@@ -464,7 +464,7 @@ let usesCustomInserter = 1 in {
                       (ins GPR:$lhs, i64imm:$rhs, i64imm:$imm,
GPR:$src, GPR:$src2),
                       "# Select PSEUDO $dst = $lhs $imm $rhs ? $src :
$src2",
                       [(set i64:$dst,
-                       (BPFselectcc i64:$lhs, (i64 imm:$rhs), (i64
imm:$imm), i64:$src, i64:$src2))]>;
+                       (BPFselectcc i64:$lhs, (i64immSExt32:$rhs),
(i64 imm:$imm), i64:$src, i64:$src2))]>;
 }

 // load 64-bit global addr into register
diff --git a/test/CodeGen/BPF/select_ri.ll b/test/CodeGen/BPF/select_ri.ll
index c4ac376..3610d40 100644
--- a/test/CodeGen/BPF/select_ri.ll
+++ b/test/CodeGen/BPF/select_ri.ll
@@ -25,3 +25,38 @@ entry:
 }

 attributes #0 = { norecurse nounwind readonly }
+
+; test immediate out of 32-bit range
+; Source file:
+
+; unsigned long long
+; load_word(void *buf, unsigned long long off)
+; asm("llvm.bpf.load.word");
+;
+; int
+; foo(void *buf)
+; {
+;  unsigned long long sum = 0;
+;
+;  sum += load_word(buf, 100);
+;  sum += load_word(buf, 104);
+;
+;  if (sum != 0x1ffffffffULL)
+;    return ~0U;
+;
+;  return 0;
+;}
+
+; Function Attrs: nounwind readonly
+define i32 @foo(i8*) local_unnamed_addr #0 {
+  %2 = tail call i64 @llvm.bpf.load.word(i8* %0, i64 100)
+  %3 = tail call i64 @llvm.bpf.load.word(i8* %0, i64 104)
+  %4 = add i64 %3, %2
+  %5 = icmp ne i64 %4, 8589934591
+; CHECK:  r{{[0-9]+}} = 8589934591ll
+  %6 = sext i1 %5 to i32
+  ret i32 %6
+}
+
+; Function Attrs: nounwind readonly
+declare i64 @llvm.bpf.load.word(i8*, i64) #1

On Wed, Nov 29, 2017 at 4:19 PM, Tom Stellard via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
> your results.
>
> -Tom
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Zig tests using Debug build of 5.0.1rc2 hit this bug:
https://bugs.llvm.org/show_bug.cgi?id=34452
I suppose the fix has not been backported to 5.0.1.

So I created a Release build of 5.0.1rc2 and all zig tests pass, with the
following patches:

* Patches to LLD:

commit a206ef34bbbc46017e471063a4a1832c1ddafb0a
Author: Andrew Kelley <superjoe30 at gmail.com>
Date:   Fri Dec 1 12:11:55 2017 -0500

    LLD patch: Fix the ASM code generated for __stub_helpers section

    This applies 93ca847862af07632197dcf2d8a68b9b27a26d7a
    from the llvm-project git monorepo to the embedded LLD.

commit ddca67a2b94f68985789fc8254fd1326e26269f6
Author: Andrew Kelley <superjoe30 at gmail.com>
Date:   Fri Dec 1 12:09:55 2017 -0500

    LLD patch: workaround for buggy MACH-O code

    This reapplies 1a1414fc42c7beb25b6de4134d99884ea6544b57
    to the embedded LLD.
diff --git a/deps/lld/lib/ReaderWriter/MachO/ArchHandler_x86_64.cpp
b/deps/lld/lib/ReaderWriter/MachO/ArchHandler_x86_64.cpp
index d687ca5d..07958da4 100644
--- a/deps/lld/lib/ReaderWriter/MachO/ArchHandler_x86_64.cpp
+++ b/deps/lld/lib/ReaderWriter/MachO/ArchHandler_x86_64.cpp
@@ -617,7 +617,6 @@ void ArchHandler_x86_64::applyFixupFinal(
     // Fall into llvm_unreachable().
     break;
   }
-  llvm_unreachable("invalid x86_64 Reference Kind");
 }

 void ArchHandler_x86_64::applyFixupRelocatable(const Reference &ref,


commit fa45407e78c7a20281bf063f659d74f86c127ea1
Author: Andrew Kelley <superjoe30 at gmail.com>
Date:   Fri Dec 1 12:08:16 2017 -0500

    LLD patch: Fix for LLD on linker scripts with empty sections

    This reapplies 569cf286ff79a10126b9f20f39fa8c64df9b8b25
    to the embedded LLD.
diff --git a/deps/lld/ELF/LinkerScript.cpp b/deps/lld/ELF/LinkerScript.cpp
index 8bdbd8db..614f5e2c 100644
--- a/deps/lld/ELF/LinkerScript.cpp
+++ b/deps/lld/ELF/LinkerScript.cpp
@@ -751,7 +751,7 @@ void LinkerScript::adjustSectionsAfterSorting() {
     if (auto *Cmd = dyn_cast<OutputSectionCommand>(Base)) {
       Cmd->MemRegion = findMemoryRegion(Cmd);
       // Handle align (e.g. ".foo : ALIGN(16) { ... }").
-      if (Cmd->AlignExpr)
+      if (Cmd->AlignExpr && Cmd->Sec)
         Cmd->Sec->updateAlignment(Cmd->AlignExpr().getValue());
     }
   }


commit 9ea23272fac7f4580d29f7ee557108883f127a5d
Author: Andrew Kelley <superjoe30 at gmail.com>
Date:   Fri Dec 1 12:06:33 2017 -0500

    LLD patch: COFF: better behavior when using as a library

    This applies de776439b61fb71c1256ad86238799c758c66048
    from the LLVM git monorepo to the embedded LLD.



* Patches to clang headers:

diff --git a/c_headers/stdarg.h b/c_headers/stdarg.h
index d603d353..101426ff 100644
--- a/c_headers/stdarg.h
+++ b/c_headers/stdarg.h
@@ -26,14 +26,10 @@
 #ifndef __STDARG_H
 #define __STDARG_H

-/* zig: added because macos _va_list.h was duplicately defining va_list
- */
 #ifndef _VA_LIST
-#ifndef _VA_LIST_T
 typedef __builtin_va_list va_list;
 #define _VA_LIST
 #endif
-#endif
 #define va_start(ap, param) __builtin_va_start(ap, param)
 #define va_end(ap)          __builtin_va_end(ap)
 #define va_arg(ap, type)    __builtin_va_arg(ap, type)
@@ -50,9 +46,6 @@ typedef __builtin_va_list va_list;
 #ifndef __GNUC_VA_LIST
 #define __GNUC_VA_LIST 1
 typedef __builtin_va_list __gnuc_va_list;
-/* zig: added because glibc stdio.h was duplicately defining va_list
- */
-#define _VA_LIST_DEFINED
 #endif

 #endif /* __STDARG_H */
diff --git a/c_headers/stddef.h b/c_headers/stddef.h
index 3b55d42c..73549967 100644
--- a/c_headers/stddef.h
+++ b/c_headers/stddef.h
@@ -48,13 +48,7 @@
 #if !__has_feature(modules)
 #define _PTRDIFF_T
 #endif
-
-/* Zig: wrap in _PTRDIFF_T_DEFINED to protect against mingw defining it
twice */
-#if !defined(_PTRDIFF_T_DEFINED)
 typedef __PTRDIFF_TYPE__ ptrdiff_t;
-#define _PTRDIFF_T_DEFINED
-#endif
-
 #endif
 #undef __need_ptrdiff_t
 #endif /* defined(__need_ptrdiff_t) */
@@ -65,24 +59,7 @@ typedef __PTRDIFF_TYPE__ ptrdiff_t;
 #if !__has_feature(modules)
 #define _SIZE_T
 #endif
-
-/* Zig: added to avoid collisions with mingw */
-#if !defined(_SIZE_T_DEFINED_)
-#if !defined(_SIZE_T_DEFINED)
-#if !defined(_BSD_SIZE_T_DEFINED_)
-#if !defined(_SIZE_T_DECLARED)
 typedef __SIZE_TYPE__ size_t;
-#define _SIZE_T_DEFINED_
-#define _SIZE_T_DEFINED
-#define _BSD_SIZE_T_DEFINED_
-#define _SIZE_T_DECLARED
-#endif
-#endif
-#endif
-#endif
-
-
-
 #endif
 #undef __need_size_t
 #endif /*defined(__need_size_t) */
@@ -110,22 +87,7 @@ typedef __SIZE_TYPE__ rsize_t;
 #define _WCHAR_T_DEFINED
 #endif
 #endif
-
-/* zig added to prevent duplicate definition with mingw */
-#if !defined(__INT_WCHAR_T_H)
-#if !defined(_GCC_WCHAR_T)
-#if !defined(_WCHAR_T_DECLARED)
-#if !defined(_WCHAR_T_DEFINED)
-#define __INT_WCHAR_T_H
-#define _GCC_WCHAR_T
-#define _WCHAR_T_DECLARED
-#define _WCHAR_T_DEFINED
 typedef __WCHAR_TYPE__ wchar_t;
-#endif
-#endif
-#endif
-#endif
-
 #endif
 #endif
 #undef __need_wchar_t





On Fri, Dec 1, 2017 at 10:30 AM, Sylvestre Ledru via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 30/11/2017 01:19, Tom Stellard via Release-testers wrote:
> > Hi,
> >
> > I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
> > your results.
> Besides an intermittent issue with mips64el (not a recent regression),
> looks great!
> Thanks
> S
>
> _______________________________________________
> 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/20171201/6fe269ae/attachment-0001.html>

Hi, Tom,

Considering the severity of this bug, I would like to go ahead to push
the fix into release_50 branch. The fix has been tested in the trunk and by
various people as well and I will also make sure all BPF tests passed
before the push.

Thanks!

Yonghong

On Fri, Dec 1, 2017 at 10:18 AM, Y Song <ys114321 at gmail.com>
wrote:
> Hi, Tom,
>
> I have a BPF backend bug which is pretty noxious which is introduced
> in 5.0 and fixed in 6.0 trunk.
> The detailed of the backport commit is at the end of this email, which
> is slightly different from
> 6.0 fix to adjust the asm output format. Is there a way for this bug
> fix into 5.0.1 release and if yes,
> what is the process?
>
> I have applied the commit below to latest release_50 branch in my
> local repo and run through all BPF tests
> and they are fine.
>
> Thanks!
>
> Yonghong
>
> ===== Commit to backport Details ====> commit
a115edb82180f0c94d692c4abfd631984ada156b
> Author: Yonghong Song <yhs at fb.com>
> Date:   Mon Oct 16 04:14:53 2017 +0000
>
>     bpf: fix bug on silently truncating 64-bit immediate
>
>     We came across an llvm bug when compiling some testcases that 64-bit
>     immediates are silently truncated into 32-bit and then packed into
>     BPF_JMP | BPF_K encoding.  This caused comparison with wrong value.
>
>     This bug looks to be introduced by r308080 (llvm 5.0). The
> Select_Ri pattern is
>     supposed to be lowered into J*_Ri while the latter only support 32-bit
>     immediate encoding, therefore Select_Ri should have similar immediate
>     predicate check as what J*_Ri are doing.
>
>     The bug is fixed by
>     git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 315889
> 91177308-0d34-0410-b5e6-96231b3b80d8
>     in llvm 6.0.
>
>     This patch is largely the same as the fix in llvm 6.0 except
>     one minor adjustment ("; CHECK:  r{{[0-9]+}} = 8589934591 ll"
in
> the original commit
>     to "; CHECK:  r{{[0-9]+}} = 8589934591ll" in this patch) for
the test case.
>
>     Reported-by: John Fastabend <john.fastabend at gmail.com>
>     Reported-by: Jakub Kicinski <jakub.kicinski at netronome.com>
>     Signed-off-by: Jiong Wang <jiong.wang at netronome.com>
>     Reviewed-by: Yonghong Song <yhs at fb.com>
>
> diff --git a/lib/Target/BPF/BPFISelLowering.cpp
> b/lib/Target/BPF/BPFISelLowering.cpp
> index 81b0aa7..5740b49 100644
> --- a/lib/Target/BPF/BPFISelLowering.cpp
> +++ b/lib/Target/BPF/BPFISelLowering.cpp
> @@ -578,11 +578,15 @@
> BPFTargetLowering::EmitInstrWithCustomInserter(MachineInstr &MI,
>          .addReg(LHS)
>          .addReg(MI.getOperand(2).getReg())
>          .addMBB(Copy1MBB);
> -  else
> +  else {
> +    int64_t imm32 = MI.getOperand(2).getImm();
> +    // sanity check before we build J*_ri instruction.
> +    assert (isInt<32>(imm32));
>      BuildMI(BB, DL, TII.get(NewCC))
>          .addReg(LHS)
> -        .addImm(MI.getOperand(2).getImm())
> +        .addImm(imm32)
>          .addMBB(Copy1MBB);
> +  }
>
>    // Copy0MBB:
>    //  %FalseValue = ...
> diff --git a/lib/Target/BPF/BPFInstrInfo.td
b/lib/Target/BPF/BPFInstrInfo.td
> index f683578..56f0f9c 100644
> --- a/lib/Target/BPF/BPFInstrInfo.td
> +++ b/lib/Target/BPF/BPFInstrInfo.td
> @@ -464,7 +464,7 @@ let usesCustomInserter = 1 in {
>                        (ins GPR:$lhs, i64imm:$rhs, i64imm:$imm,
> GPR:$src, GPR:$src2),
>                        "# Select PSEUDO $dst = $lhs $imm $rhs ? $src :
$src2",
>                        [(set i64:$dst,
> -                       (BPFselectcc i64:$lhs, (i64 imm:$rhs), (i64
> imm:$imm), i64:$src, i64:$src2))]>;
> +                       (BPFselectcc i64:$lhs, (i64immSExt32:$rhs),
> (i64 imm:$imm), i64:$src, i64:$src2))]>;
>  }
>
>  // load 64-bit global addr into register
> diff --git a/test/CodeGen/BPF/select_ri.ll b/test/CodeGen/BPF/select_ri.ll
> index c4ac376..3610d40 100644
> --- a/test/CodeGen/BPF/select_ri.ll
> +++ b/test/CodeGen/BPF/select_ri.ll
> @@ -25,3 +25,38 @@ entry:
>  }
>
>  attributes #0 = { norecurse nounwind readonly }
> +
> +; test immediate out of 32-bit range
> +; Source file:
> +
> +; unsigned long long
> +; load_word(void *buf, unsigned long long off)
> +; asm("llvm.bpf.load.word");
> +;
> +; int
> +; foo(void *buf)
> +; {
> +;  unsigned long long sum = 0;
> +;
> +;  sum += load_word(buf, 100);
> +;  sum += load_word(buf, 104);
> +;
> +;  if (sum != 0x1ffffffffULL)
> +;    return ~0U;
> +;
> +;  return 0;
> +;}
> +
> +; Function Attrs: nounwind readonly
> +define i32 @foo(i8*) local_unnamed_addr #0 {
> +  %2 = tail call i64 @llvm.bpf.load.word(i8* %0, i64 100)
> +  %3 = tail call i64 @llvm.bpf.load.word(i8* %0, i64 104)
> +  %4 = add i64 %3, %2
> +  %5 = icmp ne i64 %4, 8589934591
> +; CHECK:  r{{[0-9]+}} = 8589934591ll
> +  %6 = sext i1 %5 to i32
> +  ret i32 %6
> +}
> +
> +; Function Attrs: nounwind readonly
> +declare i64 @llvm.bpf.load.word(i8*, i64) #1
>
> On Wed, Nov 29, 2017 at 4:19 PM, Tom Stellard via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Hi,
>>
>> I've tagged the 5.0.1-rc2 release, go ahead and start testing and
report
>> your results.
>>
>> -Tom
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev