[llvm-bugs] [Bug 41939] New: Frontend crash due to infinite template recursion
https://bugs.llvm.org/show_bug.cgi?id=41939
Bug ID: 41939
Summary: Frontend crash due to infinite template recursion
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mschwa...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
The following (non-valid) C++ snippet causes clang version 8.0 to crash:
// compiled using clang++ test.cpp
#include
#include
template ::value, int> = 0>
std::ostream& operator<<(std::ostream& o, const C& container){
for(const auto& i : container){
o << i;
o << " ";
}
return o;
}
int main(){
std::vector vec = {1,2,3,4};
std::cout<___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41940] New: textDocument/rename does not work for a more complex file
https://bugs.llvm.org/show_bug.cgi?id=41940
Bug ID: 41940
Summary: textDocument/rename does not work for a more complex
file
Product: clang-tools-extra
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: clangd
Assignee: unassignedclangb...@nondot.org
Reporter: mli...@suse.cz
CC: llvm-bugs@lists.llvm.org
Using trunk@361113, I can't rename 'index' variable in following code snippet:
void
sem_item::add_reference (sem_item *target)
{
refs.safe_push (target);
unsigned index = refs.length ();
target->usages.safe_push (new sem_usage_pair(this, index));
bitmap_set_bit (target->usage_index_bitmap, index);
refs_set.add (target->node);
}
I'm using vim-lsp and for textDocument/references I get:
Mon 20 May 2019 11:23:11 AM CEST:["--->", 3, "clangd", {"method":
"textDocument/references", "on_notification": "---funcref---", "params":
{"context": {"includeDeclaration": false}, "textDocument": {"uri":
"file:///home/marxin/Programming/gcc/gcc/ipa-icf.c"}, "position": {"character":
13, "line": 159}}}]
Mon 20 May 2019 11:23:11 AM CEST:["<---(stderr)", 3, "clangd",
["I[11:23:11.382] <-- textDocument/references(3)", ""]]
Mon 20 May 2019 11:23:11 AM CEST:["<---(stderr)", 3, "clangd",
["I[11:23:11.391] --> reply:textDocument/references(3) 8 ms", ""]]
Mon 20 May 2019 11:23:11 AM CEST:["<---", 3, "clangd", {"response": {"id": 3,
"jsonrpc": "2.0", "result": [{"uri":
"file:///home/marxin/Programming/gcc/gcc/ipa-icf.c", "range": {"end":
{"character": 16, "line": 159}, "start": {"character": 11, "line": 159}}},
{"uri": "file:///home/marxin/Programming/gcc/gcc/ipa-icf.c", "range": {"end":
{"character": 58, "line": 160}, "start": {"character": 53, "line": 160}}},
{"uri": "file:///home/marxin/Programming/gcc/gcc/ipa-icf.c", "range": {"end":
{"character": 51, "line": 161}, "start": {"character": 46, "line": 161}}}]},
"request": {"id": 3, "jsonrpc": "2.0", "method": "textDocument/references",
"params": {"context": {"includeDeclaration": false}, "textDocument": {"uri":
"file:///home/marxin/Programming/gcc/gcc/ipa-icf.c"}, "position": {"character":
13, "line": 159]
That's fine. However rename does not work:
Mon 20 May 2019 11:23:16 AM CEST:["--->", 3, "clangd", {"method":
"textDocument/rename", "on_notification": "---funcref---", "params":
{"newName": "index222", "textDocument": {"uri":
"file:///home/marxin/Programming/gcc/gcc/ipa-icf.c"}, "position": {"character":
13, "line": 159}}}]
Mon 20 May 2019 11:23:16 AM CEST:["<---(stderr)", 3, "clangd",
["I[11:23:16.956] <-- textDocument/rename(4)", ""]]
Mon 20 May 2019 11:23:17 AM CEST:["<---(stderr)", 3, "clangd",
["I[11:23:17.186] --> reply:textDocument/rename(4) 230 ms", ""]]
Mon 20 May 2019 11:23:17 AM CEST:["<---", 3, "clangd", {"response": {"id": 4,
"jsonrpc": "2.0", "result": {"changes":
{"file:///home/marxin/Programming/gcc/gcc/ipa-icf.c": []}}}, "request": {"id":
4, "jsonrpc": "2.0", "method": "textDocument/rename", "params": {"newName":
"index222", "textDocument": {"uri":
"file:///home/marxin/Programming/gcc/gcc/ipa-icf.c"}, "position": {"character":
13, "line": 159]
Changes response is empty.
--
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 9950] regression in trunk...failing make check
https://bugs.llvm.org/show_bug.cgi?id=9950 J. Ryan Stinnett changed: What|Removed |Added Status|NEW |RESOLVED CC||jry...@gmail.com Resolution|--- |INVALID --- Comment #8 from J. Ryan Stinnett --- This issue seems to be about a very specific regression that occurred ~8 years ago, and my assumption is it's no longer valid for today's code, so I think it makes sense to close. Please reopen if I have misunderstood. -- 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 40645] [DebugInfo@O2] EarlyCSE accidentally deletes unused arguments
https://bugs.llvm.org/show_bug.cgi?id=40645 Stephen Tozer changed: What|Removed |Added Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
https://bugs.llvm.org/show_bug.cgi?id=38768 Bug 38768 depends on bug 40645, which changed state. Bug 40645 Summary: [DebugInfo@O2] EarlyCSE accidentally deletes unused arguments https://bugs.llvm.org/show_bug.cgi?id=40645 What|Removed |Added Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41941] New: Merge r360862 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=41941 Bug ID: 41941 Summary: Merge r360862 to the 8.0 branch Product: Runtime Libraries Version: 8.0 Hardware: Other OS: FreeBSD Status: NEW Severity: normal Priority: P Component: libunwind Assignee: unassignedb...@nondot.org Reporter: lup...@freebsd.org CC: llvm-bugs@lists.llvm.org This fixes the 32-bit build of libunwind on PowerPC. This is part of the set of fixes needed to change FreeBSD system compiler to clang8, on PowerPC. -- 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 41942] New: Merge r360861 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=41942 Bug ID: 41942 Summary: Merge r360861 to the 8.0 branch Product: Runtime Libraries Version: 8.0 Hardware: Other OS: FreeBSD Status: NEW Severity: normal Priority: P Component: libunwind Assignee: unassignedb...@nondot.org Reporter: lup...@freebsd.org CC: llvm-bugs@lists.llvm.org This fixes stack unwinding on PowerPC64. This is part of the set of fixes needed to change FreeBSD system compiler to clang8, on PowerPC. -- 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 41943] New: Merge r354184 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=41943 Bug ID: 41943 Summary: Merge r354184 to the 8.0 branch Product: lld Version: unspecified Hardware: Other OS: FreeBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: lup...@freebsd.org CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org This fixes the LocalEntry information of symbols being lost when linking, on PowerPC64. This is part of the set of fixes needed to change FreeBSD system compiler to clang8, on PowerPC. -- 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 40531] TEST 'libomp :: ompt/synchronization/lock.c' FAILED on 32-bit x86
https://bugs.llvm.org/show_bug.cgi?id=40531 Joachim Protze changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Joachim Protze --- Sorry, I missed to push the patch https://reviews.llvm.org/D58506. Just pushed to trunk now. -- 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 31027] thinlto link failure
https://bugs.llvm.org/show_bug.cgi?id=31027 Parag Warudkar changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Parag Warudkar --- (In reply to Eugene Leviant from comment #1) > Most likely build fails for you, because you're using GNU ar built without > LTO plugin. In such cases bitcode archives have no symbol table so there are > link failures. Thanks, that makes sense. Closing as I was able to build with recent clang and thin lto - not sure I used llvm-ar or if build system changed to do that automatically. -- 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 13419 in oss-fuzz: llvm/clang-fuzzer: ASSERT: DeclAccess != AS_none
Updates: Labels: Deadline-Approaching Comment #2 on issue 13419 by sheriff...@chromium.org: llvm/clang-fuzzer: ASSERT: DeclAccess != AS_none https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13419#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 41945] New: Bad continuation indent with return and function chaining
https://bugs.llvm.org/show_bug.cgi?id=41945
Bug ID: 41945
Summary: Bad continuation indent with return and function
chaining
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: dua...@vectorized.io
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
My style produces the following formatting:
int foo1() {
bar(
a,
bbb,
,
d,
e);
return bar(
a,
bbb,
,
d,
e);
}
int foo2() {
bar(
a,
bbb,
,
d,
e)
.baz(x, y);
return bar(
a,
bbb,
,
d,
e)
.baz(x, y);
}
Notice how in foo2(), the last call to "bar" has incorrect continuation
indentation. This happens consistently for functions calls preceded by "return"
and with a chained function call.
.clang-format is:
BasedOnStyle: Mozilla
Language: Cpp
AccessModifierOffset: -4
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortFunctionsOnASingleLine: false
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
BreakBeforeBraces: Attach
ContinuationIndentWidth: 2
Cpp11BracedListStyle: true
FixNamespaceComments: true
IndentCaseLabels: false
IndentWidth: 4
KeepEmptyLinesAtTheStartOfBlocks: false
PenaltyReturnTypeOnItsOwnLine: 60
--
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 41944] New: Rewriter::getRangeSize wrong on Comments
https://bugs.llvm.org/show_bug.cgi?id=41944 Bug ID: 41944 Summary: Rewriter::getRangeSize wrong on Comments Product: clang Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: m_en...@cs.uni-kl.de CC: kli...@google.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk I registered a CommentHandler::HandleComment(Preprocessor & PP, SourceRange Comment) to the preprocessor. When it is called and I ask Rewriter::getRangeSize(Comment, /* any options */) about the size, it is wrong if the comment is followed by another token immediately. Case 1: int x = 5 /* test */ ; Case 2: int y = 5 /* test */; In case 1, everything works fine. In case 2, however, the semicolon is reported within the size, which is caused by the Lexer::MeasureTokenLength call in getRangeSize. So either Rewriter::getRangeSize or Lexer::MeasureTokenLength is messing things up here. Unfortunately I'm not deep enough in the code to narrow it down any further. -- 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 13350 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: getTypeSizeInBits(SrcTy) <= getTypeSizeInBits(Ty) && "getNoopOrZeroExtend cannot
Updates: Labels: Deadline-Approaching Comment #2 on issue 13350 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: getTypeSizeInBits(SrcTy) <= getTypeSizeInBits(Ty) && "getNoopOrZeroExtend cannot https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13350#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 10454] scientific linux not detected
https://bugs.llvm.org/show_bug.cgi?id=10454 J. Ryan Stinnett changed: What|Removed |Added Resolution|--- |WORKSFORME CC||jry...@gmail.com Status|NEW |RESOLVED --- Comment #3 from J. Ryan Stinnett --- I'll assume the last comment back in 2012 is correct and this issue can be closed. -- 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 41946] New: Don't use section name for section start symbol if later symbol exists
https://bugs.llvm.org/show_bug.cgi?id=41946 Bug ID: 41946 Summary: Don't use section name for section start symbol if later symbol exists Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org llvm-objdump currently prints the section name as a symbol label for the first address in a section being disassembled, if there are no other symbols targeting the location. However, GNU objdump prints an expression relative to the first symbol in the section: objdump -d test.o test.o: file format elf64-x86-64 Disassembly of section .text: 1000 : 1000: 90 nop 1001 : 1001: 90 nop llvm-objdump -d test.o test.o: file format ELF64-x86-64 Disassembly of section .text: 1000 .text: 1000: 90nop 1001 sym: 1001: 90nop We should consider doing what GNU does here. The section name is not useful, since it's the same as in the "Disassembly of section" and could be confused with an actual section symbol at that location. -- 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 41679] --dynamic-table reports garbage when not PT_DYNAMIC is present
https://bugs.llvm.org/show_bug.cgi?id=41679 George Rimar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from George Rimar --- I believe r361165 fixes 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41947] New: Dynamic zero-sized and non-function symbols should be included in disassembly
https://bugs.llvm.org/show_bug.cgi?id=41947 Bug ID: 41947 Summary: Dynamic zero-sized and non-function symbols should be included in disassembly Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-objdump Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org For some reason, when adding dynamic symbols to the set of symbols to be used in disassembly, only non-zero-sized function symbols are added. This does not match GNU's behaviour, and is also inconsistent with the static symbol behaviour. We should remove this restriction. It doesn't give us anything. Example output for an object with two dynamic symbols (one non-function, and one zero-sized): objdump.exe -d stripped.o stripped.o: file format elf64-x86-64 Disassembly of section .text: 1000 : 1000: 90 nop 1001 : 1001: 90 llvm-objdump.exe -d stripped.o stripped.o: file format elf64-x86-64 Disassembly of section .text: 1000 .text: 1000: 90 nop 1001: 90 -- 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 41948] New: LLVM toolset for VS 2019 does not exist unless VS 2017 is installed
https://bugs.llvm.org/show_bug.cgi?id=41948 Bug ID: 41948 Summary: LLVM toolset for VS 2019 does not exist unless VS 2017 is installed Product: Packaging Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Windows Installer Assignee: unassignedb...@nondot.org Reporter: greg.bedw...@sony.com CC: llvm-bugs@lists.llvm.org, ztur...@google.com Reported by a team here who are experimenting with building their codebase with clang-cl: """ The bug we observed is: If you install the LLVM Compiler Toolchain Visual Studio extension for VS 2019 on a machine without VS 2017 (or without the VS 2017 extension), the LLVM platform toolset does not exist. You can reproduce this by: * Install the LLVM toolchain and VS 2019 extension on a machine without VS 2017, observe that the LLVM toolset does not appear as an option under Platform Toolset in the IDE. * Install VS 2017, the LLVM toolset is still missing. * Install the LLVM toolchain extension for VS 2017, the LLVM toolset now exists and works. """ -- 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 11121] configure fails if clang is installed
https://bugs.llvm.org/show_bug.cgi?id=11121 J. Ryan Stinnett changed: What|Removed |Added CC||jry...@gmail.com Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from J. Ryan Stinnett --- Since the autotools build has been removed in favor of CMake, I am assuming this no longer applies. Please reopen if I am mistaken. -- 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 11585] trunk doesn't build on linux
https://bugs.llvm.org/show_bug.cgi?id=11585 J. Ryan Stinnett changed: What|Removed |Added CC||jry...@gmail.com Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #7 from J. Ryan Stinnett --- I'm assuming this is no longer valid. Please reopen if I misunderstood. -- 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 11727] Where are the man pages?
https://bugs.llvm.org/show_bug.cgi?id=11727 J. Ryan Stinnett changed: What|Removed |Added CC||jry...@gmail.com Resolution|--- |DUPLICATE Status|REOPENED|RESOLVED --- Comment #5 from J. Ryan Stinnett --- Bug 10050 is now fixed, so let's mark this as a duplicate. *** This bug has been marked as a duplicate of bug 10050 *** -- 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 41949] New: DeadStoreElimination not handling non byte sized stores correctly (miscompile, asserts, etc)
https://bugs.llvm.org/show_bug.cgi?id=41949
Bug ID: 41949
Summary: DeadStoreElimination not handling non byte sized
stores correctly (miscompile, asserts, etc)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: bjorn.a.petters...@ericsson.com
CC: efrie...@quicinc.com, llvm-bugs@lists.llvm.org
A test case like below ends up hitting an assert
opt: ../llvm/include/llvm/ADT/APInt.h:1419: void
llvm::APInt::setBits(unsigned int, unsigned int): Assertion `loBit <= BitWidth
&& "loBit out of range"' failed.
in DeadStoreElimination when handling partial overwrites.
;-
; RUN: opt < %s --data-layout "e" -dse -S | FileCheck --check-prefix CHECK-LE
%s
; RUN: opt < %s --data-layout "E" -dse -S | FileCheck --check-prefix CHECK-BE
%s
define void @test1(i32* %P) {
%A = alloca i32
%B = bitcast i32* %A to i28*
%C = bitcast i32* %A to { i16, i16 }*
%C1 = getelementptr inbounds { i16, i16 }, { i16, i16 }* %C, i32 0, i32 1
store i28 10, i28* %B
store i16 20, i16* %C1
call void @test1(i32* %A)
ret void
}
;-
I got a feeling that DeadStoreElmination doesn't consider cases when "size in
bits" and "store size in bits" differs. opt should probably not assume anything
about the padding bits (or the internal alignment) when storing X bits using a
store size of Y bits, and Y is greater than X.
Some other problems can be observed using test2 that looks like this:
;-
; RUN: opt < %s --data-layout "e" -dse -S | FileCheck --check-prefix CHECK-LE
%s
; RUN: opt < %s --data-layout "E" -dse -S | FileCheck --check-prefix CHECK-BE
%s
define void @test2(i32* %p) {
%u = alloca i32
%a = bitcast i32* %u to i32*
%b = bitcast i32* %u to i12*
store i32 -1, i32* %a
store i12 20, i12* %b
call void @test2(i32* %u)
ret void
}
;-
For @test2 we get a single i32 store like this for little endian
store i32 -4076, i32* %a ; 0xf014
so it does not care about that the i12 store has a 16-bit store size
Looks like bit 12-15 is taken from the first store. Or we at least have a
sitution
where opt is doing assumptions on where the padding bits are (and that it is OK
that they aren't zero).
And for big endian we get a single store like this
store i32 22020095, i32* %a ; 0x014f
which means that the memory will contain
p+0: 0x01
p+1: 0x4f
p+2: 0xff
p+3: 0xff
But normally when doing
store i12 20, p
I believe that we would get
p+0: 0x00
p+1: 0x14
So in this last case we get a miscompile.
--
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 41950] New: LLVM crashed while building xray_trampoline_x86_64 with -gdwarf-5
https://bugs.llvm.org/show_bug.cgi?id=41950 Bug ID: 41950 Summary: LLVM crashed while building xray_trampoline_x86_64 with -gdwarf-5 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: cmt...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21975 --> https://bugs.llvm.org/attachment.cgi?id=21975&action=edit .S file generated by LLVM to go with bug report When building LLVM itself (inside Chrome OS), using LLVM r353983, using -gdwarf-5, LLVM died: /usr/bin/x86_64-pc-linux-gnu-clang -DXRAY_HAS_EXCEPTIONS=1 -DXRAY_SUPPORTED=1 -D_GNU_SOURCE -D__STDC_CO\ NSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/xray -I/var/tmp/portage/sys-de\ vel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/xray -I/usr/include/libxml2 -\ Iinclude -I/var/tmp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/llvm/includ\ e -I/var/tmp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/xr\ ay/.. -I/var/tmp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/li\ b/xray/../../include -O2 -pipe -fno-sanitize=vptr -Wno-backend-plugin -fPIC -fprofile-instr-use=/var/tmp/portage/s\ ys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm.profdata -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-p\ ointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-\ only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti -MD -MT projects/compiler-rt/\ lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_trampoline_x86_64.S.o -MF projects/compiler-rt/lib/xray/CMakeFiles/RTXray\ .x86_64.dir/xray_trampoline_x86_64.S.o.d -o projects/compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_trampoli\ ne_x86_64.S.o -c /var/tmp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compi\ ler-rt/lib/xray/xray_trampoline_x86_64.S FAILED: projects/compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_trampoline_x86_64.S.o /usr/bin/x86_64-pc-linux-gnu-clang -DXRAY_HAS_EXCEPTIONS=1 -DXRAY_SUPPORTED=1 -D_GNU_SOURCE -D__STDC_CONSTANT_MACRO\ S -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/xray -I/var/tmp/portage/sys-devel/llvm-9.0\ _pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/xray -I/usr/include/libxml2 -Iinclude -I/\ var/tmp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/llvm/include -I/var/tmp\ /portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/xray/.. -I/var\ /tmp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/xray/../..\ /include -O2 -pipe -fno-sanitize=vptr -Wno-backend-plugin -fPIC -fprofile-instr-use=/var/tmp/portage/sys-devel/llv\ m-9.0_pre353983_p20190325-r14/work/llvm.profdata -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funw\ ind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gn\ u -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti -MD -MT projects/compiler-rt/lib/xray/CMa\ keFiles/RTXray.x86_64.dir/xray_trampoline_x86_64.S.o -MF projects/compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/\ xray_trampoline_x86_64.S.o.d -o projects/compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_trampoline_x86_64.S.\ o -c /var/tmp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/x\ ray/xray_trampoline_x86_64.S Stack dump: 0. Program arguments: /usr/bin/clang-9 -cc1as -triple x86_64-pc-linux-gnu -filetype obj -main-file-name xray_tr\ ampoline_x86_64.S -target-cpu x86-64 -I projects/compiler-rt/lib/xray -I /var/tmp/portage/sys-devel/llvm-9.0_pre3539\ 83_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/xray -I /usr/include/libxml2 -I include -I /var/t\ mp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/llvm/include -I /var/tmp/por\ tage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/xray/.. -I /var/tm\ p/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p20190325/compiler-rt/lib/xray/../../in\ clude -fdebug-compilation-dir /var/tmp/portage/sys-devel/llvm-9.0_pre353983_p20190325-r14/work/llvm-9.0_pre353983_p2\ 0190325-abi_x86_64.amd64 -dwarf-debug-producer Chromium OS 9.0_pre353983_p20190325-r12 clang version 9.0.0 (/var/cac\ he/chromeos-cache/distfiles/host/egit-src/llvm-
[llvm-bugs] [Bug 34149] Suboptimal codegen for "fast" minnum and maxnum
https://bugs.llvm.org/show_bug.cgi?id=34149 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Sanjay Patel --- I think this: https://reviews.llvm.org/rL331992 ...solved the problem for x86 codegen, so we can close this bug. An IR canonicalization fix is proposed here: https://reviews.llvm.org/D62158 -- 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 41930] shared_ptr requires allocator to have rebind template
https://bugs.llvm.org/show_bug.cgi?id=41930 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED CC||e...@efcs.ca Resolution|--- |INVALID --- Comment #1 from Eric Fiselier --- Yes. The allocator needs to be rebindable according to the spec here: http://eel.is/c++draft/allocator.requirements#3 That doesn't strictly require a rebind template, but it does specify that `IntAllocator` is not allowed in its current state. NAD. -- 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 41951] New: [AArch64] crash in isTRNMask()
https://bugs.llvm.org/show_bug.cgi?id=41951
Bug ID: 41951
Summary: [AArch64] crash in isTRNMask()
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, peter.sm...@linaro.org,
ties.st...@arm.com
define <4 x i32> @widen_shuffles_reduced(<3 x i32> %x, <3 x i32> %y) {
%s3 = shufflevector <3 x i32> %y, <3 x i32> %x, <4 x i32>
ret <4 x i32> %s3
}
Using llc as of r361194:
$ llc -o - shuf.ll -mtriple=aarch64
.text
.file "shuf.ll"
Assertion failed: (Index < Length && "Invalid index!"), function operator[],
file /Users/spatel/GitHub/llvm-project/llvm/include/llvm/ADT/ArrayRef.h, line
240.
Stack dump:
0. Program arguments: ./llc -o - shuf.ll -mtriple=aarch64
1. Running pass 'Function Pass Manager' on module 'shuf.ll'.
2. Running pass 'AArch64 Instruction Selection' on function
'@widen_shuffles_reduced'
0 llc 0x00010948aa58
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 llc 0x000109489948 llvm::sys::RunSignalHandlers() +
248
2 llc 0x00010948b078 SignalHandler(int) + 264
3 libsystem_platform.dylib 0x7fff5c7dfb3d _sigtramp + 29
4 libsystem_platform.dylib 0x7fb92b880810 _sigtramp + 3473542384
5 libsystem_c.dylib0x7fff5c69d1c9 abort + 127
6 libsystem_c.dylib0x7fff5c665868 basename_r + 0
7 llc 0x0001077c2946 isTRNMask(llvm::ArrayRef,
llvm::EVT, unsigned int&) + 230
8 llc 0x0001077c491a
llvm::AArch64TargetLowering::isShuffleMaskLegal(llvm::ArrayRef, llvm::EVT)
const + 362
--
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 41690] SectionMemoryManager assumes allocateMappedMemory to return a size that is a multiple of page size, but it can return much larger memory blocks.
https://bugs.llvm.org/show_bug.cgi?id=41690 Lang Hames changed: What|Removed |Added CC||lha...@gmail.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Lang Hames --- https://reviews.llvm.org/D61599 has been committed as r361195. Thanks Machiel! -- 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 11672] Please provide an soname for libclang
https://bugs.llvm.org/show_bug.cgi?id=11672 J. Ryan Stinnett changed: What|Removed |Added CC||jry...@gmail.com Resolution|--- |WORKSFORME Status|REOPENED|RESOLVED --- Comment #5 from J. Ryan Stinnett --- A local CMake build of libclang 3.4 on Ubuntu appears to have SONAME set (when viewed in `objdump`), so I believe this has been resolved. Please reopen if I have misunderstood. -- 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 11672] Please provide an soname for libclang
https://bugs.llvm.org/show_bug.cgi?id=11672 Sylvestre Ledru changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED --- Comment #6 from Sylvestre Ledru --- Ubuntu (and debian) packages have an soname because I am patching LLVM ;) https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/8/debian/patches/0044-soname.diff https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/8/debian/patches/lldb-soname.diff etc -- 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 41662] llvm.orc.CtorDtorRunner.run - unreachable code
https://bugs.llvm.org/show_bug.cgi?id=41662 Lang Hames changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Lang Hames --- Thanks for the catch Simon! Fixed in r361199. -- 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 41655] Finding Bugs in LLVM 8 with PVS-Studio
https://bugs.llvm.org/show_bug.cgi?id=41655 Bug 41655 depends on bug 41662, which changed state. Bug 41662 Summary: llvm.orc.CtorDtorRunner.run - unreachable code https://bugs.llvm.org/show_bug.cgi?id=41662 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 22612] Add Orc Error Handling
https://bugs.llvm.org/show_bug.cgi?id=22612 Lang Hames changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Lang Hames --- > Are there any particular pieces missing? I don't think so (maybe there is some missing plumbing in ORCv1, but we're deprecating that now anyway). ORCv2 was written from the ground up with llvm::Error and has pretty thorough error plumbing. I'm calling this 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41876] std::hash should not accept std::basic_strings with custom character traits
https://bugs.llvm.org/show_bug.cgi?id=41876 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marshall Clow (home) --- Fixed in revision 361201 -- 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 41952] New: [x86] shiftAmountMod should be more eager?
https://bugs.llvm.org/show_bug.cgi?id=41952
Bug ID: 41952
Summary: [x86] shiftAmountMod should be more eager?
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
unsigned test(unsigned val, unsigned a, unsigned b) {
unsigned shift = (32 - a) - b;
return val << shift;
}
clang produces
mov eax, 32
sub eax, esi
sub eax, edx
shlxeax, edi, eax
icc produces
neg esi # <- yay
sub esi, edx
mov ecx, esi
shl edi, cl
https://godbolt.org/z/gdGx_u
--
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 12373] ../configure --enable-optimized --enable-targets=host-only
https://bugs.llvm.org/show_bug.cgi?id=12373 J. Ryan Stinnett changed: What|Removed |Added Resolution|--- |INVALID CC||jry...@gmail.com Status|NEW |RESOLVED --- Comment #2 from J. Ryan Stinnett --- It seems clear that more info is needed from the reporter, but they never replied ~7 years ago. Please reopen if I have misunderstood. -- 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 12300] out of tree build fails when using --enable-shared
https://bugs.llvm.org/show_bug.cgi?id=12300 J. Ryan Stinnett changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME CC||jry...@gmail.com --- Comment #1 from J. Ryan Stinnett --- I was able to build out-of-tree successfully with -D BUILD_SHARED_LIBS=ON set with the CMake build (which is now the only option). I assume this issue was eventually resolved in the last ~7 years, or perhaps solved by the CMake conversion. Please reopen if I have misunderstood. -- 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 41953] New: Out-of-order Stepping Behavior Introduced for Constant Infinite Loops at O0
https://bugs.llvm.org/show_bug.cgi?id=41953
Bug ID: 41953
Summary: Out-of-order Stepping Behavior Introduced for Constant
Infinite Loops at O0
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: matthew.v...@sony.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This behavior is seen at O0 with debug info enabled. It is observed with
constant infinite 'while' and 'for' loops. For example:
$ nl test.cpp
1 int main(void) {
2int a = 0;
3while (true)
4 ++a;
5return a;
6 }
$
When first stepping into the program the debugger will step to line 4, then
line 3. Under some circumstances this would be acceptable for an infinite loop,
but imagine that the user sets a breakpoint at line 3. If they run the program
and ask for the value of 'a', the debugger will report a value of 1, making it
look as if the debugger has skipped an iteration.
Looking at the IR, the line entry for the top of the loop is now attached to an
unconditional branch at the bottom of the loop body.
$ clang --version | grep version
clang version 9.0.0 (https://github.com/llvm/llvm-project.git f672b6170c...
$ clang -g -S -emit-llvm test.cpp
$ cat test.ll
...
define i32 @main() #0 !dbg !8 {
entry:
...
while.body:
%0 = load i32, i32* %a, align 4, !dbg !16
%inc = add nsw i32 %0, 1, !dbg !16
store i32 %inc, i32* %a, align 4, !dbg !16
br label %while.body, !dbg !17, !llvm.loop !19
}
...
!16 = !DILocation(line: 4, scope: !8)
!17 = !DILocation(line: 3, scope: !18)
...
The leads to the out-of-order stepping behavior seen in the debugger.
--
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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 40722, which changed state. Bug 40722 Summary: callbr is not inlined https://bugs.llvm.org/show_bug.cgi?id=40722 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 40722] callbr is not inlined
https://bugs.llvm.org/show_bug.cgi?id=40722 Nick Desaulniers changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Nick Desaulniers --- Fixed: https://reviews.llvm.org/rL361173 -- 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
