[llvm-bugs] [Bug 21554] clang doesn't apply proper calling conventions when using spir as target
https://llvm.org/bugs/show_bug.cgi?id=21554 Pekka Jääskeläinen changed: What|Removed |Added Status|NEW |RESOLVED CC||pekka.jaaskelai...@tut.fi 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 18119] ToT clang fails to compile a simple opencl kernel
https://llvm.org/bugs/show_bug.cgi?id=18119 Pekka Jääskeläinen changed: What|Removed |Added Status|NEW |RESOLVED CC||pekka.jaaskelai...@tut.fi Resolution|--- |FIXED --- Comment #7 from Pekka Jääskeläinen --- Works nowadays. -- 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 31666] New: Does not output the kernel metadata as specified in SPIR 1.2 specs
https://llvm.org/bugs/show_bug.cgi?id=31666 Bug ID: 31666 Summary: Does not output the kernel metadata as specified in SPIR 1.2 specs Product: clang Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: OpenCL Assignee: unassignedclangb...@nondot.org Reporter: pekka.jaaskelai...@tut.fi CC: llvm-bugs@lists.llvm.org Classification: Unclassified It seems to generate the new style MD even with SPIR target. -- 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 31667] New: inefficient code for i16 bit
https://llvm.org/bugs/show_bug.cgi?id=31667
Bug ID: 31667
Summary: inefficient code for i16 bit
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: asaf.bad...@intel.com
Reporter: asaf.bad...@intel.com
CC: amjad.ab...@intel.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Given:
define i16 @test(i16 %data) {
entry:
%shr1 = lshr i16 %data, 1
%shr1.1 = lshr i16 %data, 3
%ret = sub i16 %shr1.1, %shr1
ret i16 %ret
}
Generated asm:
movl%ecx, %eax
andl$65528, %eax # imm = 0xFFF8
andl$65534, %ecx # imm = 0xFFFE
shrl%ecx
shrl$3, %eax
subl%ecx, %eax
retq
The optimal expected asm:
andl$65535, %eax # imm = 0x
movl%eax, %ecx
shrl%ecx
shrl$3, %eax
subl%ecx, %eax
retq
--
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 31494] [Polly] The generation of the code for index expressions of copy statements in case of the base pointer computed within the SCoP
https://llvm.org/bugs/show_bug.cgi?id=31494 Tobias Grosser changed: 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 31642] variant.visit/visit.pass.cpp hangs when targeting Windows
https://llvm.org/bugs/show_bug.cgi?id=31642 Eric Fiselier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eric Fiselier --- Fixed by mpark. -- 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 31669] New: GlobalISel: Instruction selection failed
https://llvm.org/bugs/show_bug.cgi?id=31669
Bug ID: 31669
Summary: GlobalISel: Instruction selection failed
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: vlesc...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17847
--> https://llvm.org/bugs/attachment.cgi?id=17847&action=edit
Reproduction script and source
When trying to compile simple source (see attached) with GlobalISel enabled it
generates the following error:
fatal error: error in backend: Instruction selection failed
And doesn't fallback to usage of old ISel.
The problematic code:
struct S {
void f() {}
};
S s;
int main() {
s.f();
return 0;
}
This happens once you introduce call of object's non-static method: if you
change f() to static or make it just a global function, error is not
reproduced.
LLVM was build from master: 62b3258a7c27b81ccc83d0e19fa2baf295ec460e,
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292205
--
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 31670] New: redefinition of default argument
https://llvm.org/bugs/show_bug.cgi?id=31670 Bug ID: 31670 Summary: redefinition of default argument Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: vvasi...@cern.ch CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified /Users/vvassilev/workspace/llvm-git/inst/bin/clang -cc1 -triple x86_64-apple-macosx10.11.0 -fsyntax-only -resource-dir /Users/vvassilev/workspace/llvm-git/inst/bin/../lib/clang/4.0.0 -I includes/Users/vvassilev/workspace/root/gui/fitpanel/src/ -I includes/Users/vvassilev/workspace/root_obj_cmake/include -stdlib=libc++ -std=c++11 -fno-autolink -ferror-limit 19 -fmodules -fmodules-cache-path=./mod.cache -fmodule-map-file=includes/Users/vvassilev/workspace/root_obj_cmake/include/module.modulemap -fcxx-exceptions -fexceptions -fmodules-local-submodule-visibility -x c++ TFitEditor.cxx -nostdsysteminc -isystem includes/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/ -isystem includes/usr/include/ -w In file included from TFitEditor.cxx:2: In file included from /Users/vvassilev/workspace/reproducers/PR_default_args_deque/includes/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/queue:1: /Users/vvassilev/workspace/reproducers/PR_default_args_deque/includes/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/deque:5:83: error: redefinition of default argument void copy(typename enable_if<__is_random_access_iterator<_RAIter>::value>::type * = 0); ^ ~ /Users/vvassilev/workspace/reproducers/PR_default_args_deque/includes/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/deque:5:83: note: previous definition is here void copy(typename enable_if<__is_random_access_iterator<_RAIter>::value>::type * = 0); ^ ~ 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 31671] New: [Loop vectorizer] Run-time failures in test-suite with AVX512F
https://llvm.org/bugs/show_bug.cgi?id=31671
Bug ID: 31671
Summary: [Loop vectorizer] Run-time failures in test-suite with
AVX512F
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: elad2.co...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17849
--> https://llvm.org/bugs/attachment.cgi?id=17849&action=edit
test compiled with TOT clang -marh=knl -S -emit-llvm
The tests:
test-suite MultiSource/Benchmarks/TSVC/LoopRerolling-dbl/LoopRerolling-dbl
test-suite MultiSource/Benchmarks/TSVC/LoopRerolling-flt/LoopRerolling-flt
fail in runtime (wrong output) when built with AVX512 (and executed on KNL
target) - specifically the function s351() returns a wrong result.
Initially, it seems that is started failing due to the combination of r290810
and r284779. But these are actually just changes to the cost model and enabling
interleaved memory accesses by default for X86. Bisecting the erroneous
function while compiling with `force-vector-width` and
`enable-interleaved-mem-accesses` seems to lead to r282418.
I've attached the .ll files produced by compiling with -march=knl using TOT
clang VS TOT+revert-r282418.
The C code that contains the diff in IR is:
int s351() {
...
TYPE alpha = c[0];
for (int nl = 0; nl < 8*ntimes; nl++) {
for (int i = 0; i < LEN; i += 5) {
a[i] += alpha * b[i];
a[i + 1] += alpha * b[i + 1];
a[i + 2] += alpha * b[i + 2];
a[i + 3] += alpha * b[i + 3];
a[i + 4] += alpha * b[i + 4];
}
dummy(a, b, c, d, e, aa, bb, cc, 0.);
}
..
check(1);
return 0;
}
Putting aside the fact the the loop wasn't re-rolled, from the diff it looks
like the generated IR is doing something wrong(See that attached files for a
full context):
TOT:
%10 = add <16 x i64> %broadcast.splat,
...
%VectorGep86 = getelementptr inbounds %struct.GlobalData, %struct.GlobalData*
@global_data, i64 0, i32 0, <16 x i64> %10
call void @llvm.masked.scatter.v16f32(<16 x float> %15, <16 x float*>
%VectorGep86
TOT+revert:
%10 = or i64 %offset.idx, 1
%broadcast.splatinsert86 = insertelement <16 x i64> undef, i64 %10, i32 0
%broadcast.splat87 = shufflevector <16 x i64> %broadcast.splatinsert86, <16 x
i64> undef, <16 x i32> zeroinitializer
...
%VectorGep88 = getelementptr inbounds %struct.GlobalData, %struct.GlobalData*
@global_data, i64 0, i32 0, <16 x i64> %broadcast.splat87
call void @llvm.masked.scatter.v16f32(<16 x float> %14, <16 x float*>
%VectorGep88
In the latter it seems that the scatter writes to a splat of the i+1 instead of
--
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 31672] New: Assertion failed: ((TLI.getTypeAction(*DAG.getContext(), Op.getValueType()) == TargetLowering::TypeLegal || TLI.isTypeLegal(Op.getValueType()) || Op.getOpcode() == ISD::Ta
https://llvm.org/bugs/show_bug.cgi?id=31672
Bug ID: 31672
Summary: Assertion failed:
((TLI.getTypeAction(*DAG.getContext(),
Op.getValueType()) == TargetLowering::TypeLegal ||
TLI.isTypeLegal(Op.getValueType()) || Op.getOpcode()
== ISD::TargetConstant) && "Unexpected illegal
type!"), function LegalizeOp
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This assertion has been encountered in https://bugs.freebsd.org/216166, while
compiling gegl on i386. It has been produced since at least trunk r281149, and
still reproduces as of trunk r291476.
Minimized test case in C:
/* clang -cc1 -triple i386 -S -menable-unsafe-fp-math -ffast-math -target-cpu
i486 -target-feature +sse -O2 -w -vectorize-loops -vectorize-slp testcase.c */
x0, x1, x2;
float x3;
x4(float x5) {
float x6 = x0 * x5, x7 = sqrtf(x6);
return x7;
}
x8(int x5, double *x9) {
int x10 = x4(x3 - x5);
*x9 += x10;
}
x11() {
do
x8(x2, &x1);
while (++x2);
}
Minimized and simplified .ll:
; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "bugpoint-output-48ce2a9.bc"
target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128"
target triple = "i386"
@x1 = external global i32, align 4
; Function Attrs: nounwind
define void @x11() local_unnamed_addr #0 {
entry:
%0 = call fast <2 x float> @llvm.sqrt.v2f32(<2 x float> zeroinitializer)
%1 = fptosi <2 x float> %0 to <2 x i32>
%2 = sitofp <2 x i32> %1 to <2 x double>
%3 = fadd fast <2 x double> %2, zeroinitializer
%bin.rdx = fadd fast <2 x double> %3, zeroinitializer
%4 = extractelement <2 x double> %bin.rdx, i32 0
store double %4, double* bitcast (i32* @x1 to double*), align 4, !tbaa !1
ret void
}
; Function Attrs: nounwind readnone
declare <2 x float> @llvm.sqrt.v2f32(<2 x float>) #1
attributes #0 = { nounwind "correctly-rounded-divide-sqrt-fp-math"="false"
"disable-tail-calls"="false" "less-precise-fpmad"="false"
"no-frame-pointer-elim"="false" "no-infs-fp-math"="false"
"no-jump-tables"="false" "no-nans-fp-math"="false"
"no-signed-zeros-fp-math"="false" "no-trapping-math"="false"
"stack-protector-buffer-size"="8" "target-cpu"="i486"
"target-features"="+mmx,+sse,+x87" "unsafe-fp-math"="true"
"use-soft-float"="false" }
attributes #1 = { nounwind readnone }
!llvm.ident = !{!0}
!0 = !{!"FreeBSD clang version 4.0.0 (branches/release_40 292009) (based on
LLVM 4.0.0)"}
!1 = !{!2, !2, i64 0}
!2 = !{!"double", !3, i64 0}
!3 = !{!"omnipotent char", !4, i64 0}
!4 = !{!"Simple C/C++ TBAA"}
--
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 31673] New: Add Python version check to Python bindings
https://llvm.org/bugs/show_bug.cgi?id=31673 Bug ID: 31673 Summary: Add Python version check to Python bindings Product: clang Version: 4.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: jb...@me.com CC: kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified This was resolved in https://reviews.llvm.org/D28682 R292247 and should be merged to the 4.0 release branch. -- 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 27128] PowerPC64: jump tables cause failure during early Linux boot
https://llvm.org/bugs/show_bug.cgi?id=27128 Anton Blanchard changed: 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 31550] Improved "else if" diagnostic
https://llvm.org/bugs/show_bug.cgi?id=31550 Eric Huhtala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Eric Huhtala --- Accidentally double-submitted *** This bug has been marked as a duplicate of bug 31549 *** -- 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 31674] New: ExtractGV externalizes private strings
https://llvm.org/bugs/show_bug.cgi?id=31674
Bug ID: 31674
Summary: ExtractGV externalizes private strings
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: bigchees...@gmail.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Testcase:
$ cat test.ll
@.str.47 = private unnamed_addr constant [10 x i8] c"anonymous\00", align 1
define i32 @patatino(i8* nonnull %myptr) {
%blah = call i32 @strcmp(i8* nonnull %myptr, i8* getelementptr inbounds ([10
x i8], [10 x i8]* @.str.47, i64 0, i64 0))
ret i32 %blah
}
declare i32 @strcmp(i8* nocapture, i8* nocapture) local_unnamed_addr
$ ./llvm-extract patatino.ll -func=patatino -S
; ModuleID = 'patatino.ll'
source_filename = "patatino.ll"
@.str.47 = external hidden unnamed_addr constant [10 x i8], align 1
define i32 @patatino(i8* nonnull %myptr) {
%blah = call i32 @strcmp(i8* nonnull %myptr, i8* getelementptr inbounds ([10
x i8], [10 x i8]* @.str.47, i64 0, i64 0))
ret i32 %blah
}
declare i32 @strcmp(i8* nocapture, i8* nocapture) local_unnamed_addr
In the output, @.str.47 should be extracted (found out while reducing an
optimization bug and moving a given function to its own object file, and
observing a link failure because the private string was internalized and the
linker wasn't able to resolve the symbol).
--
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 31673] Add Python version check to Python bindings
https://llvm.org/bugs/show_bug.cgi?id=31673 Hans Wennborg changed: 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 31622] [meta] 4.0.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=31622 Bug 31622 depends on bug 31673, which changed state. Bug 31673 Summary: Add Python version check to Python bindings https://llvm.org/bugs/show_bug.cgi?id=31673 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 31675] New: clang incorrectly assumes extern addresses cannot be identical
https://llvm.org/bugs/show_bug.cgi?id=31675
Bug ID: 31675
Summary: clang incorrectly assumes extern addresses cannot be
identical
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: bruen...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang seems to assume that extern addresses cannot be identical. If we try to
compare two assembly labels, clang does not bother to emit a comparison and
assumes they are different:
--
#include
extern void * asm_label;
extern void * asm_label2;
int main() {
__asm("asm_label: asm_label2:");
if (&asm_label != &asm_label2)
puts("bug");
else
puts("no bug");
return 0;
}
--
# /usr/bin/clang clangbug.c -o clangbug && ./clangbug
bug
# /usr/bin/gcc clangbug.c -o clangbug && ./clangbug
no bug
Examining the generated code, there is no comparison at all and simply a call
to puts("bug"), even at -O0.
# /usr/bin/clang --version
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
More recent versions of clang have the same behavior, including a recent clang
built from sources at r290297.
Xref https://github.com/DynamoRIO/dynamorio/issues/2124 where a recent
clang (r290297 in fact) extends this problem to static const copies of extern
addresses.
Is there something in the C language spec that allows clang to make this
assumption? This does not seem limited to assembly labels: presumably function
aliases could hit the same problem (certainly it happens if these are not
"extern void *" but rather declared as extern functions which are supplied in a
separately compiled file).
--
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
