[llvm-bugs] [Bug 51179] New: "Trip Count for Loop at depth 1 containing: %for.cond1415, %for.body1419 Changed!" with verify
https://bugs.llvm.org/show_bug.cgi?id=51179 Bug ID: 51179 Summary: "Trip Count for Loop at depth 1 containing: %for.cond1415,%for.body1419 Changed!" with verify Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: mikael.hol...@ericsson.com CC: listm...@philipreames.com, llvm-bugs@lists.llvm.org CC: listm...@philipreames.com Summary: "Trip Count for Loop at depth 1 containing: %for.cond1415,%for.body1419 Changed!" with verify Created attachment 25051 --> https://bugs.llvm.org/attachment.cgi?id=25051&action=edit bbi-58443.ll llvm commit: 989bedec7a6a Reproduce with: opt -passes='function(loop-mssa(indvars),verify)' -o /dev/null bbi-58443.ll Result: Trip Count for Loop at depth 1 containing: %for.cond1415,%for.body1419 Changed! Old: 1 New: 0 Delta: 1 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: build-all-builtins/bin/opt -passes=function(loop-mssa(indvars),verify) -o /dev/null bbi-58443.ll #0 0x02aabec3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build-all-builtins/bin/opt+0x2aabec3) #1 0x02aa9b3e llvm::sys::RunSignalHandlers() (build-all-builtins/bin/opt+0x2aa9b3e) #2 0x02aac246 SignalHandler(int) Signals.cpp:0:0 #3 0x7fc5aaae9630 __restore_rt sigaction.c:0:0 #4 0x7fc5a821c387 raise (/lib64/libc.so.6+0x36387) #5 0x7fc5a821da78 abort (/lib64/libc.so.6+0x37a78) #6 0x01b81b95 llvm::ScalarEvolution::verify() const (build-all-builtins/bin/opt+0x1b81b95) #7 0x01b830e1 llvm::ScalarEvolutionVerifierPass::run(llvm::Function&, llvm::AnalysisManager&) (build-all-builtins/bin/opt+0x1b830e1) #8 0x02dab4ed llvm::detail::PassModel >::run(llvm::Function&, llvm::AnalysisManager&) crtstuff.c:0:0 #9 0x02293065 llvm::PassManager >::run(llvm::Function&, llvm::AnalysisManager&) (build-all-builtins/bin/opt+0x2293065) #10 0x00ac733d llvm::detail::PassModel >, llvm::PreservedAnalyses, llvm::AnalysisManager >::run(llvm::Function&, llvm::AnalysisManager&) crtstuff.c:0:0 #11 0x02297346 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (build-all-builtins/bin/opt+0x2297346) #12 0x007952bd llvm::detail::PassModel >::run(llvm::Module&, llvm::AnalysisManager&) crtstuff.c:0:0 #13 0x02292258 llvm::PassManager >::run(llvm::Module&, llvm::AnalysisManager&) (build-all-builtins/bin/opt+0x2292258) #14 0x0078d620 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool) (build-all-builtins/bin/opt+0x78d620) #15 0x0079ff05 main (build-all-builtins/bin/opt+0x79ff05) #16 0x7fc5a8208555 __libc_start_main (/lib64/libc.so.6+0x22555) #17 0x0078843c _start (build-all-builtins/bin/opt+0x78843c) Abort This starts happening with commit fff1363ba0ae5 [SCEV] Add false->any implication By definition of Implication operator, `false -> true` and `false -> false`. It means that `false` implies any predicate, no matter true or false. We don't need to go any further trying to prove the statement we need and just always say that `false` implies it in this case. In practice it means that we are trying to prove something guarded by `false` condition, which means that this code is unreachable, and we can safely prove any fact or perform any transform in this code. Differential Revision: https://reviews.llvm.org/D98706 Reviewed By: lebedev.ri --- Comment #1 from Mikael Holmén --- *** Bug 51180 has been marked as a duplicate of this bug. *** --- Comment #2 from listm...@philipreames.com --- This one is tricky and subtle. I'm leaning towards calling this a verifier bug. It's definitely not specific to the triggering patch though. We've proven that the code is unreachable, and any transformation is legal on unreachable code. The transformation being done here *wouldn't* be legal if the loop in question was reachable, but since it's dead, all bets are off. Unfortunately, it's hard to see a small fix for the verifier here. In this case, the fact the loop is unreachable is "obvious", but in general, it could be hidden in an arbitrarily complex way that SCEV happened to understand. So, it's not as simple as trying to restrict the verifier to reachable loops. We could probably mask this particular false positive easily enough, but I don't see a good general solution
[llvm-bugs] [Bug 52320] New: [BranchFolding] Merging blocks with identical PATCHPOINTs
https://bugs.llvm.org/show_bug.cgi?id=52320
Bug ID: 52320
Summary: [BranchFolding] Merging blocks with identical
PATCHPOINTs
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: pauls...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org
Created attachment 25392
--> https://bugs.llvm.org/attachment.cgi?id=25392&action=edit
testcase
I suspect that there is a bug in branch-folding as it merges two different
patchpoints into one:
define void @fun(i32 %Arg) {
%c = icmp eq i32 %Arg, 0
br i1 %c, label %patch0, label %patch1
patch0:
call void (i64, i32, i8*, i32, ...) @llvm.experimental.patchpoint.void(i64 0,
i32 14, i8* null, i32 0)
br label %exit
patch1:
call void (i64, i32, i8*, i32, ...) @llvm.experimental.patchpoint.void(i64 0,
i32 14, i8* null, i32 0)
br label %exit
exit:
ret void
}
declare void @llvm.experimental.patchpoint.void(i64, i32, i8*, i32, ...)
llc -mtriple=s390x-linux-gnu -O3 -o - ./tc_patchpoint_branchfolder.ll
CFG optimizer will see that these are identical and therefore remove the
conditional branch:
# *** IR Dump After Control Flow Optimizer (branch-folder) ***:
bb.0 (%ir-block.0):
STMG killed $r14d, killed $r15d, $r15d, 112
$r15d = AGHI $r15d(tied-def 0), -160, implicit-def dead $cc
CHI killed renamable $r2l, 0, implicit-def $cc
PATCHPOINT 0, 14, 0, 0, 0, , implicit-def dead early-clobber $r0d, implicit-def dead early-clobber
$r1d, implicit-def dead early-clobber $r14d
$r14d, $r15d = LMG $r15d, 272
Return
# End machine code for function fun
IIUC, PATCHPOINTs can not be considered identical as they will be patched
during runtime and therefore are conceptually always different..?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51864] gdb: watchpoint for local variable doesn't work on RISC-V
https://bugs.llvm.org/show_bug.cgi?id=51864 Shivam Gupta changed: What|Removed |Added Resolution|--- |WONTFIX 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52321] New: s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so
https://bugs.llvm.org/show_bug.cgi?id=52321 Bug ID: 52321 Summary: s390x: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so Product: libraries Version: trunk Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: SystemZ Assignee: unassignedb...@nondot.org Reporter: sarah.krie...@opensuse.org CC: llvm-bugs@lists.llvm.org We are building applications with LLVM at openSUSE and receiving these problems with multiple packages, as PostgreSQL and Rust: /usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld: @GLIBCXX_3.4.11: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so /usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld: /usr/lib64/libLLVM.so: error adding symbols: bad value collect2: error: ld returned 1 exit status make[2]: *** [../../../../src/Makefile.shlib:309: llvmjit.so] Error 1 Here, the symbol for which there are TLS and non-TLS references is mentioned, it's '@GLIBCXX_3.4.11'. That is of course not any sensible symbol, it's an empty symbol name with a symbol version, or the symbol version itself interpreted as symbol name. Our guess is that the linker plugin does something strange (aka undefined), either caused by a problem in llvms use of it, or in ld. It manipulates the symbol tables and the above definitely is something strange with the symbol table. There are exactly two TLS references in libLLVM.so.12 23: 0 TLS GLOBAL DEFAULT UND _ZSt11__once_call@GLIBCXX_3.4.11 (16) 29: 0 TLS GLOBAL DEFAULT UND _ZSt15__once_callable@GLIBCXX_3.4.11 (16) so just speculating that the 'ld' error is bogus and the second reference to '/usr/lib64/libLLVM.so' should really be to sth else, like an object from the link command-line as built by g++ -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-stat ement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-al iasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop- truncation -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fPIC -shared -o llvmjit.so llvmj it.o llvmjit_error.o llvmjit_inline.o llvmjit_wrap.o llvmjit_expr.o llvmjit_defo rm.o -L../../../../src/port -L../../../../src/common -flto=auto -ffat-lto-objec ts -L/usr/lib64 -Wl,--as-needed -lLLVM -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52322] New: C++20 warning: template lambda "does not declare any constructor to initialize its non-modifiable members"
https://bugs.llvm.org/show_bug.cgi?id=52322
Bug ID: 52322
Summary: C++20 warning: template lambda "does not declare any
constructor to initialize its non-modifiable members"
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: jake.arkinst...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
In this toy code, clang 13 warns that a lambda function isn't initializing
captured members.
https://godbolt.org/z/hhszT4fqj
I don't know whether (1) this is a false positive warning, (2) the warning is
legitimate and the generated code is incorrect, or (3) the code is truly
invalid and the warning is a side-effect of that.
I'm leaning towards #1. I'd rule #2 out because it still produces the correct
output, and I'd (tentatively) rule #3 out because GCC and MSVC don't see any
problems with the code (Clang 12 segfaults on it, which appears to be a parsing
issue).
> :9:48: warning: class '' does not declare any constructor to
> initialize its non-modifiable members
> TypeList::max(comparison, [&comparison,
> &callback]() {
> ^
> :9:48: note: in instantiation of member class '' requested
> here
>:17:31: note: in instantiation of
> function template specialization 'TypeList::max((lambda at
> :34:9) &, (lambda at :9:48) &&)::(anonymous
> class)::operator()' requested here
>
> callback.template operator()();
> ^
> :9:32: note: in instantiation of function template specialization
> 'TypeList::max<(lambda at :34:9) &, (lambda at :9:48)>'
> requested here
> TypeList::max(comparison, [&comparison,
> &callback]() {
>^
> :9:32: note: in instantiation of function template specialization
> 'TypeList::max<(lambda at :34:9) &, (lambda at
> :9:48)>' requested here
> :33:11: note: in instantiation of function template specialization
> 'TypeList::max<(lambda at :34:9), (lambda at
> :35:9)>' requested here
> list::max(
> ^
> :9:50: note: reference member '' will never be initialized
> TypeList::max(comparison, [&comparison,
> &callback]() {
> ^
> :9:63: note: reference member '' will never be initialized
> TypeList::max(comparison, [&comparison,
> &callback]() {
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35514] brace-init member initializers in function-try-blocks are not formatted correctly
https://bugs.llvm.org/show_bug.cgi?id=35514 MyDeveloperDay changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||db41c0b357d5 Status|CONFIRMED |RESOLVED --- Comment #9 from MyDeveloperDay --- Its fixed in 12,13,14 but not 11 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52323] New: New code-gen options for retpolines and straight line speculation
https://bugs.llvm.org/show_bug.cgi?id=52323
Bug ID: 52323
Summary: New code-gen options for retpolines and straight line
speculation
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: andrew.coop...@citrix.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Hello
[FYI, this is being cross-requested of GCC too]
Linux and other kernel level software makes use of
-mindirect-branch=thunk-extern to be able to alter the handling of indirect
branches at boot. It turns out to be advantageous to inline the thunks when
retpoline is not in use.
https://lore.kernel.org/lkml/20211026120132.613201...@infradead.org/ is some
infrastructure to make this work.
In some cases, we want to be able to inline an `lfence; jmp *%reg` thunk. This
is fine for the low 8 registers, but not fine for %r{8..15} where the REX
prefix pushes the replacement size to being 6 bytes.
It would be very useful to have a code-gen option to write out `call
%cs:__x86_indirect_thunk_r{8..15}` where the redundant %cs prefix will increase
the instruction length to 6, allowing the non-retpoline form to be inlined.
Relatedly, x86 straight line speculation has been discussed before, but without
any action taken. It would be helpful to have a code gen option which would
emit `int3` following any `ret` instruction, and any indirect jump, as neither
of these two cases have following architectural execution.
The reason these two are related is that if both options are in use, we want an
extra byte of replacement space to be able to inline `lfence; jmp *%reg; int3`.
Third Clang has been observed to spot conditional tail calls as `Jcc
__x86_indirect_thunk_*`. This is a 6 byte source size, but needs up to 9 bytes
of space for inlining including an `int3` for straight line speculation reasons
(See https://lore.kernel.org/lkml/20211026120310.359986...@infradead.org/ for
full details). It might be enough to simply prohibit an optimisation like this
when trying to pad retpolines for inlineability.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 40379 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::BuildCXXNestedNameSpecifier
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-10-26 Type: Bug New issue 40379 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::BuildCXXNestedNameSpecifier https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40379 Detailed Report: https://oss-fuzz.com/testcase?key=4755956525826048 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffd8fd9a8c0 Crash State: clang::Sema::BuildCXXNestedNameSpecifier clang::Sema::IsInvalidUnlessNestedName clang::Parser::ParseOptionalCXXScopeSpecifier Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202108020602:202108030618 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4755956525826048 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. 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. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 49478] SEGV dumping AST while mangling declaration for array member of class template
https://bugs.llvm.org/show_bug.cgi?id=49478 Aaron Ballman changed: What|Removed |Added CC||aa...@aaronballman.com Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Aaron Ballman --- This issue appears to have been fixed on trunk. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52260] Dead Code Elimination Regression at -O3 (trunk vs 13.0.0)
https://bugs.llvm.org/show_bug.cgi?id=52260 Sanjay Patel changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||acabad9ff6bf --- Comment #3 from Sanjay Patel --- I plan to extend this: https://reviews.llvm.org/rGacabad9ff6bf ...but that should solve the examples in this report. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52324] New: Add support for custom char8_t types with different name
https://bugs.llvm.org/show_bug.cgi?id=52324 Bug ID: 52324 Summary: Add support for custom char8_t types with different name Product: lldb Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: cont...@lsferreira.net CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org Currently for UTF-16 and UTF-32 types that are recognized by the DWARF encoding tags without `char16_t` and `char32_t` names respectively are recognized, but other names different than `char8_t` are not. To support the same behaviour of the previous encodings, DWARF encoding tags should be taken to consideration before fallback into the type name. Clang TypeSystem recognizes BuiltinType::Char8 when the encoding attribute is present but eFormatUnicode8 format is not returned in that situation, but it should. A patch was submitted to fix this issue: https://reviews.llvm.org/D112564 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52325] New: -Wshadow-uncaptured-local diagnostic is enabled by -Wshadow-all but not -Wshadow-uncaptured-local command line option
https://bugs.llvm.org/show_bug.cgi?id=52325
Bug ID: 52325
Summary: -Wshadow-uncaptured-local diagnostic is enabled by
-Wshadow-all but not -Wshadow-uncaptured-local command
line option
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: cpeter...@mozilla.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Given the following test program:
```
void foo(int a) {
([&](int* a) {
*a = 1;
})(&a);
}
int main() {
return 0;
}
```
Compiling the test program with `clang++ -std=c++17 -Wshadow-all test.cpp`
reports the following warning:
```
a.cpp:2:13: warning: declaration shadows a local variable
[-Wshadow-uncaptured-local]
([&](int* a) {
^
a.cpp:1:14: note: previous declaration is here
void foo(int a) {
^
1 warning generated.
```
But compiling the test program with `clang++ -std=c++17
-Wshadow-uncaptured-local test.cpp` compiles successfully and reports no
warnings.
See similar bug 43667 about the -Wshadow-field-in-constructor command line
option enabling the -Wshadow-field-in-constructor diagnostic.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 52326] New: lld Mach-O backend reports a warning when using DWARF 5
https://bugs.llvm.org/show_bug.cgi?id=52326 Bug ID: 52326 Summary: lld Mach-O backend reports a warning when using DWARF 5 Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: pho...@chromium.org CC: g...@fb.com, jezr...@gmail.com, llvm-bugs@lists.llvm.org, nicolaswe...@gmx.de, smee...@fb.com, v...@google.com You can reproduce it with the following: ``` $ cat >a.c <___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
