[llvm-bugs] [Bug 42420] error in backend: Functions with 'no-prototype' attribute should not have params
https://bugs.llvm.org/show_bug.cgi?id=42420 Heejin Ahn changed: What|Removed |Added CC||ahee...@gmail.com Status|NEW |RESOLVED Fixed By Commit(s)||r365426 Resolution|--- |FIXED --- Comment #4 from Heejin Ahn --- Fixed in r365426 (https://reviews.llvm.org/rG947bfe73fc2f50300fafdf9ef7a025e7d17da30e). -- 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 16548] False warning: address of stack memory associated with local
https://bugs.llvm.org/show_bug.cgi?id=16548 Óscar Fuentes changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Óscar Fuentes --- Since long time ago my code had a work around for this issue. Tested today with 8.0.1rc and it is no longer necessary, nor the test case on this PR reproduces the problem. -- 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 42550] New: Byte+shift loads are not autovectorized to movdqu on SSE4.1
https://bugs.llvm.org/show_bug.cgi?id=42550
Bug ID: 42550
Summary: Byte+shift loads are not autovectorized to movdqu on
SSE4.1
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: husseyde...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Take the following code:
#ifdef BYTE_SHIFT
static uint32_t read32(uint8_t const *data, size_t offset)
{
return (uint32_t) data[offset + 0]
| ((uint32_t) data[offset + 1] << 8)
| ((uint32_t) data[offset + 2] << 16)
| ((uint32_t) data[offset + 3] << 24);
}
#else
static uint32_t read32(uint8_t const *data, size_t offset)
{
uint32_t ret;
memcpy(&ret, data + offset, sizeof(float));
return ret;
}
#endif
Both ways are perfectly valid ways to perform an unaligned load, and when SSE
is disabled, they generate the same code when used.
However, when SSE4 is enabled and loops using these loads are autovectorized,
instead of a movdqu which is what memcpy outputs, the byte shift is expanded
literally into a bunch of pslld, pinsrb, and pmovzxbd instructions.
Demo: https://godbolt.org/z/jCAm2o
These types of loads should be converted to movdqu as well.
--
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 42549] New: std::string has incomplete type in gdb
https://bugs.llvm.org/show_bug.cgi?id=42549
Bug ID: 42549
Summary: std::string has incomplete type in gdb
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: leonardc...@google.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Printing a string in gdb gives us an incomplete type.
```
leonardchan@cp-snakewater:~/misc$ cat ~/misc/test.cpp
#include
#include
int main() {
std::string s = "a";
std::cerr << s << "\n";
}
leonardchan@cp-snakewater:~/misc$ bin/clang++ ~/misc/test.cpp -g -stdlib=libc++
leonardchan@cp-snakewater:~/misc$ gdb a.out
(gdb) list
1 #include
2 #include
3
4 int main() {
5 std::string s = "a";
6 std::cerr << s << "\n";
7 }
(gdb) break 6
Breakpoint 1 at 0x2270ed: file test.cpp, line 6.
(gdb) r
Starting program: /usr/local/google/home/leonardchan/misc/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main () at test.cpp:6
6 std::cerr << s << "\n";
(gdb) print s
$1 =
```
This was from an executable compiled with tip of tree clang. With g++ however,
we are able to get the string value.
```
leonardchan@cp-snakewater:~/misc$ g++ ~/misc/test.cpp -g
leonardchan@cp-snakewater:~/misc$ gdb a.out
(gdb) break 6
Breakpoint 1 at 0xb92: file /usr/local/google/home/leonardchan/misc/test.cpp,
line 6.
(gdb) r
Starting program: /usr/local/google/home/leonardchan/misc/a.out
Breakpoint 1, main () at /usr/local/google/home/leonardchan/misc/test.cpp:6
6 std::cerr << s << "\n";
(gdb) print s
$1 = "a"
```
Other stl classes like std::map and std::vector still seem to get printed
normally.
--
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 42548] New: llgo doesn't compile in current llvm master
https://bugs.llvm.org/show_bug.cgi?id=42548 Bug ID: 42548 Summary: llgo doesn't compile in current llvm master Product: llgo Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: b...@lindev.ch CC: llvm-bugs@lists.llvm.org Trying to enable llgo on a current (2019/07/09) llvm-project git checkout results in: llgo: /home/bero/temp/abf/llvm/BUILD/llvm-9.0.0-20190708/llvm/lib/IR/Attributes.cpp:233: llvm::Type *llvm::Attribute::getValueAsType() const: Assertion `isTypeAttribute() && "Invalid attribute type to get the value as a type!"' failed. SIGABRT: abort PC=0x7f8debf2e4c7 m=0 sigcode=18446744073709551610 goroutine 0 [idle]: runtime: unknown pc 0x7f8debf2e4c7 [...] goroutine 1 [syscall]: runtime.cgocall(0x8d0440, 0xc0001632c8, 0xc0001632d0) /usr/lib/golang/src/runtime/cgocall.go:128 +0x5b fp=0xc000163298 sp=0xc000163260 pc=0x5d926b llvm.org/llvm/bindings/go/llvm._Cfunc_LLVMAddAttributeAtIndex(0x15cc908, 0x3, 0x15eb340) _cgo_gotypes.go:687 +0x45 fp=0xc0001632c8 sp=0xc000163298 pc=0x808e35 llvm.org/llvm/bindings/go/llvm.Value.AddAttributeAtIndex.func1(0x15cc908, 0x3, 0x15eb340) /tmp/gopath529316603/src/llvm.org/llvm/bindings/go/llvm/ir.go:1154 +0x98 fp=0xc000163300 sp=0xc0001632c8 pc=0x838698 llvm.org/llvm/bindings/go/llvm.Value.AddAttributeAtIndex(0x15cc908, 0x3, 0x15eb340) /tmp/gopath529316603/src/llvm.org/llvm/bindings/go/llvm/ir.go:1154 +0x3f fp=0xc000163328 sp=0xc000163300 pc=0x82458f llvm.org/llgo/irgen.(*functionTypeInfo).declare(0xcb9860, 0x15ecb20, 0x2cfd9f, 0xb, 0xc0001639e8) /tmp/gopath529316603/src/llvm.org/llgo/irgen/cabi.go:526 +0xf0 fp=0xc000163388 sp=0xc000163328 pc=0x888b60 llvm.org/llgo/irgen.(*runtimeFnInfo).init(0xcdd6a8, 0xc000130f80, 0x15ecb20, 0x2cfd9f, 0xb, 0xc000163ed8, 0x4, 0x4, 0xc0001639e8, 0x1, ...) /tmp/gopath529316603/src/llvm.org/llgo/irgen/runtime.go:31 +0x161 fp=0xc000163480 sp=0xc000163388 pc=0x894671 llvm.org/llgo/irgen.newRuntimeInterface(0x15ecb20, 0xc000130f80, 0x25, 0x1, 0x1) /tmp/gopath529316603/src/llvm.org/llgo/irgen/runtime.go:507 +0x34bb fp=0xc0001657d8 sp=0xc000163480 pc=0x897e2b llvm.org/llgo/irgen.(*compiler).compile(0xc0001080f0, 0xcbab40, 0xc9e4e0, 0x2, 0x2, 0x7ffc1650c35e, 0xb, 0x0, 0x0, 0x0) /tmp/gopath529316603/src/llvm.org/llgo/irgen/compiler.go:233 +0x4de fp=0xc0001658d8 sp=0xc0001657d8 pc=0x88d49e llvm.org/llgo/irgen.(*Compiler).Compile(0xc00010a2c0, 0xcbab40, 0xc9e4e0, 0x2, 0x2, 0x7ffc1650c35e, 0xb, 0x0, 0x0, 0x0) /tmp/gopath529316603/src/llvm.org/llgo/irgen/compiler.go:131 +0x14c fp=0xc000165950 sp=0xc0001658d8 pc=0x88cb2c main.performAction(0xc000165e38, 0x1, 0xcae280, 0x2, 0x2, 0xcb2128, 0x5, 0x0, 0x0) /tmp/gopath529316603/src/llvm.org/llgo/cmd/gllgo/gllgo.go:604 +0x160c fp=0xc000165bd0 sp=0xc000165950 pc=0x8cd6fc main.performActions(0xc000165e38, 0x0, 0x0) /tmp/gopath529316603/src/llvm.org/llgo/cmd/gllgo/gllgo.go:811 +0x357 fp=0xc000165cc0 sp=0xc000165bd0 pc=0x8ce487 main.main() /tmp/gopath529316603/src/llvm.org/llgo/cmd/gllgo/gllgo.go:835 +0xe0 fp=0xc000165f98 sp=0xc000165cc0 pc=0x8ce910 runtime.main() /usr/lib/golang/src/runtime/proc.go:200 +0x20c fp=0xc000165fe0 sp=0xc000165f98 pc=0x6033bc runtime.goexit() /usr/lib/golang/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc000165fe8 sp=0xc000165fe0 pc=0x62d691 rax0x0 rbx0x7f8dec2ea000 rcx0x7f8debf2e4c7 rdx0x0 rdi0x2 rsi0x7ffc1650abd0 rbp0x7f8dec096290 rsp0x7ffc1650abd0 r8 0x0 r9 0x7ffc1650abd0 r100x8 r110x246 r120x7f8dec925679 r130xe9 r140x7f8deca0e8b6 r150x200 rip0x7f8debf2e4c7 rflags 0x246 cs 0x33 fs 0x0 gs 0x0 -- 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 42546] wasm/OutputSections.cpp is causing warning on GCC
https://bugs.llvm.org/show_bug.cgi?id=42546 Denis Bakhvalov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Denis Bakhvalov --- Fixed by https://reviews.llvm.org/rL365397 -- 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 42547] asm goto should not emit debug info at -g0
https://bugs.llvm.org/show_bug.cgi?id=42547 Paul Robinson changed: What|Removed |Added Status|NEW |RESOLVED CC||paul_robinson@playstation.s ||ony.com Resolution|--- |INVALID --- Comment #4 from Paul Robinson --- (In reply to Nick Desaulniers from comment #3) > So close-wontfix? WAI? There's nothing to fix so WONTFIX is inappropriate. We don't have a SPEC resolution, INVALID is the closest we have to WAI. -- 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 42547] New: asm goto should not emit debug info at -g0
https://bugs.llvm.org/show_bug.cgi?id=42547
Bug ID: 42547
Summary: asm goto should not emit debug info at -g0
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: ndesaulni...@google.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk,
srhi...@google.com
small bug, but:
void foo(void) {
for (int j = 0; j < 3; ++j) {
// looks like bar gets "unrolled" while baz does not
asm goto(".quad %l0\n\t.quad %l1" :: "i"(&&baz) :: bar);
bar:;
baz:;
}
}
generates:
callbr void asm sideeffect ".quad ${0:l}\0A\09.quad ${1:l}",
"i,X,~{dirflag},~{fpsr},~{flags}"(i8* blockaddress(@foo, %8), i8*
blockaddress(@foo, %7)) #1
to label %6 [label %7], !srcloc !2
I don't think the #1, or !srcloc !2 should be emitted at -g0. I suspect
there's a missing check for this a flag set by g0?
--
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 42546] New: wasm/OutputSections.cpp is causing warning on GCC
https://bugs.llvm.org/show_bug.cgi?id=42546 Bug ID: 42546 Summary: wasm/OutputSections.cpp is causing warning on GCC Product: lld Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P Component: wasm Assignee: unassignedb...@nondot.org Reporter: denis.bakhva...@intel.com CC: llvm-bugs@lists.llvm.org, s...@chromium.org After commit e7eb8f099298b4c79397a1a287910628c82cc319 Author: Thomas Lively Date: Wed Jul 3 22:04:54 2019 + [WebAssembly] Add option to emit passive segments We have new warning reported by GCC (I tested at least gcc 5.5.0): lld/wasm/OutputSections.cpp: In member function ‘virtual void lld::wasm::DataSection::finalizeContents()’: lld/wasm/OutputSections.cpp:136:31: error: suggest parentheses around ‘&&’ within ‘||’ [-Werror=parentheses] Segments.size() <= 1 && ^ The fix should be trivial. -- 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 42545] New: [X86_64] Excess movs in XXH64 loop
https://bugs.llvm.org/show_bug.cgi?id=42545
Bug ID: 42545
Summary: [X86_64] Excess movs in XXH64 loop
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: husseyde...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Clang seems to generate extra mov instructions in the XXH64 loop, significantly
hampering performance.
#include
#include
static const uint64_t PRIME64_1 = 11400714785074694791ULL;
uint64_t XXH64_mini(const uint64_t* input, size_t len)
{
const uint64_t *limit = input + len;
uint64_t v1 = 0;
do {
v1 += *input++ * PRIME64_1;
v1 = (v1 << 31) | (v1 >> (64 - 31)); // rotate
v1 *= PRIME64_1;
} while (input<=limit);
return v1;
}
This is a simplified version of XXH64's loop.
With -O3, I would expect something like this:
uint64_t val;
val = *input;
val *= PRIME64_1;
acc += acc;
acc = (acc << 31) | (acc >> (64-31));
acc *= PRIME64_1;
XXH64_mini:
movabs rcx, -7046029288634856825
lea rdx, [rdi + 8*rsi]
xor eax, eax
.LBB0_1:
mov rsi, qword ptr [rdi]
imulrsi, rcx
add rdi, 8
add rax, rsi
rol rax, 31
imulrax, rcx
cmp rdi, rdx
jbe .LBB0_1
ret
However, Clang swaps the add instruction's operands, resulting in an extra mov:
uint64_t val;
val = *input;
val *= PRIME64_1;
val += acc;
val = (val << 31) | (val >> (64-31));
acc = val;
acc *= PRIME64_1;
XXH64_mini:
movabs rcx, -7046029288634856825
lea rdx, [rdi + 8*rsi]
xor eax, eax
.LBB0_1:
mov rsi, qword ptr [rdi]
imulrsi, rcx
add rdi, 8
add rsi, rax # <<<
rol rsi, 31# <<<
mov rax, rsi # <<<
imulrax, rcx
cmp rdi, rdx
jbe .LBB0_1
ret
GCC and MSVC both seem to emit the proper code, as seen here:
https://godbolt.org/z/wu7jDY
It appears that all versions of LLVM do this.
I can't seem to figure out how to further simplify this.
--
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 41871] --source does not work with archive members
https://bugs.llvm.org/show_bug.cgi?id=41871 Yuanfang Chen changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Yuanfang Chen --- llvm-svn: 365376 -- 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 42544] New: Assertion `BB->getTerminator()->getNumSuccessors() == 1 && "Should have a single succ!"' failed
https://bugs.llvm.org/show_bug.cgi?id=42544
Bug ID: 42544
Summary: Assertion `BB->getTerminator()->getNumSuccessors() ==
1 && "Should have a single succ!"' failed
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: pe...@pcc.me.uk
CC: llvm-bugs@lists.llvm.org
With the following test case (reduced from an LTO build of the Linux kernel) I
get:
$ cat fair.i
enum {
a,
b
}
# 1 "" 3
c() {
asm goto("" : : : : d);
asm("");
return a;
d:
return b;
}
ag;
e(f) {
ag &&f;
_Bool am = c();
e(am);
}
$ clang -flto -O2 -c -o fair.o fair.i -fno-optimize-sibling-calls
$ ld.lld -r -o vmlinux.o fair.o
ld.lld: [...]/llvm/lib/Transforms/Utils/BasicBlockUtils.cpp:348:
llvm::BasicBlock *llvm::SplitEdge(llvm::BasicBlock *, llvm::BasicBlock *,
llvm::DominatorTree *, llvm::LoopInfo *, llvm::MemorySSAUpdater *): Assertion
`BB->getTerminator()->getNumSuccessors() == 1 && "Should have a single succ!"'
failed.
--
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 42543] New: Better reporting of what compiler versions each buildbot is using
https://bugs.llvm.org/show_bug.cgi?id=42543 Bug ID: 42543 Summary: Better reporting of what compiler versions each buildbot is using Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: gkistan...@gmail.com, htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com, r...@google.com As suggested on https://reviews.llvm.org/D64326, we should be doing more to list what compiler versions we are running on as many buildbots as possible. This is to help people triage any issue that could be related to specific compilers or help us identify gaps in out compiler coverage vs the versions we publish as supported. -- 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 42542] New: ThinLTO on Aarch64 fails to handle aliases to overridden weak functions
https://bugs.llvm.org/show_bug.cgi?id=42542
Bug ID: 42542
Summary: ThinLTO on Aarch64 fails to handle aliases to
overridden weak functions
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: samitolva...@google.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
C code that defines an alias to a weak function, which is then referred to in
assembly code that also overrides the same weak function, fails to compile with
-flto=thin on Aarch64:
$ cat alias.c
__attribute__((__weak__)) int __a(int n)
{
return n;
}
int a(int n) __attribute__((__alias__("__a")));
int main()
{
return __a(0);
}
$ cat alias.s
.arch armv8-a
__a:
b a
.globl __a
$ clang -flto=thin -fvisibility=hidden -fuse-ld=lld --target=aarch64-linux-gnu-
alias.s alias.c
Alias must point to a definition
i32 (i32)* @a
LLVM ERROR: Broken module found, compilation aborted!
clang-9: error: linker command failed with exit code 1 (use -v to see
invocation)
Using -flto instead of -flto=thin works.
This bug prevents us from compiling the Linux kernel with ThinLTO, as explained
here:
https://github.com/ClangBuiltLinux/linux/issues/509
--
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 42397] SCEVExpander wrongly adds nsw to shl instruction
https://bugs.llvm.org/show_bug.cgi?id=42397 Denis Bakhvalov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Denis Bakhvalov --- Fixed by rL365363. -- 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 42528] Linker errors after installing/compiling LLVM/CLANG on Xcode
https://bugs.llvm.org/show_bug.cgi?id=42528 Joan Lluch changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Joan Lluch --- D64300 Fixed this -- 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 42541] New: PowerPC integrated as - missing instructions mulldo, addo and subfo
https://bugs.llvm.org/show_bug.cgi?id=42541 Bug ID: 42541 Summary: PowerPC integrated as - missing instructions mulldo, addo and subfo Product: libraries Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: alfredo.jun...@eldorado.org.br CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com I'm trying to build ports/lang/ghc with LLVM 8.0.1 and found that clang doesn't understand mulldo, addo and subfo. These instructions are generated by GHC (https://github.com/ghc/ghc/blob/ghc-8.6/compiler/nativeGen/PPC/Ppr.hs#L693) and currently GCC/AS implements them. -- 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 42540] New: "version" include wreaks havoc on case-insensitive filesystems
https://bugs.llvm.org/show_bug.cgi?id=42540 Bug ID: 42540 Summary: "version" include wreaks havoc on case-insensitive filesystems Product: libc++ Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: quen...@mit.edu CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com - libc++ >= 7.0 has an include file called `version` (as part of C++20) - Many open source packages contain a file called `VERSION` (this is a standard file in autoconf-based distributions) - On a case-insensitive filesystem, #include finds `VERSION` and hilarity ensues. I'm really not sure what the best fix would be. Asking thousands of open-source projects to rename their `VERSION` files seems like a huge challenge. Asking clang to be case-sensitive even when the underlying filesystem is not seems like a non-starter. libc++ could at least not having any includes of within the standard library itself, but that just postpones the pain until it starts being included in other libraries. Is it too late to raise this as a standards issue? -- 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 42539] New: ARM:out of range pc-relative fixup value
https://bugs.llvm.org/show_bug.cgi?id=42539
Bug ID: 42539
Summary: ARM:out of range pc-relative fixup value
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: a...@linaro.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
A file in the linux kernel got compiled into an invalid assembler output. I
reduced this to:
$ clang-9 -std=gnu89 --target=arm-linux-gnueabi -fsanitize=kernel-address -O2
-Wall -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-command-line-argument -Wno-ignored-optimization-argument
/tmp/z-4fd29d.s:33: Error: bad immediate value for offset (4104)
typedef struct { long x[4 * 8 / 2]; } map_word;
struct {
void (*write)();
} g;
struct flchip {
long start;
int state;
} __attribute__((__packed__));
int a, b, c;
int fn2(void);
struct flchip d, h;
map_word e, f;
void fn1() {
g.write(e, h.start);
g.write(g, f, h.start);
while (({
for (; b;)
;
c;
}))
a = fn2();
asm(".rep 6; nop; .endr");
while (d.state)
;
}
See also https://godbolt.org/z/DSM2Jy
It seems that clang when clang tries to guess the size of the instructions in
an inline assembly, it gets the '.rep' statement wrong and assumes a smaller
number. Replacing ".rep 6; nop; .endr" with six straight nop instructions
avoids the problem.
--
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 15704 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_predication: ASSERT: isGuardAsWidenableBranch(BI) && "Stopped being a guard after transform?"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 15704 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_predication: ASSERT: isGuardAsWidenableBranch(BI) && "Stopped being a guard after transform?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15704#c1 ClusterFuzz testcase 5672737185464320 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201907070312:201907080311 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] Issue 15517 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 15517 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15517#c1 ClusterFuzz testcase 5636089345212416 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201907070312:201907080311 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] Issue 15711 in oss-fuzz: llvm/clang-fuzzer: Null-dereference READ in clang::LinkageComputer::getLVForDecl
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-07-08 Type: Bug New issue 15711 by ClusterFuzz-External: llvm/clang-fuzzer: Null-dereference READ in clang::LinkageComputer::getLVForDecl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15711 Detailed report: https://oss-fuzz.com/testcase?key=5671959158849536 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: clang::LinkageComputer::getLVForDecl clang::NamedDecl::getLinkageInternal clang::Sema::CheckCompleteVariableDeclaration Sanitizer: memory (MSAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5671959158849536 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. -- 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 42538] New: vzeroupper elimination
https://bugs.llvm.org/show_bug.cgi?id=42538
Bug ID: 42538
Summary: vzeroupper elimination
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
#include
Since GCC 9+, GCC can eliminate vzeroupper in various cases, e.g.:
long long get_elem2(__m256i v) {
return v[2];
}
Clang -O3 -march=skylake-avx512
get_elem2:
vextracti128xmm0, ymm0, 1
vmovq rax, xmm0
vzeroupper
ret
GCC -O3 -march=skylake-avx512
get_elem2:
vextracti64x2 xmm0, ymm0, 0x1
vmovq rax, xmm0
ret
--
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 42537] New: Missing documentation about cross-compilation
https://bugs.llvm.org/show_bug.cgi?id=42537 Bug ID: 42537 Summary: Missing documentation about cross-compilation Product: compiler-rt Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: builtins Assignee: unassignedb...@nondot.org Reporter: qwertyt...@gmail.com CC: llvm-bugs@lists.llvm.org I haven't found fresh documentation about cross-compilation on compiler-rt for platforms, other than the host one. For example, for me it was real challenge, to cross-compile libclang_rt.builtins-aarch64.a on from x86 host platform. Please fix me and close this issue if I'm wrong. -- 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 42536] New: lld-link reporting undefined symbol with lto
https://bugs.llvm.org/show_bug.cgi?id=42536
Bug ID: 42536
Summary: lld-link reporting undefined symbol with lto
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: russell_gal...@sn.scee.net
CC: llvm-bugs@lists.llvm.org
Created attachment 22205
--> https://bugs.llvm.org/attachment.cgi?id=22205&action=edit
Reproducible
lld-link 8.0.0 crashes when reporting an undefined symbol (still present at
r364942).
(note that the test case below wouldn't link successfully with the bug fixed
due to the undefined symbols).
--- library.cpp
struct S {
virtual void foo() {}
};
void a() { S b; }
--- main.cpp
struct __declspec(dllimport) S {
virtual void foo();
};
struct a {
a();
};
struct {
a b;
S c;
} d;
> clang-cl /c /nologo /O2 /MT /TP -m64 -flto library.cpp
> llvm-lib /OUT:library.lib /NOLOGO library.obj
> clang-cl /c /nologo /O2 /MT /TP -m64 -flto main.cpp
>lld-link /OUT:test.exe "library.lib" "main.obj" /MACHINE:X64 /INCREMENTAL:NO
>/SUBSYSTEM:CONSOLE /ERRORREPORT:PROMPT /NOLOGO /NODEFAULTLIB
lld-link: error: : undefined symbol: mainCRTStartup
Stack dump:
0. Program arguments: lld-link /OUT:test.exe library.lib main.obj
/MACHINE:X64 /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /ERRORREPORT:PROMPT /NOLOGO
/NODEFAULTLIB
#0 0x7ff6b77886d3 lld::coff::getSymbol
F:\git\llvm-project\lld\COFF\SymbolTable.cpp:72:0
#1 0x7ff6b7787c0c lld::coff::getSymbolLocations(class lld::coff::ObjFile
*,unsigned int) F:\git\llvm-project\lld\COFF\SymbolTable.cpp:102:0
#2 0x7ff6b778bcaf lld::coff::reportUndefinedSymbol
F:\git\llvm-project\lld\COFF\SymbolTable.cpp:147:0
#3 0x7ff6b778b498 lld::coff::SymbolTable::reportRemainingUndefines(void)
F:\git\llvm-project\lld\COFF\SymbolTable.cpp:331:0
#4 0x7ff6b76f0437 lld::coff::LinkerDriver::link(class llvm::ArrayRef) F:\git\llvm-project\lld\COFF\Driver.cpp:1761:0
#5 0x7ff6b76e89e1 lld::coff::link(class llvm::ArrayRef,bool,class llvm::raw_ostream &) F:\git\llvm-project\lld\COFF\Driver.cpp:78:0
#6 0x7ff6b76b1227 main F:\git\llvm-project\lld\tools\lld\lld.cpp:155:0
#7 0x7ff6b95fbc94 __scrt_common_main_seh
d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288:0
#8 0x7ffe2d414034 (C:\WINDOWS\System32\KERNEL32.DLL+0x14034)
#9 0x7ffe2e553691 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x73691)
Without -flto this reports:
lld-link: error: : undefined symbol: mainCRTStartup
lld-link: error: undefined symbol: public: __cdecl a::a(void)
>>> referenced by main.obj:(_GLOBAL__sub_I_main.cpp)
lld-link: error: undefined symbol: const type_info::`vftable'
>>> referenced by main.obj:(struct S `RTTI Type Descriptor')
>>> referenced by library.lib(library.obj)
--
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 42535] New: Atomics support missing on 32-bit SPARC
https://bugs.llvm.org/show_bug.cgi?id=42535
Bug ID: 42535
Summary: Atomics support missing on 32-bit SPARC
Product: libraries
Version: trunk
Hardware: Sun
OS: Solaris
Status: NEW
Keywords: missing-feature
Severity: normal
Priority: P
Component: Backend: Sparc
Assignee: unassignedb...@nondot.org
Reporter: r...@gcc.gnu.org
CC: llvm-bugs@lists.llvm.org, venka...@cs.wisc.edu
When trying a 2-stage build of llvm trunk on Solaris 11.5/SPARC, quite a number
of tests FAILed compared to a 1-stage build with gcc 9. Many failed due to
missing atomics support in 32-bit sparc. The problem can easily be seen with
the tests used in llvm `cmake/modules/CheckAtomic.cmake`:
```
$ cat atomic.c
#include
std::atomic x;
int main() {
return x;
}
$ clang++ -m32 -std=c++11 atomic.c
symbol in file
__atomic_load_4 /var/tmp/atomics-04089b.o
ld: fatal: symbol referencing errors
clang-9: error: linker command failed with exit code 1 (use -v to see
invocation)
$ gcc -m32 -std=c++11 atomic.c
```
While I can hack the driver to link with `-latomics` to avoid this issue, it
would make way more sense if clang would handle this like gcc.
--
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 42534] New: [DAGCombine] X86 EltsFromConsecutiveLoads logic should be more generic
https://bugs.llvm.org/show_bug.cgi?id=42534 Bug ID: 42534 Summary: [DAGCombine] X86 EltsFromConsecutiveLoads logic should be more generic Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: listm...@philipreames.com, llvm-bugs@lists.llvm.org, llvm-...@ndave.org, spatel+l...@rotateright.com We should be trying to move some/most of this load combine logic into DAGCombiner and use TLI hooks for any target specific optimizations. Builds on the work in https://reviews.llvm.org/D64205 -- 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 42533] New: Objective-C pointer bug with fobjc-arc
https://bugs.llvm.org/show_bug.cgi?id=42533
Bug ID: 42533
Summary: Objective-C pointer bug with fobjc-arc
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: mike.kl...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
when compiling the following app with "-fobjc-arc -Werror" option i am not
getting expected compilation error. the app crashes at run time, obviously.
without "-fobjc-arc" option compiler issues a warning / error as expected.
#import
@interface Animal: NSObject
@end
@implementation Animal
@end
@interface Dog: Animal
- (void)bark;
@end
@implementation Dog
- (void)bark {}
@end
void bark(Dog** dog) {
[*dog bark];
}
int main(int argc, const char* argv[]) {
Animal* animal = [Animal new];
bark(&animal);
}
// same with foundation types
#import
void foo(NSMutableDictionary** mutableDictionary) {
(*mutableDictionary)[@"hello"] = @"world";
}
int main(int argc, const char* argv[]) {
NSDictionary* dictionary = [NSDictionary new];
foo(&dictionary);
}
--
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 41565] wasm linker: __start_SECTION / __end_SECTION symbol missing
https://bugs.llvm.org/show_bug.cgi?id=41565 Sam Clegg changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Sam Clegg --- Should be fixed in https://reviews.llvm.org/D64148 -- 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 15623 in oss-fuzz: llvm: Build failure
Comment #2 on issue 15623 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15623#c2 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-5987aca5-f451-4383-8290-a81def7d452c.txt -- 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 42532] New: [libclang] Infinite recursion when trying to evaluate alignof of a typedef of a template parameter.
https://bugs.llvm.org/show_bug.cgi?id=42532
Bug ID: 42532
Summary: [libclang] Infinite recursion when trying to evaluate
alignof of a typedef of a template parameter.
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: emi...@crisal.io
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
See https://github.com/rust-lang/rust-bindgen/issues/1590
Test-case is:
template class e {
using f = d;
static const auto g = alignof(f);
};
Trying to evaluate the cursor for `g` hangs as noted in that 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
