[llvm-bugs] [Bug 31132] [inline asm] big IMM numbers doesn'nt compile
https://llvm.org/bugs/show_bug.cgi?id=31132 Coby Tayree changed: What|Removed |Added Status|NEW |RESOLVED CC||coby.tay...@intel.com 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 31006] inline asm multiline comments
https://llvm.org/bugs/show_bug.cgi?id=31006 Coby Tayree changed: What|Removed |Added Status|NEW |RESOLVED CC||coby.tay...@intel.com Resolution|--- |FIXED --- Comment #1 from Coby Tayree --- fixed upon revision 294120 -- 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 31876] New: clang-format removes space between "async" and arrow function
https://llvm.org/bugs/show_bug.cgi?id=31876
Bug ID: 31876
Summary: clang-format removes space between "async" and arrow
function
Product: clang
Version: 4.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: rchlodni...@opera.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
clang-format (with default config) formats this JS code:
const f1 = async () => {};
as:
const f1 = async() => {};
I would rather expect for the space after async keyword not be removed as it
looks confusing (like a function call).
Other context where async can be used is for example class members:
class Foo {
async foo() {}
}
Not really proving anything with this example...
--
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 31877] New: Program crashes when throwing exception under memory sanitizer.
https://llvm.org/bugs/show_bug.cgi?id=31877
Bug ID: 31877
Summary: Program crashes when throwing exception under memory
sanitizer.
Product: libc++abi
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: halya...@chromium.org
CC: k...@google.com, llvm-bugs@lists.llvm.org,
mclow.li...@gmail.com
Classification: Unclassified
The following program crashes with memory sanitizer.
test.cpp:
#include
#include
// Poison parameters shadow.
__attribute__ ((noinline)) void func(int, int, int, int, int, int) {
try {
throw std::exception();
} catch (std::exception& e) {
printf("here\n");
}
}
int main() {
int a, b, c, d, e, f;
func(a, b, c, d, e, f);
}
Compilation:
1. Compile and copy memory-sanitized libc++.so and libc++abi.so to the same
folder as test.cpp.
2. clang++ test.cpp -o test -stdlib=libc++ -L. -Wl,-rpath=. -fsanitize=memory
Output:
./test
==3802==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f51243b3313 in get_thrown_object_ptr
/home/halyavin/other/llvm/projects/libcxxabi/src/cxa_personality.cpp:490:27
#1 0x7f51243b3313 in __cxxabiv1::scan_eh_tab(__cxxabiv1::(anonymous
namespace)::scan_results&, _Unwind_Action, bool, _Unwind_Exception*,
_Unwind_Context*)
/home/halyavin/other/llvm/projects/libcxxabi/src/cxa_personality.cpp:736
#2 0x7f51243b14e5 in __gxx_personality_v0
/home/halyavin/other/llvm/projects/libcxxabi/src/cxa_personality.cpp:951:9
#3 0x7f5124995262 (/lib/x86_64-linux-gnu/libgcc_s.so.1+0x10262)
#4 0x7f51243aff6d in __cxa_throw
/home/halyavin/other/llvm/projects/libcxxabi/src/cxa_exception.cpp:238:5
#5 0x489534 in func(int, int, int, int, int, int)
(/home/halyavin/other/msan-exceptions/test+0x489534)
#6 0x4897f4 in main (/home/halyavin/other/msan-exceptions/test+0x4897f4)
#7 0x7f51245dc82f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#8 0x419c88 in _start (/home/halyavin/other/msan-exceptions/test+0x419c88)
The problem is that libgcc_s.so is not memory sanitized and so it does not
update parameters shadow before calling __gxx_personality_v0 function.
--
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 31878] New: CodeGenPrepare::placeDbgValues moves llvm.dbg.value without proper analysis
https://llvm.org/bugs/show_bug.cgi?id=31878
Bug ID: 31878
Summary: CodeGenPrepare::placeDbgValues moves llvm.dbg.value
without proper analysis
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: mattias.v.eriks...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I think CodeGenPrepare::placeDbgValues moves llvm.dbg.value too much
in this example:
Input to CodeGenPrepare. The interesting part is the last call to
llvm.dbg.value
*** IR Dump Before CodeGen Prepare ***
; Function Attrs: noinline nounwind
define void @move(i16 %from.9.par, i16 %to.10.par, i16 %aux.11.par, i16
%n.12.par, [7 x i16]* nocapture %poles.13.par, i16* nocapture %height.14.par)
local_unnamed_addr #1 !dbg !6 {
tail call void @llvm.dbg.value(metadata i16 %n.12.par, i64 0, metadata !15,
metadata !16), !dbg !17
%_tmp49 = getelementptr i16, i16* %height.14.par, i16 %to.10.par, !dbg !18
%_tmp55 = mul i16 %to.10.par, 7, !dbg !18
%_tmp57 = getelementptr [7 x i16], [7 x i16]* %poles.13.par, i16 0, i16
%_tmp55, !dbg !18
br label %bb0, !dbg !19
bb0: ; preds = %bb2, %0
%n.12.0 = phi i16 [ %n.12.par, %0 ], [ %_tmp64, %bb2 ]
%aux.11.0 = phi i16 [ %aux.11.par, %0 ], [ %from.9.0, %bb2 ]
%from.9.0 = phi i16 [ %from.9.par, %0 ], [ %aux.11.0, %bb2 ]
tail call void @llvm.dbg.value(metadata i16 %n.12.0, i64 0, metadata !15,
metadata !16), !dbg !17
%_tmp59 = icmp sgt i16 %n.12.0, 1, !dbg !20
%_tmp64 = add nsw i16 %n.12.0, -1
br i1 %_tmp59, label %bb1, label %bb2, !dbg !20
bb1: ; preds = %bb0
tail call void @move(i16 %from.9.0, i16 %aux.11.0, i16 %to.10.par, i16
%_tmp64, [7 x i16]* %poles.13.par, i16* %height.14.par), !dbg !21
br label %bb2, !dbg !21
bb2: ; preds = %bb1, %bb0
%_tmp68 = load i16, i16* %_tmp49, align 1, !dbg !23
%_tmp70 = add i16 %_tmp68, 1, !dbg !24
store i16 %_tmp70, i16* %_tmp49, align 1, !dbg !24
%_tmp75 = getelementptr i16, i16* %height.14.par, i16 %from.9.0, !dbg !24
%_tmp77 = load i16, i16* %_tmp75, align 1, !dbg !24
%_tmp78 = add i16 %_tmp77, -1, !dbg !24
store i16 %_tmp78, i16* %_tmp75, align 1, !dbg !24
%_tmp83 = mul i16 %from.9.0, 7, !dbg !24
%_tmp85 = getelementptr [7 x i16], [7 x i16]* %poles.13.par, i16 0, i16
%_tmp83, !dbg !24
%_tmp89 = getelementptr i16, i16* %_tmp85, i16 %_tmp78, !dbg !24
%_tmp90 = load i16, i16* %_tmp89, align 1, !dbg !24
%_tmp94 = getelementptr i16, i16* %_tmp57, i16 %_tmp68, !dbg !24
store i16 %_tmp90, i16* %_tmp94, align 1, !dbg !24
%_tmp9712 = load i16, i16* %_tmp75, align 1, !dbg !25
%_tmp99 = getelementptr i16, i16* %_tmp85, i16 %_tmp9712, !dbg !25
store i16 0, i16* %_tmp99, align 1, !dbg !25
tail call void @show([7 x i16]* %poles.13.par, i16* undef), !dbg !26
;; Here "n" should get the updated value (n = n - 1).
tail call void @llvm.dbg.value(metadata i16 %_tmp64, i64 0, metadata !15,
metadata !16), !dbg !17
%1 = add i16 %_tmp64, 1, !dbg !20
%bb0.termcond = icmp sgt i16 %1, 1, !dbg !20
br i1 %bb0.termcond, label %bb0, label %bb4, !dbg !27
bb4: ; preds = %bb2
ret void, !dbg !28
}
!15 = !DILocalVariable(name: "n", arg: 4, scope: !6, line: 47, type: !9)
And here's the output, note how the last llvm.dbg.value has been moved
to %bb0.
*** IR Dump After CodeGen Prepare ***
; Function Attrs: noinline nounwind
define void @move(i16 %from.9.par, i16 %to.10.par, i16 %aux.11.par, i16
%n.12.par, [7 x i16]* nocapture %poles.13.par, i16* nocapture %height.14.par)
local_unnamed_addr #1 !dbg !6 {
tail call void @llvm.dbg.value(metadata i16 %n.12.par, i64 0, metadata !15,
metadata !16), !dbg !17
%_tmp49 = getelementptr i16, i16* %height.14.par, i16 %to.10.par, !dbg !18
%_tmp55 = mul i16 %to.10.par, 7, !dbg !18
%_tmp57 = getelementptr [7 x i16], [7 x i16]* %poles.13.par, i16 0, i16
%_tmp55, !dbg !18
br label %bb0, !dbg !19
bb0: ; preds = %bb2, %0
%n.12.0 = phi i16 [ %n.12.par, %0 ], [ %_tmp64, %bb2 ]
%aux.11.0 = phi i16 [ %aux.11.par, %0 ], [ %from.9.0, %bb2 ]
%from.9.0 = phi i16 [ %from.9.par, %0 ], [ %aux.11.0, %bb2 ]
tail call void @llvm.dbg.value(metadata i16 %n.12.0, i64 0, metadata !15,
metadata !16), !dbg !17
%_tmp59 = icmp sgt i16 %n.12.0, 1, !dbg !20
%_tmp64 = add nsw i16 %n.12.0, -1
; Now "n" is updated with its new value already in this block.
tail call void @llvm.dbg.value(metadata i16 %_tmp64, i64 0, metadata !15,
metadata !16), !dbg !17
br i1 %_tmp59, label %bb1, label %bb2, !dbg !20
bb1: ; preds = %b
[llvm-bugs] [Bug 31879] New: vectorize repeated scalar ops that don't get put back into a vector
https://llvm.org/bugs/show_bug.cgi?id=31879
Bug ID: 31879
Summary: vectorize repeated scalar ops that don't get put back
into a vector
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
Forking this off from bug 31866:
; For vector , return x0^2 + x1^2
define float @f(<2 x float> %x) {
%x0 = extractelement <2 x float> %x, i32 0
%x1 = extractelement <2 x float> %x, i32 1
%x0x0 = fmul float %x0, %x0
%x1x1 = fmul float %x1, %x1
%add = fadd float %x0x0, %x1x1
ret float %add
}
We should recognize patterns where the same scalar ops are applied to all
extracted elements in a vector and turn that into vector ops followed by
extraction:
define float @f(<2 x float> %x) {
%xx = fmul <2 x float> %x, %x
%x0x0 = extractelement <2 x float> %xx, i32 0
%x1x1 = extractelement <2 x float> %xx, i32 1
%add = fadd float %x0x0, %x1x1
ret float %add
}
The SLP vectorizer already handles the case where we insert back into a vector,
so we can loosen the restriction and use the existing SLP logic to catch this
case?
define <2 x i8> @g(<2 x i8> %x) {
%x0 = extractelement <2 x i8> %x, i32 0
%x1 = extractelement <2 x i8> %x, i32 1
%x0x0 = mul i8 %x0, %x0
%x1x1 = mul i8 %x1, %x1
%ins1 = insertelement <2 x i8> undef, i8 %x0x0, i32 0
%ins2 = insertelement <2 x i8> %ins1, i8 %x1x1, i32 1
ret <2 x i8> %ins2
}
$ ./opt -slp-vectorizer scalarizedmath.ll -S
define <2 x i8> @g(<2 x i8> %x) {
%1 = mul <2 x i8> %x, %x
%2 = extractelement <2 x i8> %1, i32 0
%ret = insertelement <2 x i8> undef, i8 %2, i32 0
%3 = extractelement <2 x i8> %1, i32 1
%ret2 = insertelement <2 x i8> %ret, i8 %3, i32 1
ret <2 x i8> %ret2
}
Instcombine can then clean up the useless inserts and extracts.
--
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 30304] Combination of BreakBeforeBinaryOperators: All, AlignAfterOpenBracket: AlwaysBreak doesn't handling long template parameter list.
https://llvm.org/bugs/show_bug.cgi?id=30304 Daphne Pfister changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Daphne Pfister --- Fixed by r294179 -- 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 31880] New: shuffle and vectorize repeated scalar ops on extracted elements
https://llvm.org/bugs/show_bug.cgi?id=31880
Bug ID: 31880
Summary: shuffle and vectorize repeated scalar ops on extracted
elements
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
Forking this off from the (possibly more specific and less useful) bug 31879
and the motivating (complex numbers) bug 31866:
; For vectors and , return
define <2 x i8> @g(<2 x i8> %x, <2 x i8> %y) {
%x0 = extractelement <2 x i8> %x, i32 0
%y1 = extractelement <2 x i8> %y, i32 1
%x0x0 = mul i8 %x0, %x0
%y1y1 = mul i8 %y1, %y1
%ins1 = insertelement <2 x i8> undef, i8 %x0x0, i32 0
%ins2 = insertelement <2 x i8> %ins1, i8 %y1y1, i32 1
ret <2 x i8> %ins2
}
The canonical IR should be:
define <2 x i8> @h(<2 x i8> %x, <2 x i8> %y) {
%x0y1 = shufflevector <2 x i8> %x, <2 x i8> %y, <2 x i32>
%x0x0y1y1 = mul <2 x i8> %x0y1, %x0y1
ret <2 x i8> %x0x0y1y1
}
This is obviously less instructions and does no extra computational work. Ie,
there are still just two 8-bit multiplies, and we're not operating on unknown
vector elements. Therefore, this is safe even for FP vectors that might contain
perf bombs like denorms because we're still not going to touch them.
The backend will scalarize the vector op if it is not supported to effectively
undo this transform. That should also eliminate the shuffle.
Note that we don't create arbitrary shuffles in IR because it could be
disastrous for the backend, but this is a special case: it's a "blend" (x86
terminology). Ie, we're taking elements from the 2 source vectors without
crossing vector lanes. There's precedent for this type of shuffle because we
canonicalize vector selects to this form:
define <2 x i8> @h(<2 x i8> %x, <2 x i8> %y) {
%x0y1 = select <2 x i1> , <2 x i8> %x, <2 x i8> %y
%mul = mul <2 x i8> %x0y1, %x0y1
ret <2 x i8> %mul
}
$ ./opt -instcombine scalarizedmath.ll -S
define <2 x i8> @h(<2 x i8> %x, <2 x i8> %y) {
%x0y1 = shufflevector <2 x i8> %x, <2 x i8> %y, <2 x i32>
%mul = mul <2 x i8> %x0y1, %x0y1
ret <2 x i8> %mul
}
--
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 31831] clang-cl does not evaluate arguments left-to-right in initializer-list constructor call
https://llvm.org/bugs/show_bug.cgi?id=31831 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- r293732 -- 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 13707] [meta] VCPP compatibility issues
https://llvm.org/bugs/show_bug.cgi?id=13707 Bug 13707 depends on bug 31831, which changed state. Bug 31831 Summary: clang-cl does not evaluate arguments left-to-right in initializer-list constructor call https://llvm.org/bugs/show_bug.cgi?id=31831 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 31881] New: Cherry pick r294088 to 4.0 branch (MachineCopyPropagation fix)
https://llvm.org/bugs/show_bug.cgi?id=31881 Bug ID: 31881 Summary: Cherry pick r294088 to 4.0 branch (MachineCopyPropagation fix) Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17940 --> https://llvm.org/bugs/attachment.cgi?id=17940&action=edit Patch adapted to 4.0 branch r294088 addresses a miscompile in situations with non-coalesced COPY instructions in combination with deeper register hierarchies (ARMv7 neon in this case). The problem was found in swift code but the issue is general. The patch needs to be slightly adapted for the 4.0 branch, I attached a patch. -- 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 31882] New: print a remark when an llvm.assume has a false param
https://llvm.org/bugs/show_bug.cgi?id=31882
Bug ID: 31882
Summary: print a remark when an llvm.assume has a false param
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Filing this based on Daniel's example in:
https://reviews.llvm.org/D29404
declare void @llvm.assume(i1) nounwind
define i32 @assume_false(i32 %p) {
entry:
%cmp = icmp eq i32 %p, 42
call void @llvm.assume(i1 %cmp)
br i1 %cmp, label %bb2, label %bb3
bb2:
%cmp3 = icmp eq i32 %p, 43
call void @llvm.assume(i1 %cmp3)
ret i32 15
bb3:
ret i32 17
}
---
-instsimplify tells us that the 2nd icmp is false via isKnownNonEqual() which
calls computeKnownBits() which calls computeKnownBitsFromAssume():
$ ./opt -instsimplify badass.ll -S
...
declare void @llvm.assume(i1) #0
define i32 @assume_false(i32 %p) {
entry:
%cmp = icmp eq i32 %p, 42
call void @llvm.assume(i1 %cmp)
br i1 %cmp, label %bb2, label %bb3
bb2:
call void @llvm.assume(i1 false) <--- oops...alternative facts!
ret i32 15
bb3:
ret i32 17
}
--
As mentioned in D29404, we can't print a strong warning, but we can at least
print a weasel-worded remark because it's likely that either the program or the
compiler has a bug when a condition that was supposed to be true was proven
false.
--
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 31809] Assertion failed: ((KnownZero & KnownOne) == 0 && "Bits known to be one AND zero?"), function computeKnownBits, file lib/Analysis/ValueTracking.cpp, line 1606.
https://llvm.org/bugs/show_bug.cgi?id=31809 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Sanjay Patel --- Resolving as fixed (although there may now be undefined behavior in the program that gets silently compiled to something unexpected). It should be possible to see a compiler analysis remark for this example after: https://reviews.llvm.org/rL294208 See also related bug 31882. -- 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 31437] Assertion with LTO and debug info when mixing -g and -gmlt
https://llvm.org/bugs/show_bug.cgi?id=31437 Paul Robinson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Paul Robinson --- Fixed with r293818 and r293841. -- 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 31883] New: LICM spends large part of its time computing Alias info
https://llvm.org/bugs/show_bug.cgi?id=31883 Bug ID: 31883 Summary: LICM spends large part of its time computing Alias info Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Keywords: slow-compile Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: dber...@dberlin.org, llvm-bugs@lists.llvm.org, simon.f.whitta...@gmail.com Classification: Unclassified Created attachment 17942 --> https://llvm.org/bugs/attachment.cgi?id=17942&action=edit LTO profile LICM seems to spend 90-95% of its time in AST, which is terribly O(N^2). This slowness is exacerbated on large files or at LTO time. See attachment. -- 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 31884] New: COFF LTO creates object files MSVC cannot read
https://llvm.org/bugs/show_bug.cgi?id=31884 Bug ID: 31884 Summary: COFF LTO creates object files MSVC cannot read Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I tried to link medium size programs with LLD's new command line option, /msvclto. That option does LTO in LLD and then pass resulting object files to MSVC link.exe. When I attempt to link ninja, MSVC link failed with the following error. lld-lto-5b59ce.obj : fatal error LNK1243: invalid or corrupt file: COMDAT section 0x22C associated with following section 0x22F Looks like MSVC cannot handle forward references when reading associated sections. We probably have to emit associated sections first and then references to them next. -- 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 31885] New: Integrated assembler complains moveq is deprecated
https://llvm.org/bugs/show_bug.cgi?id=31885
Bug ID: 31885
Summary: Integrated assembler complains moveq is deprecated
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: manojgu...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
MOV and MVN are in the list of supported IT blocks instructions for ARM
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802b/Cjabicci.html).
However, integrated assembler complains about it.
Minimal repro case:
"""
void test() {
int __res;
__asm__(
"iteq\n"
"moveq %0,%1\n"
: "=r" (__res)
: "i"(-22));
}
"""
clang --target=arm-linux-gnueabihf -march=armv8-a -mthumb -c inline_test.c
inline_test.c:5:8: warning: deprecated instruction in IT block [-Winline-asm]
"moveq %0,%1\n"
^
:2:1: note: instantiated into assembly here
moveq r0,#-22
Interestingly, the actual generated code does not use MOV but rather uses MVN
instead. So it could be the case of MVN instruction incorrectly classified as
unsupported in IT blocks.
- Generated code
.code 16 @ @test
.thumb_func
test:
.fnstart
@ BB#0:
.pad#4
sub sp, #4
@APP
it eq
mvneq r0, #21
--
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 31884] COFF LTO creates object files MSVC cannot read
https://llvm.org/bugs/show_bug.cgi?id=31884 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from David Majnemer --- *** This bug has been marked as a duplicate of bug 24847 *** -- 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 31886] New: in -traditional mode, the preprocessor should only process directives whose '#' appears in column 1
https://llvm.org/bugs/show_bug.cgi?id=31886 Bug ID: 31886 Summary: in -traditional mode, the preprocessor should only process directives whose '#' appears in column 1 Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: froy...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Relaying this bug report on behalf of Zack Weinberg: In -traditional mode, the preprocessor should only process directives whose '#' appears in column 1. For instance, in this fragment ... #ifndef foo #ifdef bar quux #endif #endif ... no tokens survive preprocessing in the standard mode, but the expected output of 'cc -E -traditional' (ignoring blank lines and line number annotations) is #ifdef bar quux #endif clang, however, has a bug in which the nested #endif is *not* ignored, causing the subsequent non-nested #endif to trigger an error: #ifdef bar quux test.c:5:2: error: #endif without #if #endif ^ 1 error generated. This may not just affect #endif: clang preprocesses *this* fragment ... /* this comment is not indented */ #ifdef bar quux #else greeble #endif ... to just 'greeble' and no errors, with or without -traditional. I observe this behavior with both 'clang version 3.8.1-17 (tags/RELEASE_381/final)' and 'clang version 3.9.1-4 (tags/RELEASE_391/rc2)' as supplied by Debian. Another person has reported identical behavior with 'Apple LLVM version 8.0.0 (clang-800.0.42.1)'. -- 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 31887] New: speccpu2000 175.vpr runtime failure when compiled with LLVM -Ofast x86_64
https://llvm.org/bugs/show_bug.cgi?id=31887 Bug ID: 31887 Summary: speccpu2000 175.vpr runtime failure when compiled with LLVM -Ofast x86_64 Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: brzy...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified SPECCPU 2000 175.vpr produces the following runtime error: Error in check_rr_graph: node 2 connects to node 8 2 times. This only happens with the following configuration: x86_64, -Ofast. The test is with the reference run dataset and the command line arguments: ./vpr net.in arch.in place.in route.out -nodisp -route_only -route_chan_width 15 -pres_fac_mult 2 -acc_fac 1 -first_iter_pres_fac 4 -initial_pres_fac 8 This error does not happen on aarch64 with -Ofast. Likewise, other optimization levels -O0, -O1, -O2, -O3 on x86_64 also do not fail. Using -Ofast -fno-fast-math also runs correctly. -- 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 31888] New: assembler ELF .section type defaulted wrong for .bss-like sections not named .bss
https://llvm.org/bugs/show_bug.cgi?id=31888 Bug ID: 31888 Summary: assembler ELF .section type defaulted wrong for .bss-like sections not named .bss Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: MC Assignee: unassignedb...@nondot.org Reporter: rol...@hack.frob.com CC: llvm-bugs@lists.llvm.org, pho...@chromium.org Classification: Unclassified In the GNU assembler, several patterns of section name make the default type be SHT_NOBITS if none was given explicitly in the .section directive. LLVM's assembler does this for .bss and .tbss, but not the others. Test case: .text .data d0:.space 1 .section .bss a:.space 1 .section .bss.foo b:.space 1 .section .bss.bar,"aw" b1:.space 1 .section .tbss c:.space 1 .section .tbss.foo d:.space 1 .section .tbss.bar,"aw" d1:.space 1 .section .gnu.linkonce.b e:.space 1 .section .gnu.linkonce.b.foo f:.space 1 .section .gnu.linkonce.b.bar,"aw" f1:.space 1 With GAS, all of these (except .text and .data) get SHT_NOBITS. The cases with no explicit flags string SHF_ALLOC|SHF_WRITE (as if the flags string were "aw"), and .tbss* also get SHF_TLS (as if the flags string were "awT"). .tbss.bar also gets SHT_TLS set even though T did not appear in the explicit flags string. With LLVM MC, only .bss and .tbss get SHT_NOBITS and only .tbss gets SHT_TLS. The cases with no explicit flags string (except for .bss and .tbss) get no bits set in sh_flags. I can see the case for not adding SHT_TLS when there was an explicit flags string. I won't consider it a continuing bug if the .tbss.bar case fails to add in SHF_TLS. When the flags or type was omitted, people expect to get the defaults based on the section name as GAS does. I'm only looking at the SHT_NOBITS cases here. There are other cases where GAS defines a default type and default flags based on the name. You can see them in bfd/elf.c in the special_sections_* tables. -- 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 31889] New: Cherry pick r294268 to 4.0 branch (RegisterCoalescer: Fix joinReservedPhysReg())
https://llvm.org/bugs/show_bug.cgi?id=31889 Bug ID: 31889 Summary: Cherry pick r294268 to 4.0 branch (RegisterCoalescer: Fix joinReservedPhysReg()) Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: ma...@braunis.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified This fixes a miscompile in the presence of reserved registers. This is not a regression though (the bug was already present in 3.9) however the fix is simple and low risk. -- 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 25670] [Feature] Add a builtin for indexing into parameter packs
https://llvm.org/bugs/show_bug.cgi?id=25670 Louis Dionne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Louis Dionne --- This has been merged, closing this bug. -- 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 24098] Wrong number of template arguments with empty parameter pack
https://llvm.org/bugs/show_bug.cgi?id=24098 Louis Dionne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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] [guards] canonicalize guards in instcombine
https://llvm.org/bugs/show_bug.cgi?id=31520 max.kazant...@azul.com changed: What|Removed |Added Status|NEW |RESOLVED CC||max.kazant...@azul.com Resolution|--- |FIXED --- Comment #1 from max.kazant...@azul.com --- This issue has been resolved with following patches: https://reviews.llvm.org/D29071 https://reviews.llvm.org/D29378 We changed the approach to canonicalization, preferring merging adjacent guards rather than splitting them. This allows us to reduce the size of generated code. -- 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
