[llvm-bugs] [Bug 26334] New: Segmentation fault with attribute aligned
https://llvm.org/bugs/show_bug.cgi?id=26334
Bug ID: 26334
Summary: Segmentation fault with attribute aligned
Product: clang
Version: 3.6
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: wangynu...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Currently, I am working on a big project with clang. I met a segmentation fault
when compile the project with clang. Here is the sample code:
#include
#include
typedef __attribute__ ((aligned (16))) struct uint128_t_str {
uint64_t i1;
uint64_t i2;
} uint128_t;
uint128_t data = {0xBADBEEF, 0xDEADBEEF};
uint128_t GetData() {
return data;
}
int main() {
uint128_t val;
int i = 0;
val = GetData();
}
==
I compile it with clang -O0 -m32 test.c, it will crash with segmentation fault
while gcc is OK.
I think it's because clang does not align some data to the specific address,
but not very sure.
--
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 26335] New: lldb (after 3.7.x) compilation fails at link-time with shared library
https://llvm.org/bugs/show_bug.cgi?id=26335 Bug ID: 26335 Summary: lldb (after 3.7.x) compilation fails at link-time with shared library Product: lldb Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: voyageu...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15726 --> https://llvm.org/bugs/attachment.cgi?id=15726&action=edit Build log showing lldb link failure Link operation fails in lllb for versions > 3.7 (3.7.1 works fine), with shared library and --as-needed link flag (enabled by default in most distributions). There are many errors "undefined reference to `llvm::*". I am attaching a full build log (bzipped for size). It would be nice to have this one fixed for 3.8 release Note: this is on trunk build, but I saw it too before the 3.8 branch (the Gentoo ebuild for 3.8 rc1 is not ready yet) FAILED: : && /usr/bin/x86_64-pc-linux-gnu-g++ -march=native -O2 -pipe -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -fno-exceptions -fno-rtti -Wl,-O1 -Wl,--as-needed -Wl,-allow-shlib-undefined -Wl,-O3 -Wl,--gc-sections tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/Acceptor.cpp.o tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-gdbserver.cpp.o tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-platform.cpp.o tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-server.cpp.o tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/LLDBServerUtilities.cpp.o -o bin/lldb-server-3.9.0 lib64/liblldb.so.3.9.0 -lcurses -lform -lpanel -lcurses -lpython2.7 -lxml2 -lpthread -ldl -lcurses -lform -lpanel lib64/libLLVMBPFCodeGen.so lib64/libLLVMBPFAsmPrinter.so lib64/libLLVMBPFDesc.so lib64/libLLVMBPFInfo.so lib64/libLLVMCppBackendCodeGen.so lib64/libLLVMCppBackendInfo.so lib64/libLLVMX86CodeGen.so lib64/libLLVMX86AsmPrinter.so lib64/libLLVMX86AsmParser.so lib64/libLLVMX86Desc.so lib64/libLLVMX86Info.so lib64/libLLVMX86Disassembler.so lib64/libLLVMInterpreter.so lib64/libLLVMAsmParser.so lib64/libLLVMBitReader.so lib64/libLLVMBitWriter.so lib64/libLLVMCodeGen.so lib64/libLLVMipo.so lib64/libLLVMSelectionDAG.so lib64/libLLVMMC.so lib64/libLLVMMCJIT.so lib64/libLLVMCore.so lib64/libLLVMMCDisassembler.so lib64/libLLVMExecutionEngine.so lib64/libLLVMRuntimeDyld.so lib64/libLLVMOption.so lib64/libLLVMSupport.so -Wl,--start-group lib64/liblldbBase.a lib64/liblldbBreakpoint.a lib64/liblldbCommands.a lib64/liblldbDataFormatters.a lib64/liblldbHost.a lib64/liblldbCore.a lib64/liblldbExpression.a lib64/liblldbInitialization.a lib64/liblldbInterpreter.a lib64/liblldbSymbol.a lib64/liblldbTarget.a lib64/liblldbUtility.a lib64/liblldbPluginDisassemblerLLVM.a lib64/liblldbPluginSymbolFileDWARF.a lib64/liblldbPluginSymbolFileSymtab.a lib64/liblldbPluginDynamicLoaderStatic.a lib64/liblldbPluginDynamicLoaderPosixDYLD.a lib64/liblldbPluginDynamicLoaderHexagonDYLD.a lib64/liblldbPluginDynamicLoaderWindowsDYLD.a lib64/liblldbPluginCPlusPlusLanguage.a lib64/liblldbPluginGoLanguage.a lib64/liblldbPluginObjCLanguage.a lib64/liblldbPluginObjCPlusPlusLanguage.a lib64/liblldbPluginObjectFileELF.a lib64/liblldbPluginObjectFileJIT.a lib64/liblldbPluginSymbolVendorELF.a lib64/liblldbPluginObjectContainerBSDArchive.a lib64/liblldbPluginObjectContainerMachOArchive.a lib64/liblldbPluginProcessGDBRemote.a lib64/liblldbPluginProcessUtility.a lib64/liblldbPluginPlatformAndroid.a lib64/liblldbPluginPlatformGDB.a lib64/liblldbPluginPlatformFreeBSD.a lib64/liblldbPluginPlatformKalimba.a lib64/liblldbPluginPlatformLinux.a lib64/liblldbPluginPlatformNetBSD.a lib64/liblldbPluginPlatformPOSIX.a lib64/liblldbPluginPlatformWindows.a lib64/liblldbPluginPlatformMacOSX.a lib64/liblldbPluginDynamicLoaderMacOSXDYLD.a lib64/liblldbPluginUnwindAssemblyInstEmulation.a lib64/liblldbPluginUnwindAssemblyX86.a lib64/liblldbPluginAppleObjCRuntime.a lib64/liblldbPluginRenderScriptRuntime.a lib64/liblldbPluginLanguageRuntimeGo.a lib64/liblldbPluginCXXItaniumABI.a lib64/liblldbPluginABIMacOSX_arm.a lib64/liblldbPluginABIMacOSX_arm64.a lib64/liblldbPluginABIMacOSX_i386.a lib64/liblldbPluginABISysV_arm.a lib64/liblldbPluginABISysV_arm64.a lib64/liblldbPluginABISysV_i386.a lib64/liblldbPluginABISysV_x86_64.a lib64/liblldbPluginABISysV_hexagon.a lib64/liblldbPluginABISysV_ppc.a lib64/liblldbPluginABISysV_ppc64.a lib64/liblldbPluginABISysV_mips.a lib64/liblldbPluginABISysV_mips64.a lib64/liblldbPluginIn
[llvm-bugs] [Bug 26173] 4 test failures on PPC64 & PPC64LE
https://llvm.org/bugs/show_bug.cgi?id=26173 İsmail Dönmez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from İsmail Dönmez --- This was yet another fallout from r258180 , 3.8 branch is fine now. Thanks! -- 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 26173] 4 test failures on PPC64 & PPC64LE
https://llvm.org/bugs/show_bug.cgi?id=26173 İsmail Dönmez changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from İsmail Dönmez --- Oh sorry checked the wrong machine. This tests still fail on PPC64, PPC64LE. The builds are Release without Asserts. -- 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 26336] New: Clang allows address of array with 'register' storage-class to be taken
https://llvm.org/bugs/show_bug.cgi?id=26336
Bug ID: 26336
Summary: Clang allows address of array with 'register'
storage-class to be taken
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: sne...@dei.uc.pt
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Example:
extern int f(int *);
int main() {
register int x[1];
return f(x);
}
The C99 standard, in footnote 100 of §6.7.1, states
> However, whether or not addressable storage is actually used, the address
> of any part of an object declared with storage-class specifier register
> cannot be computed, either explicitly (by use of the unary & operator as
> discussed in 6.5.3.2) or implicitly (by converting an array name to a
> pointer as discussed in 6.3.2.1).
Clang already does the right thing for explicit & operators on register
variables. However it misses the implicit pointer decay of array types.
Thus the example above should fail with a "address of register variable
requested" error message.
--
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 26337] New: extern "C" void fun(struct dummy, struct foo) doesn't always work
https://llvm.org/bugs/show_bug.cgi?id=26337
Bug ID: 26337
Summary: extern "C" void fun(struct dummy, struct foo) doesn't
always work
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: hjl.to...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
On x86-64, I got
[hjl@gnu-6 empty-1]$ cat emptya.c
#include "empty.h"
void fun(struct dummy d, struct foo f)
{
if (f.i1 != -1)
__builtin_abort();
}
[hjl@gnu-6 empty-1]$ cat empty.cc
#include "empty.h"
extern "C" void fun(struct dummy, struct foo);
int main()
{
struct dummy d;
struct foo f = { -1, -2, -3, -4, -5 };
fun(d, f);
return 0;
}
[hjl@gnu-6 empty-1]$ cat empty.h
#ifdef __x86_64__
# ifndef PAD_SIZE
# define PAD_SIZE 16
# endif
struct dummy0 { };
struct dummy { struct dummy0 d[PAD_SIZE]; };
#else
# ifndef PAD_SIZE
struct dummy { };
# else
struct dummy0 { };
struct dummy { struct dummy0 d[1]; };
# endif
#endif
struct foo
{
int i1;
int i2;
int i3;
int i4;
int i5;
};
[hjl@gnu-6 empty-1]$ make
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -m32 -c -O emptya.c
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang++ -m32 -c -O empty.cc
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -m32 -o x emptya.o
empty.o
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -m32 -c -O -o
empty1a.o emptya.c -DPAD_SIZE=17
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang++ -m32 -c -O -o
empty1.o empty.cc -DPAD_SIZE=17
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -m32 -o y empty1a.o
empty1.o
./x
./y
Makefile:17: recipe for target 'all' failed
make: *** [all] Aborted
[hjl@gnu-6 empty-1]$ make
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -c -O emptya.c
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang++ -c -O empty.cc
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -o x emptya.o empty.o
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -c -O -o empty1a.o
emptya.c -DPAD_SIZE=17
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang++ -c -O -o empty1.o
empty.cc -DPAD_SIZE=17
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -o y empty1a.o
empty1.o
./x
./y
Makefile:17: recipe for target 'all' failed
make: *** [all] Aborted
[hjl@gnu-6 empty-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 26338] New: [AVX512]: 3.8 and trunk llc fails on gather.qps and scatter.qps
https://llvm.org/bugs/show_bug.cgi?id=26338
Bug ID: 26338
Summary: [AVX512]: 3.8 and trunk llc fails on gather.qps and
scatter.qps
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: llc
Assignee: unassignedb...@nondot.org
Reporter: anton.mitrok...@phystech.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15728
--> https://llvm.org/bugs/attachment.cgi?id=15728&action=edit
Reproducer for gather.qps.512 llc fail
; Here is a small reproducer:
;foo_scatter.ll:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: argmemonly nounwind
declare void @llvm.x86.avx512.scatter.qps.512(i8*, i8, <8 x i64>, <8 x float>,
i32) #0
; Function Attrs: nounwind
define void @f_fu() #1 {
foreach_reset:
call void @llvm.x86.avx512.scatter.qps.512(i8* undef, i8 127, <8 x i64> , <8 x
float> undef, i32 1) #1
ret void
}
attributes #0 = { argmemonly nounwind }
attributes #1 = { nounwind }
!llvm.ident = !{!0}
!0 = !{!"clang version 3.8.0 (branches/release_38)"}
foo_gather.ll:
see attachment
Run llc (3.8 or trunk):
llc -mcpu=knl foo_scatter.ll
llc -mcpu=knl foo_gather.ll
Both commands will output something similar to:
llc:
/export/users/nightly/llvm/llvm-3.8/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1110:
llvm::SDValue llvm::SelectionDAG::getConstant(uint64_t, llvm::SDLoc, llvm::EVT,
bool, bool): Assertion `(EltVT.getSizeInBits() >= 64 || (uint64_t)((int64_t)Val
>> EltVT.getSizeInBits()) + 1 < 2) && "getConstant with a uint64_t value that
doesn't fit in the type!"' failed.
#0 0x01144048 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/llvm/bin-3.8/bin/llc+0x1144048)
#1 0x011447b7 (/llvm/bin-3.8/bin/llc+0x11447b7)
#2 0x7fccb27da430 __restore_rt (/lib64/libpthread.so.0+0x10430)
#3 0x7fccb176f9c8 __GI_raise (/lib64/libc.so.6+0x349c8)
#4 0x7fccb177165a __GI_abort (/lib64/libc.so.6+0x3665a)
#5 0x7fccb1768187 __assert_fail_base (/lib64/libc.so.6+0x2d187)
#6 0x7fccb1768232 (/lib64/libc.so.6+0x2d232)
#7 0x00848041 (/llvm/bin-3.8/bin/llc+0x848041)
#8 0x00667bd4 (/llvm/bin-3.8/bin/llc+0x667bd4)
#9 0x0064f855 llvm::X86TargetLowering::LowerOperation(llvm::SDValue,
llvm::SelectionDAG&) const (/llvm/bin-3.8/bin/llc+0x64f855)
#10 0x007fd767 (/llvm/bin-3.8/bin/llc+0x7fd767)
#11 0x007fcb47 llvm::SelectionDAG::Legalize()
(/llvm/bin-3.8/bin/llc+0x7fcb47)
#12 0x008cc250 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/llvm/bin-3.8/bin/llc+0x8cc250)
#13 0x008cabe7
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/llvm/bin-3.8/bin/llc+0x8cabe7)
#14 0x008c7bf6
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/llvm/bin-3.8/bin/llc+0x8c7bf6)
#15 0x00606ba1 (/llvm/bin-3.8/bin/llc+0x606ba1)
#16 0x00a9cbf9
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/llvm/bin-3.8/bin/llc+0xa9cbf9)
#17 0x01032c64 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/llvm/bin-3.8/bin/llc+0x1032c64)
#18 0x01032eab llvm::FPPassManager::runOnModule(llvm::Module&)
(/llvm/bin-3.8/bin/llc+0x1032eab)
#19 0x01033375 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/llvm/bin-3.8/bin/llc+0x1033375)
#20 0x0052db9d main (/llvm/bin-3.8/bin/llc+0x52db9d)
#21 0x7fccb175b700 __libc_start_main (/lib64/libc.so.6+0x20700)
#22 0x005279f9 _start (/llvm/bin-3.8/bin/llc+0x5279f9)
Stack dump:
0. Program arguments: llc -mcpu=knl foo_gather.ll
1. Running pass 'Function Pass Manager' on module 'foo_gather.ll'.
2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@f_f'
Aborted (core dumped)
--
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 19675] [x86-64 Itanium ABI] clang uses wrong return location for class with head padding
https://llvm.org/bugs/show_bug.cgi?id=19675 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Reid Kleckner --- GCC decided that their behavior is intentional, so I'd say this is working as intended. -- 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 26339] New: TestCPPAuto.py fails on Windows
https://llvm.org/bugs/show_bug.cgi?id=26339
Bug ID: 26339
Summary: TestCPPAuto.py fails on Windows
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: amcca...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
On Windows, expression commands like this:
(lldb) expr struct Test { int x; int y; Test() : x(123), y(456) {} }; auto t
= Test(); t
result in:
error: Can't run the expression locally: (null)
This requires more research to understand the root problem.
--
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 26340] New: Cuda device constant doesn't work
https://llvm.org/bugs/show_bug.cgi?id=26340 Bug ID: 26340 Summary: Cuda device constant doesn't work Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: crtr...@sandia.gov CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15729 --> https://llvm.org/bugs/attachment.cgi?id=15729&action=edit Reproduction code without extern symbols It looks like cuda __device__ __symbols__ don't work. Effectively it looks like the host side functions such as cudaGetSymbolAddress or cudaMemcpyToSymbol have an issue at link time, where it says something with the same name as the cuda symbol is an undefined reference. The compilation it self gets through. If you cheat the linker by adding another .o file with a global host symbol of the same name the linking works, but at runtime the aforementioned functions produce an error of invalid device symbol. I attach a reproduction example with build scripts for NVCC (which works) and Clang. In the build script for clang you have to comment in the line with the workaround c.cpp file. I also attach a similar example, where a constant symbol is declared extern. This requires compilation with -rdc true for NVCC. It fails right now for similar reasons I assume as the first example, but I'd like to get that working as well. I'll attach that later. -- 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 26341] New: Cuda __device__ lambda does not work
https://llvm.org/bugs/show_bug.cgi?id=26341
Bug ID: 26341
Summary: Cuda __device__ lambda does not work
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: crtr...@sandia.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15731
--> https://llvm.org/bugs/attachment.cgi?id=15731&action=edit
Reproduction code
This is an experimental feature in CUDA 7.5 and expected to be non experimental
in CUDA 8. The attached simple test code fails to compile.
Code:
run( [=] __device__ (int i) {
d_a[i] = d_c;
});
Error:
main.cpp:23:12: error: lambda requires '()' before attribute specifier
run( [=] __device__ (int i) {
^
()
/usr/local/cuda/include/host_defines.h:189:9: note: expanded from macro
'__device__'
__location__(device)
^
/usr/local/cuda/include/host_defines.h:88:9: note: expanded from macro
'__location__'
__annotate__(a)
^
/usr/local/cuda/include/host_defines.h:86:9: note: expanded from macro
'__annotate__'
__attribute__((a))
^
main.cpp:23:23: error: expected body of lambda expression
run( [=] __device__ (int i) {
^
main.cpp:23:28: error: expected '(' for function-style cast or type
construction
run( [=] __device__ (int i) {
~~~ ^
3 errors generated.
I actually like to see to be able to do __host__ __device__ (which does not
work with NVCC right now) so that you can dispatch the lambda to the host or to
the device. Effectively I just want the operator of the auto generated struct
to be marked __host__ __device__. I am responsible to only capture stuff which
is accesible on the device. Furthermore one might want to restrict a __device__
lambda to only capture by value. i.e. [=] __host__ __device__ (...) {...}
--
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 26342] New: clang segfault reported while compiling seastar
https://llvm.org/bugs/show_bug.cgi?id=26342 Bug ID: 26342 Summary: clang segfault reported while compiling seastar Product: clang Version: 3.7 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: erich.ke...@verizon.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified [ekeane1@ekeane1-desk1 seastar]$ clang++ --version clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-redhat-linux-gnu Thread model: posix [32/124] CXX build/release/tests/rpc.o FAILED: clang++ -MMD -MT build/release/tests/rpc.o -MF build/release/tests/rpc.o.d -O2 -I build/release/gen -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -I. -U_FORTIFY_SOURCE -Wno-mismatched-tags -Wno-pessimizing-move -Wno-redundant-move -Wno-inconsistent-missing-override -Wno-unused-private-field -Wno-unneeded-internal-declaration -DHAVE_HWLOC -DHAVE_NUMA -c -o build/release/tests/rpc.o tests/rpc.cc clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-redhat-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/rpc-4337de.cpp clang: note: diagnostic msg: /tmp/rpc-4337de.sh clang: note: diagnostic msg: ninja: build stopped: subcommand failed. Those files have been 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 26343] New: Cuda: Relocatable device code doesn't work
https://llvm.org/bugs/show_bug.cgi?id=26343
Bug ID: 26343
Summary: Cuda: Relocatable device code doesn't work
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: crtr...@sandia.gov
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15733
--> https://llvm.org/bugs/attachment.cgi?id=15733&action=edit
Reproduction code
With nvcc one can use the option "-rdc true", to allow device (or device host)
functions to be declared "extern". This means device functions can be compiled
in one compilation unit and called from others. This doesn't work here:
Error:
[crtrott@apollo test_relocatable_device_code]$ ./build_clang
ptxas fatal : Unresolved extern function '_Z4calcv'
fatal error: cannot open file '/tmp/main-b2a94f.fatbin': No such file or
directory
1 error generated.
clang-3.9: error: ptxas command failed with exit code 255 (use -v to see
invocation)
clang-3.9: error: no such file or directory: 'main.o'
Code:
extern int __device__ calc();
__global__ void foo(int* a) {
a[blockIdx.x*blockDim.x+threadIdx.x] = calc();
}
--
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 26344] New: failure with unrolled loops which exit in the first iteration.
https://llvm.org/bugs/show_bug.cgi?id=26344
Bug ID: 26344
Summary: failure with unrolled loops which exit in the first
iteration.
Product: clang
Version: 3.7
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: lo...@phantasia.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
System: OSX 10.10.5
Xcode 7.2
gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
Having a loop, which might exit after the first iteration, the optimization
fails to produce correct code.
<---
#define FAIL 0x
#define rotate_left(v, n) (v << n | v >> (32 - n))
unsigned int
encode_arm_immediate (unsigned int val)
{
unsigned int a, i;
for (i = 0; i < 32 ; i += 2)
if((a = rotate_left (val, i)) <= 0xFF)
return a | (i << 7) ; /* 12-bit pack: [shift-cnt,const]. */
return FAIL;
}
<---
calling this with val = 0xFF the loop should exit within the first iteration
with 0xFF
if this code fragment gets compiled with
clang -Wall -m32 -O2 test.c
or
clang -Wall -m64 -O2 test.c
the function will incorrectly return FAIL
looking at the assembler text generated on
clang -Wall -S -O2 test.c
shows the following:
<---
_encode_arm_immediate: ## @encode_arm_immediate
.cfi_startproc
## BB#0:
pushq %rbp
Ltmp4:
.cfi_def_cfa_offset 16
Ltmp5:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp6:
.cfi_def_cfa_register %rbp
movl%edi, %ecx
roll$2, %ecx
movl$256, %edx ## imm = 0x100
cmpl$255, %ecx
jbe LBB1_1
LBB1_1:
orl %edx, %ecx
movl%ecx, %eax
LBB1_2: ## %.loopexit5
popq%rbp
retq
.cfi_endproc
<---
it seems the first iteration with i=0 has been omited which causes the loop to
begin with i=1.
I attached the testcase source and the 2 (32bit, 64bit) generated files
--
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 26344] failure with unrolled loops which exit in the first iteration.
https://llvm.org/bugs/show_bug.cgi?id=26344 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Resolution|--- |INVALID --- Comment #5 from David Majnemer --- $ clang -fsanitize=undefined test.c -o test && ./test test.c:11:13: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int' 0xA7 0xA7 0x1 0x1 0x0 0x0 line 11 has: if((a = rotate_left (val, i)) <= 0xFF) expands to: if((a = (val << i | val >> (32 - i))) <= 0xFF) when i == 0, we will compute: if((a = (val << 0 | val >> (32 - 0))) <= 0xFF) val >> 32 is undefined behavior. -- 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 26345] New: FAIL: cfi :: cross-dso/dlopen.cpp (27647 of 27652)
https://llvm.org/bugs/show_bug.cgi?id=26345 Bug ID: 26345 Summary: FAIL: cfi :: cross-dso/dlopen.cpp (27647 of 27652) Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: hjl.to...@gmail.com CC: eugeni.stepa...@gmail.com, llvm-bugs@lists.llvm.org Classification: Unclassified On Fedora 23/x86-64, I got FAIL: cfi :: cross-dso/dlopen.cpp (27647 of 27652) TEST 'cfi :: cross-dso/dlopen.cpp' FAILED Script: -- /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/clang --driver-mode=g++ -fuse-ld=gold -flto -fsanitize=cfi -fsanitize-cfi-cross-dso -DSHARED_LIB /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp -fPIC -shared -o /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp1-so.so /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/clang --driver-mode=g++ -fuse-ld=gold -flto -fsanitize=cfi -fsanitize-cfi-cross-dso /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp -o /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp1 not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp1 2>&1 | FileCheck --check-prefix=CFI /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp1 cast 2>&1 | FileCheck --check-prefix=CFI-CAST /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp1 dlclose 2>&1 | FileCheck --check-prefix=CFI /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/clang --driver-mode=g++ -fuse-ld=gold -flto -fsanitize=cfi -fsanitize-cfi-cross-dso -DB32 -DSHARED_LIB /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp -fPIC -shared -o /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp2-so.so /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/clang --driver-mode=g++ -fuse-ld=gold -flto -fsanitize=cfi -fsanitize-cfi-cross-dso -DB32 /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp -o /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp2 not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp2 2>&1 | FileCheck --check-prefix=CFI /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp2 cast 2>&1 | FileCheck --check-prefix=CFI-CAST /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp2 dlclose 2>&1 | FileCheck --check-prefix=CFI /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/clang --driver-mode=g++ -fuse-ld=gold -flto -fsanitize=cfi -fsanitize-cfi-cross-dso -DB64 -DSHARED_LIB /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp -fPIC -shared -o /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp3-so.so /export/build/gnu/llvm-clang/build-x86_64-linux/./bin/clang --driver-mode=g++ -fuse-ld=gold -flto -fsanitize=cfi -fsanitize-cfi-cross-dso -DB64 /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp -o /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp3 not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp3 2>&1 | FileCheck --check-prefix=CFI /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp3 cast 2>&1 | FileCheck --check-prefix=CFI-CAST /export/gnu/import/git/llvm/projects/compiler-rt/test/cfi/cross-dso/dlopen.cpp not --crash /export/build/gnu/llvm-clang/build-x86_64-linux/projects/compiler-rt/test/cfi/cross-dso/Output/dlopen.cpp.tmp3 dlclose 2>&1 | FileCheck --check-prefix=CFI /export/gnu/import/git/llvm/projects/compiler-r
[llvm-bugs] [Bug 26346] New: IRLinker::stripNullSubprograms dominates the CPU profile
https://llvm.org/bugs/show_bug.cgi?id=26346 Bug ID: 26346 Summary: IRLinker::stripNullSubprograms dominates the CPU profile Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kra...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I regularly profile linking Chrome with CFI (Control Flow Integrity, ) and in the last time I spotted something new in the CPU profile: + 19.16%ld.gold LLVMgold.so [.] (anonymous namespace)::IRLinker::stripNullSubprograms() [clone .isra.460] + 4.41%ld.gold libc-2.19.so [.] _int_malloc + 4.21%ld.gold [kernel.kallsyms][k] 0x8172c822 + 2.49%ld.gold LLVMgold.so [.] llvm::NamedMDNode::getOperand(unsigned int) const + 1.71%ld.gold libc-2.19.so [.] malloc_consolidate + 1.26%ld.gold libc-2.19.so [.] _int_free + 1.02%ld.gold LLVMgold.so [.] llvm::Value::assertModuleIsMaterialized() const + 1.02%ld.gold LLVMgold.so [.] llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults&, llvm::CodeGenOpt::Level) + 0.94%ld.gold LLVMgold.so [.] llvm::PMDataManager::findAnalysisPass(void const*, bool) + 0.91%ld.gold libc-2.19.so [.] memset + 0.84%ld.gold LLVMgold.so [.] llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) + 0.77%ld.gold LLVMgold.so [.] llvm::sys::MemoryFence() + 0.75%ld.gold LLVMgold.so [.] llvm::SmallPtrSetImplBase::FindBucketFor(void const*) const + 0.60%ld.gold LLVMgold.so [.] llvm::ReplaceableMetadataImpl::get(llvm::Metadata&) + 0.59%ld.gold libc-2.19.so [.] malloc + 0.56%ld.gold LLVMgold.so [.] llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) + 0.53%ld.gold LLVMgold.so [.] llvm::MCExpr::evaluateAsRelocatableImpl(llvm::MCValue&, llvm::MCAssembler const*, llvm::MCAsmLayout const*, llvm::MCFixup const*, llvm::DenseMap&, llvm::StringRef*) + 0.50%ld.gold LLVMgold.so [.] llvm::PMDataManager::removeNotPreservedAnalysis(llvm::Pass*) stripNullSubprograms is fairly new (introduced in http://reviews.llvm.org/rL256003) and based on the quick look could be made faster / avoided alltogether (not 100% sure about the latter). It would be nice to get rid of this unnecessary slowdown. It seems that the performance is hit due to a lot of cache misses, which happens because stripNullSubprograms accesses every single DISubprogram, and at this point this data is not in L2 cache anymore. If this is done earlier, it could be 1 times faster (this is the ratio between findNeededSubprograms and stripNullSubprograms). -- 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 26308] clang crashes on valid code at -O1 and above on x86_64-linux-gnu with no diagnostic msg (SimplifyCFG)
https://llvm.org/bugs/show_bug.cgi?id=26308 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Summary|clang crashes on valid code |clang crashes on valid code |at -O1 and above on |at -O1 and above on |x86_64-linux-gnu with no|x86_64-linux-gnu with no |diagnostic msg |diagnostic msg ||(SimplifyCFG) --- Comment #7 from Sanjay Patel --- Marking as fixed since we shouldn't crash after: http://reviews.llvm.org/rL258971 ...but as noted by Daniel Berlin and David, we can do better than using a recursion limit to prevent 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 26347] New: clang crashes on valid code (with packed struct) at -Os and above on x86_64-linux-gnu (in 32-bit mode)
nstance::ExecuteAction(clang::FrontendAction&)
(/usr/local/clang-trunk/bin/clang+0xab5eb6)
#27 0x00a98fc3
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/local/clang-trunk/bin/clang+0xa98fc3)
#28 0x00a902d0 cc1_main(llvm::ArrayRef, char const*,
void*) (/usr/local/clang-trunk/bin/clang+0xa902d0)
#29 0x00a516ed main (/usr/local/clang-trunk/bin/clang+0xa516ed)
#30 0x7f5cea23dec5 __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:321:0
#31 0x00a8ecf8 _start (/usr/local/clang-trunk/bin/clang+0xa8ecf8)
Stack dump:
0.Program arguments: /usr/local/clang-trunk/bin/clang -cc1 -triple
i386-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose
-mconstructor-aliases -fuse-init-array -target-cpu pentium4
-target-linker-version 2.24 -momit-leaf-frame-pointer -dwarf-column-info
-debugger-tuning=gdb -resource-dir
/usr/local/clang-trunk/bin/../lib/clang/3.9.0 -internal-isystem
/usr/local/include -internal-isystem
/usr/local/clang-trunk/bin/../lib/clang/3.9.0/include -internal-externc-isystem
/include -internal-externc-isystem /usr/include -Os -fdebug-compilation-dir
/home/su/20160127-clang-trunk-m64-Os-build-084902 -ferror-limit 19
-fmessage-length 88 -fobjc-runtime=gcc -fdiagnostics-show-option
-fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/small-5368dd.o -x c
small.c
1. parser at end of file
2.Per-module optimization passes
3.Running pass 'Function Pass Manager' on module 'small.c'.
4.Running pass 'Combine redundant instructions' on function '@fn1'
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.9.0 (trunk 258783)
Target: i386-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/small-79f9e5.c
clang: note: diagnostic msg: /tmp/small-79f9e5.sh
clang: note: diagnostic msg:
$
$
--
int printf (const char *, ...);
#pragma pack(1)
struct S
{
int f0:29;
int f1:26;
int:13;
};
int a;
void
fn1 ()
{
struct S b;
for (; a;)
{
int c = b.f0 - b.f1;
int d = a = a + c;
printf ("0");
b.f1 = d;
b.f0 = c;
}
}
int
main ()
{
fn1 ();
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 26348] New: 3.8 AArch64 support for half floats
https://llvm.org/bugs/show_bug.cgi?id=26348
Bug ID: 26348
Summary: 3.8 AArch64 support for half floats
Product: tools
Version: 3.8
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: llc
Assignee: unassignedb...@nondot.org
Reporter: apa...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Branch 3.7 had broken support for half floats. Since then there have been
several patches in mainline that improved it. But branch 3.8 seems to be
missing at least one of the latest fixes (what I could detect in my
validations).
For example the test below will crash in branch 3.8, but passes in the tip.
There is one commit that could be brought to branch 3.8 to resolve this crash I
suggest we pick it.
@258471 - Do not lower VSETCC if operand is an f16 vector
target datalayout = "e-m:e-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-none-linux-android"
@.str28 = external unnamed_addr constant [94 x i8], align 1
@.str29 = external unnamed_addr constant [84 x i8], align 1
; Function Attrs: nounwind
define i16 @test() {
%1 = call <4 x i16> @llvm.aarch64.neon.vcvtfp2hf(<4 x float> undef)
%2 = bitcast <4 x i16> %1 to <4 x half>
%3 = shufflevector <4 x half> %2, <4 x half> undef, <8 x i32>
%4 = fcmp une <8 x half> zeroinitializer, %3
%5 = sext <8 x i1> %4 to <8 x i16>
%6 = extractelement <8 x i16> %5, i64 undef
ret i16 %6
}
declare <4 x i16> @llvm.aarch64.neon.vcvtfp2hf(<4 x float>)
llc test.ll
llc:
/prj/llvm-arm/home/nightly/src/community-38/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:6693:
llvm::SDValue llvm::AArch64TargetLowering::LowerVSETCC(llvm::SDValue,
llvm::SelectionDAG &) const: Assertion
`LHS.getValueType().getVectorElementType() == MVT::f32 ||
LHS.getValueType().getVectorElementType() == MVT::f64' failed.
#0 0x010c68d8 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0x10c68d8)
#1 0x010c4de6 llvm::sys::RunSignalHandlers()
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0x10c4de6)
#2 0x010c70f9 SignalHandler(int)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0x10c70f9)
#3 0x7fbbe6b24cb0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0xfcb0)
#4 0x7fbbe5e670d5 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x360d5)
#5 0x7fbbe5e6a83b abort (/lib/x86_64-linux-gnu/libc.so.6+0x3983b)
#6 0x7fbbe5e5fd9e (/lib/x86_64-linux-gnu/libc.so.6+0x2ed9e)
#7 0x7fbbe5e5fe42 (/lib/x86_64-linux-gnu/libc.so.6+0x2ee42)
#8 0x00764545
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0x764545)
#9 0x0074052e llvm::AArch64TargetLowering::LowerSETCC(llvm::SDValue,
llvm::SelectionDAG&) const
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0x74052e)
#10 0x0073f54f
llvm::AArch64TargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&)
const
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0x73f54f)
#11 0x00fc821f (anonymous
namespace)::VectorLegalizer::LegalizeOp(llvm::SDValue)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xfc821f)
#12 0x00fc763d llvm::SelectionDAG::LegalizeVectors()
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xfc763d)
#13 0x00f7a2ec llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xf7a2ec)
#14 0x00f792e2
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xf792e2)
#15 0x00f769f7
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xf769f7)
#16 0x00a443bc
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xa443bc)
#17 0x00cfee2d llvm::FPPassManager::runOnFunction(llvm::Function&)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xcfee2d)
#18 0x00cff07b llvm::FPPassManager::runOnModule(llvm::Module&)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xcff07b)
#19 0x00cff622 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0xcff622)
#20 0x0054f5bf compileModule(char**, llvm::LLVMContext&)
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0x54f5bf)
#21 0x0054c6ab main
(/prj/llvm-arm/home/nightly/install/community-38/cross/2016-01-27/bin/llc+0x54c6ab)
#22 0x7fbbe5e5276d __libc_start_main
(/lib/x86_64-linux-
[llvm-bugs] [Bug 26349] New: Digit separators as only characters in significand or exponent of floating point constants can trigger assertions
https://llvm.org/bugs/show_bug.cgi?id=26349 Bug ID: 26349 Summary: Digit separators as only characters in significand or exponent of floating point constants can trigger assertions Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: C++14 Assignee: unassignedclangb...@nondot.org Reporter: craig.top...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The following literals trick NumericLiteralParser into believing that they have an exponent or significand when they don't. Later when GetFloatValue tries to process them the empty exponent or significand is detected and triggers an assertion. They also diagnose the digit separator as being both at the start and end of a digit sequence. float f = 0x.'p1f; float g = 0e'f; This one doesn't trigger an assertion, but isn't diagnosed as an empty exponent either. float h = 0x0p'f; -- 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 26347] clang crashes on valid code (with packed struct) at -Os and above on x86_64-linux-gnu (in 32-bit mode)
https://llvm.org/bugs/show_bug.cgi?id=26347 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 26307 *** -- 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 26350] New: wrong code on x86_64-linux-gnu at -O1 and above in 32-bit mode
https://llvm.org/bugs/show_bug.cgi?id=26350
Bug ID: 26350
Summary: wrong code on x86_64-linux-gnu at -O1 and above in
32-bit mode
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: chengnian...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code is miscompiled by the trunk in 32-bit mode at -O1 and above.
It also affects clang-3.2 and later versions.
The compiled executable non-deterministically outputs "l_1845=0".
$: clang-trunk -v
clang version 3.9.0 (trunk 258824) (llvm/trunk 258823)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/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.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.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.3
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.4
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2
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 -w -m32 -O0 small.c
$: (for i in {1..1000} ; do ./a.out ; done) | wc -l
1000
$: clang-trunk -w -m32 -O1 small.c
$: (for i in {1..1000} ; do ./a.out ; done) | wc -l
474
$: clang-trunk -w -m32 -O2 small.c
$: (for i in {1..1000} ; do ./a.out ; done) | wc -l
502
$: clang-trunk -w -m32 -O3 small.c
$: (for i in {1..1000} ; do ./a.out ; done) | wc -l
516
$:
$: cat small.c
int printf(const char*, ...);
volatile char a, h;
long long b;
int d;
long long fn1_p;
int main() {
unsigned j = 9, m;
int k = -1L, o;
long long n = -1L;
o = m = ~fn1_p;
b = -(-n ^ (j | d)) * ~ - k;
if (m > b)
printf("l_1845=%llu\n", (long long)h);
o || a;
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 26331] __attribute__((init_priority)) does not work accross multiple translation units
https://llvm.org/bugs/show_bug.cgi?id=26331 Anton Korobeynikov changed: What|Removed |Added Status|NEW |RESOLVED CC||an...@korobeynikov.info Resolution|--- |WONTFIX --- Comment #1 from Anton Korobeynikov --- This is expected. The constructors on Darwin are ordered by their .o link 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
