[llvm-bugs] [Bug 31514] New: Segfault when evaluating alias template in class template specialization.
https://llvm.org/bugs/show_bug.cgi?id=31514
Bug ID: 31514
Summary: Segfault when evaluating alias template in class
template specialization.
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: e...@efcs.ca
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Reproducer:
// clang++ -std=c++11 test.cpp
template
using EnableTupleSize = T;
template struct tuple_size;
template
struct tuple_size::value)>> {};
template
struct tuple_size::value)>>
{};
struct Tuple;
template <> struct tuple_size { enum { value = 1 };};
int main()
{
tuple_size t;
}
--
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 31515] New: test-suite/MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/cjpeg.execution_time fails for KNL target starting from r289653
https://llvm.org/bugs/show_bug.cgi?id=31515 Bug ID: 31515 Summary: test-suite/MultiSource/Benchmarks/mediabench/jpeg/jpeg -6a/cjpeg.execution_time fails for KNL target starting from r289653 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: elad2.co...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified test-suite/MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/cjpeg.execution_time fails for KNL target. I ran a 'git bisect' and pinned down commit 289653. A diff on the test artifacts after and before the commit shows the following changes in MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/jcdctmgr.s: before: vpandn%ymm0, %ymm1, %ymm0 after: .LCPI2_0: .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 .short1 # 0x1 ... vmovdqa.LCPI2_0(%rip), %ymm9 # ymm9 = [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1] ... vpxor%ymm9, %ymm1, %ymm1 vpand%ymm0, %ymm1, %ymm0 Looks like r289653 creates a XOR with [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1] instead of "allones" in this specific case. I'm working on uploading a fix. -- 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 31516] New: Restore ability to set locale
https://llvm.org/bugs/show_bug.cgi?id=31516 Bug ID: 31516 Summary: Restore ability to set locale Product: libc++ Version: unspecified Hardware: Other OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: compn...@compnerd.org CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified The msvcrt and ucrt split changed the locale information structure and made it opaque. This prevents building libc++ against VC CRT 14+. SVN r280935 temporarily disables the setting of the locale as it needs to indirect through the locale structure type to convert it to a name. Given that it is opaque, we will need to recreate the internal structure declaration to indirect through it of no API exists to query the locale name. -- 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 31517] New: The LoadCombine pass wrongly reorder load and store
https://llvm.org/bugs/show_bug.cgi?id=31517
Bug ID: 31517
Summary: The LoadCombine pass wrongly reorder load and store
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: karl-johan.karls...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 17800
--> https://llvm.org/bugs/attachment.cgi?id=17800&action=edit
opt -S -load-combine -adce -o - loadcombine.ll | FileCheck loadcombine.ll
Input code:
define i16 @bazinga() {
%_tmp9 = getelementptr %rec11, %rec11* @str, i16 0, i32 1
%_tmp10 = load i16, i16* %_tmp9
%_tmp12 = getelementptr %rec11, %rec11* @str, i16 0, i32 0
store i16 %_tmp10, i16* %_tmp12
%_tmp13 = getelementptr %rec11, %rec11* @str, i16 0, i32 0
%_tmp14 = load i16, i16* %_tmp13
%_tmp15 = icmp eq i16 %_tmp14, 3
%_tmp16 = select i1 %_tmp15, i16 1, i16 0
br label %bb1
bb1:
ret i16 %_tmp16
}
The load combiner can not reorder the three memory operations above (load,
store, load) as the first load will load the value from the second location in
the struct, the store will write the loaded value in the first location in the
struct and the last load will load a value from the second location in the
struct.
Output code:
define i16 @bazinga() {
%_tmp14.combined = load i32, i32* bitcast (%rec11* @str to i32*)
%combine.extract.shift = lshr i32 %_tmp14.combined, 16
%combine.extract.trunc1 = trunc i32 %combine.extract.shift to i16
%_tmp12 = getelementptr %rec11, %rec11* @str, i16 0, i32 0
store i16 %combine.extract.trunc1, i16* %_tmp12
%combine.extract.trunc = trunc i32 %_tmp14.combined to i16
%_tmp15 = icmp eq i16 %combine.extract.trunc, 3
%_tmp16 = select i1 %_tmp15, i16 1, i16 0
br label %bb1
bb1:
ret i16 %_tmp16
}
The load combine pass have combined the two loads and thereby reordered the
instructions as the store is done afterwards. Result is that the input value to
the icmp do not get the updated value written by the store.
--
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 31518] New: refactor metadata propagation for consistency and completeness
https://llvm.org/bugs/show_bug.cgi?id=31518 Bug ID: 31518 Summary: refactor metadata propagation for consistency and completeness Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: spatel+l...@rotateright.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified As Davide noted in the post-commit thread for r290844: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170102/416121.html ...we have many implementations/variations for propagating metadata in individual passes. Some of these may require different behavior, but there must be some functionality that can be shared amongst: GVN::patchReplacementInstruction() GVNHoist::combineKnownMetadata() SimplifyCFG::HoistThenElseCodeToIf() BBVectorize::fuseChosenPairs() VectorUtils:propagateMetadata() We have Local.cpp -> llvm::combineMetadataForCSE(). Can it be used in these cases? -- 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 26692] Clang fails to recognize unqualified template template argument in C++11
https://llvm.org/bugs/show_bug.cgi?id=26692
Reid Kleckner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Reid Kleckner ---
This version compiles successfully:
template class> using T = void;
template struct A { using T2 = T<::A>; };
I think we're doing the right thing here. In the original test case, A is the
injected class name, and refers to a class, not a class template. Feel free to
reopen if you don't agree.
--
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 26692] Clang fails to recognize unqualified template template argument in C++11
https://llvm.org/bugs/show_bug.cgi?id=26692 Richard Smith changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #4 from Richard Smith --- This is, sadly, valid. The injected class name of a class template is the one special case that can be used as two different kinds of template argument. -- 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 31519] New: [AArch64] bitreverse does not generate rbit
https://llvm.org/bugs/show_bug.cgi?id=31519 Bug ID: 31519 Summary: [AArch64] bitreverse does not generate rbit Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: AArch64 Assignee: unassignedb...@nondot.org Reporter: bage...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17801 --> https://llvm.org/bugs/attachment.cgi?id=17801&action=edit Test case for bitreverse The intrinsic llvm.bitreverse.iN does not generate the rbit instruction. Test attached. -- 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 31521] New: Profiling support in ORC
https://llvm.org/bugs/show_bug.cgi?id=31521 Bug ID: 31521 Summary: Profiling support in ORC Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: lha...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified We need to be able to profile the performance of JIT'd code. This bug should serve as an umbrella for ORC clients and developers to discuss ORC profiling support. -- 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 31520] New: [guards] canonicalize guards in instcombine
https://llvm.org/bugs/show_bug.cgi?id=31520 Bug ID: 31520 Summary: [guards] canonicalize guards in instcombine Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: listm...@philipreames.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified At the moment, instcombine is missing any knowledge of the llvm.experimental.guard intrinsics. We should implement canonicalization rules similar to those used for instcombine: 1) remove immediately adjacent identical guards 2) guard(a && b) -> guard(a); guard(b); 3) guard(!(a || b)) ->guard(!a) guard(!b); Once those three are done, we could consider implementing a naive form of guard widening as an extension of (1) above. -- 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 31522] New: [guards] Jump threading of guards
https://llvm.org/bugs/show_bug.cgi?id=31522
Bug ID: 31522
Summary: [guards] Jump threading of guards
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: listm...@philipreames.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
JumpThreading should handle guards when the guard can be reorder to the
beginning of the block and the guard condition is known to be true along some
inbound paths.
if (a != null) {
a->f = 5;
}
guard (a != null);
==>
if (a != null) {
a->f = 5;
} else {
guard (a != null);
}
Note that we only need to handle the relatively simple cases. The idea is to
allow better canonicalization before lowering, not to duplicate the entirety of
our optimizations over branches on guards.
--
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 31523] New: [guards] GVN/NewGVN should propagate guard conditions
https://llvm.org/bugs/show_bug.cgi?id=31523 Bug ID: 31523 Summary: [guards] GVN/NewGVN should propagate guard conditions Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: listm...@philipreames.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified GVN currently does not have any handling for the llvm.experimental.guard intrinsics. It does support assumes. We should extend the handling to propagate equalities from guards as well. As a trivial example: guard (a != null); ... guard (a != null); // can be removed Note that we also need to add the same handling to the new memory SSA based NewGVN. -- 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
