[llvm-bugs] [Bug 8035] Injected friend redefinition
https://llvm.org/bugs/show_bug.cgi?id=8035 Serge Pavlov changed: What|Removed |Added Status|NEW |RESOLVED CC||sepavl...@gmail.com Resolution|--- |FIXED --- Comment #2 from Serge Pavlov --- After changes made in r283207 clang successfully compiles and links both the code snippets provided in this PR. -- 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 17923] crash with non-dependent friend defined in uninstantiated class template
https://llvm.org/bugs/show_bug.cgi?id=17923 Serge Pavlov changed: What|Removed |Added Status|NEW |RESOLVED CC||sepavl...@gmail.com Resolution|--- |FIXED --- Comment #3 from Serge Pavlov --- After changes made in r283207 clang successfully compiles both the code snippets provided in this PR. The example from Comment 1 is also successfully built. The example from description can be built if instantiation of `struct X` is added somewhere in the source. -- 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 22307] Template may multiply define friend function
https://llvm.org/bugs/show_bug.cgi?id=22307 Serge Pavlov changed: What|Removed |Added Status|NEW |RESOLVED CC||sepavl...@gmail.com Resolution|--- |FIXED --- Comment #2 from Serge Pavlov --- After changes made in r283207 clang do not segfault anymore. It does report function redefinition because each instantiation of `struct m` introduces friend function definition. gcc also reports similar error. -- 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 25848] Crash with Unhandled DeclRefExpr when using inline friend functions, templates, and member pointers
https://llvm.org/bugs/show_bug.cgi?id=25848 Serge Pavlov changed: What|Removed |Added Status|NEW |RESOLVED CC||sepavl...@gmail.com Resolution|--- |FIXED --- Comment #2 from Serge Pavlov --- After changes made in r283207 clang does not crash anymore. It issues a warning that inline function `g()` is not defined, so cannot be built. Instantiation of `struct R` would provide the definition. -- 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 30623] New: Test 'LLVM :: LTO/X86/symver-asm.ll' failed on Windows after LTO change
https://llvm.org/bugs/show_bug.cgi?id=30623 Bug ID: 30623 Summary: Test 'LLVM :: LTO/X86/symver-asm.ll' failed on Windows after LTO change Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: mehdi.am...@apple.com Reporter: denis.bri...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Test 'LLVM :: LTO/X86/symver-asm.ll' failed on Windows after one of these changes: Change #126308 Changed bymehdi_amini Changed atFri 30 Sep 2016 18:29:54 Repositoryhttp://llvm.org/svn/llvm-project Projectllvm Branchtrunk Revision282997 Comments Use StringRef in LTOModule implementation (NFC) Change #126309 Changed bymehdi_amini Changed atFri 30 Sep 2016 18:29:55 Repositoryhttp://llvm.org/svn/llvm-project Projectllvm Branchtrunk Revision282998 Comments Use StringRef in LTOCodegenerator (NFC) (http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/16028) Test output: TEST 'LLVM :: LTO/X86/symver-asm.ll' FAILED Script: -- D:/buildslave/clang-x64-ninja-win7/stage1/./bin\llvm-as.EXE < D:\buildslave\clang-x64-ninja-win7\llvm\test\LTO\X86\symver-asm.ll >D:\buildslave\clang-x64-ninja-win7\stage1\test\LTO\X86\Output\symver-asm.ll.tmp1 D:/buildslave/clang-x64-ninja-win7/stage1/./bin\llvm-lto.EXE -o D:\buildslave\clang-x64-ninja-win7\stage1\test\LTO\X86\Output\symver-asm.ll.tmp2 D:\buildslave\clang-x64-ninja-win7\stage1\test\LTO\X86\Output\symver-asm.ll.tmp1 D:/buildslave/clang-x64-ninja-win7/stage1/./bin\llvm-nm.EXE D:\buildslave\clang-x64-ninja-win7\stage1\test\LTO\X86\Output\symver-asm.ll.tmp2 | D:/buildslave/clang-x64-ninja-win7/stage1/./bin\FileCheck.EXE D:\buildslave\clang-x64-ninja-win7\llvm\test\LTO\X86\symver-asm.ll -- Exit Code: -2147483645 Command Output (stdout): -- $ "D:/buildslave/clang-x64-ninja-win7/stage1/./bin\llvm-as.EXE" $ "D:/buildslave/clang-x64-ninja-win7/stage1/./bin\llvm-lto.EXE" "-o" "D:\buildslave\clang-x64-ninja-win7\stage1\test\LTO\X86\Output\symver-asm.ll.tmp2" "D:\buildslave\clang-x64-ninja-win7\stage1\test\LTO\X86\Output\symver-asm.ll.tmp1" # command stderr: Assertion failed: isa(Val) && "cast() argument of incompatible type!", file D:\buildslave\clang-x64-ninja-win7\llvm\include\llvm/Support/Casting.h, line 237 #0 0x00013f98f735 (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x3cf735) #1 0x07feee91ee1d (C:\WINDOWS\system32\MSVCR120.dll+0x6ee1d) #2 0x07feee924a14 (C:\WINDOWS\system32\MSVCR120.dll+0x74a14) #3 0x07feee925d5f (C:\WINDOWS\system32\MSVCR120.dll+0x75d5f) #4 0x00013f8c4a19 (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x304a19) #5 0x00013f9078ad (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x3478ad) #6 0x00013f907448 (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x347448) #7 0x00013f9070f3 (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x3470f3) #8 0x00013f909905 (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x349905) #9 0x00013f908e52 (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x348e52) #10 0x00013f90869f (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x34869f) #11 0x00013f5f5b22 (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0x35b22) #12 0x0001402b7f23 (D:\buildslave\clang-x64-ninja-win7\stage1\bin\llvm-lto.EXE+0xcf7f23) #13 0x776659ed (C:\WINDOWS\system32\kernel32.dll+0x159ed) #14 0x7789c541 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x2c541) error: command failed with exit status: -2147483645 -- 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 30440] crash on valid c++ code on x86_64-linux-gnu with -std=c++14 (void {anonymous}::CXXNameMangler::mangleFunctionParam(const clang::ParmVarDecl*): Assertion `parmDepth < FunctionTy
https://llvm.org/bugs/show_bug.cgi?id=30440 arpha...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from arpha...@gmail.com --- Fixed in r283428 (http://llvm.org/viewvc/llvm-project?rev=283428&view=rev) -- 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 30520] clang segfaults on invalid transparent_union declaration
https://llvm.org/bugs/show_bug.cgi?id=30520 arpha...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from arpha...@gmail.com --- Fixed in r283432 (http://llvm.org/viewvc/llvm-project?rev=283432&view=rev) -- 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 30624] New: [META][X86] Avoid lowering C intrinsics calls to target-specific LLVM IR intrinsics
https://llvm.org/bugs/show_bug.cgi?id=30624 Bug ID: 30624 Summary: [META][X86] Avoid lowering C intrinsics calls to target-specific LLVM IR intrinsics Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: zvi.racko...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17408 --> https://llvm.org/bugs/attachment.cgi?id=17408&action=edit List of C intrinsics that are lowered to llvm.x86.* LLVM IR intrinsics This bug is for tracking the effort of lowering all X86 C intrinsics to target-independent LLVM IR, for all cases that it can be done reasonably. The attached CSV file was created by Ayman Musa. It should contain a list of all intrinsics which are lowered to calls to llvm.x86.* intrinsics. The list was created by parsing the Clang tests. All intrinsics that cannot be lowered to a reasonable LLVM-IR code such that the semantics of the original function are easy to identify at Isel, are marked as so. Of the 3142 intrinsics functions that appear in the CSV: - 139 were identified as *can* be lowered to target-independent IR - 55 were identified as *cannot* be lowered to target-independent IR - 2948 are TBD. (Yes, lots of more work ahead of us). -- 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 30625] New: Add test coverage for SelectionDAG::getTargetIndex
https://llvm.org/bugs/show_bug.cgi?id=30625 Bug ID: 30625 Summary: Add test coverage for SelectionDAG::getTargetIndex Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: v...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This function is missing test coverage via check-llvm: SDValue getTargetIndex(int Index, EVT VT, int64_t Offset, unsigned char TargetFlags); See this review for context: https://reviews.llvm.org/D24435 -- 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 28921] Assembly parser breaks on certain comments
https://llvm.org/bugs/show_bug.cgi?id=28921 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Nirav Dave --- Fixed in r283111. -- 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 22028] [MC] X86 intel syntax: push immediate misassembled to a 16 bit push
https://llvm.org/bugs/show_bug.cgi?id=22028 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED CC||nir...@google.com Resolution|--- |FIXED --- Comment #8 from Nirav Dave --- Workaround committed in r283457. -- 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 30626] New: Compiler crash inside SLP Vectorizer ("Use still stuck around after Def is destroyed")
https://llvm.org/bugs/show_bug.cgi?id=30626
Bug ID: 30626
Summary: Compiler crash inside SLP Vectorizer ("Use still stuck
around after Def is destroyed")
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: charles...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17409
--> https://llvm.org/bugs/attachment.cgi?id=17409&action=edit
test case that causes ICE
Hi Everyone,
I have found a compiler crash bug.
Attached are the test case and the crash log.
To reproduce this ICE, compile using the following command.
$ clang -c -ffast-math -fslp-vectorize -O1 -march=btver2 test.cpp
I have triaged the history of this bug.
1. ICE started at commit r253240.
2. ICE went away at commit r258830.
3. ICE resurfaced when commit r258830 was reverted at r278938.
4. As of today, this ICE still exists.
FYI, the Commit Logs for r253240, r258830 and r278938.
$ svn log -r 253240
r253240 | resistor | 2015-11-16 10:07:30 -0800 (Mon, 16 Nov 2015) | 7 lines
Add intermediate subtract instructions to reassociation worklist.
We sometimes create intermediate subtract instructions during
reassociation. Adding these to the worklist to revisit exposes many
additional reassociation opportunities.
Patch by Aditya Nandakumar.
$ svn log -r 258830
r258830 | aditya_nandakumar | 2016-01-26 10:42:36 -0800 (Tue, 26 Jan 2016) | 7
lines
Reassociate: Reprocess RedoInsts after each inst
Previously the RedoInsts was processed at the end of the block.
However it was possible that it left behind some instructions that
were not canonicalized.
This should guarantee that any previous instruction in the basic
block is canonicalized before we process a new instruction.
$ svn log -r 278938
r278938 | mcrosier | 2016-08-17 08:54:39 -0700 (Wed, 17 Aug 2016) | 5 lines
Revert "Reassociate: Reprocess RedoInsts after each inst".
This reverts commit r258830, which introduced a bug described in PR28367.
PR28367
--
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 30627] New: [AArch64] LLVM vectorizer produces erroneous output
https://llvm.org/bugs/show_bug.cgi?id=30627 Bug ID: 30627 Summary: [AArch64] LLVM vectorizer produces erroneous output Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: hxy9...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17413 --> https://llvm.org/bugs/attachment.cgi?id=17413&action=edit IR from reduced cpp code. We noticed ever since patch https://reviews.llvm.org/rL282418, trunk LLVM will produce errorneous output in the vectorized part of the code with flags "-O3 -cl-fast-relaxed-math", with the command listed below: clang --target=aarch64-unknown-linux-gnu -O3 -cl-fast-relaxed-math reduced.O0.strip.ll -emit-llvm -S The erroneous IR is as following: ; :82: ; preds = %82, %77 %83 = phi i64 [ 0, %77 ], [ %188, %82 ] %84 = phi <2 x i64> [ , %77 ], [ %189, %82 ] ... %108 = add nuw nsw <2 x i64> %84, %109 = add <2 x i64> %84, %110 = extractelement <2 x i64> %108, i32 0 %111 = icmp slt i64 %110, %64 %112 = extractelement <2 x i64> %109, i32 0 %113 = icmp slt i64 %112, %64 %114 = insertelement <2 x i1> undef, i1 %111, i32 0 %115 = shufflevector <2 x i1> %114, <2 x i1> undef, <2 x i32> zeroinitializer %116 = insertelement <2 x i1> undef, i1 %113, i32 0 %117 = shufflevector <2 x i1> %116, <2 x i1> undef, <2 x i32> zeroinitializer %118 = select <2 x i1> %115, <2 x i64> %108, <2 x i64> zeroinitializer %119 = select <2 x i1> %117, <2 x i64> %109, <2 x i64> zeroinitializer ... Before the patch, the generated IR should look like the following: %43 = add nuw nsw <2 x i64> %vec.ind, %44 = add <2 x i64> %vec.ind, %45 = icmp slt <2 x i64> %43, %broadcast.splat158 %46 = icmp slt <2 x i64> %44, %broadcast.splat158 %47 = select <2 x i1> %45, <2 x i64> %43, <2 x i64> zeroinitializer %48 = select <2 x i1> %46, <2 x i64> %44, <2 x i64> zeroinitializer Scalar values %111 and %113 are coming from the 1st element of vector %108 and %109. And these are inserted in both lanes of the vectors %115 and %117, which are used in the select statement. Where before the patch the select statements are using values from vector comparisons %43 and %44, and they're using both values in the vectors. For example, %108 is <8, 9>, and %64 is 8. %114 will have the value of the <0, undef> %115 will propagate the 1st value to the 2nd lane, and %115 is <0, 0>, which is used in the select. Before the patch, %43 is <8, 9>, and %broadcast.splat158 is <8, 8>. %45 is <0, 1>, which is used in the select, producing different result. We believe it's the problem in the scalarization part of the pass. As the commit message suggests: [LV] Scalarize instructions marked scalar after vectorization This patch ensures that we actually scalarize instructions marked scalar after vectorization. Previously, such instructions may have been vectorized instead. Differential Revision: https://reviews.llvm.org/D23889 -- 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 30614] [i686, pre-SSE41] vec3 type legalization fails for zero_extend_vector_inreg
https://llvm.org/bugs/show_bug.cgi?id=30614 Pirama Arumuga Nainar changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Pirama Arumuga Nainar --- r283496 -- 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 30628] New: poor unrolling of range-based for loops
https://llvm.org/bugs/show_bug.cgi?id=30628
Bug ID: 30628
Summary: poor unrolling of range-based for loops
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: matthias.t...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
This is not a bug but a suggestion for an improvement. Consider the following
range based for loop:
==
#include
#include
#include
#include
const size_t N = 10;
const unsigned value = 31415926;
template
std::array generateData() {
std::mt19937 randomEngine(0);
std::array data;
std::generate(data.begin(), data.end(), randomEngine);
return data;
}
void testRange() {
auto const data = generateData();
bool result = true;
for (unsigned entry : data) {
if (entry == value) {
result = false;
break;
}
}
assert(result);
}
==
I compiled it with "-std=c++14 -O3" using Clang 3.9. I was expecting the
range-based for loop to be unrolled but this didn't happen. Using "#pragma
unroll 8" before the loop didn't have any effect either.
I was expecting the compiler to essentially generate the same code that it does
for the below two loops, both of which are unrolled automatically 8 times
without the pragma directive.
==
void testManual() {
auto data = generateData();
bool result = true;
for (size_t i = 0; i < N; i++) {
if (data[i] == value) {
result = false;
break;
}
}
assert(result);
}
void testIterator() {
auto data = generateData();
bool result = true;
for (auto itData = data.begin(); itData != data.end(); ++itData) {
if (*itData == value) {
result = false;
break;
}
}
assert(result);
}
==
This has an severe effect on performance as you can see from the below
benchmark:
Benchmark Time CPU Iterations
benchmarkManual33175 ns 33135 ns 21015
benchmarkRange 58488 ns 58370 ns 10771
benchmarkIterator 27077 ns 27045 ns 29426
The benchmark was generated using the Google benchmark library and only the
loops but not the array generation were benchmarked.
--
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 25890] Possibility pass a pointer as an array dimension in new-expr
https://llvm.org/bugs/show_bug.cgi?id=25890 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Smith --- Fixed more comprehensively in r283508. -- 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 30492] On Linux, lldb lit tests fail
https://llvm.org/bugs/show_bug.cgi?id=30492 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Hal Finkel --- (In reply to comment #3) > (In reply to comment #2) > > LGTM as well! > > > > Hal, if you'd like to commit it please go ahead. > > Thanks; will do. lit/Expr/TestCallStopAndContinue.test was fixed in r283082. The lit/lit.cfg debugserver fix committed in r283520. -- 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
