[llvm-bugs] [Bug 26914] [AVX512] lowerV4X128VectorShuffle doesn't correctly select input operands
https://llvm.org/bugs/show_bug.cgi?id=26914 igorb changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from igorb --- fixed in r268368 http://reviews.llvm.org/D19803 -- 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 27613] New: Wrong end location for -Winitializer-overrides with overridden initializers
https://llvm.org/bugs/show_bug.cgi?id=27613
Bug ID: 27613
Summary: Wrong end location for -Winitializer-overrides with
overridden initializers
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: chere...@mccme.ru
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Source code:
--
int main()
{
struct s { int x, y; } s1 = { 1, 2 };
struct { struct s sub; int z; } s2 = { .sub = s1, .sub = 3, 4, 5 };
(void)s2;
}
--
Results:
--
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
test.c:4:60: warning: subobject initialization overrides initialization of
other fields within its enclosing subobject [-Winitializer-overrides]
struct { struct s sub; int z; } s2 = { .sub = s1, .sub = 3, 4, 5 };
^
test.c:4:49: note: previous initialization is here
struct { struct s sub; int z; } s2 = { .sub = s1, .sub = 3, 4, 5 };
^~
test.c:4:60: warning: suggest braces around initialization of subobject
[-Wmissing-braces]
struct { struct s sub; int z; } s2 = { .sub = s1, .sub = 3, 4, 5 };
^~~~
{ }
2 warnings generated.
--
clang version: clang version 3.9.0 (trunk 268228)
The first warning underlines "3, 4, 5 }". I think it should underline "3, 4"
only.
--
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 27614] New: Wrong location for -Wmissing-braces for overriding initializers
https://llvm.org/bugs/show_bug.cgi?id=27614
Bug ID: 27614
Summary: Wrong location for -Wmissing-braces for overriding
initializers
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: chere...@mccme.ru
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Source code:
--
int main()
{
struct { struct { int x; } sub; } s = { .sub = { 1 }, .sub = 2 };
(void)s;
}
--
Results:
--
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
test.c:3:65: warning: initializer overrides prior initialization of this
subobject [-Winitializer-overrides]
struct { struct { int x; } sub; } s1 = { .sub = { 1 }, .sub = 2 };
^
test.c:3:53: note: previous initialization is here
struct { struct { int x; } sub; } s1 = { .sub = { 1 }, .sub = 2 };
^
test.c:3:51: warning: suggest braces around initialization of subobject
[-Wmissing-braces]
struct { struct { int x; } sub; } s1 = { .sub = { 1 }, .sub = 2 };
^
{}
test.c:4:51: warning: suggest braces around initialization of subobject
[-Wmissing-braces]
struct { struct { int x; } sub; } s2 = { .sub = 1, .sub = 2 };
^
{}
test.c:4:61: warning: initializer overrides prior initialization of this
subobject [-Winitializer-overrides]
struct { struct { int x; } sub; } s2 = { .sub = 1, .sub = 2 };
^
test.c:4:51: note: previous initialization is here
struct { struct { int x; } sub; } s2 = { .sub = 1, .sub = 2 };
^
test.c:4:51: warning: suggest braces around initialization of subobject
[-Wmissing-braces]
struct { struct { int x; } sub; } s2 = { .sub = 1, .sub = 2 };
^~~
{ }
5 warnings generated.
--
clang version: clang version 3.9.0 (trunk 268228)
I guess the 2nd and 5th warnings intended to warn about missing braces around
"2" only.
--
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 27615] New: SimplifyCFG::isSafeToSpeculateStore produce different result with debug intrinsic
https://llvm.org/bugs/show_bug.cgi?id=27615
Bug ID: 27615
Summary: SimplifyCFG::isSafeToSpeculateStore produce different
result with debug intrinsic
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: henric.karls...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16297
--> https://llvm.org/bugs/attachment.cgi?id=16297&action=edit
Test case that shows diff in output
Depending on if you have @llvm.dbg.value present or not the output from
isSafeToSpeculateStore will in some cases be different.
Right now the method checks a fixed number of instructions back, but those
instructions include the dbg values.
One possible fix could be to just ignore dbg values:
diff --git a/lib/Transforms/Utils/SimplifyCFG.cpp
b/lib/Transforms/Utils/SimplifyCFG.cpp
index 1c27bc6..32b68de 100644
--- a/lib/Transforms/Utils/SimplifyCFG.cpp
+++ b/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -1449,9 +1449,14 @@ static Value *isSafeToSpeculateStore(Instruction *I,
BasicBlock *BrBB,
// Look for a store to the same pointer in BrBB.
unsigned MaxNumInstToLookAt = 10;
for (BasicBlock::reverse_iterator RI = BrBB->rbegin(),
- RE = BrBB->rend(); RI != RE && (--MaxNumInstToLookAt); ++RI) {
+ RE = BrBB->rend(); RI != RE && MaxNumInstToLookAt; ++RI) {
Instruction *CurI = &*RI;
+// Skip debug info.
+if (isa(CurI))
+ continue;
+--MaxNumInstToLookAt;
+
// Could be calling an instruction that effects memory like free().
if (CurI->mayHaveSideEffects() && !isa(CurI))
return nullptr;
--
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 27588] [AVX-512/KNL] Cannot select v16f32 = X86ISD::FMAXC
https://llvm.org/bugs/show_bug.cgi?id=27588 igorb changed: What|Removed |Added Status|NEW |RESOLVED CC||igor.bre...@intel.com Resolution|--- |FIXED --- Comment #1 from igorb --- fixed in r268375 http://reviews.llvm.org/D19860 -- 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 27616] New: clang-format 3.6 vs 3.7
https://llvm.org/bugs/show_bug.cgi?id=27616
Bug ID: 27616
Summary: clang-format 3.6 vs 3.7
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: sbchish...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
Below is an example of a source file test.cpp formatted by both clang-format
versions 3.6 and 3.7. I like the output from 3.6 far better than what I'm
getting from 3.7. Wondering if it's a bug that it's formatted differently in
3.7 or if there is a configuration item that I'm missing to have it behave the
same as 3.6.
$ cat test.cpp
size_t tempYLTFileCount =
Helpers::getFiles(m_pvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic)).size() +
Helpers::getFiles(m_lvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic)).size();
$ clang-format-3.7 -style=google test.cpp
size_t tempYLTFileCount =
Helpers::getFiles(m_pvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic))
.size() +
Helpers::getFiles(m_lvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic))
.size();
$ clang-format-3.6 -style=google test.cpp
size_t tempYLTFileCount =
Helpers::getFiles(m_pvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic)).size()
+
Helpers::getFiles(m_lvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic)).size();
--
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 27617] New: SLPVectorizer asserts in buildtree_rec
https://llvm.org/bugs/show_bug.cgi?id=27617 Bug ID: 27617 Summary: SLPVectorizer asserts in buildtree_rec Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: jesper.antons...@ericsson.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16298 --> https://llvm.org/bugs/attachment.cgi?id=16298&action=edit minimal llvm assembly language file that triggers the assert For the attached ll code example and the invocation: ./build-all/bin/opt -S -mcpu=x86-64 -mtriple=x86_64-linux -indvars -slp-vectorizer -O1 -o /dev/null foo.opt.ll I get this assert: opt: ../lib/Transforms/Vectorize/SLPVectorizer.cpp:1005: void (anonymous namespace)::BoUpSLP::buildTree_rec(ArrayRef, unsigned int): Assertion `SameTy && "Invalid types!"' failed. The problem is that two getelementpointer indicies have differing types. Both have the value 4, but one is of i16 type and one is i64. The recursive call to gather those values fails with an assert because the types differ. The simplest fix might be to change the assert to allow this. Something like this: - bool SameTy = getSameType(VL); (void)SameTy; + bool SameTy = allConstant(VL) || getSameType(VL); (void)SameTy; -- 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 27618] New: vectorization remark is printed multiple times
https://llvm.org/bugs/show_bug.cgi?id=27618
Bug ID: 27618
Summary: vectorization remark is printed multiple times
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: albertnet...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
```
#define SIZE (1 << 15)
#define MINDEX(n, m) (SIZE*(n)+(m))
#define XMM_ALIGNMENT_BYTES 16
float *restrict mat_a __attribute__((aligned (XMM_ALIGNMENT_BYTES)));
float *restrict vec_b __attribute__((aligned (XMM_ALIGNMENT_BYTES)));
float *restrict vec_c __attribute__((aligned (XMM_ALIGNMENT_BYTES)));
// __attribute__ ((noinline))
void matvec_autovec()
{
int i, j;
float tmp;
for (i = 0; i < SIZE; i++) {
tmp = 0;
for (j = 0; j < SIZE; j++) {
tmp += mat_a[MINDEX(i, j)] * vec_b[j];
}
vec_c[i] = tmp;
}
}
void multiple()
{
matvec_autovec();
}
int main(int argc, char **argv)
{
return 0;
}
```
The command I used is `clang-3.8 -Ofast test.c -Rpass=loop-vectorize`
```
test.c:22:9: remark: vectorized loop (vectorization width: 4, interleaved
count: 1) [-Rpass=loop-vectorize]
for (j = 0; j < SIZE; j++) {
^
test.c:22:9: remark: vectorized loop (vectorization width: 4, interleaved
count: 1) [-Rpass=loop-vectorize]
```
The output reduces to 1 after I uncomment the `noinline` attribute.
--
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 27619] New: [x86, loop vectorizer] cost model causes loop to not vectorize
https://llvm.org/bugs/show_bug.cgi?id=27619
Bug ID: 27619
Summary: [x86, loop vectorizer] cost model causes loop to not
vectorize
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Re-filing the example from bug 27078 as a potential x86 cost model bug and/or
loop vectorizer bug. Note that this vectorizes for PPC but not x86 w/ AVX. But
I don't think the vectorization is being done optimally for PPC: no shuffles
should be needed if we treat everything as <12 x float>.
$ ./clang -O2 27078_orig.c -S -o - -emit-llvm -Rpass-analysis=loop-vectorize
-mavx
27078_orig.c:5:30: remark: the cost-model indicates that vectorization is not
beneficial [-Rpass-analysis=loop-vectorize]
float* blurred_pixel = blurred_row[j];
^
27078_orig.c:5:30: remark: the cost-model indicates that interleaving is not
beneficial [-Rpass-analysis=loop-vectorize]
typedef float Vector3_f[3];
void foo(Vector3_f* blurred_row, int width, float* pixel, float pixel_diff_avg)
{
for (int j = 0; j < width; ++j, pixel += 3) {
float* blurred_pixel = blurred_row[j];
float pixel_diff[3];
pixel_diff[0] = blurred_pixel[0] - pixel[0];
pixel_diff[1] = blurred_pixel[1] - pixel[1];
pixel_diff[2] = blurred_pixel[2] - pixel[2];
pixel_diff[0] -= pixel_diff_avg;
pixel_diff[1] -= pixel_diff_avg;
pixel_diff[2] -= pixel_diff_avg;
pixel[0] += pixel_diff[0];
pixel[1] += pixel_diff[1];
pixel[2] += pixel_diff[2];
}
}
--
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] clang-format 3.6 vs 3.7
Below is an example of a source file test.cpp formatted by both
clang-format versions 3.6 and 3.7. I like the output from 3.6 far
better than what I'm getting from 3.7. Wondering if it's a bug that
it's formatted differently in 3.7 or if there is a configuration item
that I'm missing to have it behave the same as 3.6.
$ cat test.cpp
size_t tempYLTFileCount =
Helpers::getFiles(m_pvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic)).size() +
Helpers::getFiles(m_lvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic)).size();
$ clang-format-3.7 -style=google test.cpp
size_t tempYLTFileCount = Helpers::getFiles(m_pvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic))
.size() +
Helpers::getFiles(m_lvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic))
.size();
$ clang-format-3.6 -style=google test.cpp
size_t tempYLTFileCount = Helpers::getFiles(m_pvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic)).size() +
Helpers::getFiles(m_lvSimulatedUnsortedYLTFilePattern,
regex(".*~", regex::basic)).size();
Cheers, Steve
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27522] Inefficient passing of byval parameters
https://llvm.org/bugs/show_bug.cgi?id=27522 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Hans Wennborg --- With r268261 (and r268321), I think this is fixed enough for 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27620] New: O3 pass pipeline does not remove trivial LCSSA node
https://llvm.org/bugs/show_bug.cgi?id=27620
Bug ID: 27620
Summary: O3 pass pipeline does not remove trivial LCSSA node
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: m...@manueljacob.de
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Given this IR:
define i64 @test() {
entry:
br label %loop
loop:
%i = phi i64 [ 0, %entry ], [ %inc, %loop ]
%inc = add i64 %i, 1
%cond = tail call i1 @check()
br i1 %cond, label %loop, label %exit
exit:
ret i64 %i
}
declare i1 @check()
Running opt -S -O3 on it gives the following output:
define i64 @test() {
entry:
br label %loop
loop: ; preds = %loop, %entry
%i = phi i64 [ 0, %entry ], [ %inc, %loop ]
%inc = add i64 %i, 1
%cond = tail call i1 @check()
br i1 %cond, label %loop, label %exit
exit: ; preds = %loop
%i.lcssa = phi i64 [ %i, %loop ]
ret i64 %i.lcssa
}
declare i1 @check()
Here, the LCSSA pass introduces a trivially removable PHI node in the exit
block. However, InstCombine (or a similar pass) isn't run after LCSSA in the
pass pipeline.
--
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 23497] Regression in r233747 - [ExecutionEngine] Fix MCJIT::addGlobalMapping.
https://llvm.org/bugs/show_bug.cgi?id=23497 Lang Hames changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Lang Hames --- Sorry - this one fell through the cracks. We only support adding global mappings for named external and weak symbols. Other globals have values that can't, in general, be overridden via a global mapping. Usually if you're running in to this the solution is just to name the value in question, and bump its linkage to external if necessary. I've added a comment to ExecutionEngine.h in r268415 to clarify this. -- 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 27621] New: [MS] Devirtualizing a method call on the result of a static_cast uses wrong this adjustment
https://llvm.org/bugs/show_bug.cgi?id=27621
Bug ID: 27621
Summary: [MS] Devirtualizing a method call on the result of a
static_cast uses wrong this adjustment
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org
Blocks: 12477
Classification: Unclassified
Consider:
struct A { virtual void f(); };
struct B { virtual void g(); };
struct C final : A, B {
virtual void h();
void g() override;
};
void doit(C *p) {
// Fails to adjust from C* to B* when calling C::g
static_cast(p)->g();
}
The problem is that we pass the wrong CXXMethodDecl to
adjustThisArgumentForVirtualFunctionCall. We pass B::g instead of C::g. B::g
has no 'this' adjustment in its prologue.
The fix is trivial:
diff --git a/lib/CodeGen/CGExprCXX.cpp b/lib/CodeGen/CGExprCXX.cpp
index a90610f..c6f46c3 100644
--- a/lib/CodeGen/CGExprCXX.cpp
+++ b/lib/CodeGen/CGExprCXX.cpp
@@ -274,7 +274,7 @@ RValue
CodeGenFunction::EmitCXXMemberOrOperatorMemberCallExpr(
if (MD->isVirtual()) {
This = CGM.getCXXABI().adjustThisArgumentForVirtualFunctionCall(
-*this, MD, This, UseVirtualCall);
+*this, CalleeDecl, This, UseVirtualCall);
}
return EmitCXXMemberOrOperatorCall(MD, Callee, ReturnValue,
This.getPointer(),
--
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 27621] [MS] Devirtualizing a method call on the result of a static_cast uses wrong this adjustment
https://llvm.org/bugs/show_bug.cgi?id=27621 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Reid Kleckner --- r268418 -- 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 12477] [meta] Support Microsoft C++ ABI
https://llvm.org/bugs/show_bug.cgi?id=12477 Bug 12477 depends on bug 27621, which changed state. Bug 27621 Summary: [MS] Devirtualizing a method call on the result of a static_cast uses wrong this adjustment https://llvm.org/bugs/show_bug.cgi?id=27621 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 27622] New: -Wbackslash-newline-escape printed twice, but only when other warning is present
https://llvm.org/bugs/show_bug.cgi?id=27622 Bug ID: 27622 Summary: -Wbackslash-newline-escape printed twice, but only when other warning is present Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: doug.cole...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The -Wbackslash-newline-escape is printed twice, but only when other warnings are present. Case 1) demonstrates the bug, cases 2) and 3) are each warning/error by themselves, where the warning is not erroneously printed twice. 1) This program demonstrates the bug. Notice that the ``hello.c:1:19`` warning is displayed twice. (There's a space character after the \, not the text [space]) Program``` #include " ^ 3 warnings and 1 error generated. ``` 2) The same program with the correct terminator character only displays the warning once. (No space after the \) Program``` ergmac:~ erg$ cat hello.c #include ``` Output``` ergmac:~ erg$ clang hello.c hello.c:1:19: warning: backslash and newline separated by space [-Wbackslash-newline-escape] #include " ^ 1 warning and 1 error 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 27623] New: r268227 X86::MOV32mr to X86::PUSH64r conversion leads incorrect code
https://llvm.org/bugs/show_bug.cgi?id=27623 Bug ID: 27623 Summary: r268227 X86::MOV32mr to X86::PUSH64r conversion leads incorrect code Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: hjl.to...@gmail.com CC: david.l.kreit...@intel.com, llvm-bugs@lists.llvm.org, zia.ans...@intel.com Classification: Unclassified X86::MOV32mr to X86::PUSH64r conversion in r268227 leads incorrect code. I am trying to find a small testcase. -- 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 27276] global functions in anonymous namespace cause runtime cuda error
https://llvm.org/bugs/show_bug.cgi?id=27276 Artem Belevich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Artem Belevich --- This should be fixed by http://reviews.llvm.org/rL268299 -- 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 27624] New: wrong code at -O3 with -g enabled in 32-bit mode on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=27624
Bug ID: 27624
Summary: wrong code at -O3 with -g enabled in 32-bit mode on
x86_64-linux-gnu
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code is miscompiled by the current trunk at -O3 with debugging
enabled (-g) in the 32-bit mode (but not in the 64-bit mode) on
x86_64-linux-gnu.
This is a regression from 3.8.x.
$ clang-trunk -v
clang version 3.9.0 (trunk 268365)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/tools/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang-trunk -m32 -O3 small.c; ./a.out
0
$ clang-trunk -m32 -O2 -g small.c; ./a.out
0
$ clang-3.8 -m32 -O3 -g small.c; ./a.out
0
$
$ clang-trunk -m32 -O3 -g small.c; ./a.out
1
$
---
int printf (const char *, ...);
int a, b[1], c, d, e, f, g, h, i, j[4843583], k, l, m, n;
unsigned o;
unsigned long long p;
char q;
short r;
void
fn1 (int p1)
{
o = 1 & b[o ^ p1];
}
void
fn2 (long long p1)
{
fn1 (p1 >> 56);
}
void
fn3 (int p1)
{
int s = 0;
r = s = -p1;
h = s >= p1;
if (q)
c = 1;
}
static unsigned
fn4 ()
{
for (i = 0;; i++)
for (; e < 2;)
{
for (d = 1; d; d--)
for (g = 0; g;)
if (q)
l = 0;
for (; m; m++)
for (k = 0; k < 10; k++)
fn2 (j[4843582 + m * k]);
if (q)
break;
n = a + 1;
if (n)
return 1;
for (; f; f++)
for (; q < 5; q++)
;
}
}
static unsigned
fn5 ()
{
fn4 ();
return 0;
}
int
main ()
{
fn3 (p <= (fn5 (), 1));
printf ("%d\n", c);
return 0;
}
--
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 27626] New: [LV] Miscompile of interleaved accesses
https://llvm.org/bugs/show_bug.cgi?id=27626 Bug ID: 27626 Summary: [LV] Miscompile of interleaved accesses Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: mssim...@codeaurora.org CC: llvm-bugs@lists.llvm.org, mcros...@codeaurora.org, silviu.bara...@arm.com Classification: Unclassified Created attachment 16299 --> https://llvm.org/bugs/attachment.cgi?id=16299&action=edit Test case I believe we are miscompiling the attached test case due to a bug in the interleaved access analysis. We are reusing a load when we should not be. I've included the actual and expected IR in the test case. -- 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 27625] New: clang loop vectorizer doesn't work when reduction variable is a slot in an array
https://llvm.org/bugs/show_bug.cgi?id=27625
Bug ID: 27625
Summary: clang loop vectorizer doesn't work when reduction
variable is a slot in an array
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: albertnet...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
```
#define SIZE (1 << 15)
#define XMM_ALIGNMENT_BYTES 16
float *vec_a __attribute__((aligned (XMM_ALIGNMENT_BYTES)));
float *vec_b __attribute__((aligned (XMM_ALIGNMENT_BYTES)));
float *vec_c __attribute__((aligned (XMM_ALIGNMENT_BYTES)));
void matvec_autovec()
{
int i, j;
for (i = 0; i < SIZE; i++) {
for (j = 0; j < SIZE; j++) {
vec_c[i] += vec_a[j] * vec_b[j];
}
}
}
```
Command used: `clang-3.8 -c -S -Ofast -Rpass-analysis=loop-vectorize test.c`
```
test.c:17:22: remark: loop not vectorized: value that could not be identified
as reduction is used outside the loop [-Rpass-analysis=loop-vectorize]
vec_c[i] += vec_a[j] * vec_b[j];```
```
I was expecting that `vec_c[i]` to be treated as inner loop invariant and the
vectorization would work. The auto-vectorization works fine if I use a tmp
variable for accumulation. Could someone explain why the vectorizer bails out
in this case?
--
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 27627] New: [ASan] False positive stack-buffer-underflow with mmap and boost::context
https://llvm.org/bugs/show_bug.cgi?id=27627 Bug ID: 27627 Summary: [ASan] False positive stack-buffer-underflow with mmap and boost::context Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Miscellaneous Instrumentation passes Assignee: unassignedb...@nondot.org Reporter: m...@fb.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16300 --> https://llvm.org/bugs/attachment.cgi?id=16300&action=edit Repro for the described bug For a couple of weeks we've been seeing errors in our ASan-enabled builds that upon closer investigation appear to be false positives. I've spent some time trying to reduce the code to the attached repro, which only depends on the boost context library. In a nutshell, the error triggers when: 1. A stack frame for boost::context is allocated via mmap 2. An actual context switch happens to a function that uses the stack 3. The region is munmap'd after switching back to the main context 4. We mmap a new region that happens to overlap with the previously freed one (in the repro code, this overlap is forced, in the original code it happens randomly) 5. Now, reading from memory inside that region that is close to the stack frame used before for the context switch will trigger the stack-buffer-underflow error The attached repro contains some more details and includes a command line to trigger the FP ASan error. The problem can be reproduced with any recent version of clang (or gcc). Happy to provide more details if needed! -- 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 27629] New: LiveDebugValues missing propagation of debug info across bb boundaries
https://llvm.org/bugs/show_bug.cgi?id=27629
Bug ID: 27629
Summary: LiveDebugValues missing propagation of debug info
across bb boundaries
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: warren_ris...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The test case listed at the end of this comment shows a degradation in
debug-info quality when compiled at '-O1 -g', when moving from llvm 3.7 to
llvm 3.8.
When using llvm 3.7, the variable 'ptr' can be examined at the two lines
with the comment "set a breakpoint here", but with llvm 3.8, 'ptr' is no
longer visible on those lines, because the needed DBG_VALUE instructions
haven't been inserted by the LiveDebugValues pass. (Also tested with modern
TOT, r268454, and the behavior is the same as llvm 3.8.)
In looking at it, I believe the problem is a bug in the data flow analysis
done in the (relatively new) LiveDebugValues pass.
Note that when the LiveDebugValues pass was first committed (r255759), the
debug-quality for 'ptr' was still "good" at '-O1 -g'. The poor visibility
of 'ptr' first appeared in r256188, when a change was made to the related
LiveDebugVariables analysis. Regarding r256188, this was to fix the issue
of bug 24563 (LiveDebugVariables unconditionally propagates all DBG_VALUEs).
In that change, it was noted that with the recent data flow analysis of the
LiveDebugValues pass (which runs after LiveDebugVariables), the propagation
being done by LiveDebugVariables was redundant, and could be removed. I
believe that's the correct approach, but I think there was a latent bug in
the data flow analysis of LiveDebugValues that was exposed when that
propagation was removed from LiveDebugVariables, causing the problem
described here.
/* == "test.c" == */
/* Compile as:
*
* clang -c -O1 -g test.c
*
* and check the visiblilty of 'ptr' in llvm3.7 vs llvm3.8 at lines with
* the 'set a breakpoint here' comment.
*/
struct A {
int i;
float f;
};
extern void foo(struct A *ptr, int lim);
extern int use(int i);
void foo(struct A *ptr, int lim)
{
int i;
for (i = 0; i < lim; ++i) {
if (i > lim/2) {
ptr->i += 2*use(i); // set a breakpoint here, and examine 'ptr'
} else {
ptr->i += use(i); // set a breakpoint here, and examine 'ptr'
}
}
}
/* == */
--
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 27630] New: LLVM generates SIMD instructions on copying a large object which is slow.
https://llvm.org/bugs/show_bug.cgi?id=27630
Bug ID: 27630
Summary: LLVM generates SIMD instructions on copying a large
object which is slow.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: co...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
LLVM generates SSE instructions (on x86 each movaps copies 16 bytes) on copying
a large object for the following code, which underperforms GCC's generated code
in which each mov instruction copies 8 bytes:
struct A {
int a[16];
};
constexpr int N = 1;
A a[N], b[N];
int main() {
for (int j = 0; j < 1000; ++j) {
for (int i = 0; i < N; ++i) {
a[i] = b[i];
}
}
}
Running time (on a Haswell machine):
LLVM: 0.071s
GCC: 0.039s
The performance becomes worse if we don't unroll the loop.
--
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 27631] New: Poor code generation from LLVM.
https://llvm.org/bugs/show_bug.cgi?id=27631
Bug ID: 27631
Summary: Poor code generation from LLVM.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: co...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
LLVM generates very poor code for the following source code:
struct A {
int t[16] = {0};
};
const int N = 1;
A a[N];
void foo() {
for (int i = 0; i < N; ++i) {
a[i] = A();
a[i].t[0] = a[i].t[1] = a[i].t[2] = a[i].t[3] =
a[i].t[4] = a[i].t[5] = a[i].t[6] = a[i].t[7] = i;
}
}
When disabling loop unrolling, the assembly of the loop body generated on x86
is shown below (from clang++ t.C -O2 -fno-unroll-loops -S):
xorps%xmm0, %xmm0
LOOP:
movaps%xmm0, -24(%rsp)
movaps%xmm0, -40(%rsp)
movaps%xmm0, -56(%rsp)
movaps%xmm0, -72(%rsp)
movaps-72(%rsp), %xmm1
movaps-56(%rsp), %xmm2
movaps-40(%rsp), %xmm3
movaps-24(%rsp), %xmm4
movups%xmm4, 48(%rax)
movups%xmm3, 32(%rax)
movups%xmm2, 16(%rax)
movups%xmm1, (%rax)
movd%ecx, %xmm1
pshufd$0, %xmm1, %xmm1# xmm1 = xmm1[0,0,0,0]
movdqa%xmm1, 16(%rax)
movdqa%xmm1, (%rax)
incq%rcx
addq$64, %rax
cmpq$1, %rcx# imm = 0x2710
jne.LBB0_1
Note that how the values in %xmm0 (all zeros) are copied to the stack multiple
times, which are then copied back to other SIMD registers, which are copied to
memory. Furthermore, the first 32 bytes of each object are written twice.
--
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 27593] clang fails to compile intel vulkan driver
https://llvm.org/bugs/show_bug.cgi?id=27593 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Component|-New Bugs |Interprocedural ||Optimizations Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | Product|clang |libraries --- Comment #2 from David Majnemer --- Fixed in r268468. -- 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 27591] Clang crash with KNL target, Assertion `Emitted && "Failed to emit a zext!"' failed
https://llvm.org/bugs/show_bug.cgi?id=27591 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Component|llc |Backend: X86 Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |david.majne...@gmail.com Product|tools |libraries --- Comment #4 from David Majnemer --- Fixed in r268470. -- 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 23362] [AVX512] i1 parameter in function declaration -> UNREACHABLE executed at CallingConvLower.cpp:81!
https://llvm.org/bugs/show_bug.cgi?id=23362 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from David Majnemer --- Seems to work on r268470. -- 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 23363] [AVX512] bitcast assertion hits in SelectionDAG.cpp
https://llvm.org/bugs/show_bug.cgi?id=23363 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from David Majnemer --- Seems to work on r268470. -- 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 27632] New: SLP vectorizer is highly dependent on the operand order
https://llvm.org/bugs/show_bug.cgi?id=27632 Bug ID: 27632 Summary: SLP vectorizer is highly dependent on the operand order Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Keywords: googler, performance Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: daniel...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16302 --> https://llvm.org/bugs/attachment.cgi?id=16302&action=edit loads that cannot be vectorized In the attached IR, the only difference between 1.ll and 2.ll is the order of the add opeands, e.g. 33c33 < %24 = add nsw i32 %23, %15 --- > %24 = add nsw i32 %15, %23 However, this will lead to SLPVectorizer being unable to vectorize the basic block. #opt -slp-vectorizer 1.ll -S |grep load %9 = load i8, i8* %.08.i, align 1 %10 = load i8, i8* %.036.i, align 1 %12 = load i8, i8* %11, align 1 %14 = load i8, i8* %13, align 1 %16 = load i8, i8* %15, align 1 %18 = load i8, i8* %17, align 1 %20 = load i8, i8* %19, align 1 %22 = load i8, i8* %21, align 1 %24 = load i8, i8* %23, align 1 %26 = load i8, i8* %25, align 1 %28 = load i8, i8* %27, align 1 %30 = load i8, i8* %29, align 1 %32 = load i8, i8* %31, align 1 %34 = load i8, i8* %33, align 1 %36 = load i8, i8* %35, align 1 %47 = load i8, i8* %46, align 1 #opt -slp-vectorizer x.ll -S |grep load %23 = load <8 x i8>, <8 x i8>* %22, align 1 %27 = load <8 x i8>, <8 x i8>* %26, align 1 This is because when building the vectorization tree, it uses post-order to traverse the reduction operations, and visits its children in the order of its index. So if the index of the operand change, load will need to be processed in reverse-order, thus cannot be vectorized. Note that the operand could be any order after reassociation pass. Thus it important that SLPVectorizer can handle any operand order. -- 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 27633] New: Spelling fixes within libc++
https://llvm.org/bugs/show_bug.cgi?id=27633 Bug ID: 27633 Summary: Spelling fixes within libc++ Product: libc++ Version: 3.8 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: giffu...@yahoo.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified Created attachment 16304 --> https://llvm.org/bugs/attachment.cgi?id=16304&action=edit Patch with spelling fixes Hello; I am playing with codespell, a pattern matching tool that understands about comments and strings, and it found these common spelling errors in libc++. Handle, with care.. it's untested. -- 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 27634] New: Spelling fixes for lldb
https://llvm.org/bugs/show_bug.cgi?id=27634 Bug ID: 27634 Summary: Spelling fixes for lldb Product: lldb Version: 3.8 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: giffu...@yahoo.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16305 --> https://llvm.org/bugs/attachment.cgi?id=16305&action=edit Patch with spelling fixes Hello; I am playing with codespell, a pattern matching tool that understands about comments and strings, and it found these common spelling errors in lldb. Handle, with care.. it's untested. -- 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 27635] New: Spelling fixes for clang
https://llvm.org/bugs/show_bug.cgi?id=27635 Bug ID: 27635 Summary: Spelling fixes for clang Product: clang Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: giffu...@yahoo.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16306 --> https://llvm.org/bugs/attachment.cgi?id=16306&action=edit Patch with spelling fixes for clang Hello; I am playing with codespell, a pattern matching tool that understands about comments and strings, and it found these common spelling errors in clang. Handle, with care.. it's untested. -- 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 27636] New: General llvm spelling fixes
https://llvm.org/bugs/show_bug.cgi?id=27636 Bug ID: 27636 Summary: General llvm spelling fixes Product: new-bugs Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: giffu...@yahoo.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16307 --> https://llvm.org/bugs/attachment.cgi?id=16307&action=edit patch with llvm spelling fixes Hello; I am playing with codespell, a pattern matching tool that understands about comments and strings, and it found these common spelling errors in lllvm. Handle, with care.. it's untested. -- 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 27570] clang crashes on valid code at -Os and above on x86_64-linux-gnu: Assertion `isLoopInvariant(Operands[i], L) && "SCEVAddRecExpr operand is not loop-invariant!"' failed
https://llvm.org/bugs/show_bug.cgi?id=27570 Sanjoy Das changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Sanjoy Das --- Should be fixed in 268406 -- 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 20678] [AVX512] bitcast and compare of compile-time i1 vector not optimized well
https://llvm.org/bugs/show_bug.cgi?id=20678 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Component|new bugs|Global Analyses Version|unspecified |trunk Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |david.majne...@gmail.com Product|new-bugs|libraries --- Comment #1 from David Majnemer --- Fixed in r268479. -- 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 20723] [AVX512] Cannot select: 0x7fd80b841b68: ch = store when returning <16 x i1> from function
https://llvm.org/bugs/show_bug.cgi?id=20723 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from David Majnemer --- seems to work on r268479. generates the following: _crashEven___: ## @crashEven___ .cfi_startproc ## BB#0:## %allocas vxorps %xmm0, %xmm0, %xmm0 retq .cfi_endproc -- 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 27637] New: creating object of abstract class allowed in all versions of clang++
https://llvm.org/bugs/show_bug.cgi?id=27637
Bug ID: 27637
Summary: creating object of abstract class allowed in all
versions of clang++
Product: clang
Version: 3.8
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: pravasimeet...@yahoo.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 16308
--> https://llvm.org/bugs/attachment.cgi?id=16308&action=edit
bug in clang++
clang++ compiles ill formed C++ program successfully.
The following program is ill formed C++ program because it is not allowed to
create objects of abstract class. But in all versions of g++ the program
compiles successfully.
This question originally asked on stackoverflow by user Matt. See here:
http://stackoverflow.com/questions/37017094/why-do-gcc-and-clang-allow-me-to-construct-an-abstract-class
.
(See live demo here: http://melpon.org/wandbox/permlink/uT43g5lw26HWAbog )
#include
class A
{
public:
A() {
printf("A()\n");
}
virtual void b() const = 0;
};
int main()
{
const A& a{};
a.b();
return 0;
}
The program is clearly invalid & implementation is required to produce a
diagnosis for this according to C++ standard.
--
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
