[llvm-bugs] [Bug 36587] [IPRA] wrong code
https://bugs.llvm.org/show_bug.cgi?id=36587 Jonas Paulsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Jonas Paulsson --- (In reply to Francis Visoiu Mistrih from comment #6) > @Jonas, is this fixed by r331509? Hi Francis, as I remember it, r331509 should have fixed one of the issues I found, while not fixing everything related to IPRA... I reran the test case and at least it is giving the right checksum, so I think we can close this one now. Thanks, Jonas -- 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] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #19 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c19 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-2491ab07-d04a-4a2b-970a-205d7486498e.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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39875] Error: instruction requires: AVX-512 ISA when using -mavx512f
https://bugs.llvm.org/show_bug.cgi?id=39875 Jeffrey Walton changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #7 from Jeffrey Walton --- *** This bug has been marked as a duplicate of bug 36202 *** -- 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 39890] New: New assertion failure `MustInsert.second && "New discriminator shouldn't be present in set"' (X86DiscriminateMemOps.cpp)
https://bugs.llvm.org/show_bug.cgi?id=39890
Bug ID: 39890
Summary: New assertion failure `MustInsert.second && "New
discriminator shouldn't be present in set"'
(X86DiscriminateMemOps.cpp)
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: greg.bedw...@sony.com
CC: davi...@google.com, htmldevelo...@gmail.com,
llvm-bugs@lists.llvm.org, w...@google.com
Bisected on our internal fork to r347938 (Revert "Revert r347596 "Support for
inserting profile-directed cache prefetches") but reproducible with upstream
TOT (r348340) as follows:
$ cat 1.cpp
# define B4 b; b; b; b
# define B16 B4; B4; B4; B4
# define B64 B16; B16; B16; B16
# define B256 B64; B64; B64; B64
# define B1024 B256; B256; B256; B256
void a() {
volatile int b;
B1024; B1024; B;
}
$ ./bin/clang 1.cpp -c --target=x86_64-unknown-unknown -g
-fdebug-info-for-profiling -DB=
$ ./bin/clang 1.cpp -c --target=x86_64-unknown-unknown -g
-fdebug-info-for-profiling -DB=b
clang-8:
/mnt/e/work/public-git/llvm-project/llvm/lib/Target/X86/X86DiscriminateMemOps.cpp:119:
virtual bool
{anonymous}::X86DiscriminateMemOps::runOnMachineFunction(llvm::MachineFunction&):
Assertion `MustInsert.second && "New discriminator shouldn't be present in
set"' failed.
Obviously the above is quite a contrived testcase but we've seen it happen in
real code where there is heavy use of nested macro expansions.
--
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 39891] New: raw string literals in C
https://bugs.llvm.org/show_bug.cgi?id=39891 Bug ID: 39891 Summary: raw string literals in C Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: jan.sm...@nokia.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk GCC supports, as an extension, raw string literals in C For example, R"(^((.*[^[:space:]].*)|())$)" is valid in C code (with GCC). Would it be possible for Clang to also provide this as an extension. Thank you -- 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 39892] New: ASTDumper.cpp gets stuck on AArch64
https://bugs.llvm.org/show_bug.cgi?id=39892 Bug ID: 39892 Summary: ASTDumper.cpp gets stuck on AArch64 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: renato.go...@linaro.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk As of http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/6221, the AArch64 buildbot is stuck compiling ASTDumper.cpp and times out. After bisecting, I got to the commit r348060 as the culprit. -- 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 39893] New: Assertion failed: `NumElements > 0 && "#Elements of a VectorType must be greater than 0"'
https://bugs.llvm.org/show_bug.cgi?id=39893
Bug ID: 39893
Summary: Assertion failed: `NumElements > 0 && "#Elements of a
VectorType must be greater than 0"'
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: russell_gal...@sn.scee.net
CC: llvm-bugs@lists.llvm.org
$ cat test.cpp
typedef int __attribute__((ext_vector_type(2))) d;
typedef char __attribute__((ext_vector_type(2))) e;
typedef char __attribute__((ext_vector_type(8))) f;
typedef union {
d a;
f b;
} g;
f h;
d j;
void k() {
g l;
l.a = - j;
volatile e m = __builtin_shufflevector(h, l.b, 10, 4);
}
$ clang -c -O1 test.cpp
clang-8: .../llvm/lib/IR/Type.cpp:607: static llvm::VectorType*
llvm::VectorType::get(llvm::Type*, unsigned int): Assertion `NumElements > 0 &&
"#Elements of a VectorType must be greater than 0"' failed.
Introduced at r345602.
Author: Sanjay Patel
Date: Tue Oct 30 14:14:34 2018 +
[DAGCombiner] narrow vector binops when extraction is cheap
Narrowing vector binops came up in the demanded bits discussion in D52912.
I don't think we're going to be able to do this transform in IR as a
canonicalization
because of the risk of creating unsupported widths for vector ops, but we
already have
a DAG TLI hook to allow what I was hoping for: isExtractSubvectorCheap().
This is
currently enabled for x86, ARM, and AArch64 (although only x86 has existing
regression
test diffs).
This is artificially limited to not look through bitcasts because there are
so many
test diffs already, but that's marked with a TODO and is a small follow-up.
Differential Revision: https://reviews.llvm.org/D53784
--
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 39894] New: Compilation errors for libclang svn 348328
https://bugs.llvm.org/show_bug.cgi?id=39894 Bug ID: 39894 Summary: Compilation errors for libclang svn 348328 Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: htmldevelo...@gmail.com CC: kli...@google.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk svn info: 348328 [ 82%] Built target libclang_exports [ 82%] Building CXX object tools/clang/tools/libclang/CMakeFiles/libclang.dir/CXType.cpp.o /root/llvm/tools/clang/tools/libclang/CXType.cpp: In function 'CXCallingConv clang_getFunctionTypeCallingConv(CXType)': /root/llvm/tools/clang/tools/libclang/CXType.cpp:645:30: error: 'CC_AArch64VectorCall' was not declared in this scope #define TCALLINGCONV(X) case CC_##X: return CXCallingConv_##X ^ /root/llvm/tools/clang/tools/libclang/CXType.cpp:654:7: note: in expansion of macro 'TCALLINGCONV' TCALLINGCONV(AArch64VectorCall); ^ /root/llvm/tools/clang/tools/libclang/CXType.cpp:645:45: error: 'CXCallingConv_AArch64VectorCall' was not declared in this scope #define TCALLINGCONV(X) case CC_##X: return CXCallingConv_##X ^ /root/llvm/tools/clang/tools/libclang/CXType.cpp:654:7: note: in expansion of macro 'TCALLINGCONV' TCALLINGCONV(AArch64VectorCall); ^ tools/clang/tools/libclang/CMakeFiles/libclang.dir/build.make:494: recipe for target 'tools/clang/tools/libclang/CMakeFiles/libclang.dir/CXType.cpp.o' failed make[2]: *** [tools/clang/tools/libclang/CMakeFiles/libclang.dir/CXType.cpp.o] Error 1 CMakeFiles/Makefile2:42294: recipe for target 'tools/clang/tools/libclang/CMakeFiles/libclang.dir/all' failed make[1]: *** [tools/clang/tools/libclang/CMakeFiles/libclang.dir/all] Error 2 Makefile:149: recipe for target 'all' failed make: *** [all] Error 2 root@877aa7b58ab3:~/build# -- 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] Issue 11763 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !isUniformAfterVectorization(PredInst, VF) && "Instruction marked uniform-after-
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-12-05 Type: Bug New issue 11763 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: !isUniformAfterVectorization(PredInst, VF) && "Instruction marked uniform-after- https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11763 Detailed report: https://oss-fuzz.com/testcase?key=5759137967767552 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_vectorize Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: !isUniformAfterVectorization(PredInst, VF) && "Instruction marked uniform-after- llvm::LoopVectorizationCostModel::computePredInstDiscount llvm::LoopVectorizationCostModel::collectInstsToScalarize Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201810170227:20181623 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5759137967767552 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11749 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs
Comment #1 on issue 11749 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11749#c1 ClusterFuzz has detected this issue as fixed in range 201812040236:201812050231. Detailed report: https://oss-fuzz.com/testcase?key=5163134281580544 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff3b310b40 Crash State: processTypeAttrs ConvertDeclSpecToType GetDeclSpecTypeForDeclarator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201808202008:201808210126 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812040236:201812050231 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5163134281580544 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11544 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType
Comment #1 on issue 11544 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11544#c1 ClusterFuzz has detected this issue as fixed in range 201812040236:201812050231. Detailed report: https://oss-fuzz.com/testcase?key=5713136359833600 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fffa1181e18 Crash State: ConvertDeclSpecToType GetDeclSpecTypeForDeclarator clang::Sema::GetTypeForDeclarator Sanitizer: address (ASAN) Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201812040236:201812050231 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5713136359833600 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11749 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 11749 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in processTypeAttrs https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11749#c2 ClusterFuzz testcase 5163134281580544 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11544 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 11544 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in ConvertDeclSpecToType https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11544#c2 ClusterFuzz testcase 5713136359833600 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39895] New: Error: unknown token in expression using inline asm
https://bugs.llvm.org/show_bug.cgi?id=39895
Bug ID: 39895
Summary: Error: unknown token in expression using inline asm
Product: clang
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: noloa...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
We have about 8K lines of inline assembly written to accommodate GCC and MSVC.
Clang is currently disabled but we would like to enable it.
The inline assembly in the production code is hidden behind macros. The body is
Intel and the assembler template is AT&T. GCC sees both while MSVC only sees
the Intel body without the other adornments.
Clang is having trouble with it. It looks like Clang handles the noprefix OK
because "xor rsi, rsi" does not cause an error. However, the positional
arguments are giving it trouble.
$ cat TestPrograms/test_mixed_asm.cxx
#include
int main(int argc, char* argv[])
{
size_t ret = 1, N = 0;
asm __volatile__
(
".intel_syntax noprefix ;\n"
"xor rsi, rsi;\n"
"neg %1 ;\n"
"inc %1 ;\n"
"push %1 ;\n"
"pop rax ;\n"
".att_syntax prefix ;\n"
: "=a" (ret) : "c" (N) : "%rsi"
);
return (int)ret;
}
Compiling with GCC on Linux is OK:
$ g++ TestPrograms/test_mixed_asm.cxx
But Clang on Linux is having trouble:
$ clang++ TestPrograms/test_mixed_asm.cxx
TestPrograms/test_mixed_asm.cxx:11:4: error: unknown token in expression
"neg %1 ;\n"
^
:3:5: note: instantiated into assembly here
neg %rcx ;
^
TestPrograms/test_mixed_asm.cxx:12:4: error: unknown token in expression
"inc %1 ;\n"
^
:4:5: note: instantiated into assembly here
inc %rcx ;
^
TestPrograms/test_mixed_asm.cxx:13:4: error: unknown token in expression
"push %1 ;\n"
^
:5:6: note: instantiated into assembly here
push %rcx ;
^
3 errors generated.
And:
$ clang++ --version
clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /bin
Jumping over to MacPorts for Clang 7:
$ /opt/local/bin/clang++-mp-7.0 TestPrograms/test_mixed_asm.cxx
TestPrograms/test_mixed_asm.cxx:11:4: error: unknown token in expression
"neg %1 ;\n"
^
:3:5: note: instantiated into assembly here
neg %rcx ;
^
TestPrograms/test_mixed_asm.cxx:12:4: error: unknown token in expression
"inc %1 ;\n"
^
:4:5: note: instantiated into assembly here
inc %rcx ;
^
TestPrograms/test_mixed_asm.cxx:13:4: error: unknown token in expression
"push %1 ;\n"
^
:5:6: note: instantiated into assembly here
push %rcx ;
^
3 errors generated.
--
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 39896] New: Lowering loses information about debug variable assignment.
https://bugs.llvm.org/show_bug.cgi?id=39896
Bug ID: 39896
Summary: Lowering loses information about debug variable
assignment.
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Keywords: wrong-debug
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: carlos.alberto.enc...@gmail.com,
greg.bedw...@sony.com, jdevliegh...@apple.com,
jeremy.morse.l...@gmail.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Created attachment 21196
--> https://bugs.llvm.org/attachment.cgi?id=21196&action=edit
testcase
The following IR debug instruction/metadata (please see attachment for the full
file):
@a = global i8 25, align 1, !dbg !0
; Function Attrs: nounwind ssp uwtable
define signext i16 @b() #0 !dbg !12 {
entry:
call void @llvm.dbg.value(metadata i16 23680, metadata !17, metadata
!DIExpression()), !dbg !18
%0 = load i8, i8* @a, align 1, !dbg !19, !tbaa !20
%conv = sext i8 %0 to i16, !dbg !19
call void @llvm.dbg.value(metadata i16 %conv, metadata !17, metadata
!DIExpression()), !dbg !18
%call = call i32 (...) @optimize_me_not(), !dbg !23
%1 = load i8, i8* @a, align 1, !dbg !24, !tbaa !20
%conv1 = sext i8 %1 to i16, !dbg !24
ret i16 %conv1, !dbg !25
}
Gets lowered into:
$ ./llc -filetype=obj ./baciotto.ll -o Palatino
$ dwarfdump ./patatino
[…]
0x0046: TAG_subprogram [4] *
AT_low_pc( 0x )
AT_high_pc( 0x0014 )
AT_frame_base( rbp )
Unknown DW_AT constant: 0x7a( true )
AT_name( "b" )
AT_decl_file( "/Users/dcci/work/llvm/build-debug/bin/run.c" )
AT_decl_line( 2 )
AT_type( {0x0095} ( short ) )
AT_external( true )
AT_APPLE_optimized( true )
0x005f: TAG_variable [5]
AT_const_value( 0x5c80 )
AT_name( "i" )
AT_decl_file(
"/Users/dcci/work/llvm/build-debug/bin/run.c" )
AT_decl_line( 3 )
AT_type( {0x0095} ( short ) )
0x006d: NULL
Somehow, somewhere in the backend or in MC we loose track that the variable
gets reassigned to the value loaded from the global @a. This degrades the debug
info quality, printing the wrong value.
--
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 39195] Clang no longer optimizing patterns to horizontal add/sub after r343727
https://bugs.llvm.org/show_bug.cgi?id=39195 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||344141, 344361 Resolution|--- |FIXED --- Comment #12 from Sanjay Patel --- (In reply to Simon Pilgrim from comment #11) > What is left to do for this bug? > > https://godbolt.org/z/FtBGsD > This looks right for btver2 (fast horizontal ops). I think we can close this one after: https://reviews.llvm.org/D52997 / https://reviews.llvm.org/rL344141 https://reviews.llvm.org/D53095 / https://reviews.llvm.org/rL344361 We still have h-op holes, but they should be tracked by remaining bugs. -- 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 39893] Assertion failed: `NumElements > 0 && "#Elements of a VectorType must be greater than 0"'
https://bugs.llvm.org/show_bug.cgi?id=39893 Sanjay Patel changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||348383 --- Comment #2 from Sanjay Patel --- Should be fixed after: https://reviews.llvm.org/rL348383 -- 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 34758] r313904 causes "command source" to assert and die
https://bugs.llvm.org/show_bug.cgi?id=34758 Leonard Mosescu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 39897] New: NativePDB reader detects multiple symbols with the same address in chrome_child.pdb
https://bugs.llvm.org/show_bug.cgi?id=39897
Bug ID: 39897
Summary: NativePDB reader detects multiple symbols with the
same address in chrome_child.pdb
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: mose...@google.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
It's not clear if the debug information is valid or not, but the current code
asserts this should not happen:
void PdbIndex::BuildAddrToSymbolMap(CompilandIndexItem &cci) {
...
for (auto iter = syms.begin(); iter != syms.end(); ++iter) {
...
// If the debug info is incorrect, we could have multiple symbols with the
// same address. So use try_emplace instead of insert, and the first one
// will win.
auto insert_result =
cci.m_symbols_by_va.insert(std::make_pair(va, PdbSymUid(cu_sym_id)));
(void)insert_result;
// The odds of an error in some function such as GetSegmentAndOffset or
// MakeVirtualAddress are much higher than the odds of encountering bad
// debug info, so assert that this item was inserted in the map as opposed
// to having already been there.
lldbassert(insert_result.second);
}
}
Loading a Chrome minidump which points to chrome_child.pdb leads to this:
tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp:158: void
lldb_private::npdb::PdbIndex::BuildAddrToSymbolMap(lldb_private::npdb::CompilandIndexItem&):
Assertion `insert_result.second' failed.
libc.so.6!__GI___assert_fail(const char * assertion, const char * file,
unsigned int line, const char * function)
(/tmp/build-debs.Lfl5zt/glibc-2.24/assert/assert.c:101)
liblldb.so.8svn!lldb_private::npdb::PdbIndex::BuildAddrToSymbolMap(lldb_private::npdb::PdbIndex
* const this, lldb_private::npdb::CompilandIndexItem & cci)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp:158)
liblldb.so.8svn!lldb_private::npdb::PdbIndex::FindSymbolsByVa(lldb_private::npdb::PdbIndex
* const this, lldb::addr_t va)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp:171)
liblldb.so.8svn!lldb_private::npdb::SymbolFileNativePDB::ResolveSymbolContext(lldb_private::npdb::SymbolFileNativePDB
* const this, const lldb_private::Address & addr, lldb::SymbolContextItem
resolve_scope, lldb_private::SymbolContext & sc)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:1498)
liblldb.so.8svn!lldb_private::SymbolVendor::ResolveSymbolContext(lldb_private::SymbolVendor
* const this, const lldb_private::Address & so_addr, lldb::SymbolContextItem
resolve_scope, lldb_private::SymbolContext & sc)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Symbol/SymbolVendor.cpp:240)
liblldb.so.8svn!lldb_private::Module::ResolveSymbolContextForAddress(lldb_private::Module
* const this, const lldb_private::Address & so_addr, lldb::SymbolContextItem
resolve_scope, lldb_private::SymbolContext & sc, bool
resolve_tail_call_address)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Core/Module.cpp:467)
liblldb.so.8svn!lldb_private::RegisterContextLLDB::InitializeNonZerothFrame(lldb_private::RegisterContextLLDB
* const this)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:449)
liblldb.so.8svn!lldb_private::RegisterContextLLDB::RegisterContextLLDB(lldb_private::RegisterContextLLDB
* const this, lldb_private::Thread & thread, const
lldb_private::RegisterContextLLDB::SharedPtr & next_frame,
lldb_private::SymbolContext & sym_ctx, uint32_t frame_number,
lldb_private::UnwindLLDB & unwind_lldb)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:68)
liblldb.so.8svn!lldb_private::UnwindLLDB::GetOneMoreFrame(lldb_private::UnwindLLDB
* const this, lldb_private::ABI * abi)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:131)
liblldb.so.8svn!lldb_private::UnwindLLDB::AddOneMoreFrame(lldb_private::UnwindLLDB
* const this, lldb_private::ABI * abi)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:338)
liblldb.so.8svn!lldb_private::UnwindLLDB::UpdateUnwindPlanForFirstFrameIfInvalid(lldb_private::UnwindLLDB
* const this, lldb_private::ABI * abi)
(/usr/local/google/home/mosescu/extra/llvm/src/tools/lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp:311)
liblldb.so.8svn!lldb_private::UnwindLLDB::AddFirstFrame(lldb_private::UnwindLLDB
* const this)
(/usr/local/google/home/mos
[llvm-bugs] [Bug 39882] [codeview] LLVM-generated PDBs contain CodeView symbols with invalid Seg:Offset
https://bugs.llvm.org/show_bug.cgi?id=39882 Reid Kleckner changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||r...@google.com --- Comment #1 from Reid Kleckner --- I strongly suspect these globals were discarded by /OPT:REF. When this happens, those fields will remain unrelocated, and they typically contain zeroes. Fixing it should be easy, I think we can just discard such symbol records from the globals stream if the segment index/offset pair is zero. IIRC valid segments start at 1 (maybe?), so zero should be invalid. *** This bug has been marked as a duplicate of bug 39147 *** -- 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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39847, which changed state. Bug 39847 Summary: Merge r347981 into the 7.0 branch https://bugs.llvm.org/show_bug.cgi?id=39847 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 39847] Merge r347981 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=39847 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|r348362 |r348362 r348362 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tom Stellard --- I can confirm this was merged: r348362. -- 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 39735] Merge r344257 and r345470 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=39735 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|r344257 r345470 |r345470 r348405 Status|NEW |RESOLVED --- Comment #2 from Tom Stellard --- I've merged r345470 as r348405. -- 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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39735, which changed state. Bug 39735 Summary: Merge r344257 and r345470 into the 7.0 branch https://bugs.llvm.org/show_bug.cgi?id=39735 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 39898] New: Missed min max optimization
https://bugs.llvm.org/show_bug.cgi?id=39898
Bug ID: 39898
Summary: Missed min max optimization
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
int minmax(int num) {
int t = std::max(15, num);
return std::min(1, t);
}
Current codegen -O3, x86-64:
minmax(int): # @minmax(int)
cmp edi, 14
mov ecx, 15
cmovg ecx, edi
cmp ecx, 2
mov eax, 1
cmovl eax, ecx
ret
We can fold it to 1 (GCC does it).
--
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 39899] New: Clang/LLVM Produces a constant description of a global constant, even when that constant has storage
https://bugs.llvm.org/show_bug.cgi?id=39899
Bug ID: 39899
Summary: Clang/LLVM Produces a constant description of a global
constant, even when that constant has storage
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: dblai...@gmail.com
CC: apra...@apple.com, echri...@gmail.com,
jdevliegh...@apple.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, paul.robin...@am.sony.com,
richard-l...@metafoo.co.uk
Given this:
static const int x = 3;
const int *y() {
return &x;
}
int z() {
return 1;
}
Clang produces IR with a variable description like this:
@_ZL1x = internal constant i32 3, align 4, !dbg !0
!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
Which seems all right and good.
but if you change the "return 1" to "return x", you get IR like this:
@_ZL1x = internal constant i32 3, align 4, !dbg !0
!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression(DW_OP_constu,
3, DW_OP_stack_value))
It's weird that the !dbg is even attached to the global anymore, since it
doesn't use its address in the location expression at all.
But also, it's a regression to describe something with a constant when it does
have storage - it means you can't, say evaluate "&i" in a debugger, or pass the
address of the global to a function that wants an address, etc.
According to some rough debugging with godbolt, this regression first appeared
in the 4.0 release.
--
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 39900] New: DebugInfo: SCCP loses debug info for constant globals
https://bugs.llvm.org/show_bug.cgi?id=39900
Bug ID: 39900
Summary: DebugInfo: SCCP loses debug info for constant globals
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, jdevliegh...@apple.com,
keith.wal...@arm.com, llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Given this code:
static int x = 3;
int z() { return x; }
Unoptimized, the resulting DWARF describes the location of 'x'.
Once optimized by SCCP, the LLVM IR is not updated with a description of the
constant value of 'x', the value is lost entirely.
Looks like down in the final loop (line ~2140) in SCCP.cpp, that's deleting
globals - it could check if there's debug info attached to the GlobalVariable,
and rewrite it to a constant description using I->second.getConstant(), if the
constant is of a type (int or float? I think are the ones currently supported)
that can be encoded as a constant in the debug info metadata at the moment.
This may be incorrect in cases where this optimization fires & due to previous
passes eliminating dead stores to the variable (in which case the dead stores
wouldn't be reflected - though I suppose at that point describing the location
of the variable as being in the global is just as erroneous), but it looks
like, at least if you complicate the case by adding "x = 7;" to z() before the
return, it's not SCCP that optimizes away the GlobalVariable, but GlobalOpt. So
maybe fixing SCCP isn't an issue in this way.
--
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 30806] Wrong code generation at -O2 leading to division by zero
https://bugs.llvm.org/show_bug.cgi?id=30806 Warren Ristow changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Fixed By Commit(s)|r347934 | --- Comment #17 from Warren Ristow --- (In reply to Warren Ristow from comment #16) > > The patch has landed: > https://reviews.llvm.org/rL347934 I'm re-opening, as this patch was reverted at: https://reviews.llvm.org/rL348426 The problem is SEGVs in PHINode simplification in instcombine, as described in the llvm-commits thread for r347934. - As an aside, as discussed in the review: https://reviews.llvm.org/D55232 (for a related patch, to fix bug 38697), in studying the history of the code in this area, I noticed that a similar fix was made about a year ago at r289412. But that year-old fix was reverted at r289453, with the following note: Reverts r289412. It caused an OOB PHI operand access in instcombine when ASan is enabled. Reduction in progress. It may be that the SEGVs in PHINode simplification that motivated the revert for the new patch are rooted in the same problem that motivated the revert that was done a year ago. -- 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 39753] Merge r343369 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=39753 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|r343369 |r343369 r348450 r348451 ||r348452 r348453 Status|NEW |RESOLVED --- Comment #2 from Tom Stellard --- Merged: llvm: r348450 clang: r348451 clang-tools-extra: r348452 libcxx: r348453 -- 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 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39753, which changed state. Bug 39753 Summary: Merge r343369 into the 7.0 branch https://bugs.llvm.org/show_bug.cgi?id=39753 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
