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

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

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.

SLES11 uploaded.

1312db7bdfd05c82dd52983f8c5df1a6819df79f
clang+llvm-5.0.1-rc2-linux-x86_64-sles11.3.tar.xz

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

Besides an intermittent issue with mips64el (not a recent regression), looks great!
Thanks
S

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

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@fb.com>

    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@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@gmail.com>
    Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
    Reviewed-by: Yonghong Song <yhs@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 }

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@gmail.com>

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

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.

Hi Yonghong,

Thank you for helping out with LLVM release testing.

Patches need to be approved by the release manager and code owner before they
can be committed to the release branch.

Take a look at http://llvm.org/docs/HowToReleaseLLVM.html#merge-requests
for the process of filling a merge request.

This late in the process we usually only accept critical bugs or regression
fixes.

Can you give me a little more information about this particular bug?
What is the impact to users and how likely are they to encounter this
issue?

Thanks,
Tom

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.

At this point in the release process, we usually only accept critical fixes
or fixes for regressions.

I'm not familiar with Zig tests, can you give me a little more information
about these tests and how these failures will impact users.

Also are these 4 lld patches backports from trunk? If so, which revsions are they?

Thanks,
Tom

Hi, Tom,

Sorry about my rushness about going ahead to get a BPF patch in as
this is my first time to push a patch to a release branch, and I am not aware of
proper process. I promise to follow proper procedures from now on.

See my other comments below.

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.

Hi Yonghong,

Thank you for helping out with LLVM release testing.

Yes, in the future, I do plan to test BPF backend regularly for release branch.

Patches need to be approved by the release manager and code owner before they
can be committed to the release branch.

Take a look at http://llvm.org/docs/HowToReleaseLLVM.html#merge-requests
for the process of filling a merge request.

Sorry about this as I searched and did not find this document earlier.
Now I know it and will definitely follow it from now on.

This late in the process we usually only accept critical bugs or regression
fixes.

Understood.

Can you give me a little more information about this particular bug?
What is the impact to users and how likely are they to encounter this
issue?

This cilium pull request (https://github.com/cilium/cilium/pull/2162)
provided some information and discussion.

The symptom bug looks like below:
  /* here x is a variable */
  if (x == #const) /* the same for != */
    ...

Wrong code will be generated if #const is > 0x7FFFFFFFF.
For example,
   if (x == 0xffff0000)
     ...
will generate wrong code
and
  if (x != 0xffff00000000ULL)
will generate wrong code as well.

The bug is pretty nasty and if it hits the user, it is very hard for
them to debug and workaround unless they know compiler internals.
And the chance some people hits this bug is pretty high.

The bug was introduced in 5.0 and was fixed in trunk:

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

At this point in the release process, we usually only accept critical fixes
or fixes for regressions.

That's fair; I'm content to wait for llvm 6 for this patch. Currently, zig
officially depends on a non-assertions-enabled build of LLVM 5 due to this
bug, but we will support LLVM assertions when 6 is released.

I'm not familiar with Zig tests, can you give me a little more information
about these tests and how these failures will impact users.

Zig is a frontend to LLVM just like clang. The tests do a reasonably
thorough job of testing the LLVM API, libclang API, and LLD test cases that
the zig compiler depends on. There are no new regressions since 5.0.0, so
users will continue to use zig like normal after 5.0.1 is released.

Also are these 4 lld patches backports from trunk? If so, which revsions
are they?

2 of them are from trunk.

rL311734: Fix the ASM code generated for __stub_helpers section
rL316370: COFF: better behavior when using as a library

2 of them are not:
* workaround for buggy MACH-O code: This is not a high enough quality
patch to go into trunk; when someone on the zig team has time we will do a
better fix for the root cause and send the patch upstream. No one on the
LLD team has had motivation to fix this bug, which is
https://bugs.llvm.org/show_bug.cgi?id=32254
* Fix for LLD on linker scripts with empty sections: The bug this fixes is
not present in trunk, and this patch will be removed when llvm 6 is
released.

I'll send the c header patches upstream separately.

Hi,

Any idea when the release will land?

Thanks,
R.

Hi, Tom,

Sorry about my rushness about going ahead to get a BPF patch in as
this is my first time to push a patch to a release branch, and I am not aware of
proper process. I promise to follow proper procedures from now on.

Don't worry about it, I know the documentation can be hard to track down sometimes.

It does sound like this is pretty critical, so I've gone ahead and created
a merge request for this: https://bugs.llvm.org/show_bug.cgi?id=35532 so
we can get Alexey's opinion.

I think for now it is OK to leave the patch in the release branch if
for some reason Alexey objects we can just revert it

Thanks,
Tom

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

Hi,

Any idea when the release will land?

5.0.1-rc3 is planned for Thursday, and I'm hoping this is the last release
candidate. If all goes well final release will happen in around 2 weeks.

-Tom

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

I've created a merge request for this one: https://bugs.llvm.org/show_bug.cgi?id=35537
to get feedback from Daniel on how important this fixes is, but I'm not going to
block -rc3 (scheduled for Thursday) waiting for feedback on this bug.

    At this point in the release process, we usually only accept critical fixes
    or fixes for regressions.

That's fair; I'm content to wait for llvm 6 for this patch. Currently, zig officially depends on a non-assertions-enabled build of LLVM 5 due to this bug, but we will support LLVM assertions when 6 is released.

    I'm not familiar with Zig tests, can you give me a little more information
    about these tests and how these failures will impact users.

Zig is a frontend to LLVM just like clang. The tests do a reasonably thorough job of testing the LLVM API, libclang API, and LLD test cases that the zig compiler depends on. There are no new regressions since 5.0.0, so users will continue to use zig like normal after 5.0.1 is released.

    Also are these 4 lld patches backports from trunk? If so, which revsions are they?

2 of them are from trunk.

rL311734: Fix the ASM code generated for __stub_helpers section

This one was approved to merge, but I missed it for -rc2, so I will merge
it for -rc3.

rL316370: COFF: better behavior when using as a library

This isn't critical enough for -rc3.

2 of them are not:
* workaround for buggy MACH-O code: This is not a high enough quality patch to go into trunk; when someone on the zig team has time we will do a better fix for the root cause and send the patch upstream. No one on the LLD team has had motivation to fix this bug, which is https://bugs.llvm.org/show_bug.cgi?id=32254
* Fix for LLD on linker scripts with empty sections: The bug this fixes is not present in trunk, and this patch will be removed when llvm 6 is released.

We can't take patches that aren't upstream yet.

-Tom