[llvm-bugs] [Bug 40840] New: clang-format violates WebKit: braces empty block
https://bugs.llvm.org/show_bug.cgi?id=40840
Bug ID: 40840
Summary: clang-format violates WebKit: braces empty block
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: rodionmal...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Formatting using webkit style violates style guide
https://webkit.org/code-style-guidelines/#braces-empty-block
config:
Language: Cpp
BasedOnStyle: WebKit
1) Case with empty block
having
for (int i = 0; i < 0; ++i, doBar()) { }
after formatting I've got
for (int i = 0; i < 0; ++i, doBar()) {
}
2) Case with empty function body. Strictly speaking I wasn't able to find exact
requirement for this but I've got warning from linter (check-webkit-style)
having
void Foo() { }
after formating I've got
void Foo() {}
warning is
Missing space inside { }. [whitespace/braces] [5]
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33963] opt crashes with "opt -sroa -adce -lcssa -indvars": Assertion `L->isRecursivelyLCSSAForm(*DT, *LI) && "Requested to preserve LCSSA, but it's already broken."' failed
https://bugs.llvm.org/show_bug.cgi?id=33963 Zhide Zhou changed: What|Removed |Added Resolution|--- |FIXED CC||csz...@163.com Status|NEW |RESOLVED --- Comment #2 from Zhide Zhou --- This is fixed in latest trunk. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40841] New: opt crashes with "opt -inline -early-cse-memssa -jump-threading -early-cse-memssa -lcssa -loop-rotate": Assertion `L->isRecursivelyLCSSAForm(*DT, *LI) && "Requested to pre
https://bugs.llvm.org/show_bug.cgi?id=40841 Bug ID: 40841 Summary: opt crashes with "opt -inline -early-cse-memssa -jump-threading -early-cse-memssa -lcssa -loop-rotate": Assertion `L->isRecursivelyLCSSAForm(*DT, *LI) && "Requested to preserve LCSSA, but it's already broken."' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: csz...@163.com CC: llvm-bugs@lists.llvm.org Created attachment 21510 --> https://bugs.llvm.org/attachment.cgi?id=21510&action=edit .bc file of the source code $clang -v clang version 9.0.0 (trunk 354742) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/jack-zhou/Documents/llvm/llvm_truck/llvm/build2/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.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.5.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.3.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $clang -O3 -c -emit-llvm -mllvm -disable-llvm-optzns small.c -o small.bc -I"path to csmith's runtime" $ opt -inline -early-cse-memssa -jump-threading -early-cse-memssa -lcssa -loop-rotate small.bc -o small-opt.bc opt: /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Transforms/Utils/LoopSimplify.cpp:693: bool llvm::simplifyLoop(llvm::Loop*, llvm::DominatorTree*, llvm::LoopInfo*, llvm::ScalarEvolution*, llvm::AssumptionCache*, bool): Assertion `L->isRecursivelyLCSSAForm(*DT, *LI) && "Requested to preserve LCSSA, but it's already broken."' failed. Stack dump: 0. Program arguments: /home/jack-zhou/Documents/llvm/llvm_truck/llvm/build2/bin/opt -inline -early-cse-memssa -jump-threading -early-cse-memssa -lcssa -loop-rotate crash331-reduced0.bc 1. Running pass 'CallGraph Pass Manager' on module 'crash331-reduced0.bc'. 2. Running pass 'Canonicalize natural loops' on function '@k' #0 0x5561c4e62b7b llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Support/Unix/Signals.inc:494:0 #1 0x5561c4e62c0e PrintStackTraceSignalHandler(void*) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Support/Unix/Signals.inc:558:0 #2 0x5561c4e60b92 llvm::sys::RunSignalHandlers() /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Support/Signals.cpp:68:0 #3 0x5561c4e6259d SignalHandler(int) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Support/Unix/Signals.inc:357:0 #4 0x7f1e47c5d890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #5 0x7f1e4690fe97 gsignal /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #6 0x7f1e46911801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0 #7 0x7f1e4690139a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0 #8 0x7f1e46901412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412) #9 0x5561c4ef460b llvm::simplifyLoop(llvm::Loop*, llvm::DominatorTree*, llvm::LoopInfo*, llvm::ScalarEvolution*, llvm::AssumptionCache*, bool) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Transforms/Utils/LoopSimplify.cpp:692:0 #10 0x5561c4ef4b22 (anonymous namespace)::LoopSimplify::runOnFunction(llvm::Function&) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Transforms/Utils/LoopSimplify.cpp:779:0 #11 0x5561c45e31fc llvm::FPPassManager::runOnFunction(llvm::Function&) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/IR/LegacyPassManager.cpp:1643:0 #12 0x5561c3c82e33 (anonymous namespace)::CGPassManager::RunPassOnSCC(llvm::Pass*, llvm::CallGraphSCC&, llvm::CallGraph&, bool&, bool&) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Analysis/CallGraphSCCPass.cpp:177:0 #13 0x5561c3c83e4d (anonymous namespace)::CGPassManager::RunAllPassesOnSCC(llvm::CallGraphSCC&, llvm::CallGraph&, bool&) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Analysis/CallGraphSCCPass.cpp:441:0 #14 0x5561c3c8419a (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/Analysis/CallGraphSCCPass.cpp:497:0 #15 0x5561c45e3844 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /home/jack-zhou/Documents/llvm/llvm_truck/llvm/lib/IR/LegacyPassManager.cpp:1743:0 #16 0x00
[llvm-bugs] [Bug 39645] opt crashes with -loop-deletion pass
https://bugs.llvm.org/show_bug.cgi?id=39645 Zhide Zhou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Zhide Zhou --- This is fixed in the latest truck. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13243 in oss-fuzz: llvm/clang-fuzzer: Timeout in llvm_clang-fuzzer
Comment #2 on issue 13243 by ClusterFuzz-External: llvm/clang-fuzzer: Timeout in llvm_clang-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13243#c2 ClusterFuzz has detected this issue as fixed in range 201902230417:201902240409. Detailed report: https://oss-fuzz.com/testcase?key=5641829305810944 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: llvm_clang-fuzzer Sanitizer: address (ASAN) Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201902230417:201902240409 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5641829305810944 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31754] replacing variable by a constant breaks add-with-carry (adc) and subtract-with-borrow (sbb) optimization
https://bugs.llvm.org/show_bug.cgi?id=31754 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=40825 Fixed By Commit(s)|352210 |352210, 354746 Status|CONFIRMED |RESOLVED --- Comment #11 from Sanjay Patel --- (In reply to Simon Pilgrim from comment #10) > https://godbolt.org/z/vMyJNI > > Of Vincent's original sub/add cases only the add1 looks like its still > having problems. That's the last problem that I was tracking for this report too. Should be fixed after: https://reviews.llvm.org/rL354746 Feel free to reopen and/or file new bugs (like bug 40825) for missing pieces. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 13243 in oss-fuzz: llvm/clang-fuzzer: Timeout in llvm_clang-fuzzer
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 13243 by ClusterFuzz-External: llvm/clang-fuzzer: Timeout in llvm_clang-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13243#c3 ClusterFuzz testcase 5641829305810944 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40842] New: adding min signed value constant does not result in expected 'unsigned add with overflow' codegen
https://bugs.llvm.org/show_bug.cgi?id=40842
Bug ID: 40842
Summary: adding min signed value constant does not result in
expected 'unsigned add with overflow' codegen
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Forking this reduced example from bug 40486:
#include
using u64 = unsigned;
template
void test(u64& alo, u64& ahi)
{
u64 blo = K;
u64 bhi = 0;
bool cf = (alo += blo) < blo;
_addcarry_u32(cf, ahi, bhi, &ahi);
}
template void test<0x8000u>(u64&, u64&);
--
https://godbolt.org/z/lPSSir
Either we've prematurely formed bit magic from icmp or we need to recognize
this as another special-case form of uaddo:
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40486] CodeGenPrepare::CombineUAddWithOverflow - improve icmp eq/ne matching
https://bugs.llvm.org/show_bug.cgi?id=40486 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||354746 --- Comment #14 from Sanjay Patel --- We should have all of the common cases after: https://reviews.llvm.org/rL354746 I filed bug 40842 to track the +0x8000... case because I think the root cause is different on that one. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31754] replacing variable by a constant breaks add-with-carry (adc) and subtract-with-borrow (sbb) optimization
https://bugs.llvm.org/show_bug.cgi?id=31754 Bug 31754 depends on bug 40486, which changed state. Bug 40486 Summary: CodeGenPrepare::CombineUAddWithOverflow - improve icmp eq/ne matching https://bugs.llvm.org/show_bug.cgi?id=40486 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40843] New: Vector ABI does not respect target attribute
https://bugs.llvm.org/show_bug.cgi?id=40843
Bug ID: 40843
Summary: Vector ABI does not respect target attribute
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: yyc1...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
When compiling code with target attribute that may affect the ABI, clang appear
to not handling it correct.
First the observations. Considering the code below compiled on x64.
```
typedef double vdouble __attribute__((vector_size(32)));
__attribute__((target("avx")))
vdouble f(vdouble x, vdouble y)
{
return x + y;
}
```
Without the target attribute, GCC produces
```
f:
movapd 8(%rsp), %xmm1
movapd 24(%rsp), %xmm2
movq%rdi, %rax
addpd 40(%rsp), %xmm1
addpd 56(%rsp), %xmm2
movaps %xmm1, (%rax)
movaps %xmm2, 16(%rax)
ret
```
which AFAICT, is treating the vector as a struct which is passed in on the
stack and passed out by sret. It also issues a warning by default suggesting
that without AVX enabled the ABI is different. (It also gives another warning
about 32bit aligned argument ABI change in gcc 4.6 but that's not relavant to
this issue).
OTOH, without the attribute, clang produces.
```
f: # @f
# %bb.0:
pushq %rbp
movq%rsp, %rbp
andq$-32, %rsp
subq$32, %rsp
movapd 16(%rbp), %xmm0
movapd 32(%rbp), %xmm1
addpd 48(%rbp), %xmm0
addpd 64(%rbp), %xmm1
movq%rbp, %rsp
popq%rbp
retq
```
which uses the same argument passing as GCC but passes the value back in `xmm0`
and `xmm1`. I couldn't find any other use of this ABI in other context and
since the LLVM ir returns `<4 x double>` I assume clang just give up fixing it.
As a side note, the generated code is doing a lot of useless work on the stack
pointer. It aligns the stack but actually never uses it. (We'll see this
below as well)
Now with the attribute, GCC behaves just as if `-mavx` is passed on the command
line, which is what I expected,
```
f:
vaddpd %ymm1, %ymm0, %ymm0
ret
```
Clang, OTOH does,
```
f: # @f
# %bb.0:
pushq %rbp
movq%rsp, %rbp
andq$-32, %rsp
subq$32, %rsp
vmovapd 16(%rbp), %ymm0
vaddpd 48(%rbp), %ymm0, %ymm0
movq%rbp, %rsp
popq%rbp
retq
```
which still passes the parameter in on the stack but passing the return value
in `ymm0`. The uselsess manipulation of the stack pointer is still there as
well...
If `-mavx` is passed on the command line, both clang and gcc generates the same
code. `vaddpd %ymm1, %ymm0, %ymm0`
Based on the observations above, I believe at the least the stack pointer
manipulation should be fixed and the clang behavior when the attribute is there
should be fixed to match GCC as well (or at least be made consistent though I
don't see why not matching GCC).
I could see an argument about the target attribute not altering the ABI but
that's not what clang is doing either (the ABI with and without that attribute
**is** different in clang). From the generated code, clang is clearly assuming
that the caller knows about ymm0 (that's where it puts the return value) so I
think it should at least be consistent about that for the input arguments too.
If there's a really good argument for separating the feature available in the
function and the feature used for the ABI, there should at least be an
attribute to make the clang behavior match that of gcc in additional to fixing
the return value passing in this case. IMHO though, that should be handled by
the user... (by passing the argument by reference for example).
I saw this on clang 5.0 and 7.0.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40844] New: Unneeded stack alignment on x86
https://bugs.llvm.org/show_bug.cgi?id=40844
Bug ID: 40844
Summary: Unneeded stack alignment on x86
Product: libraries
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: yyc1...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Ref https://bugs.llvm.org/show_bug.cgi?id=40843. The useless stack operations
are likely caused by a different issue...
Reproducible with C code,
```
typedef double _vdouble __attribute__((vector_size(32)));
typedef struct {
_vdouble x;
int y;
} vdouble;
vdouble f(vdouble x, vdouble y)
{
vdouble res = {x.x + y.x, x.y + y.y};
return res;
}
```
Compiling with clang with `-mavx` emits very similar code to GCC
```
f: # @f
# %bb.0:
pushq %rbp
movq%rsp, %rbp
andq$-32, %rsp
subq$32, %rsp
vmovapd 16(%rbp), %ymm0
vaddpd 80(%rbp), %ymm0, %ymm0
vmovapd %ymm0, (%rdi)
movl112(%rbp), %eax
addl48(%rbp), %eax
movl%eax, 32(%rdi)
movq%rdi, %rax
movq%rbp, %rsp
popq%rbp
vzeroupper
retq
```
except that it emits 6 additional instructions for stack realignment without
actually using the stack pointer anywhere else in the function.
Seems to be a x86 backend issue since I can reproduce even without enabling avx
(so nothing in the backend should require 32bit alignment, only the frontend
should) and I can't reproduce on arm or aarch64.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40845] New: Missed optimization with redundant overflow checks
https://bugs.llvm.org/show_bug.cgi?id=40845
Bug ID: 40845
Summary: Missed optimization with redundant overflow checks
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: alex.gay...@gmail.com
CC: llvm-bugs@lists.llvm.org
Godbolt link: https://godbolt.org/z/h2lkGE
The subtraction can be known not to overflow because it's derived from an
overflow checked addition. This was reduced/converted to C from this rust bug:
https://github.com/rust-lang/rust/issues/58692
One commenter suggested they thought the issue was in how GVN handled overflow
checked operations.
Code:
#include
extern void panic1();
extern void panic2();
extern void panic3();
size_t f(size_t a, size_t b) {
size_t x;
if (!__builtin_add_overflow(a, b, &x)) {
panic1();
__builtin_unreachable();
}
size_t r;
if (!__builtin_sub_overflow(x, a, &r)) {
panic2();
__builtin_unreachable();
}
if (r < 0) {
panic3();
__builtin_unreachable();
}
return x;
}
Assembly:
f(unsigned long, unsigned long): # @f(unsigned
long, unsigned long)
pushrax
mov rax, rsi
add rax, rdi
jae .LBB0_3
cmp rax, rdi
jae .LBB0_4
pop rcx
ret
.LBB0_3:
callpanic1()
.LBB0_4:
callpanic2()
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40846] New: Missing redundancy elimination for uadd.with.overflow and manual overflow check
https://bugs.llvm.org/show_bug.cgi?id=40846
Bug ID: 40846
Summary: Missing redundancy elimination for uadd.with.overflow
and manual overflow check
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: nikita@gmail.com
CC: llvm-bugs@lists.llvm.org
Originally reported at: https://github.com/rust-lang/rust/issues/58692
The following IR remains unchanged under opt -O3:
define i1 @test(i64 %x, i64 %y) nounwind {
%a = call { i64, i1 } @llvm.uadd.with.overflow.i64(i64 %x, i64 %y)
%b = extractvalue { i64, i1 } %a, 1
br i1 %b, label %trap, label %bb
bb:
%c = extractvalue { i64, i1 } %a, 0
%d = icmp ult i64 %c, %x
ret i1 %d
trap:
call void @llvm.trap()
unreachable
}
declare { i64, i1 } @llvm.uadd.with.overflow.i64(i64, i64)
declare void @llvm.trap()
Here %d is the same as %b, and must be false in %bb by implication.
I think this should be fairly easy to fix (at least for this specific case)
with an instcombine pattern that converts the icmp into an extract, and CSE/GVN
will take care of the rest.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40847] New: Merge r354733 into the 8.0 branch : [WebAssembly] Fix select of and (PR40805)
https://bugs.llvm.org/show_bug.cgi?id=40847 Bug ID: 40847 Summary: Merge r354733 into the 8.0 branch : [WebAssembly] Fix select of and (PR40805) Product: libraries Version: trunk Hardware: Other OS: other Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: dan433...@gmail.com CC: llvm-bugs@lists.llvm.org, tliv...@google.com Blocks: 40331 Hello, r354733 is a simple bug fix that fixes a miscompile on WebAssembly, so we'd like to merge it into 8.0: https://reviews.llvm.org/rL354733 https://reviews.llvm.org/D58575 It fixes PR40805 and possibly also Emscripten issue #8173: https://bugs.llvm.org/show_bug.cgi?id=40805 https://github.com/emscripten-core/emscripten/issues/8173 Thanks! Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=40331 [Bug 40331] [meta] 8.0.0 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40832] Merge r354733 into 8.0
https://bugs.llvm.org/show_bug.cgi?id=40832 Nikita Popov changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Nikita Popov --- Looks like we have two of these now, closing as dup of PR40847. *** This bug has been marked as a duplicate of bug 40847 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40331] [meta] 8.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=40331 Bug 40331 depends on bug 40832, which changed state. Bug 40832 Summary: Merge r354733 into 8.0 https://bugs.llvm.org/show_bug.cgi?id=40832 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26906] -mcmodel=large, Cannot select: t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64
https://bugs.llvm.org/show_bug.cgi?id=26906 Craig Topper changed: What|Removed |Added Fixed By Commit(s)||r354756 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Craig Topper --- Fixed in r354756 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39637] [X86] Failure to combine vpmovzxbw with a v16i16->v16i8 truncate implemented with extract+packuswb
https://bugs.llvm.org/show_bug.cgi?id=39637 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r354757 Status|NEW |RESOLVED --- Comment #2 from Simon Pilgrim --- Fixed in rL354757 zext(packus(x),packus(y)) -> concat(x,y) I'm intending to generalize the solution in the future to combine zext with any shuffle, but until combineX86ShufflesRecursively can handle vector ops of different sizes this basic pattern is the most stable. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40848] New: Wrong debug info generated at -O1/-O2/-O3 (-O0 is correct)
https://bugs.llvm.org/show_bug.cgi?id=40848
Bug ID: 40848
Summary: Wrong debug info generated at -O1/-O2/-O3 (-O0 is
correct)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Keywords: wrong-debug
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: florian_h...@apple.com, jeremy.morse.l...@gmail.com,
llvm-bugs@lists.llvm.org, v...@apple.com
$ cat outer.c
void optimize_me_not() {}
$ cat 5.c
int main() {
int p_9 = -1662757339;
optimize_me_not();
}
(lldb) br set -p optimize_me_not
Breakpoint 1: where = a.out`main + 1 at 5.c:4:3, address = 0x00400481
-O1
(lldb) frame var p_9
(int) p_9 = -3
### -O0
(lldb) frame var p_9
(int) p_9 = -1662757339
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40826] Lost debug location during optimization
https://bugs.llvm.org/show_bug.cgi?id=40826 David Blaikie changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from David Blaikie --- OK - 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40849] New: Diagnostics for non-SFINAE errors triggered by deduction guides should include a line number
https://bugs.llvm.org/show_bug.cgi?id=40849
Bug ID: 40849
Summary: Diagnostics for non-SFINAE errors triggered by
deduction guides should include a line number
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
This is an example of the diagnostics that Clang produces when it encounters a
slightly buggy deduction guide. The error is quite verbose, but it critically
omits to mention WHICH "function template ''" it was considering when the error hit. (There are at least 8
possibilities in my code. Maybe more: I don't know if Clang might be counting
the implicitly generated candidates as "deduction guides".)
I would love it if Clang reported the source line number of the offending
''. I wouldn't even ask for the line to be
printed out; just having the number would be really helpful for tracking down
this bug of mine.
```
In file included from llvm/projects/libcxx/include/unordered_set:362:
In file included from llvm/projects/libcxx/include/__hash_table:15:
llvm/projects/libcxx/include/memory:1522:38: error: no type named 'value_type'
in 'std::__1::hash'
typedef typename allocator_type::value_type value_type;
~^~
llvm/projects/libcxx/include/__hash_table:893:51: note: in instantiation of
template class 'std::__1::allocator_traits >' requested
here
__make_hash_node_types::type
^
llvm/projects/libcxx/include/__hash_table:1410:12: note: in instantiation of
template class 'std::__1::__hash_table,
std::__1::equal_to, std::__1::hash >' requested here
bool = __hash_table<_Tp, _Hash, _Equal,
_Alloc>::__allow_trivial_relocation::value>
^
llvm/projects/libcxx/include/unordered_set:400:13: note: in instantiation of
default argument for '__hash_table_relocate_base,
std::__1::equal_to, std::__1::hash >' required here
typedef __hash_table_relocate_base __table;
^
llvm/projects/libcxx/test/std/containers/unord/unord.set/unord.set.cnstr/deduct.pass.cpp:143:24:
note: while substituting deduced template arguments into function template
'' [with _Value = int, _Hash = (no value),
_Pred = (no value), _Alloc = std::__1::hash]
std::unordered_set s({ 1, 2, 1, INT_MAX, 3 }, 42, std::hash());
^
```
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40850] New: Add clang-format C# language support
https://bugs.llvm.org/show_bug.cgi?id=40850 Bug ID: 40850 Summary: Add clang-format C# language support Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: mydeveloper...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org This enhancement is to add support for clang-format to be able to parse C# source code files and format using existing clang-format rules clang-format currently butchers C# often breaking it from compiling, as a primarily C syntax language similar to java in constructs it should be possible for clang-format to be setup to format C# in much the same way as it handles Java This would allow code bases with a mixture of C# and C++ code to use a common style file between the two and automated format on save in visual studio can be used to keep code conforming. Formatting by default should fallback to some sort of Microsoft .NET Core equivalent style to minimize the amount of flux on newly formatted code or the need for users to discover the Microsoft style. Some additional consideration will be required to handle, verbatim and interpolated strings which are outside of currently supported string literal styles handled by the lexer In the future additional formatting styles for constructs like set;get could be added. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
