[llvm-bugs] [Bug 37369] LoopInvariantCodeMotion do not preserve PostDominatorTree info
https://bugs.llvm.org/show_bug.cgi?id=37369 Karl-Johan Karlsson changed: What|Removed |Added Status|NEW |RESOLVED CC||junb...@codeaurora.org Resolution|--- |DUPLICATE --- Comment #3 from Karl-Johan Karlsson --- Daniel Berlin is right, SplitBlockPredecessors() (from BasicBlockUtils.cpp) is called from LICM and it only update DominatorTree not the PostDominatorTree When I wrote this issue I missed that this seems to be a duplicate of the issue https://bugs.llvm.org/show_bug.cgi?id=37323 *** This bug has been marked as a duplicate of bug 37323 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37390] New: -reassociate runs forever
https://bugs.llvm.org/show_bug.cgi?id=37390 Bug ID: 37390 Summary: -reassociate runs forever Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: llvm-bugs@lists.llvm.org Created attachment 20274 --> https://bugs.llvm.org/attachment.cgi?id=20274&action=edit reproducer Running opt -reassociate tr15989.ll -o - -S never finish. The input is very similar to the one in https://bugs.llvm.org/show_bug.cgi?id=30818 but in this new case we also refer to one of the values produced in the dead basic block in a live basic block. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37357] Assertion failure in RegionStoreManager::getBindingForField()
https://bugs.llvm.org/show_bug.cgi?id=37357 Alexander Kornienko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37391] New: [DebugInfo] Bug in location list address ranges for conditional instruction
https://bugs.llvm.org/show_bug.cgi?id=37391
Bug ID: 37391
Summary: [DebugInfo] Bug in location list address ranges for
conditional instruction
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: sontuan.vu...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hello,
This follows the discussion in
http://lists.llvm.org/pipermail/llvm-dev/2018-May/123080.html
Consider this function:
int verifyPIN(char *userPin, char *cardPin, int *cpt)
{
int i;
int status;
int diff;
if (*cpt > 0) {
status = 0x55;
diff = 0x55;
for (i = 0; i < 4; i++) {
if (userPin[i] != cardPin[i]) {
diff = 0xAA;
}
}
if (diff == 0x55) {
status = 0xAA;
}
else {
status = 0x55;
}
if (status == 0xAA) {
*cpt = 3;
return 0xAA;
} else {
*cpt--;
return 0x55;
}
}
return 0x55;
}
Compiling it using:
$ clang -c -target arm-none-eabi -mcpu=cortex-m3 -mthumb -O1 -g main.c -o
main.o
$ arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -o main main.o
Here's the assembly code of `verifyPin()`:
8124 :
8124: push{r4, r6, r7, lr}
8126: add r7, sp, #8
8128: mov r4, r0
812a: ldrsb.w r0, [r2]
812e: cmp r0, #1
8130: itt lt
8132: movlt r0, #85 ; 0x55
8134: poplt {r4, r6, r7, pc}// a function
return
8136: ldrb.w ip, [r1, #3]
813a: ldrb.w lr, [r4, #3]
813e: movsr0, #85 ; 0x55
8140: cmp lr, ip
8142: bne.n 8168
8144: ldrb.w ip, [r1, #2]
8148: ldrbr3, [r4, #2]
814a: cmp r3, ip
814c: it ne
814e: popne {r4, r6, r7, pc} // a function
return
8150: ldrb.w ip, [r1, #1]
8154: ldrbr3, [r4, #1]
8156: cmp r3, ip
8158: bne.n 8168
815a: ldrbr1, [r1, #0]
815c: ldrbr3, [r4, #0]
815e: cmp r3, r1
8160: ittteq
8162: moveq r0, #3
8164: strbeq r0, [r2, #0]
8166: moveq r0, #170; 0xaa
8168: pop {r4, r6, r7, pc} // a function
return
Here's the debug location of `userPin`:
<2><3b>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<3c> DW_AT_location: 0x0 (location list)
<40> DW_AT_name: (indirect string, offset: 0x9e): userPin
<44> DW_AT_decl_file : 1
<45> DW_AT_decl_line : 34
<46> DW_AT_type: <0x153>
// Its location list
8124 812a (DW_OP_reg0 (r0))
000b 812a 8136 (DW_OP_reg4 (r4))
0016
So, currently, r4 contains `userPin`'s value until 0x8134 (poplt {r4, r6, r7,
pc}). However, this is only correct when cpt <= 0 (so 812e: cmp r0, #1 yields
`lt`).
This is because in `IfConversionPass`, `poplt` is generated and is considered
to clobber r4. There's no logic to handle conditional instruction in subsequent
passes, so `DbgValueHistoryCalculator` closes the range at 0x8134.
I think the solution is that conditional instructions should not clobber
register. What do you think?
Thanks for the help
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37392] New: Undesirable -Wrange-loop-analysis warning with auto and vector
https://bugs.llvm.org/show_bug.cgi?id=37392
Bug ID: 37392
Summary: Undesirable -Wrange-loop-analysis warning with auto
and vector
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: s...@rogue-research.com
CC: llvm-bugs@lists.llvm.org
In clang 6.0 and trunk (according to godbolt), the following snippet generates
a warning from -Wrange-loop-analysis when building as C++11:
-
#include
int main()
{
std::vector vectorBool;
for (auto&& elem : vectorBool)
(void)elem;
}
-
warning: loop variable 'elem' is always a copy because the range of type
'std::vector' does not return a reference [-Wrange-loop-analysis]
for (auto&& elem : vectorBool)
^
See also:
Others seem to agree that the warning is not helpful:
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37248] LoopVectorizer triggers "Instruction does not dominate all uses!" after r326079
https://bugs.llvm.org/show_bug.cgi?id=37248 Florian Hahn changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r331799 CC||florian.h...@arm.com --- Comment #4 from Florian Hahn --- Should be fixed by https://reviews.llvm.org/rL331799, thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37375] Merge r327877 into the 6.0 branch : [PowerPC] Make AddrSpaceCast noop
https://bugs.llvm.org/show_bug.cgi?id=37375 Valentin Churavy changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Valentin Churavy --- Hi Hal, I was going through the list of patches that Julia is carrying against 6.0 and I like to see as many of them upstreamed. On the matter of this patch, I maybe should have screened them more carefully and excluded this one. Given this patch a bit more time on trunk to see if any issues crop up seems to be the better avenue. I will be more conservative in the future. Sorry about that. -Valentin -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36649] [meta] 6.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=36649 Bug 36649 depends on bug 37375, which changed state. Bug 37375 Summary: Merge r327877 into the 6.0 branch : [PowerPC] Make AddrSpaceCast noop https://bugs.llvm.org/show_bug.cgi?id=37375 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36977] [PPC64] V2 ABI: Implement symbol resolver stubs and set PPC64_GLINK dynamic tag
https://bugs.llvm.org/show_bug.cgi?id=36977 sfert...@ca.ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from sfert...@ca.ibm.com --- resolved with https://reviews.llvm.org/rLLD331840 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35389] Support ppc64le
https://bugs.llvm.org/show_bug.cgi?id=35389 Bug 35389 depends on bug 36977, which changed state. Bug 36977 Summary: [PPC64] V2 ABI: Implement symbol resolver stubs and set PPC64_GLINK dynamic tag https://bugs.llvm.org/show_bug.cgi?id=36977 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37393] New: natvis files don't work properly with /LINKREPRO
https://bugs.llvm.org/show_bug.cgi?id=37393 Bug ID: 37393 Summary: natvis files don't work properly with /LINKREPRO Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: ztur...@google.com CC: llvm-bugs@lists.llvm.org, pe...@pcc.me.uk, r...@google.com Natvis files should be copied into the repro tar, but instead they aren't and the response file contains the original relative path that was used on the command line. This leads to the natvis files not being located and the linker complaining about a missing input file. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37394] New: clang produces duplicate symbols when enabling Control Flow Integrity (icall)
https://bugs.llvm.org/show_bug.cgi?id=37394
Bug ID: 37394
Summary: clang produces duplicate symbols when enabling Control
Flow Integrity (icall)
Product: clang
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: t...@ritter.vg
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
When I compile the following minimized repoducer, I have duplicate symbols when
enabling CFI. Without CFI, there is only one symbol
> extern int printf (__const char *__restrict __format, ...);
>
> class nsIXPTCStubBase
> {
> public:
> virtual int Stub20() = 0;
> virtual int Sentinel0() = 0;
> };
> class nsXPTCStubBase final : public nsIXPTCStubBase
> {
> public:
> virtual int Stub20() override;
> virtual int Sentinel0() override;
> };
>
>
> asm(".section \".text\"\n\t" \
> ".align 2\n\t" \
> ".globl _ZN14nsXPTCStubBase6Stub20Ev\n\t" \
> ".hidden _ZN14nsXPTCStubBase6Stub20Ev\n\t" \
> ".type _ZN14nsXPTCStubBase6Stub20Ev,@function\n" \
> "_ZN14nsXPTCStubBase6Stub20Ev:\n\t" \
>
> "movl $20, %eax\n\t" \
> "jmp SharedStub\n\t" \
>
> ".size _ZN14nsXPTCStubBase6Stub20Ev,.-_ZN14nsXPTCStubBase6Stub20Ev\n\t" \
> );
>
> int nsXPTCStubBase::Sentinel0() { printf("hi"); return 0; }
My command is
> clang++ -std=gnu++14 -c -o xptcstubs_x86_64_linux.o -fuse-ld=lld -flto=thin
> -fsanitize=cfi-icall xptcstubs_x86_64_linux.i && llvm-nm
> xptcstubs_x86_64_linux.o | grep Stub20 && rm xptcstubs_x86_64_linux.o
> clang-6.0: warning: treating 'cpp-output' input as 'c++-cpp-output' when in
> C++ mode, this behavior is deprecated [-Wdeprecated]
> clang-6.0: warning: argument unused during compilation: '-fuse-ld=lld'
> [-Wunused-command-line-argument]
> T _ZN14nsXPTCStubBase6Stub20Ev
> T _ZN14nsXPTCStubBase6Stub20Ev
I am using a clang/lld/llvm toolchain with llvm revision 317840
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1459624
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37395] New: clang crashes on valid code at -O1 and above with debugging enabled: Assertion `!cast(MD)->getNumOperands() && "Expected an empty MDNode"' failed
https://bugs.llvm.org/show_bug.cgi?id=37395 Bug ID: 37395 Summary: clang crashes on valid code at -O1 and above with debugging enabled: Assertion `!cast(MD)->getNumOperands() && "Expected an empty MDNode"' failed Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Tested with trunk vision 331844. $ clangpolly -v clang version 7.0.0 (http://llvm.org/git/clang.git 49d557c3652a0113159c2d4442391835a2e220e3) (llvm/trunk 331844) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/su/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clangpolly -O1 -c small.c $ clangpolly -O0 -g -c small.c $ $ clangpolly -O1 -g -c small.c clang-6.0: /home/su/software/tmp/polly/llvm/lib/IR/IntrinsicInst.cpp:47: llvm::Value* llvm::DbgInfoIntrinsic::getVariableLocation(bool) const: Assertion `!cast(MD)->getNumOperands() && "Expected an empty MDNode"' failed. Stack dump: 0. Program arguments: /home/su/software/tmp/polly/llvm_build/bin/clang-6.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -momit-leaf-frame-pointer -coverage-notes-file /home/su/specres/good/20180509-clangpolly-m32-O3-g-build-085458/delta/small.gcno -resource-dir /home/su/software/tmp/polly/llvm_build/lib/clang/7.0.0 -internal-isystem /usr/local/include -internal-isystem /home/su/software/tmp/polly/llvm_build/lib/clang/7.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O1 -fdebug-compilation-dir /home/su/specres/good/20180509-clangpolly-m32-O3-g-build-085458/delta -ferror-limit 19 -fmessage-length 116 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o small.o -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Loop-Closed SSA Form Pass' on function '@f' #0 0x0254b29a llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/su/software/tmp/polly/llvm/lib/Support/Unix/Signals.inc:403:0 #1 0x0254944e llvm::sys::RunSignalHandlers() /home/su/software/tmp/polly/llvm/lib/Support/Signals.cpp:50:0 #2 0x025495b0 SignalHandler(int) /home/su/software/tmp/polly/llvm/lib/Support/Unix/Signals.inc:243:0 #3 0x7f5f940e5330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #4 0x7f5f92ecdc37 gsignal /build/eglibc-SvCtMH/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f5f92ed1028 abort /build/eglibc-SvCtMH/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f5f92ec6bf6 __assert_fail_base /build/eglibc-SvCtMH/eglibc-2.19/assert/assert.c:92:0 #7 0x7f5f92ec6ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #8 0x0207ac0f (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0x207ac0f) #9 0x025b91bd dyn_cast_or_null /home/su/software/tmp/polly/llvm/include/llvm/Support/Casting.h:359:0 #10 0x025b
[llvm-bugs] [Bug 37396] New: [AVX512] Incorrect register argument to test instruction
https://bugs.llvm.org/show_bug.cgi?id=37396
Bug ID: 37396
Summary: [AVX512] Incorrect register argument to test
instruction
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: k...@alumni.harvard.edu
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org
Consider the following bugpoint-reduced reproducer of
https://github.com/JuliaLang/julia/issues/27032:
```
define void @japi1_foo2_34617() {
pass2:; preds = %top
br label %if5
L174: ; preds = %if5
%tmp = icmp sgt <2 x i64> undef, zeroinitializer
%tmp1 = icmp sle <2 x i64> undef, undef
%tmp2 = and <2 x i1> %tmp, %tmp1
%tmp3 = extractelement <2 x i1> %tmp2, i32 0
%tmp4 = extractelement <2 x i1> %tmp2, i32 1
%tmp106 = and i1 %tmp4, %tmp3
%tmp107 = zext i1 %tmp106 to i8
%tmp108 = and i8 %tmp122, %tmp107
%tmp109 = icmp eq i8 %tmp108, 0
br i1 %tmp109, label %L188, label %L190
if5: ; preds = %if5, %pass2
%b.055 = phi i8 [ 1, %pass2 ], [ %tmp122, %if5 ]
%tmp118 = icmp sgt i64 undef, 0
%tmp119 = icmp sle i64 undef, undef
%tmp120 = and i1 %tmp118, %tmp119
%tmp121 = zext i1 %tmp120 to i8
%tmp122 = and i8 %b.055, %tmp121
br i1 undef, label %L174, label %if5
L188: ; preds = %L174
unreachable
L190: ; preds = %L174
ret void
}
```
Running llc on trunk (and 6.0) gives:
```
$ llc -mcpu=skylake-avx512 bug.ll -o -
.text
.file "wip.ll"
.globl japi1_foo2_34617# -- Begin function japi1_foo2_34617
.p2align4, 0x90
.type japi1_foo2_34617,@function
japi1_foo2_34617: # @japi1_foo2_34617
.cfi_startproc
# %bb.0:# %L174
testq %rax, %rax
setg%al
vpxor %xmm0, %xmm0, %xmm0
vpcmpgtq%xmm0, %xmm0, %k0
kshiftrw$1, %k0, %k1
kandd %k0, %k1, %k0
testb %k0, %al
je .LBB0_1
# %bb.2:# %L190
retq
.LBB0_1:# %L188
.Lfunc_end0:
.size japi1_foo2_34617, .Lfunc_end0-japi1_foo2_34617
.cfi_endproc
# -- End function
.section".note.GNU-stack","",@progbits
```
llvm-mc says it best:
```
$ llvm-mc bug.s
bug.s:15:8: error: invalid operand for instruction
testb %k0, %al
^~~
```
If we try to generate code directly rather than go through textual assembly,
we end up generating `testb %al, %al`, which was the cause of the above linked
bug report.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37397] New: [GlobalISel][AArch64] i1 value in aggregate not zero-extend prior to store
https://bugs.llvm.org/show_bug.cgi?id=37397
Bug ID: 37397
Summary: [GlobalISel][AArch64] i1 value in aggregate not
zero-extend prior to store
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: tstel...@redhat.com
CC: efrie...@codeaurora.org, jist...@redhat.com,
llvm-bugs@lists.llvm.org
Blocks: 36649
This testcase comes from https://github.com/rust-lang/rust/issues/50516 and
shows that GlobalISel does not zero-extend an i1 value to 8-bits prior to
writing it to memory:
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-unknown-linux-gnu"
define void @i1_store() {
start:
%tmp0 = alloca { i32, i1 }, align 4
%tmp1 = call { i32, i1 } @foo()
store { i32, i1 } %tmp1, { i32, i1 }* %tmp0, align 4
ret void
}
declare { i32, i1 } @foo()
llc -O0 gives us:
sub sp, sp, #32 // =32
str x30, [sp, #16] // 8-byte Folded Spill
.cfi_def_cfa_offset 32
.cfi_offset w30, -16
bl foo
// implicit-def: $x8
mov w9, w0
bfxil x8, x9, #0, #32
mov w9, w1
bfi x8, x9, #32, #1
str x8, [sp, #8]
i1 values are stored in memory as 8-bit values, but it is expected that value
will be either 0x0 or 0x1. In this case, since Bits 33-39 of x8 remain
uninitialized, when this value is loaded there will be random values in the
high 7-bits.
Fast-ISel seems to handle this test case correctly:
sub sp, sp, #32 // =32
str x30, [sp, #16] // 8-byte Folded Spill
.cfi_def_cfa_offset 32
.cfi_offset w30, -16
bl foo
str w0, [sp, #8]
and w0, w1, #0x1
strbw0, [sp, #12]
ldr x30, [sp, #16] // 8-byte Folded Reload
add sp, sp, #32 // =32
ret
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=36649
[Bug 36649] [meta] 6.0.1 Release Blockers
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37398] New: Incorrect std::type_info comparison and hash_code for pointer to incomplete type
https://bugs.llvm.org/show_bug.cgi?id=37398 Bug ID: 37398 Summary: Incorrect std::type_info comparison and hash_code for pointer to incomplete type Product: libc++ Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: vsap...@apple.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 20275 --> https://bugs.llvm.org/attachment.cgi?id=20275&action=edit Repro that gets std::type_info in different translation units and compares them. Steps to reproduce: 1. With typeid get std::type_info for a pointer to incomplete type in one translation unit. 2. Get std::type_info for the same type in different translation unit. 3. Compare obtained type_info. 4. Compare hashes of obtained type_info. Small repro case is attached. Actual result: Types are considered to be different, hash codes are different. std::type_info::name() are equal by value, char* pointers are different. Expected result: Types should be equal, hash codes should be equal. Comments: In this case clang emits type info with internal linkage [1] which is correct according to my understanding of Itanium C++ ABI. Also ABI documentation [2] tells > After linking and loading, only one std::type_info structure is accessible > via the external name defined by this ABI for any particular complete type > symbol (see Vague Linkage). Therefore, except for direct or indirect pointers > to incomplete types, the equality and inequality operators can be written as > address comparisons when operating on those type_info objects: two type_info > structures describe the same type if and only if they are the same structure > (at the same address). However, in the case of pointer types, directly or > indirectly pointing to incomplete class types, a more complex comparison is > required, described below with the RTTI layout of pointer types. So to me it looks like libc++ bug. [1] https://github.com/llvm-mirror/clang/blob/6a37651bb30339e60ea617d510b4703bcd2e89e8/lib/CodeGen/ItaniumCXXABI.cpp#L3013-L3023 [2] http://refspecs.linuxbase.org/cxxabi-1.83.html#rtti -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37399] New: [ms] CXXRecordDecl::getMSInheritanceModel() dereferences null MSInheritanceAttr
https://bugs.llvm.org/show_bug.cgi?id=37399
Bug ID: 37399
Summary: [ms] CXXRecordDecl::getMSInheritanceModel()
dereferences null MSInheritanceAttr
Product: clang
Version: trunk
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: andrew.rog...@wdc.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20277
--> https://bugs.llvm.org/attachment.cgi?id=20277&action=edit
Testcase
Compile the following:
template
class Functor
{
void (ObjT::*PtrToMemberFunction)();
};
template class DerivedFunctor;
template
class DerivedFunctor
: public Functor >
{
};
DerivedFunctor AFunctor;
with:
clang-cpp.exe -cc1 -emit-llvm-only -x c++ test.cpp
This generates the following ASSERT (debug build) / AV (release build):
C:\Temp\clang\clang>c:\workspaces\llvm-build\Debug\bin\clang-cpp.exe -cc1
-emit-llvm-only -x c++ test.cpp
Assertion failed: IA && "Expected MSInheritanceAttr on the CXXRecordDecl!",
file c:\workspaces\llvm\tools\clang\lib\ast\microsoftcxxabi.cpp, line 171
Wrote crash dump file
"C:\Users\14166\AppData\Local\Temp\clang-cpp.exe-346498.dmp"
...
The failing callstack which tries to use a null MSInheritanceAttr looks like
this:
> clang-cpp.exe!clang::CXXRecordDecl::getMSInheritanceModel() Line 171
> C++
clang-cpp.exe!getMSMemberPointerSlots(const clang::MemberPointerType *
MPT) Line 213C++
clang-cpp.exe!`anonymous
namespace'::MicrosoftCXXABI::getMemberPointerInfo(const
clang::MemberPointerType * MPT) Line 239 C++
clang-cpp.exe!clang::ASTContext::getTypeInfoImpl(const clang::Type * T)
Line 1858 C++
clang-cpp.exe!clang::ASTContext::getTypeInfo(const clang::Type * T)
Line 1657 C++
clang-cpp.exe!clang::ASTContext::getTypeInfoInChars(const clang::Type *
T) Line 1609C++
clang-cpp.exe!`anonymous
namespace'::MicrosoftRecordLayoutBuilder::getAdjustedElementInfo(const
clang::FieldDecl * FD) Line 2387C++
clang-cpp.exe!`anonymous
namespace'::MicrosoftRecordLayoutBuilder::layoutField(const clang::FieldDecl *
FD) Line 2646 C++
clang-cpp.exe!`anonymous
namespace'::MicrosoftRecordLayoutBuilder::layoutFields(const clang::RecordDecl
* RD) Line 2636 C++
clang-cpp.exe!`anonymous
namespace'::MicrosoftRecordLayoutBuilder::cxxLayout(const clang::CXXRecordDecl
* RD) Line 2439 C++
clang-cpp.exe!clang::ASTContext::getASTRecordLayout(const
clang::RecordDecl * D) Line 2980 C++
clang-cpp.exe!`anonymous
namespace'::CGRecordLowering::CGRecordLowering(clang::CodeGen::CodeGenTypes &
Types, const clang::RecordDecl * D, bool Packed) Line 221C++
clang-cpp.exe!clang::CodeGen::CodeGenTypes::ComputeRecordLayout(const
clang::RecordDecl * D, llvm::StructType * Ty) Line 726C++
clang-cpp.exe!clang::CodeGen::CodeGenTypes::ConvertRecordDeclType(const
clang::RecordDecl * RD) Line 710C++
clang-cpp.exe!clang::CodeGen::CodeGenTypes::ConvertRecordDeclType(const
clang::RecordDecl * RD) Line 706C++
clang-cpp.exe!clang::CodeGen::CodeGenTypes::getCGRecordLayout(const
clang::RecordDecl * RD) Line 743C++
clang-cpp.exe!clang::CodeGen::CodeGenTypes::isZeroInitializable(const
clang::RecordDecl * RD) Line 784 C++
clang-cpp.exe!clang::CodeGen::CodeGenTypes::isZeroInitializable(clang::QualType
T) Line 772 C++
clang-cpp.exe!clang::CodeGen::CodeGenModule::EmitNullConstant(clang::QualType
T) Line 2103 C++
clang-cpp.exe!clang::CodeGen::ConstantEmitter::tryEmitPrivateForVarInit(const
clang::VarDecl & D) Line 1406 C++
clang-cpp.exe!clang::CodeGen::ConstantEmitter::tryEmitForInitializer(const
clang::VarDecl & D) Line 1191C++
clang-cpp.exe!clang::CodeGen::CodeGenModule::EmitGlobalVarDefinition(const
clang::VarDecl * D, bool IsTentative) Line 3156 C++
clang-cpp.exe!clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl
GD, llvm::GlobalValue * GV) Line 2304 C++
clang-cpp.exe!clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl GD)
Line 2077 C++
clang-cpp.exe!clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl * D)
Line 4393C++
clang-cpp.exe!`anonymous
namespace'::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef DG) Line
160 C++
clang-cpp.exe!clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef D)
Line 168C++
clang-cpp.exe!clang::ParseAST(clang::Sema & S, bool PrintStats, bool
SkipFunctionBodies) Line 156 C++
clang-cpp.exe!clang::ASTFrontendAction::ExecuteAction() Line 1005
C++
clang-cpp.exe!clang::CodeGenAction::ExecuteAction() Line 1044 C++
clang-cpp.exe!clang::FrontendAction::Execute() Line 904
[llvm-bugs] [Bug 37400] New: MSVC and Clang use different values for _MM_HINT constants; Windows SDK hardcodes MSVC values
https://bugs.llvm.org/show_bug.cgi?id=37400
Bug ID: 37400
Summary: MSVC and Clang use different values for _MM_HINT
constants; Windows SDK hardcodes MSVC values
Product: clang
Version: 6.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Headers
Assignee: unassignedclangb...@nondot.org
Reporter: fabi...@radgametools.com
CC: llvm-bugs@lists.llvm.org
With clang-cl 6.0:
// begin
#include
#include // <--- only with this present!
void f(const void *p)
{
_mm_prefetch((const char *)p, _MM_HINT_T0);
}
// end
"clang-cl -c -O2 -FA prefetch.cpp" yields (only relevant parts):
# begin
"?f@@YAXPEBX@Z":# @"\01?f@@YAXPEBX@Z"
# %bb.0:
prefetcht2 (%rcx)
retq
# end
...huh? Some grepping later, it turns out that "um\winnt.h" in the Windows SDK
10.0.16299.0 (and presumably other versions as well, but I didn't check)
contains this:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0>rg MM_HINT_T0
um\winnt.h
3266:#define _MM_HINT_T0 1
3296:#define PF_TEMPORAL_LEVEL_1 _MM_HINT_T0
7349:#define _MM_HINT_T0 1
7366:#define PF_TEMPORAL_LEVEL_1 _MM_HINT_T0
and indeed, the MSVC version of xmmintrin.h has _MM_HINT_T0 #defined to 1.
Long story short, for any translation unit that includes Windows.h,
_MM_HINT_* end up re-#defined to MSVC-specific values, which produce the wrong
instructions with clang-cl.
If the goal is to make clang-cl be able to compile apps using unmodified
Windows headers, then Clang needs to use the same values for _MM_HINT_* as MSVC
does. (Presumably with some remapping done in the frontend.) Sigh.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37401] New: wasm32: Runtime signature for __muloti4 may be wrong
https://bugs.llvm.org/show_bug.cgi?id=37401 Bug ID: 37401 Summary: wasm32: Runtime signature for __muloti4 may be wrong Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: a...@crichton.co CC: dan433...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 20279 --> https://bugs.llvm.org/attachment.cgi?id=20279&action=edit IR When Rust code uses LLD and turns on `--fatal-warnings` with LLD recent builds of LLD will fail with: lld: error: Function type mismatch: __muloti4 >>> defined as (I32, I64, I64, I64, I64) -> void in >>> core-e5bf43c84917cf15.core5-ceca1e00e36ddf6282e22e0bc4528df.rs.rcgu.o >>> defined as (I32, I64, I64, I64, I64, I32) -> void in >>> compiler_builtins-9dbaa47e4e7765c7.compiler_builtins4-c780f72fce4e9840f0ab093af18d8809.rs.rcgu.o Our __muloti4 implementation [1] is located in compiler_builtins (the second of those two object files) and the last extra argument is the flag as to whether the call overflowed. It looks like, though, that the wasm code generator isn't expecting that flag to be there, which seems odd? If the attached IR is compiled and disassembled with `wasm2wat` you can see that LLVM is emitting the first signature above (no flag at the end). The internal IR (I think?) looks to have a final trailing argument but it seems to be chopped off somewhere in the wasm backend. Is this signature different on wasm? Or is this a bug in the wasm codegen? [1]: https://github.com/rust-lang-nursery/compiler-builtins/blob/cb04a0718b2437a32436d4cc2eb66d012066c835/src/int/mul.rs#L105-L108 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37402] New: [inline asm, AVX] Issue with the SSE register allocation in inline assembly
https://bugs.llvm.org/show_bug.cgi?id=37402
Bug ID: 37402
Summary: [inline asm, AVX] Issue with the SSE register
allocation in inline assembly
Product: clang
Version: 6.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: raphael_b...@alumni.brown.edu
CC: llvm-bugs@lists.llvm.org
Created attachment 20280
--> https://bugs.llvm.org/attachment.cgi?id=20280&action=edit
Test code
It seems there is a bug when using inline assembly for x86.
Say, we want to implement the following pseudo-code where all
variables (except cond) are __m128
// va = *a;
// vb = *b;
// mask = (cond)?0x00:0xFF;
//
// vc = (va ^ vb) & mask;
// va = va ^ vc;
// vb = vb ^ vc;
//
// *a = va;
// *b = vb;
Branch free, memory access oblivious code is targeted: use of
inline assembly seems recommended for such cases.
In this bug report, we will focus on the three middle lines from
above. Let us consider two implementations, and the generated assembly,
with -mavx -O3.
// Implementation 1:
asm volatile("vpxor %0, %1, %2\n\t"
"vpand %2, %3, %2\n\t"
"vpxor %0, %2, %0\n\t"
"vpxor %1, %2, %1\n\t"
: "+x"(va), "+x"(vb), "+x"(vc) /* output */
: "x"(mask) /* input */
: /* clobbered register */
);
// Generated ASM 1
vpxor %xmm0, %xmm1, %xmm2
vpand %xmm2, %xmm2, %xmm2 <- Idempotent and useless instruction
vpxor %xmm0, %xmm2, %xmm0
vpxor %xmm1, %xmm2, %xmm1
// Implementation 2:
asm volatile("vpxor %0, %1, %2\n\t"
"vpand %2, %3, %2\n\t"
"vpxor %0, %2, %0\n\t"
"vpxor %1, %2, %1\n\t"
: "+x"(va), "+x"(vb), "=x"(vc), "+x"(mask) /* output */
: /* input */
: /* clobbered register */
);
// Generated ASM 2
vpxor %xmm0, %xmm1, %xmm3
vpand %xmm3, %xmm2, %xmm3
vpxor %xmm0, %xmm3, %xmm0
vpxor %xmm1, %xmm3, %xmm1
Clearly, Implementation 1 does not work, and produces an invalid assembly.
I had the same generated assembly with clang 3.7, 5.0, 6.0 and trunk.
gcc and icc generate identical asm (cf. https://godbolt.org/g/gvkRph and the
attachements),
equivalent to ASM 2.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
