[llvm-bugs] [Bug 34494] New: wrong code (in Polly?) on x86_64-linux-gnu with "opt -simplifycfg -sroa -early-cse-memssa -loop-rotate -jump-threading -licm -instcombine -polly-simplify -polly-opt-isl -p
https://bugs.llvm.org/show_bug.cgi?id=34494
Bug ID: 34494
Summary: wrong code (in Polly?) on x86_64-linux-gnu with "opt
-simplifycfg -sroa -early-cse-memssa -loop-rotate
-jump-threading -licm -instcombine -polly-simplify
-polly-opt-isl -polly-codegen"
Product: Polly
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Optimizer
Assignee: polly-...@googlegroups.com
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
$ clangpolly -v
clang version 6.0.0 (http://llvm.org/git/clang.git
9df566f7bbb4927b16ccc0e0770fa43a52eb759d)
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 -O3 -mllvm -disable-llvm-optzns -c -emit-llvm -o small.bc small.c
$ optpolly -simplifycfg -sroa -early-cse-memssa -loop-rotate -jump-threading
-licm -instcombine -polly-simplify -polly-opt-isl -polly-codegen -o
small-opt.bc small.bc
$ clangpolly small-opt.bc
$ ./a.out
199280720
$
$ clangpolly -O0 small.c; ./a.out
1
$
-
int printf (const char *, ...);
int a, b, c, d, e;
int foo ()
{
int h;
for (; a < 1; a++)
if ((d++ != 1 || e++ || h) && c)
return b;
return 0;
}
int main ()
{
foo ();
printf ("%d\n", d);
return 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34496] New: [osx.cocoa.RetainCount] Crash with function named 'C'
https://bugs.llvm.org/show_bug.cgi?id=34496
Bug ID: 34496
Summary: [osx.cocoa.RetainCount] Crash with function named 'C'
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: kreme...@apple.com
Reporter: v.reich...@netcologne.de
CC: llvm-bugs@lists.llvm.org
Running the command
clang++ --analyze -Xclang -analyzer-checker -Xclang osx.cocoa.RetainCount -c
bug.cc
on the following line of code:
===
int C() { return 0; }
===
triggers the assertion below.
If I rename the function, everything works fine.
This happens on trunk (r312474), LLVM-5.0.0 is not affected.
===
clang-6.0: /tmp/LLVM/llvm/include/llvm/ADT/StringRef.h:239: char
llvm::StringRef::operator[](size_t) const: Assertion `Index < Length &&
"Invalid index!"' failed.
#0 0x01ea65ca llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x1ea65ca)
#1 0x01ea425e llvm::sys::RunSignalHandlers()
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x1ea425e)
#2 0x01ea43ac SignalHandler(int)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x1ea43ac)
#3 0x0038b4c0f710 __restore_rt (/lib64/libpthread.so.0+0x38b4c0f710)
#4 0x0038b4432625 __GI_raise (/lib64/libc.so.6+0x38b4432625)
#5 0x0038b4433e05 __GI_abort (/lib64/libc.so.6+0x38b4433e05)
#6 0x0038b442b74e __assert_fail_base (/lib64/libc.so.6+0x38b442b74e)
#7 0x0038b442b810 __GI___assert_perror_fail (/lib64/libc.so.6+0x38b442b810)
#8 0x03565b81 (anonymous
namespace)::RetainSummaryManager::getFunctionSummary(clang::FunctionDecl
const*) (/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x3565b81)
#9 0x03565f09 void
clang::ento::check::BeginFunction::_checkBeginFunction<(anonymous
namespace)::RetainCountChecker>(void*, clang::ento::CheckerContext&)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x3565f09)
#10 0x036679a4
clang::ento::CheckerManager::runCheckersForBeginFunction(clang::ento::ExplodedNodeSet&,
clang::BlockEdge const&, clang::ento::ExplodedNode*, clang::ento::ExprEngine&)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x36679a4)
#11 0x0368dfd9
clang::ento::ExprEngine::processBeginOfFunction(clang::ento::NodeBuilderContext&,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&, clang::BlockEdge
const&) (/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x368dfd9)
#12 0x03674cbd
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, llvm::IntrusiveRefCntPtr)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x3674cbd)
#13 0x02beb09a (anonymous
namespace)::AnalysisConsumer::ActionExprEngine(clang::Decl*, bool,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet >*) [clone .part.4651]
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x2beb09a)
#14 0x02beb854 (anonymous
namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet >*)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x2beb854)
#15 0x02bfc358 (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&) [clone
.part.4701] (/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x2bfc358)
#16 0x02c287f8 clang::ParseAST(clang::Sema&, bool, bool)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x2c287f8)
#17 0x0243f2be clang::FrontendAction::Execute()
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x243f2be)
#18 0x0240d906
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x240d906)
#19 0x024e0eeb
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x24e0eeb)
#20 0x0080eff8 cc1_main(llvm::ArrayRef, char const*,
void*) (/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x80eff8)
#21 0x0080d2fb main (/LLVM/LLVM-trunk-312474/bin/clang-6.0+0x80d2fb)
clang version 6.0.0 (trunk)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /LLVM/LLVM-trunk/bin
===
--
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 34407] lld does not seem to honour the linker script load address
https://bugs.llvm.org/show_bug.cgi?id=34407 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from George Rimar --- r312625 -- 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 34498] New: x86-64: std::atomic is not atomic for a 16 byte object with -mno-cx16
https://bugs.llvm.org/show_bug.cgi?id=34498
Bug ID: 34498
Summary: x86-64: std::atomic is not atomic for a 16 byte
object with -mno-cx16
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: pe...@cordes.ca
CC: llvm-bugs@lists.llvm.org
struct A{
int a;
int b;
double c;
};
#include
std::atomic shared_struct;
void update_shared2(A tmp) {
shared_struct.store(tmp, std::memory_order_relaxed);
// shared_struct = tmp; // same buggy asm with libc++
}
Godbolt compiler explorer: https://godbolt.org/g/drmtAe
clang 6.0.0 (trunk 312520) -std=c++11 -stdlib=libc++ -Wall -Wextra -O3
-march=skylake -mno-cx16
update_shared2(A): # @update_shared2(A)
mov qword ptr [rip + shared_struct], rdi
vmovsd qword ptr [rip + shared_struct+8], xmm0
ret
Two separate stores are obviously not atomic!!
This might actually be a libc++ bug. The asm output is different with
-stdlib=libstdc++:
sub rsp, 24
mov qword ptr [rsp + 8], rdi
vmovsd qword ptr [rsp + 16], xmm0
lea rdx, [rsp + 8]
mov edi, 16
mov esi, shared_struct
xor ecx, ecx
call__atomic_store
add rsp, 24
ret
mov rdi, rax
call__clang_call_terminate
-
correct clang4.0 output with libc++ (same options)
update_shared2(A): # @update_shared2(A)
pushrax
mov rax, rdi
vmovq rdx, xmm0
mov edi, shared_struct
mov rsi, rax
call__sync_lock_test_and_set_16
pop rax
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24191] Possibly inefficient std::atomic codegen on x86 for simple arithmetic
https://bugs.llvm.org/show_bug.cgi?id=24191 Peter Cordes changed: What|Removed |Added Resolution|--- |FIXED CC||pe...@cordes.ca Status|NEW |RESOLVED --- Comment #4 from Peter Cordes --- Fixed since 3.8, still fixed in trunk. Closing. -- 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 34499] New: PDB emission fails with thin-lto
https://bugs.llvm.org/show_bug.cgi?id=34499 Bug ID: 34499 Summary: PDB emission fails with thin-lto Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: COFF Assignee: unassignedb...@nondot.org Reporter: alberto.ma...@microsoft.com CC: llvm-bugs@lists.llvm.org Created attachment 19107 --> https://bugs.llvm.org/attachment.cgi?id=19107&action=edit Reproducer Given the reproducer attached, the following sequence of commands clang-cl /c /Zi /O2 -flto=thin foo.c clang-cl /c /Zi /O2 -flto=thin main.c lld-link /OUT:prog.exe /DEBUG /PDB:prog.pdb /subsystem:CONSOLE /entry:main foo.obj main.obj produces this error: Native PDB Error: The entry already exists. The specified module already exists The following commands, with full LTO, work correctly: clang-cl /c /Zi /O2 -flto foo.c clang-cl /c /Zi /O2 -flto main.c lld-link /OUT:prog.exe /DEBUG /PDB:prog.pdb /subsystem:CONSOLE /entry:main foo.obj main.obj I am using: https://github.com/llvm-mirror/clang.git 3f0db6ed816c5fae9bf6a7b2b1711e8fc57b8589 https://github.com/llvm-mirror/llvm.git aba02efc6c6441eddd72388638f70cbb17e39b96 https://github.com/llvm-mirror/lld.git: d470133e80e2090b7281880320ddead759c7fa2d -- 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 33922] [OpenMP 5.0] New ident_t flags for __kmpc_for_static_init()
https://bugs.llvm.org/show_bug.cgi?id=33922 Olga Malysheva changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Olga Malysheva --- I found that the flags should be also set when __kmpc_for_static_fini() is called. -- 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 34501] New: [ARM] - LLD does not deduplicate entries in .ARM.exidx
https://bugs.llvm.org/show_bug.cgi?id=34501 Bug ID: 34501 Summary: [ARM] - LLD does not deduplicate entries in .ARM.exidx Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: gri...@accesssoftek.com CC: llvm-bugs@lists.llvm.org It was spotted in comments for PR34407 that when linking sample with LLD and gnu ld (sample can be taken from following reply: https://bugs.llvm.org/show_bug.cgi?id=34407#c2) the size of .ARM.exidx produced is different. gnu ld output is: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 3] .ARM.exidxARM_EXIDX 0001f098 00f098 08 00 AL 2 0 4 Unwind table index '.ARM.exidx' at offset 0xf098 contains 1 entries: 0x1f008 : 0x1 [cantunwind] and LLD's is: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 3] .ARM.exidxARM_EXIDX 0001f098 001098 18 00 AL 2 0 4 Unwind table index '.ARM.exidx' at offset 0x1098 contains 3 entries: 0x1f008 : 0x1 [cantunwind] 0x1f03e : 0x1 [cantunwind] 0x1f05a : 0x1 [cantunwind] So LLD produces 3x size of .ARM.exidx at this moment. I know almost nothing about ARM, but after quick investigation found that gnu ld do some proccessing for SHT_ARM_EXIDX sections. One of stepd is deduplicating of entries. Patch implementing this was: https://sourceware.org/ml/binutils/2009-05/msg00048.html And also looks they had to add --no-merge-exidx-entries flag to be able to disable deduplication (https://sourceware.org/ml/binutils/2010-04/msg00193.html). Not sure do we want to support this or not, reporting the difference just in case. -- 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 34502] New: Regalloc assert fails: Unexpected VNI
https://bugs.llvm.org/show_bug.cgi?id=34502 Bug ID: 34502 Summary: Regalloc assert fails: Unexpected VNI Product: libraries Version: 3.9 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 19112 --> https://bugs.llvm.org/attachment.cgi?id=19112&action=edit reduced testcase This is actually a bug that may have kept the SystemZ build bots red for some time now, but due to vacations this has not been reported yet. So this is quite urgent. I have done a git bisect, and found that it seems that commit 463fa38 (trunk@311401) is the cause for this. The attached reduced test case fails with that commit, but compiles if it's reverted. bin/llc -mcpu=z13 -O3 hoistspills_crash.ll -- 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 34503] New: Codegen generates invalid code.
https://bugs.llvm.org/show_bug.cgi?id=34503 Bug ID: 34503 Summary: Codegen generates invalid code. Product: Polly Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: l...@meinersbur.de CC: llvm-bugs@lists.llvm.org Created attachment 19113 --> https://bugs.llvm.org/attachment.cgi?id=19113&action=edit lambda-code_0.ll The attached test case fails with opt -polly-process-unprofitable -polly-remarks-minimal -polly-use-llvm-names -polly-import-jscop-dir=C:\Users\Meinersbur\src\llvm\tools\polly\test -polly-codegen -S -verify-each < C:\Users\Meinersbur\src\llvm\tools\polly\test\lambda-code_0.ll -- Exit Code: 1 Command Output (stdout): -- $ "opt" "-polly-process-unprofitable" "-polly-remarks-minimal" "-polly-use-llvm-names" "-polly-import-jscop-dir=C:\Users\Meinersbur\src\llvm\tools\polly\test" "-polly-codegen" "-S" "-verify-each" # command stderr: Instruction does not dominate all uses! %call3.i.i.i73 = call i8* @vec_heap_o_reserve() #3 %1 = ptrtoint i8* %call3.i.i.i73 to i64 Instruction does not dominate all uses! %call3.i.i.i73 = call i8* @vec_heap_o_reserve() #3 %3 = ptrtoint i8* %call3.i.i.i73 to i64 LLVM ERROR: Broken function found, compilation aborted! error: command failed with exit status: 1 This is probably caused by commit r312410 - [ScopDetect/Info] Look through PHIs that follow an error 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 34504] New: Assertion failed: getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"
https://bugs.llvm.org/show_bug.cgi?id=34504 Bug ID: 34504 Summary: Assertion failed: getOperand(0)->getType() == cast(getOperand(1)->getType())->getElemen tType() && "Ptr must be a pointer to Val type!" Product: Polly Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: l...@meinersbur.de CC: llvm-bugs@lists.llvm.org Created attachment 19114 --> https://bugs.llvm.org/attachment.cgi?id=19114&action=edit bitmap_0.ll The attached program crashes with: $ opt -polly-process-unprofitable -polly-remarks-minimal -polly-use-llvm-names -polly-import-jscop-dir=C:\Users\Meinersbur\src\llvm\tools\polly\test -polly-codegen -S < bitmap_0.ll Assertion failed: getOperand(0)->getType() == cast(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!", file C:\Users\Meinersbur\src\llvm\lib\IR\Instructions.cpp, line 1400 -- 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 34445] OpenMP: Reduction initializer segfaults at runtime in move constructor
https://bugs.llvm.org/show_bug.cgi?id=34445 Alexey Bataev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Alexey Bataev --- Fixed in rL312638 -- 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 34505] New: llvm-nm test fails on SystemZ
https://bugs.llvm.org/show_bug.cgi?id=34505 Bug ID: 34505 Summary: llvm-nm test fails on SystemZ Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org These are failures that are currently keeping a s390 build-bot red: bin/llvm-lit test/tools/llvm-nm/wasm -- Testing: 3 tests, 3 threads -- ... FAIL: LLVM :: tools/llvm-nm/wasm/exports.yaml (2 of 3) FAIL: LLVM :: tools/llvm-nm/wasm/weak-symbols.yaml (3 of 3) I found that by reverting 3ccf551 / trunk@312294, the problem disappears. TEST 'LLVM :: tools/llvm-nm/wasm/exports.yaml' FAILED *** test/tools/llvm-nm/wasm/exports.yaml:43:10: error: expected string not found in input # CHECK: 0400 D bar ^ :1:1: note: scanning from here D bar ^ TEST 'LLVM :: tools/llvm-nm/wasm/weak-symbols.yaml' FAILED *** test/tools/llvm-nm/wasm/weak-symbols.yaml:67:10: error: expected string not found in input # CHECK: 0400 W weak_global_data ^ :1:1: note: scanning from here W weak_global_data ^ -- 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 34506] New: lld -r corrupts comdat groups
https://bugs.llvm.org/show_bug.cgi?id=34506 Bug ID: 34506 Summary: lld -r corrupts comdat groups Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org given the .s: .section.foo,"axG",@progbits,bar,comdat .section.foo,"axG",@progbits,zed,comdat If the corresponding .o is passed to lld -r, the result has COMDAT group section [2] `.group' [bar] contains 1 sections: [Index]Name [3] .foo COMDAT group section [4] `.group' [zed] contains 1 sections: [Index]Name [3] .foo Note that the same section is in two groups -- 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 34239] clang generated object files linked with MSVC /DEBUG:FASTLINK generate huge PDBs
https://bugs.llvm.org/show_bug.cgi?id=34239
Zachary Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #23 from Zachary Turner ---
Closing this issue out since the size issues are fixed. Since this was
originally reported for Chrome, I wanted to get some numbers against Chrome
before closing it out for good.
Before patch:
08/16/2017 01:49 PM 1,079,554,048 content.dll.pdb
08/16/2017 12:56 PM 1,365,020,672 chrome.dll.pdb
after patch:
09/05/2017 08:08 PM 528,838,656 content.dll.pdb
09/06/2017 08:43 AM 777,490,432 chrome.dll.pdb
@blaikie: I'm going to look at what happens with out of line class definitions
separately. I've also found another strange issue which ist hat when you have
typedef struct { int X; } S;
we output 2 S_UDT records for this, one of which points to a forward decl and
could confuse the debugger.
But I'm considering this (and any potential issue we might have regarding
out-of-line definitions) a debug info quality issue, so I'll treat it
separately from this size 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33922] [OpenMP 5.0] New ident_t flags for __kmpc_for_static_init()
https://bugs.llvm.org/show_bug.cgi?id=33922 Alexey Bataev changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Alexey Bataev --- Fixed in r312642 -- 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 34507] New: Assertion failure (DelayedTypos.empty() && "Uncorrected typos!") in case of multiple typos in expression
https://bugs.llvm.org/show_bug.cgi?id=34507 Bug ID: 34507 Summary: Assertion failure (DelayedTypos.empty() && "Uncorrected typos!") in case of multiple typos in expression Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: oranevs...@accesssoftek.com CC: llvm-bugs@lists.llvm.org Created attachment 19115 --> https://bugs.llvm.org/attachment.cgi?id=19115&action=edit Reproducer If a chain of member function calls has multiple typos in it clang -cc1 fails with the assertion failure if built with assertion enabled. To reproduce compile the attached test case: clang -cc1 typo.cpp In the expression "z_obj.getY2().getM();" both getY2() and getM() calls are mistyped. The initial AST for this expression: CallExpr 0xcda1b01428 '' `-CXXDependentScopeMemberExpr 0xcda1b013d0 '' lvalue .getM `-CallExpr 0xcda1b013a8 '' `-TypoExpr 0xcda1b01398 '' lvalue The TypoExpr here stands for the getY2() call. During typo resolution TransformCXXDependentScopeMemberExpr() detects that getM() is also a typo and transforms the whole CXXDependentScopeMemberExpr into a single TypoExpr. The resulting expression after the transformation looks like this: CallExpr 0xcda1b01768 '' `-TypoExpr 0xcda1b01758 '' lvalue This newly created TypoExpr does not get into the TypoExprs container and it is not processed by the transform, thereby causing the assertion failure with clang built with assertions enabled or missing typo diagnostics for getM() if assertions are disabled. -- 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 34508] New: clang -x cuda requires duplicating __host__ and __device__ specifiers
https://bugs.llvm.org/show_bug.cgi?id=34508
Bug ID: 34508
Summary: clang -x cuda requires duplicating __host__ and
__device__ specifiers
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: CUDA
Assignee: unassignedclangb...@nondot.org
Reporter: ibiryu...@google.com
CC: llvm-bugs@lists.llvm.org
The following code compiles with nvcc and fails to compile with clang.
struct X {
__device__ __host__ int foo();
};
int X::foo() {
return 10;
}
namespace ns {
__device__ __host__ int bar();
}
int ns::bar() {
return 20;
}
clang assumes __host__ specifier on out-of-line definitions, producing
following errors:
cuda2.cu:6:12: error: __host__ function 'foo' cannot overload __host__
__device__ function 'foo'
int X::foo() {
^
cuda2.cu:2:33: note: previous declaration is here
__device__ __host__ int foo();
^
cuda2.cu:14:13: error: __host__ function 'bar' cannot overload __host__
__device__ function 'bar'
int ns::bar() {
^
cuda2.cu:11:33: note: previous declaration is here
__device__ __host__ int bar();
^
It seems that nvcc is doing the right thing here, not requiring to duplicate
specifiers.
--
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 34505] llvm-nm test fails on SystemZ
https://bugs.llvm.org/show_bug.cgi?id=34505 Jonas Paulsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonas Paulsson --- Thanks. *** This bug has been marked as a duplicate of bug 34487 *** -- 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 33878] BasicAA incorrectly assumes different address spaces don't alias
https://bugs.llvm.org/show_bug.cgi?id=33878 Nuno Lopes changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Nuno Lopes --- Changed committed in r312648. Thanks for reviewing! -- 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 34509] New: global memory allocation and pointers to this are not parsed correctly to exports
https://bugs.llvm.org/show_bug.cgi?id=34509 Bug ID: 34509 Summary: global memory allocation and pointers to this are not parsed correctly to exports Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: stef...@dyhr-nielsen.dk CC: llvm-bugs@lists.llvm.org Please see : https://stackoverflow.com/questions/46043622/how-do-i-access-compiled-memory-in-webassembly-from-js#46043622 -- 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 34510] New: Minidump target does not resolve new symbols correctly
https://bugs.llvm.org/show_bug.cgi?id=34510 Bug ID: 34510 Summary: Minidump target does not resolve new symbols correctly Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: mose...@google.com CC: llvm-bugs@lists.llvm.org Once frames are "symbolized" they will not get re-symbolized if modules/symbols are added later on. For example: target create --core "foo.dmp" bt image add full/libcontent.so image load --file libcontent.so --slide 0x7f17fc361000 bt Here I add libcontent.so explicitly but since the frames are cached from the first bt, the bt after the image load will not use the new symbols. As far as I can tell this is due to the explicit disabling of ClearStackFrames() in ThreadMinidump. -- 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 34511] New: Mangled names for unnamed local types declared in block expressions in non-static data member initializers lack discriminators
https://bugs.llvm.org/show_bug.cgi?id=34511
Bug ID: 34511
Summary: Mangled names for unnamed local types declared in
block expressions in non-static data member
initializers lack discriminators
Product: clang
Version: 4.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: thone...@synopsys.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Mangled names for unnamed local types declared in block expressions in
non-static data member initializers lack discriminators:
$ cat t.cpp
template void tf(T) {}
struct S {
void(^bp)() = ^{
enum {} e;
tf(e);
struct {} s1;
tf(s1);
struct {} s2;
tf(s2);
};
};
auto x = S{}.bp;
$ clang++ --version
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang++ -c -std=c++11 -fblocks t.cpp
t.cpp:1:27: error: definition with same mangled name as another definition
template void tf(T) {}
^
t.cpp:1:27: note: previous definition is here
t.cpp:1:27: error: definition with same mangled name as another definition
template void tf(T) {}
^
t.cpp:1:27: note: previous definition is here
2 errors generated.
Reducing the function template from a definition to a declaration reveals the
conflicting name:
$ cat t2.cpp
template void tf(T);
struct S {
void(^bp)() = ^{
enum {} e;
tf(e);
struct {} s1;
tf(s1);
struct {} s2;
tf(s2);
};
};
auto x = S{}.bp;
$ clang++ -c -std=c++11 -fblocks t2.cpp
$ nm t2.o
U _NSConcreteGlobalBlock
U _Z2tfIZ1S2bpMUb0_EUt_EvT_
r __block_descriptor_tmp
0020 r __block_literal_global
D x
t x_block_invoke
The single symbol ('_Z2tfIZ1S2bpMUb0_EUt_EvT_') emitted for the function
template instantiations reveals that each of the unnamed types were given the
same name: 'Z1S2bpMUb0_EUt_'. This name is strange in that the 'M' production
corresponding to from the Itanium ABI [1] matches the
'' production (with 'Ub0_'), but is missing a match for ''; thus the mangled name appears to be ill-formed.
Clearly, there should be three separate symbol references emitted; each
disambiguated by a discriminator on the ('Ut_') production
within the name.
[1]:
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.pointer-to-member-type
--
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 29092] psABI inconsistency when passing vector registers?
https://bugs.llvm.org/show_bug.cgi?id=29092 Wenzel Jakob changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 34512] New: ld.lld crash (SEGV) with --emit-relocs
https://bugs.llvm.org/show_bug.cgi?id=34512 Bug ID: 34512 Summary: ld.lld crash (SEGV) with --emit-relocs Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rol...@hack.frob.com CC: llvm-bugs@lists.llvm.org, pho...@chromium.org Depends on: 31579 --reproduce tarball attached Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=31579 [Bug 31579] ld.lld doesn't support --emmit-relocs (-q) -- 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 34513] New: Missing DW_OP_deref for non-trivial return by value
https://bugs.llvm.org/show_bug.cgi?id=34513
Bug ID: 34513
Summary: Missing DW_OP_deref for non-trivial return by value
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: dblai...@gmail.com
CC: apra...@apple.com, llvm-bugs@lists.llvm.org,
paul.robin...@am.sony.com, ztur...@google.com
Try this in a debugger:
struct string {
string() {}
string(int i) : i(i) {}
~string() {}
int i = 0;
};
string get_string() {
string unused;
string result = 3;
return result;
}
int main() { get_string(); }
$ clang++ -g -fno-exceptions str.cpp
$ gdb ./a.out
b 10
r
p result
p *(string*)result
Looks like there's a missing DW_OP_deref in here somehow.
--
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 34514] New: r311737 caused miscompile of chromium under msan
https://bugs.llvm.org/show_bug.cgi?id=34514 Bug ID: 34514 Summary: r311737 caused miscompile of chromium under msan Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: chandl...@gmail.com, craig.top...@gmail.com, llvm-bugs@lists.llvm.org This is based on a Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=762156 After r311737 we started seeing a single test binary failing, and only in msan builds, with an incorrect result. I don't have a good repro for this besides building and running the test. The test failure correlated with a change in X86TargetLowering::EmitTest's behaviour for a single SDAG node. Before r311737, EmitTest for an ISD::AND would generally return an X86ISD::AND. After that revision, it will more often return an X86ISD::CMP against 0, which is the pattern for a "test" instruction. If I change the new code to not do that for ISD::AND nodes which are used by both an X86ISD::CMP and an ISD::SELECT, the test passes. But even when targeting just that node, the difference in asm output is large and hard to make sense of. See the Chromium bug for IR and the patch I used. -- 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 34360] Linking error when calling operator new in CUDA kernel
https://bugs.llvm.org/show_bug.cgi?id=34360 Justin Lebar (:jlebar) changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Justin Lebar (:jlebar) --- Fix committed. -- 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 34515] New: std::indirect_array::operator= gives wrong result.
https://bugs.llvm.org/show_bug.cgi?id=34515
Bug ID: 34515
Summary: std::indirect_array::operator= gives wrong result.
Product: libc++
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: pichet2...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
#include "iostream"
#include
int main() {
int input[] = { 0, 1, 2, 3, 4, 5, 6 };
std::valarrayfilled(input, 7);
size_t indexes[] = { 1, 3, 4, 6 };
std::valarray index(indexes, 4);
size_t indexes2[] = { 1, 2, 3, 4 };
std::valarray index2(indexes2, 4);
const std::indirect_array result = filled[index];
const std::indirect_array result2 = filled[index2];
result = result2;
std::valarray temp(result);
for (int i = 0; i < temp.size(); i++)
std::cout << temp[i] << " ";
}
using clang, this will print:
1 2 2 2
using msvc or gcc, this will print:
1 2 3 4
--
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 34369] [X86][AVX512] suboptimal shuffle sequence instead of one vpermw instruction
https://bugs.llvm.org/show_bug.cgi?id=34369 Jatin Bhateja changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Jatin Bhateja --- Resolving with commit ID rL312608. -- 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
