[llvm-bugs] [Bug 33825] clang boostrap fails at link time with TLS errors
https://bugs.llvm.org/show_bug.cgi?id=33825 Fedor Sergeev changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED -- 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 33825] clang boostrap fails at link time with TLS errors
https://bugs.llvm.org/show_bug.cgi?id=33825 Fedor Sergeev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33858] New: libunwind tests fail on the 5.0 branch
https://bugs.llvm.org/show_bug.cgi?id=33858 Bug ID: 33858 Summary: libunwind tests fail on the 5.0 branch Product: new-bugs Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org Blocks: 33849 When running the test-release.sh script for 5.0.0, the two tests below fail with undefined reference to `unw_getcontext' and undefined reference to `unw_getcontext' undefined reference to `unw_init_local' undefined reference to `unw_step' FAIL: libunwind :: unw_getcontext.pass.cpp (42966 of 44229) TEST 'libunwind :: unw_getcontext.pass.cpp' FAILED Command: ['/work/release-test/branches_release_50/Phase2/Release/llvmCore-test-branches_release_50.install/usr/local/bin/clang++', '-o', '/usr/local/google/work/relea se-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/libunwind/test/Output/unw_getcontext.pass.cpp.o', '-x', 'c++', '/usr/local/g oogle/work/release-test/branches_release_50/llvm.src/projects/libunwind/test/unw_getcontext.pass.cpp', '-c', '-v', '-D_LIBCPP_DISABLE_AVAILABILITY', '-Werror=thread-s afety', '-DLIBUNWIND_NO_TIMER', '-fno-exceptions', '-DLIBUNWIND_HAS_NO_EXCEPTIONS', '-std=c++1z', '-I/work/release-test/branches_release_50/llvm.src/projects/libunwin d/include', '-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', '-D__STDC_CONSTANT_MACROS', '-Itest/support', '-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', '-Wextr a', '-Werror', '-Wuser-defined-warnings', '-Wshadow', '-Wno-unused-command-line-argument', '-Wno-attributes', '-Wno-pessimizing-move', '-Wno-c++11-extensions', '-Wno- user-defined-literals', '-Wno-noexcept-type', '-Wno-aligned-allocation-unavailable', '-Wsign-compare', '-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code' , '-Wno-conversion', '-Wno-unused-local-typedef', '-Wno-#warnings', '-c', '&&', '/work/release-test/branches_release_50/Phase2/Release/llvmCore-test-branches_release_ 50.install/usr/local/bin/clang++', '-o', '/usr/local/google/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/libunw ind/test/Output/unw_getcontext.pass.cpp.exe', '/usr/local/google/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/l ibunwind/test/Output/unw_getcontext.pass.cpp.o', '-v', '-D_LIBCPP_DISABLE_AVAILABILITY', '-L/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branch es_release_50.obj/./lib', '-Wl,-rpath,/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/./lib', '-nodefaultlibs', '-lc++', ' -lc++abi', '-lm', '-lgcc_s', '-lgcc', '-lpthread', '-lc', '-lgcc_s', '-lgcc'] Exit Code: 1 Standard Error: -- clang version 5.0.0 (branches/release_50) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /work/release-test/branches_release_50/Phase2/Release/llvmCore-test-branches_release_50.install/usr/local/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.4 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3 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.4 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.3 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 "/usr/local/google/work/release-test/branches_release_50/Phase2/Release/llvmCore-test-branches_release_50.install/usr/local/bin/clang-5.0" -cc1 -triple x86_64-unknow n-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name unw_getcontext.pass.cpp -mrelocation-model static -mthread -model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -v -dwarf-column-info -debugger-tu ning=gdb -coverage-notes-file /usr/local/google/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/libunwind/test/Out put/unw_getcontext.pass.cpp.gcno -resource-dir /usr/local/google/work/release-test/branches_release_50/Phase2/Release/llvmCore-test-branches_release_50.install/usr/lo cal/lib/clang/5.0.0 -D _LIBCPP_DISABLE_AVAILABILITY -D LIBUNWIND_NO_TIMER -D LIBU
[llvm-bugs] [Bug 33859] New: openmp offloading/offloading_success.c and .cpp tests fail on the 5.0 branch
https://bugs.llvm.org/show_bug.cgi?id=33859 Bug ID: 33859 Summary: openmp offloading/offloading_success.c and .cpp tests fail on the 5.0 branch Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: gro...@us.ibm.com, hah...@hahnjo.de, llvm-bugs@lists.llvm.org Blocks: 33849 When running the test-release.sh script for the 5.0 branch on Linux, the openmp tests fail as below. Are these tests run on any buildbots somewhere? FAIL: libomptarget :: offloading/offloading_success.c (42977 of 44229) TEST 'libomptarget :: offloading/offloading_success.c' FAILED Script: -- echo ignored-command echo ignored-command echo ignored-command /work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/./bin/clang -fopenmp=libomp -I /work/release-test/branches_release_50/llvm .src/projects/openmp/libomptarget/test -I /work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/openmp/libomptarget/../ runtime/src -L /work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/lib -lomptarget -fopenmp-targets=x86_64-pc-linux-gnu /usr/ local/google/work/release-test/branches_release_50/llvm.src/projects/openmp/libomptarget/test/offloading/offloading_success.c -o /usr/local/google/work/release-test/b ranches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/openmp/libomptarget/test/offloading/Output/offloading_success.c.tmp-x86_64-pc-linux-g nu && /usr/local/google/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/openmp/libomptarget/test/offloading/Output /offloading_success.c.tmp-x86_64-pc-linux-gnu | /work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/./bin/FileCheck /usr/local /google/work/release-test/branches_release_50/llvm.src/projects/openmp/libomptarget/test/offloading/offloading_success.c -- Exit Code: 1 Command Output (stdout): -- $ "echo" "ignored-command" # command output: ignored-command $ "echo" "ignored-command" # command output: ignored-command $ "echo" "ignored-command" # command output: ignored-command $ "/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/./bin/clang" "-fopenmp=libomp" "-I" "/work/release-test/branches_releas e_50/llvm.src/projects/openmp/libomptarget/test" "-I" "/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/openmp/lib omptarget/../runtime/src" "-L" "/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/lib" "-lomptarget" "-fopenmp-targets=x86_6 4-pc-linux-gnu" "/usr/local/google/work/release-test/branches_release_50/llvm.src/projects/openmp/libomptarget/test/offloading/offloading_success.c" "-o" "/usr/local/ google/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/openmp/libomptarget/test/offloading/Output/offloading_succe ss.c.tmp-x86_64-pc-linux-gnu" $ "/usr/local/google/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/openmp/libomptarget/test/offloading/Output/of floading_success.c.tmp-x86_64-pc-linux-gnu" note: command had no output on stdout or stderr error: command failed with exit status: 1 $ "/work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/./bin/FileCheck" "/usr/local/google/work/release-test/branches_release_ 50/llvm.src/projects/openmp/libomptarget/test/offloading/offloading_success.c" # command stderr: /usr/local/google/work/release-test/branches_release_50/llvm.src/projects/openmp/libomptarget/test/offloading/offloading_success.c:19:12: error: expected string not f ound in input // CHECK: Target region executed on the device ^ :1:1: note: scanning from here Target region executed on the host ^ error: command failed with exit status: 1 -- Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90. FAIL: libomptarget :: offloading/offloading_success.cpp (42981 of 44229) TEST 'libomptarget :: offloading/offloading_success.cpp' FAILED Script: -- echo ignored-command echo ignored-command echo ignored-command /work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/./bin/clang++ -fopenmp=libomp -I /work/release-test/branches_release_50/ll vm.src/projects/openmp/libomptarget/test -I /work/release-test/branches_release_50/Phase3/Release/llvmCore-test-branches_release_50.obj/projects/openmp/libompta
[llvm-bugs] [Bug 32920] Potentially premature destroying of the locker in Python interpreter
https://bugs.llvm.org/show_bug.cgi?id=32920 Tatyana Krasnukha changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Tatyana Krasnukha --- Fixed with commit https://reviews.llvm.org/rL307512. -- 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 33860] New: Merge D35387: "[MACH-O] Fix the ASM code generated for __stub_helpers section" to 5.0
https://bugs.llvm.org/show_bug.cgi?id=33860 Bug ID: 33860 Summary: Merge D35387: "[MACH-O] Fix the ASM code generated for __stub_helpers section" to 5.0 Product: new-bugs Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org, superjo...@gmail.com Blocks: 33849 Andrew asked for this to be merged: https://reviews.llvm.org/D35387 Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=33849 [Bug 33849] [meta] 5.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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33861] New: Invalid scale in LEA crashes llvm-mc
https://bugs.llvm.org/show_bug.cgi?id=33861 Bug ID: 33861 Summary: Invalid scale in LEA crashes llvm-mc Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk Single-line testcase: $ cat patatino.s lea RDX, [number * RAX + RBX + _foo] Run: $ ./llvm-mc -triple x86_64-unknown-unknown -x86-asm-syntax=intel patatino.s .text _test: xorl%eax, %eax retq number = 8 .globl _foo .globl main main: llvm-mc: ../lib/Target/X86/AsmParser/X86Operand.h:551: static std::unique_ptr llvm::X86Operand::CreateMem(unsigned int, unsigned int, const llvm::MCExpr*, unsigned int, unsigned int, unsigned int, llvm::SMLoc, llvm::SMLoc, unsigned int, llvm::StringRef, void*, unsigned int): Assertion `((Scale == 1 || Scale == 2 || Scale == 4 || Scale == 8)) && "Invalid scale!"' failed. #0 0x0077c2ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) (./llvm-mc+0x77c2ea) #1 0x0077a23e llvm::sys::RunSignalHandlers() (./llvm-mc+0x77a23e) #2 0x0077a38c SignalHandler(int) (./llvm-mc+0x77a38c) #3 0x7f2fc5d70c30 __restore_rt (/lib64/libpthread.so.0+0x10c30) #4 0x7f2fc48dc765 __GI_raise (/lib64/libc.so.6+0x34765) #5 0x7f2fc48de36a __GI_abort (/lib64/libc.so.6+0x3636a) #6 0x7f2fc48d4f97 __assert_fail_base (/lib64/libc.so.6+0x2cf97) #7 0x7f2fc48d5042 (/lib64/libc.so.6+0x2d042) #8 0x00506669 llvm::X86Operand::CreateMem(unsigned int, unsigned int, llvm::MCExpr const*, unsigned int, unsigned int, unsigned int, llvm::SMLoc, llvm::SMLoc, unsigned int, llvm::StringRef, void*, unsigned int) (./llvm-mc+0x506669) #9 0x00509b00 (anonymous namespace)::X86AsmParser::ParseIntelBracExpression(unsigned int, llvm::SMLoc, long, bool, unsigned int) (./llvm-mc+0x509b00) #10 0x0050af7e (anonymous namespace)::X86AsmParser::ParseIntelOperand() (./llvm-mc+0x50af7e) #11 0x0050ba88 (anonymous namespace)::X86AsmParser::ParseOperand() (./llvm-mc+0x50ba88) #12 0x0050cec4 (anonymous namespace)::X86AsmParser::ParseInstruction(llvm::ParseInstructionInfo&, llvm::StringRef, llvm::SMLoc, llvm::SmallVectorImpl > >&) (./llvm-mc+0x50cec4) #13 0x00437ad6 llvm::MCTargetAsmParser::ParseInstruction(llvm::ParseInstructionInfo&, llvm::StringRef, llvm::AsmToken, llvm::SmallVectorImpl > >&) (./llvm-mc+0x437ad6) #14 0x00715a63 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) [clone .constprop.506] (./llvm-mc+0x715a63) #15 0x00718d1b (anonymous namespace)::AsmParser::Run(bool, bool) (./llvm-mc+0x718d1b) #16 0x0041718a main (./llvm-mc+0x41718a) #17 0x7f2fc48c8731 __libc_start_main (/lib64/libc.so.6+0x20731) #18 0x00431249 _start (./llvm-mc+0x431249) Stack dump: 0. Program arguments: ./llvm-mc -triple x86_64-unknown-unknown -x86-asm-syntax=intel patatino.s Aborted (core dumped) -- 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 33862] New: Assertion `!IndexReg && "IndexReg already set!"' failed. in MC
https://bugs.llvm.org/show_bug.cgi?id=33862
Bug ID: 33862
Summary: Assertion `!IndexReg && "IndexReg already set!"'
failed. in MC
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: MC
Assignee: andrew.v.tische...@gmail.com
Reporter: dav...@freebsd.org
CC: llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk,
simon.f.whitta...@gmail.com
$ ./llvm-mc -triple x86_64-unknown-unknown -x86-asm-syntax=intel patatino.s
llvm-mc: ../lib/Target/X86/AsmParser/X86AsmParser.cpp:535: void
{anonymous}::X86AsmParser::IntelExprStateMachine::onRegister(unsigned int):
Assertion `!IndexReg && "IndexReg already set!"' failed.
$ cat patatino.s
lea RDX, [4 * RAX + 27 * RBX + _pat]
Assigning this to Andrew as he's looking into this area already.
--
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 33173] failed to compute relocation: R_X86_64_DTPOFF32 with --gdb-index
https://bugs.llvm.org/show_bug.cgi?id=33173 Rafael Ávila de Espíndola changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Rafael Ávila de Espíndola --- Fixed in r308544. -- 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 33863] New: _Atomic _Bool decrement gives infinite loop
https://bugs.llvm.org/show_bug.cgi?id=33863
Bug ID: 33863
Summary: _Atomic _Bool decrement gives infinite loop
Product: clang
Version: 4.0
Hardware: PC
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: mib.bugzi...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
clang -v
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-apple-darwin14.4.0
Thread model: posix
InstalledDir:
/site/spt/usr8/mblower/bin/clang+llvm-4.0.1-x86_64-apple-macosx10.9.0/bin
sptem26:_test mblower$ cat tm.c
void
test_minus (void)
{
_Atomic _Bool a = 0;
_Bool b = 1;
_Atomic _Bool c = 1;
a -= b; // Test completes OK if this line is removed.
a -= c;
}
int main(void)
{
test_minus ();
}
I adapted this testcase from gcc testsuite. Execution of the 2nd decrement
doesn't complete. It works OK without the first decrement.
--Melanie Blower (I work for Intel on the Intel c++ compiler)
--
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 33832] cfi-icall + ThinLTO: no jump table entry created for functions defined in both ThinLTO module and merged module
https://bugs.llvm.org/show_bug.cgi?id=33832 Peter Collingbourne changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Peter Collingbourne --- r308642 -- 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 33818] segfault in opt
https://bugs.llvm.org/show_bug.cgi?id=33818 Davide Italiano changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #19 from Davide Italiano --- Reopening as the OP seems to still be able to reproduce this. I can't reproduce on any of my machines although I tried really hard :) -- 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 23214] [META] Using LLD as FreeBSD's system linker
https://bugs.llvm.org/show_bug.cgi?id=23214 Bug 23214 depends on bug 31582, which changed state. Bug 31582 Summary: ld.lld -v reports "no input files" error, conflicts with libtool test https://bugs.llvm.org/show_bug.cgi?id=31582 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31582] ld.lld -v reports "no input files" error, conflicts with libtool test
https://bugs.llvm.org/show_bug.cgi?id=31582 Rafael Ávila de Espíndola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Rafael Ávila de Espíndola --- Yes, looks like this is fixed. Building binutils I get checking if the linker (/home/espindola/inst/clang/bin/ld.lld) is GNU ld... yes -- 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 33864] New: Backport r308492 to 5.0
https://bugs.llvm.org/show_bug.cgi?id=33864 Bug ID: 33864 Summary: Backport r308492 to 5.0 Product: lld Version: unspecified Hardware: PC OS: Linux Status: ASSIGNED Severity: enhancement Priority: P Component: ELF Assignee: r...@google.com Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org -- 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 33791] Move PGOInstrumentation to new OptRemark API
https://bugs.llvm.org/show_bug.cgi?id=33791 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Davide Italiano --- r308668 -- 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 33789] Remove old OptRemark API
https://bugs.llvm.org/show_bug.cgi?id=33789 Bug 33789 depends on bug 33791, which changed state. Bug 33791 Summary: Move PGOInstrumentation to new OptRemark API https://bugs.llvm.org/show_bug.cgi?id=33791 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33865] New: rendering regressions since AMDGPU: Figure out private memory regs after lowering
https://bugs.llvm.org/show_bug.cgi?id=33865 Bug ID: 33865 Summary: rendering regressions since AMDGPU: Figure out private memory regs after lowering Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: adf.li...@gmail.com CC: llvm-bugs@lists.llvm.org On R9 285 tonga I am seeing some rendering regressions. The most reliable is produced with Unreal Tournament alpha, but slight more intermittent regressions are seen with unigine valley or unreal elemental demo. I intended to attach good and bad R600_DEBUG=vs,ps,fs from UT - but they are too big even when .xz. The diff is huge so I don't know whether they would be much use anyway. If requested I could upload elsewhere. When seen, reverting/re-instating below and rebuilding will reliably fix/re-produce, but to add some complication after initially noticing it I thought it had been fixed already as building next days llvm apparently fixed it. I was not testing with UT at that time, though. commit da7ac1f435e780c84dae27af22e9559676448781 Author: Matt Arsenault Date: Tue Jul 18 16:44:56 2017 + AMDGPU: Figure out private memory regs after lowering Introduce pseudo-registers for registers needed for stack access, which are replaced during finalizeLowering. Note these pseudo-registers are currently only used for the used register location, and not for determining their input argument register. This is better because it avoids the need to try to predict whether a call will be emitted from the IR, and also detects stack objects introduced by legalization. Test changes are from the HasStackObjects check being more accurate since stack objects introduced during legalization are now known. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308325 91177308-0d34-0410-b5e6-96231b3b80d8 -- 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 33866] New: Minor code gen difference between debug and no-debug introduced by X86FixupSetCC.
https://bugs.llvm.org/show_bug.cgi?id=33866 Bug ID: 33866 Summary: Minor code gen difference between debug and no-debug introduced by X86FixupSetCC. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: wolfgang_p...@playstation.sony.com CC: llvm-bugs@lists.llvm.org Created attachment 18824 --> https://bugs.llvm.org/attachment.cgi?id=18824&action=edit Test source (random generated and reduced). The attached C++ source exhibits a subtle difference in code gen when compiled with -g vs. without it. Nothing particularly important, but probably caused by the presence of DBG_VALUE instructions. Compile with clang with -O2 and with -O2 -g and diff the objdump -d output: 58,70c58,70 < a9: 8a 0d 00 00 00 00 mov0x0(%rip),%cl# af <_Z6test30v+0xaf> < af: 31 c0 xor%eax,%eax < b1: 0a 4c 24 1e or 0x1e(%rsp),%cl < b5: 0f 28 05 00 00 00 00movaps 0x0(%rip),%xmm0# bc <_Z6test30v+0xbc> < bc: 0f 29 44 24 20 movaps %xmm0,0x20(%rsp) < c1: 0f 28 05 00 00 00 00movaps 0x0(%rip),%xmm0# c8 <_Z6test30v+0xc8> < c8: 0f 29 44 24 30 movaps %xmm0,0x30(%rsp) < cd: 0f 95 c1setne %cl < d0: 74 33 je 105 <_Z6test30v+0x105> < d2: 88 c8 mov%cl,%al < d4: b1 01 mov$0x1,%cl < d6: 0f 57 c0xorps %xmm0,%xmm0 < d9: 0f 1f 80 00 00 00 00nopl 0x0(%rax) --- > a9: 8a 05 00 00 00 00 mov0x0(%rip),%al# af > <_Z6test30v+0xaf> > af: 0a 44 24 1e or 0x1e(%rsp),%al > b3: 0f 28 05 00 00 00 00movaps 0x0(%rip),%xmm0# ba > <_Z6test30v+0xba> > ba: 0f 29 44 24 20 movaps %xmm0,0x20(%rsp) > bf: 0f 28 05 00 00 00 00movaps 0x0(%rip),%xmm0# c6 > <_Z6test30v+0xc6> > c6: 0f 29 44 24 30 movaps %xmm0,0x30(%rsp) > cb: 0f 95 c0setne %al > ce: 74 35 je 105 <_Z6test30v+0x105> > d0: 0f b6 c0movzbl %al,%eax > d3: b1 01 mov$0x1,%cl > d5: 0f 57 c0xorps %xmm0,%xmm0 > d8: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1) > df: 00 -- 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 33867] New: Minor code gen difference betwen debug and no-debug introduced by X86FixupBWInsts
https://bugs.llvm.org/show_bug.cgi?id=33867 Bug ID: 33867 Summary: Minor code gen difference betwen debug and no-debug introduced by X86FixupBWInsts Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: wolfgang_p...@playstation.sony.com CC: llvm-bugs@lists.llvm.org Created attachment 18825 --> https://bugs.llvm.org/attachment.cgi?id=18825&action=edit Randomly generated and reduced test source The attached C++ source exhibits a minor difference in code gen when compiled with -g vs. without it. Not particularly important, probably caused by the presence of DBG_VALUE instructions. Compile with -O2 -g and with -O2 and examine the difference of the objdump -d outputs: 37c37 < 72: 0f b7 44 24 ec movzwl -0x14(%rsp),%eax --- > 72: 66 8b 44 24 ec mov-0x14(%rsp),%ax -- 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 33868] New: Shrink wrapping not firing on seemingly basic cases? (maybe i misunderstand how it works)
https://bugs.llvm.org/show_bug.cgi?id=33868
Bug ID: 33868
Summary: Shrink wrapping not firing on seemingly basic cases?
(maybe i misunderstand how it works)
Product: new-bugs
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: chandl...@gmail.com
CC: llvm-bugs@lists.llvm.org
I was digging into sadly unrelated performance issues and noticed a surprising
lack of shrink wrapping for functions with obvious, trivial early-exits.
Here is one example I was able to quickly reproduce:
% cat shrink_wrap.cpp
struct S { long a, b; };
struct C {
S doit() { return {1, 2}; }
};
S compute() {
static C* c = new C();
return c->doit();
}
% ./dev/bin/clang++ -std=c++11 -fno-rtti -fno-exceptions -c -S -o -
shrink_wrap.cpp -O3
.text
.file "shrink_wrap.cpp"
.globl _Z7computev # -- Begin function _Z7computev
.p2align4, 0x90
.type _Z7computev,@function
_Z7computev:# @_Z7computev
.cfi_startproc
# BB#0: # %entry
pushq %rax
.Lcfi0:
.cfi_def_cfa_offset 16
movb_ZGVZ7computevE1c(%rip), %al
testb %al, %al
jne .LBB0_3
# BB#1: # %init.check
movl$_ZGVZ7computevE1c, %edi
callq __cxa_guard_acquire
testl %eax, %eax
je .LBB0_3
# BB#2: # %init
movl$1, %edi
callq _Znwm
movq%rax, _ZZ7computevE1c(%rip)
movl$_ZGVZ7computevE1c, %edi
callq __cxa_guard_release
.LBB0_3:# %init.end
movl$1, %eax
movl$2, %edx
popq%rcx
retq
.Lfunc_end0:
Why do we need to pushq %rax and popq %rcx in the fast path?
--
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 33869] New: Clang is not aware of a false dependency of POPCNT on desitnation register on Intel Skylake CPU
https://bugs.llvm.org/show_bug.cgi?id=33869
Bug ID: 33869
Summary: Clang is not aware of a false dependency of POPCNT on
desitnation register on Intel Skylake CPU
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: m...@adhokshajmishraonline.in
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 18826
--> https://bugs.llvm.org/attachment.cgi?id=18826&action=edit
Test source code, dumped assmebler source code, and LLVM IR code
POPCNT instruction on Intel Skylake CPU seems have a false dependency on
destination register, resulting in a performance loss if destination register
is used immediately after POPCNT. The same bug has been present in Sandy
Bridge, Ivy Bridge and Haswell processors as well.
While G++ seems to be aware of dependency, it does not generate code where
false dependecy is triggerd. However, clang generated code gets hit immediately
due to false dependency coming up again and again.
Platform Details
CPU: Intel(R) Core(TM) i7-6700HQ CPU
OS:Arch Linux x86_64 Kernel Version 4.11.9-1
Compilers: g++ (GCC) 7.1.1 20170630
clang version 4.0.1 (tags/RELEASE_401/final)
Test Code
=
#include
#include
#include
int main(int argc, char* argv[]) {
using namespace std;
uint64_t size = 10<<20;
uint64_t* buffer = new uint64_t[size/8];
char* charbuffer = reinterpret_cast(buffer);
for (unsigned i=0; i startP,endP;
{
startP = chrono::system_clock::now();
count=0;
for( unsigned k = 0; k < 1; k++){
// Tight unrolled loop with uint64_t
for (uint64_t i=0;i(endP-startP).count();
cout << "Counter\t" << count << "\nSpeed\t" <<
(1.0*size)/(duration) << " GB/s" << endl;
}
free(charbuffer);
}
Code Generated by Clang
===
Compilation: clang++ poc.cpp -o poc_clang -O3 -march=native -std=c++14
[code stripped]
popcnt rcx, qword ptr [r15 + 8*rax]
add rcx, rbx
popcnt rdx, qword ptr [r15 + 8*rax + 8]
add rdx, rcx
popcnt rcx, qword ptr [r15 + 8*rax + 16]
add rcx, rdx
popcnt rdx, qword ptr [r15 + 8*rax + 24]
add rdx, rcx
popcnt rcx, qword ptr [r15 + 8*rax + 32]
add rcx, rdx
popcnt rdx, qword ptr [r15 + 8*rax + 40]
add rdx, rcx
popcnt rcx, qword ptr [r15 + 8*rax + 48]
add rcx, rdx
popcnt rbx, qword ptr [r15 + 8*rax + 56]
[code stripped]
In the above generated code, destination register of POPCNT is used in next
instruction (write only). Due to false dependency, next line does not execute
until destination register is ready for read (while we are only writing to it)
Code Generated by GCC
=
Compilation: g++ poc.cpp -o poc_gcc -O3 -march=native -std=c++14
[code stripped]
xor eax, eax
xor ecx, ecx
popcnt rax, QWORD PTR [rdx]
popcnt rcx, QWORD PTR 8[rdx]
add rax, rcx
xor ecx, ecx
popcnt rcx, QWORD PTR 16[rdx]
add rdx, 32
add rax, rcx
xor ecx, ecx
popcnt rcx, QWORD PTR -8[rdx]
add rax, rcx
add r12, rax
cmp rdx, r13
[code stripped]
In the code generated by GCC, false dependency is triggered in only 2 cases (in
clang it is 7), resulting in faster performance.
The test code, dumped assembly code (dumped from compiler), and LLVM IR code is
attached herewith (in ZIP)
--
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 33870] New: Fatal error when compiling with dataflow sanitizer (DFSan) - "fatal error: error in backend: Broken function found, compilation aborted!"
https://bugs.llvm.org/show_bug.cgi?id=33870
Bug ID: 33870
Summary: Fatal error when compiling with dataflow sanitizer
(DFSan) - "fatal error: error in backend: Broken
function found, compilation aborted!"
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: rtr...@google.com
CC: llvm-bugs@lists.llvm.org
$ cat blacklist.txt
fun:snprintf=uninstrumented
fun:snprintf=custom
$ cat reduce.cpp
extern "C" void snprintf(...);
void Foo() {
char a[1];
snprintf(0, a);
}
$ clang -cc1 -emit-obj -O1 -fsanitize=dataflow
-fsanitize-blacklist=dfsan_abilist.txt -x c++ reduce.cpp
Wrong types for attribute: byval inalloca nest noalias nocapture nonnull
readnone readonly sret dereferenceable(1) dereferenceable_or_null(1)
call void (i16*, ...) @__dfsw_snprintf(i16* %3, i32 nonnull 0, i8* %0) #5
fatal error: error in backend: Broken function found, compilation aborted!
--
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 33871] New: "visibility does not match previous declaration" error could be more useful
https://bugs.llvm.org/show_bug.cgi?id=33871
Bug ID: 33871
Summary: "visibility does not match previous declaration" error
could be more useful
Product: clang
Version: 5.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mh+l...@glandium.org
CC: llvm-bugs@lists.llvm.org
Reduced testcase:
#pragma GCC visibility push(hidden)
class Foo;
class __attribute__((visibility("default"))) Foo {
};
Compiling the above fails with:
test.cc:5:22: error: visibility does not match previous declaration
class __attribute__((visibility("default"))) Foo {
^
test.cc:1:13: note: previous attribute is here
#pragma GCC visibility push(hidden)
While technically entirely accurate, in real cases, the #pragma is not
necessarily close to the forward declaration, and it's really not obvious
what's wrong, and can lead to some unnecessary hair pulling.
The error message should mention the forward declaration 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
