[llvm-bugs] [Bug 25202] unrecognized reloc 23
https://llvm.org/bugs/show_bug.cgi?id=25202 İsmail Dönmez changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from İsmail Dönmez --- Both the crash and unrecognized reloc with -g works with trunk 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 25488] New: [Polly] Preloading code references load inside the region
https://llvm.org/bugs/show_bug.cgi?id=25488 Bug ID: 25488 Summary: [Polly] Preloading code references load inside the region Product: Projects Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Polly Assignee: polly-...@googlegroups.com Reporter: tob...@grosser.es CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15264 --> https://llvm.org/bugs/attachment.cgi?id=15264&action=edit Test case With 252725 polly-opt -polly-codegen -polly-process-unprofitable value-incorrectly-preloaded.ll causes IR verification to fail due to proloading code referencing loads from within the region. -- 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 25489] New: AlignConsecutiveAssignments misbehaves for functions returning references
https://llvm.org/bugs/show_bug.cgi?id=25489
Bug ID: 25489
Summary: AlignConsecutiveAssignments misbehaves for functions
returning references
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
Given functions returning references:
static int a_v = 3;
static int a2_v = 4;
int& a() { return a_v; }
int& a2() { return b_v; }
one can assign through a function call as follows:
a() = 4;
a2() = 5;
clang-format doesn't recognizes that the assignment operator=(..) is being used
here, and thus doesn't align these assignments.
They should probably be aligned to:
a() = 4;
a2() = 5;
--
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 25490] New: [LV] non-deterministic output related to ext/trunc
https://llvm.org/bugs/show_bug.cgi?id=25490
Bug ID: 25490
Summary: [LV] non-deterministic output related to ext/trunc
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: mcros...@codeaurora.org
CC: ane...@apple.com, james.mol...@arm.com,
llvm-bugs@lists.llvm.org, mssim...@codeaurora.org
Classification: Unclassified
Given the below test case I get non-deterministic output from the loop
vectorizer:
void test(unsigned n, unsigned char *a, unsigned char *b, unsigned char *c)
{
for (unsigned i = 0; i < n; ++i) {
int tmp = c[i];
a[i] = (((int)a[i] * ((int)tmp)) >> 8);
b[i] = (((int)b[i] * ((int)tmp)) >> 8);
}
}
Both outputs appear to be correct, but non-determinism is bad in general.
Reproduce with:
clang -S -o test1.ll -O3 --target=aarch64-linux-gnu -mcpu=cortex-a57 test.c
-emit-llvm
Emitting IR seems to work better than emitting assembly.
--
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 25458] [Polly] Timeout during scop construction due to overly complex sets being formed
https://llvm.org/bugs/show_bug.cgi?id=25458 Tobias Grosser changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Grosser --- This has been addressed in r252750. -- 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 25491] New: clang crashes on valid code at -Os and above on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=25491 Bug ID: 25491 Summary: clang crashes on valid code at -Os and above 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 current clang trunk crashes when compiling the following test case on x86_64-linux-gnu at -Os and above in both 32-bit and 64-bit modes. It also affects 3.1 and later (3.1 hangs instead of crashing). It is thus a regression from 3.0. $ clang-trunk -v clang version 3.8.0 (trunk 252640) 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.2 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.1.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.4 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.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.1.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 -O1 -c small.c $ clang-3.0 -Os -c small.c $ $ timeout -s 9 30 clang-3.1 -Os -c small.c Killed $ $ clang-trunk -Os -c small.c clang: /tmp/llvm/lib/CodeGen/ScheduleDAG.cpp:510: void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong topological sorting"' failed. #0 0x03107ec5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang+0x3107ec5) #1 0x03105936 llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang+0x3105936) #2 0x03105b46 (/usr/local/clang-trunk/bin/clang+0x3105b46) #3 0x7f68338f9340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x7f6832894cc9 gsignal /build/buildd/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f68328980d8 abort /build/buildd/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f683288db86 __assert_fail_base /build/buildd/eglibc-2.19/assert/assert.c:92:0 #7 0x7f683288dc32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #8 0x0293c627 llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting() (/usr/local/clang-trunk/bin/clang+0x293c627) #9 0x027317df (/usr/local/clang-trunk/bin/clang+0x27317df) #10 0x026bf5e4 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr/local/clang-trunk/bin/clang+0x26bf5e4) #11 0x026c81ed llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/usr/local/clang-trunk/bin/clang+0x26c81ed) #12 0x026ca03f llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/usr/local/clang-trunk/bin/clang+0x26ca03f) #13 0x02483c54 (/usr/local/clang-trunk/bin/clang+0x2483c54) #14 0x03073aef llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/local/clang-trunk/bin/clang+0x3073aef) #15 0x03073b2b llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x3073b2b) #16 0x030757c7 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang+0x30757c7) #17 0x00bb3548 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_pwrite_stream*) (/usr/local/clang-trunk/bin/clang+0xbb3548) #18 0x00b90c38 (/usr/local/clang-trunk/bin/clang+0xb90c38) #19 0x00df5832 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang+0xdf5832) #20 0x00b93732 clang::CodeGenAction::ExecuteAction() (/usr/local/clang-trunk/bin/clang+0xb93732) #21 0x00980536 clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang+0x980536) #22 0x00955bae clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/local/clang-trunk/bin/clang+0x955bae) #23 0x00936e9c clang::ExecuteCompilerInvocation(clang::C
[llvm-bugs] [Bug 24862] crasher: "auto lol = (__typeof__(auto())*) 2; "
https://llvm.org/bugs/show_bug.cgi?id=24862 zhykzhykz...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||zhykzhykz...@gmail.com Resolution|--- |FIXED --- Comment #2 from zhykzhykz...@gmail.com --- Fixed in r252690. -- 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 17760] Re-introduce Shrink-Wrap for ARM if beneficial
https://llvm.org/bugs/show_bug.cgi?id=17760 Renato Golin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Renato Golin --- Thanks Sanjay! -- 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 25492] New: Incorrect code generated for <3 x half> store.
https://llvm.org/bugs/show_bug.cgi?id=25492
Bug ID: 25492
Summary: Incorrect code generated for <3 x half> store.
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: pir...@google.com
CC: ahmed.bouga...@gmail.com, james.mol...@arm.com,
llvm-bugs@lists.llvm.org, srhi...@google.com
Classification: Unclassified
Consider the following IR:
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n32"
target triple = "armv7---eabihf"
define void @f1(<3 x half>* %arr, i32 %X) #0 {
%XH = sitofp i32 %X to half
%S = fadd half %XH, 0xH4A00
%1 = insertelement <3 x half> undef, half %S, i32 0
%2 = insertelement <3 x half> %1, half %S, i32 1
%3 = insertelement <3 x half> %2, half %S, i32 2
store <3 x half> %3, <3 x half>* %arr, align 8
ret void
}
When compiled using "llc -mtriple=armv7-none-linux-gnueabi -O3 -o half.s
-mattr=+vfp3,+fp16 < half.ll", the code generated is as follows:
f1: @ @f1
.fnstart
@ BB#0:
mov r2, #18944
vmovs2, r1
vmovs0, r2
vcvtb.f32.f16 s0, s0
vcvt.f32.s32s2, s2
vadd.f32s0, s2, s0
vcvtb.f16.f32 s0, s0
vmovr1, s0
orr r2, r1, r1, lsl #16
strhr1, [r0, #4]
vmovd16, r2, r1
vst1.32 {d16[0]}, [r0:32]
bx lr
.Lfunc_end0:
.size f1, .Lfunc_end0-f1
.fnend
The 'orr' instruction ORs r1 with a left-shifted-by-16-bits copy of r1. This
assumes that the top half of r1 is zero, but it need not be. The information
that only the lower 16-bits of r1 are valid and the top 16-bits are not zeroed
doesn't seem to be propagated properly.
--
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 25463] Inlined callsite does not have discriminator emitted
https://llvm.org/bugs/show_bug.cgi?id=25463 Dehao Chen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dehao Chen --- Fixed in http://reviews.llvm.org/D14511 -- 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 25482] Debug info not maintained in AutoFDO
https://llvm.org/bugs/show_bug.cgi?id=25482 Diego Novillo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Diego Novillo --- Fixed with http://llvm.org/viewvc/llvm-project?rev=252763&view=rev -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25493] New: The flag SymbolRef::SF_Export is never set in COFFObjectFile
https://llvm.org/bugs/show_bug.cgi?id=25493 Bug ID: 25493 Summary: The flag SymbolRef::SF_Export is never set in COFFObjectFile Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: sergey.zy...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The flag SymbolRef::SF_Export flag is never set in the COFFObjectFile::getSymbolFlags method. Because Kaleidoscope-Orc expects that its compiled expressions will be exported, in Windows environment it gets null pointer instead of valid symbol reference and crush. -- 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 25494] New: Error block contains invalid memory access
https://llvm.org/bugs/show_bug.cgi?id=25494 Bug ID: 25494 Summary: Error block contains invalid memory access Product: Projects Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Polly Assignee: polly-...@googlegroups.com Reporter: doerf...@cs.uni-saarland.de CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15267 --> https://llvm.org/bugs/attachment.cgi?id=15267&action=edit Testcase The error block %if.else contains an access to i32* null which is not checked in the ScopDetection but will crash the ScopInfo as we try to generate a memory access for it. This is probably another side effect of 27b0d14 similar to 85c7fc. -- 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 25494] Error block contains invalid memory access
https://llvm.org/bugs/show_bug.cgi?id=25494 Tobias Grosser changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Tobias Grosser --- Fixed in r252794 -- 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 25495] New: Inline assembly does not support macro
https://llvm.org/bugs/show_bug.cgi?id=25495
Bug ID: 25495
Summary: Inline assembly does not support macro
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: oliv...@labapart.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
clang does not support assembly macro when defined with inline assembly. GCC
supports it and produce the expected binary.
This use case is actually present in newlib source code
(https://sourceware.org/newlib/).
Source code:
hello.c
asm(".macro COPY\n\t"
"mov r0, r1\n\t"
".endm"
);
int main(void) {
asm ("COPY\n");
return 0;
}
-
Here is the error generated by clang:
$ clang-3.8 -target arm-none-eabi -c hello.c
hello.c:7:8: error: invalid instruction mnemonic 'copy'
asm ("COPY\n");
^
:1:2: note: instantiated into assembly here
COPY
^~~~
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 25496] New: clang++ -pg links with -lc++ instead of -lc++_p
https://llvm.org/bugs/show_bug.cgi?id=25496
Bug ID: 25496
Summary: clang++ -pg links with -lc++ instead of -lc++_p
Product: clang
Version: 3.7
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: yelli...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I'm seeing a link failure when using "clang++ -pg" to link a program.
I first saw the problem on FreeBSD 10.1:
$ clang -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
I was able to reproduce the problem on FreeBSD 11.0-CURRENT:
$ clang -v
FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906
Target: x86_64-unknown-freebsd11.0
Here is a small test script to reproduce the problem:
#!/bin/sh -x
clang++ -pg -o foo -x c++ - -pthread <<\!EOF!
#include
static pthread_mutex_t mutex;
int main(int argc, char **argv) { pthread_mutex_lock(&mutex); return 0; }
!EOF!
The failure looks like this:
+ clang++ -pg -o foo -x c++ - -pthread
/usr/bin/ld: //lib/libgcc_s.so.1: invalid DSO for symbol
`_Unwind_ForcedUnwind@@GCC_3.0' definition
//lib/libgcc_s.so.1: could not read symbols: Bad value
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)
On success, the program compiles and links without any warnings.
If you add -v to the clang++ command line, you can see that it's linking with
-lc++, whereas all the other "system" type libraries that it's linking with
have "_p" tacked onto their names. When I adjusted the driver to use -lc++_p
in this case, the link proceeded without errors. The diff (in the FreeBSD HEAD
tree) looked like this:
Index: contrib/llvm/tools/clang/lib/Driver/ToolChain.cpp
===
--- contrib/llvm/tools/clang/lib/Driver/ToolChain.cpp (revision 290623)
+++ contrib/llvm/tools/clang/lib/Driver/ToolChain.cpp (working copy)
@@ -451,7 +451,11 @@
switch (Type) {
case ToolChain::CST_Libcxx:
-CmdArgs.push_back("-lc++");
+if (Args.hasArg(options::OPT_pg)) {
+ CmdArgs.push_back("-lc++_p");
+} else {
+ CmdArgs.push_back("-lc++");
+}
break;
case ToolChain::CST_Libstdcxx:
I don't claim that this is a comprehensive solution -- there seem to be quite a
few places in the driver that know about "-lc++" -- but it was enough to solve
the problem that I was seeing on FreeBSD.
--
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 25488] [Polly] Preloading code references load inside the region
https://llvm.org/bugs/show_bug.cgi?id=25488 Johannes Doerfert changed: What|Removed |Added Status|NEW |RESOLVED CC||doerf...@cs.uni-saarland.de Resolution|--- |FIXED --- Comment #2 from Johannes Doerfert --- Fixed in r252813. -- 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 25497] New: Using `__builtin_frame_address(-1)` causes infinite loop.
https://llvm.org/bugs/show_bug.cgi?id=25497
Bug ID: 25497
Summary: Using `__builtin_frame_address(-1)` causes infinite
loop.
Product: clang
Version: 3.7
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: richardr...@fb.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15268
--> https://llvm.org/bugs/attachment.cgi?id=15268&action=edit
clang-backtrace
This simple snippet of code:
int main() {
void *x = __builtin_frame_address(-1);
}
Will cause the compiler to run infinitely, or at least until the systems'
memory limit is reached.
Obviously, __builtin_frame_address(-1) is an invalid operation and undefined
behavior, but there should probably be a better reporting mechanism than to
cause the compiler to hang.
Attached is a stack trace as provided by OSX's activity monitor sampler. Also
tested with latest trunk 3.7, unfortunately the precompiled version has no
symbol information.
--
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 25498] New: codegen crash with i256 instructions
https://llvm.org/bugs/show_bug.cgi?id=25498
Bug ID: 25498
Summary: codegen crash with i256 instructions
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Using llc built from r252817:
$ cat scheduler-backtracking.ll
define i256 @foo(i256 %a) {
%b = sub i256 0, %a
%cmpz = icmp eq i256 %b, 0
br i1 %cmpz, label %cond.end, label %cond.false
cond.false:
%d = call i256 @llvm.ctlz.i256(i256 %b, i1 true)
br label %cond.end
cond.end:
%ctz = phi i256 [ 256, %0 ], [ %d, %cond.false ]
ret i256 %ctz
}
declare i256 @llvm.ctlz.i256(i256, i1) nounwind readnone
$ ./llc -o - scheduler-backtracking.ll -pre-RA-sched=linearize -march=x86-64
.section__TEXT,__text,regular,pure_instructions
.macosx_version_min 15, 0
.syntax unified
Assertion failed: (isImm() && "Wrong MachineOperand accessor"), function
getImm, file /Users/spatel/myllvm/llvm/include/llvm/CodeGen/MachineOperand.h,
line 411.
0 llc 0x00010381c51e
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
1 llc 0x00010381c969
PrintStackTraceSignalHandler(void*) + 25
2 llc 0x000103819109 llvm::sys::RunSignalHandlers() +
425
3 llc 0x00010381cca9 SignalHandler(int) + 345
4 libsystem_platform.dylib 0x7fff9924352a _sigtramp + 26
5 libsystem_platform.dylib 0x7fff6453c8d5 _sigtramp + 3408892869
6 llc 0x00010381c98b raise + 27
7 llc 0x00010381ca42 abort + 18
8 llc 0x00010381ca21 __assert_rtn + 129
9 llc 0x0001014cd428 llvm::MachineOperand::getImm()
const + 104
10 llc 0x000101938908
llvm::ARMBaseInstrInfo::optimizeCompareInstr(llvm::MachineInstr*, unsigned int,
unsigned int, int, int, llvm::MachineRegisterInfo const*) const + 2584
11 llc 0x000102c259c6 (anonymous
namespace)::PeepholeOptimizer::optimizeCmpInstr(llvm::MachineInstr*,
llvm::MachineBasicBlock*) + 230
12 llc 0x000102c24bd0 (anonymous
namespace)::PeepholeOptimizer::runOnMachineFunction(llvm::MachineFunction&) +
1152
13 llc 0x000102b42fee
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110
14 llc 0x00010308bb3d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 413
15 llc 0x00010308be75
llvm::FPPassManager::runOnModule(llvm::Module&) + 117
16 llc 0x00010308cbca (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&) + 2010
17 llc 0x00010308c15b
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 347
18 llc 0x00010308d811
llvm::legacy::PassManager::run(llvm::Module&) + 33
19 llc 0x0001014813f7 compileModule(char**,
llvm::LLVMContext&) + 19239
20 llc 0x00010147c866 main + 230
21 libdyld.dylib0x7fff84ef65ad start + 1
Stack dump:
0.Program arguments: ./llc -o - scheduler-backtracking.ll
-pre-RA-sched=linearize -march=arm
1.Running pass 'Function Pass Manager' on module
'scheduler-backtracking.ll'.
2.Running pass 'Peephole Optimizations' on function '@foo'
Illegal instruction: 4
--
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 25246] internal error on simple configure program for AVX
https://llvm.org/bugs/show_bug.cgi?id=25246 Eric Christopher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Eric Christopher --- Should be fixed in the patch set leading up to and including r252834. -- 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 24091] fabs of -0 returns -0 on Cortex-M4
https://llvm.org/bugs/show_bug.cgi?id=24091 Matthias Braun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Matthias Braun --- Finally got back to this. The proposed fix landed in 252839. -- 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 25500] New: Atomic compare_exchange_weak/strong
https://llvm.org/bugs/show_bug.cgi?id=25500
Bug ID: 25500
Summary: Atomic compare_exchange_weak/strong
Product: libc++
Version: 3.7
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: venkat.mu...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
Created attachment 15269
--> https://llvm.org/bugs/attachment.cgi?id=15269&action=edit
A test c++ code that shows the bug. It spawns 8 threads.
The following snippet does not work as expected.
struct Node { Node* next; };
std::atomic head (nullptr);
// Is like free
void push (void* p)
{
Node* n = (Node*) p;
n->next = head.load ();
while (!head.compare_exchange_strong (n->next, n));
}
// is like malloc
void* pop ()
{
Node* n = head.load ();
while (n &&
!head.compare_exchange_strong (n, n->next));
return n ? n : malloc (SIZE);
}
The attached file with the driver crashes every 1 in 5 times.
clang++ -g -std=c++11 test.cpp
--
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 25501] New: Clang crashes with -fmodules to compile clang-interpreter/main.cpp
https://llvm.org/bugs/show_bug.cgi?id=25501 Bug ID: 25501 Summary: Clang crashes with -fmodules to compile clang-interpreter/main.cpp Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: geek4ci...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Classification: Unclassified Created attachment 15270 --> https://llvm.org/bugs/attachment.cgi?id=15270&action=edit Reduced-testcase.zip (requires external libc++) $ clang++ -std=c++11 -stdlib=libc++ -I llvm/include -I clang/include -fsyntax-only -fmodules clang-interpreter-main.cpp clang-3.8: clang/lib/Serialization/ASTReaderDecl.cpp:1493: void clang::ASTDeclReader::MergeDefinitionData(clang::CXXRecordDecl *, struct CXXRecordDecl::DefinitionData &&): Assertion `Reader.Lookups.find(MergeDD.Definition) == Reader.Lookups.end() && "already loaded pending lookups for merged definition"' failed. A reduced testcase is attached. Excuse me, I haven't reduced libc++. -- 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
