[llvm-bugs] [Bug 26488] [3.8 rc2] CodeGenOpenCL/pipe_types.cl test fails on SystemZ
https://llvm.org/bugs/show_bug.cgi?id=26488 İsmail Dönmez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from İsmail Dönmez --- Confirmed r259808 fixing the issue. -- 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 26489] New: improve error message for 'label prefixing declaration'
https://llvm.org/bugs/show_bug.cgi?id=26489
Bug ID: 26489
Summary: improve error message for 'label prefixing
declaration'
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: chengnian...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
I think the error message by clang can be more user friendly. When I put a
label before a declaration, I got "error: expected expression". Then I used gcc
and got to know the reason.
$: cat t.c
void f() {
l1:
int a = 1;
goto l1;
}
$: clang-trunk t.c
t.c:3:5: error: expected expression
int a = 1;
^
1 error generated.
$: gcc-trunk t.c
t.c: In function ‘f’:
t.c:3:5: error: a label can only be part of a statement and a declaration is
not a statement
int a = 1;
^~~
$: clang-trunk -v
clang version 3.9.0 (trunk 259077) (llvm/trunk 259321)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
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.2
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.1
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.8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$:
--
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 26490] New: clang-cl.exe from 3.9.0/32bit crashes compiling Qt 5 source qtbase/src/widgets/graphicsview/qgraphicsscenelinearindex.cpp
https://llvm.org/bugs/show_bug.cgi?id=26490 Bug ID: 26490 Summary: clang-cl.exe from 3.9.0/32bit crashes compiling Qt 5 source qtbase/src/widgets/graphicsview/qgraphicsscenelinearin dex.cpp Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: friedemann.kle...@theqtcompany.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified When using LLVM-3.9.0-r259040-win32.exe with MSVC2015 Professional Update 1 on Windows 10 to build Qt 5, dev branch at qtbase: 58bd015ddff84c6bd0b5dcff54b9512e188f346c and the experimental change https://codereview.qt-project.org/#/c/145351/ applied on top using the configure options: -confirm-license -developer-build -opensource -debug -nomake tests -nomake examples -opengl dynamic -no-headersclean a crash occurs when compiling qtbase/src/widgets/graphicsview/qgraphicsscenelinearindex.cpp: Assertion failed: DefaultArg && "sema forgot to instantiate default args", file D:\src\llvm_package_259040\llvm\tools\clang\lib\CodeGen\MicrosoftCXXABI.cpp, line 3857 (full log + sources in attached zip file) Reportedly, this is working with 3.8. -- 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 26059] [meta] 3.8.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=26059 Bug 26059 depends on bug 26278, which changed state. Bug 26278 Summary: compiler-rt adds a tsan version of libc++ without checking whether tsan is supported https://llvm.org/bugs/show_bug.cgi?id=26278 What|Removed |Added Status|ASSIGNED|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 26278] compiler-rt adds a tsan version of libc++ without checking whether tsan is supported
https://llvm.org/bugs/show_bug.cgi?id=26278 Daniel Sanders changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Daniel Sanders --- This has been committed and merged. -- 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 26491] New: _mm_movehl_ps pesimised to movaps/shufpd instead of movhlps
https://llvm.org/bugs/show_bug.cgi?id=26491
Bug ID: 26491
Summary: _mm_movehl_ps pesimised to movaps/shufpd instead of
movhlps
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Keywords: performance
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: pe...@cordes.ca
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
clang sometimes uses a different instruction that the "normal" one for the
intrinsic. Usually it gets an improvement, but not in this case where it ends
up wasting a movaps and using a bigger instruction.
float hsum_ps(__m128 v) {
__m128 tmp = _mm_movehdup_ps(v); // dest of MOVSHDUP is write-only
__m128 sums = _mm_add_ps(v, tmp);
tmp = _mm_movehl_ps(tmp, sums);
sums= _mm_add_ss(sums, tmp);
return _mm_cvtss_f32(sums);
}
compiles to: clang 3.7.1 -O3 -march=core2
movshdupxmm1, xmm0 # xmm1 = xmm0[1,1,3,3]
addps xmm1, xmm0
movaps xmm0, xmm1
shufpd xmm0, xmm0, 1 # xmm0 = xmm0[1,0]
addss xmm0, xmm1
ret
movhlps is very compact: OF 12 /r, vs. shufpd being a 5 byte insn. At least
it doesn't use shufps, which is slow on Core2. A similar sequence after a loop
produced a movaps/unpckhpd instead of the movhlps.
What I was hoping for (and which gcc produces) is the obvious literal
translation from intrinsics to instructions:
movshdup xmm1, xmm0
addps xmm0, xmm1
movhlps xmm1, xmm0
addss xmm0, xmm1
ret
I used movshdup first because its destination is write-only. I can avoid a
movaps without needing the compiler to keep some other variable live so I can
movhlps into it. (And so I could put it in a function that only takes one
parameter.) I can't use _mm_undefined_ps() without risk of denormals or NaN
slowdowns.
--
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 26492] New: TestPrintStackTraces sometimes fails on android arm
https://llvm.org/bugs/show_bug.cgi?id=26492 Bug ID: 26492 Summary: TestPrintStackTraces sometimes fails on android arm Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: tbergham...@google.com Reporter: lab...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15835 --> https://llvm.org/bugs/attachment.cgi?id=15835&action=edit Test trace It seems that the main thread has stopped somewhere in libc, and we cannot unwind out of it. Stack trace for thread id=0x4c7e name=a.out queue=None stop reason=none frame #0: 0x00b6e4135c libc.so`None + -18446744073709149347 The address seems to be 0x4cb1c bytes inside the .text section 1454675830.031735000 [9437/97fd]: SectionLoadList::SetSectionLoadAddress (section = 0x2a40f00 (/home/lldb_build/.lldb/module_cache/remote-android/.cache/208950F0-49F2-74B2-3ABE-0BCAB12FA0BD/libc.so..text), load_addr = 0xb6df4840) module = 0x2d077e0 Full logs are in the 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 26493] New: Inline assembly constraint "X" triggers assert
https://llvm.org/bugs/show_bug.cgi?id=26493
Bug ID: 26493
Summary: Inline assembly constraint "X" triggers assert
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: kristof.be...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
When trying to build https://gitorious.org/arm-neon-tests/arm-neon-tests with
clang, clang crashes with assertion failures.
Below are 2 small reproducers, which each trigger a different assert. These
snippets use the "X" inline assembly constraint to avoid the inline assembly
being reordered with the computations happening later. The technique is
explained in detail at http://www.ethernut.de/en/documents/arm-inline-asm.html,
under section "C code optimization".
$ cat t2.c
double f2(double f, int pscr_value) {
asm volatile("vmsr fpscr,%1" : "=X" ((f)): "r" (pscr_value));
return f+f;
}
$ cat t3.c
typedef signed char int8_t;
typedef __attribute__((neon_vector_type(8))) int8_t int8x8_t;
void f (void)
{
int8x8_t vector_res_int8x8;
unsigned int fpscr;
asm volatile ("vmsr fpscr,%1" : "=X" ((vector_res_int8x8)) : "r" (fpscr));
}
$ ~/dev/llvm.org/build/bin/clang -target armv7a-none-eabi -c -mcpu=cortex-a9
-mfloat-abi=hard -S -O -o- t2.c
.text
.syntax unified
.eabi_attribute 67, "2.09" @ Tag_conformance
.cpucortex-a9
.eabi_attribute 6, 10 @ Tag_CPU_arch
.eabi_attribute 7, 65 @ Tag_CPU_arch_profile
.eabi_attribute 8, 1@ Tag_ARM_ISA_use
.eabi_attribute 9, 2@ Tag_THUMB_ISA_use
.fpuneon-fp16
.eabi_attribute 17, 1 @ Tag_ABI_PCS_GOT_use
.eabi_attribute 20, 1 @ Tag_ABI_FP_denormal
.eabi_attribute 21, 1 @ Tag_ABI_FP_exceptions
.eabi_attribute 23, 3 @ Tag_ABI_FP_number_model
.eabi_attribute 34, 0 @ Tag_CPU_unaligned_access
.eabi_attribute 24, 1 @ Tag_ABI_align_needed
.eabi_attribute 25, 1 @ Tag_ABI_align_preserved
.eabi_attribute 28, 1 @ Tag_ABI_VFP_args
.eabi_attribute 36, 1 @ Tag_FP_HP_extension
.eabi_attribute 38, 1 @ Tag_ABI_FP_16bit_format
.eabi_attribute 42, 1 @ Tag_MPextension_use
.eabi_attribute 18, 4 @ Tag_ABI_PCS_wchar_t
.eabi_attribute 26, 2 @ Tag_ABI_enum_size
.eabi_attribute 14, 0 @ Tag_ABI_PCS_R9_use
.eabi_attribute 68, 1 @ Tag_Virtualization_use
.file "t2.c"
Assertion failed: (ConstraintID != InlineAsm::Constraint_Unknown && "Failed to
convert memory constraint code to constraint id."), function visitInlineAsm,
file /Users/kribey01/dev/llvm.org/llvm-clang-compiler-rt
/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp, line 6401.
0 clang-3.90x000101f6f96b
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 43
1 clang-3.90x000101f6ebe6 llvm::sys::RunSignalHandlers() +
70
2 clang-3.90x000101f70012 SignalHandler(int) + 322
3 libsystem_platform.dylib 0x7fff8e779f1a _sigtramp + 26
4 clang-3.90x000104041fd7 clang::Stmt::StatisticsEnabled +
92386
5 clang-3.90x000101f6fe26 abort + 22
6 clang-3.90x000101f6fe01 __assert_rtn + 81
7 clang-3.90x0001025e4eff
llvm::SelectionDAGBuilder::visitInlineAsm(llvm::ImmutableCallSite) + 15695
8 clang-3.90x0001025cd895
llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 69
9 clang-3.90x00010264c2e8
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 40
10 clang-3.90x00010264bf74
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 6612
11 clang-3.90x000102649554
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 2020
12 clang-3.90x00010108f4f4 (anonymous
namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20
13 clang-3.90x0001019b94dc
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 140
14 clang-3.90x000101b9acd8
llvm::FPPassManager::runOnFunction(llvm::Function&) + 328
15 clang-3.90x000101b9af2b
llvm::FPPassManager::runOnModule(llvm::Module&) + 43
16 clang-3.90x000101b9b3b6
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 806
17 clang-3.90x0001020cb6be
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&,
llvm::StringRef, llvm::Modu
le*, clang::BackendAction, llvm::raw_pwrite_stream*) + 8750
18 clang-3.90x00010223c502
clang::BackendConsumer::Han
[llvm-bugs] [Bug 26494] New: Seg fault when trying to include non-existent file
https://llvm.org/bugs/show_bug.cgi?id=26494
Bug ID: 26494
Summary: Seg fault when trying to include non-existent file
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@gmx.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
cat > bug.cc <
#include
namespace cmdline {
class Descr {};
void parse( int argc, char const* const* argv, Descr const* descr = 0,
std::function usage = 0 );
}
namespace foo { namespace cmdln = ::cmdline; }
int main( int argc, char** argv ) {
foo::cmdln::Descr descr;
parse( argc, argv, &descr );
}
EOF
clang++-3.7 -v -c bug.cc
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation:
/tools/pkg/gcc/4.9.3/lib/gcc/x86_64-unknown-linux-gnu/4.9.3
Selected GCC installation:
/tools/pkg/gcc/4.9.3/lib/gcc/x86_64-unknown-linux-gnu/4.9.3
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
"/tools/pkg/clang/3.7.0/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
bug.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu x86-64 -target-linker-version 2.25 -v
-dwarf-column-info -coverage-file /tmp/bug.cc -resource-dir
/tools/pkg/clang/3.7.0/bin/../lib/clang/3.7.0 -internal-isystem
/tools/pkg/gcc/4.9.3/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../../../include/c++/4.9.3
-internal-isystem
/tools/pkg/gcc/4.9.3/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../../../include/c++/4.9.3/x86_64-unknown-linux-gnu
-internal-isystem
/tools/pkg/gcc/4.9.3/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../../../include/c++/4.9.3/backward
-internal-isystem /usr/local/include -internal-isystem
/tools/pkg/clang/3.7.0/bin/../lib/clang/3.7.0/include -internal-externc-isystem
/include -internal-externc-isystem /usr/include -fdeprecated-macro
-fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 0 -mstackrealign
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o
bug.o -x c++ bug.cc
clang -cc1 version 3.7.0 based upon LLVM 3.7.0 default target
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/tools/pkg/gcc/4.9.3/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../../../include/c++/4.9.3
/tools/pkg/gcc/4.9.3/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../../../include/c++/4.9.3/x86_64-unknown-linux-gnu
/tools/pkg/gcc/4.9.3/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../../../include/c++/4.9.3/backward
/usr/local/include
/tools/pkg/clang/3.7.0/bin/../lib/clang/3.7.0/include
/usr/include
End of search list.
bug.cc:1:10: fatal error: 'no_such_file.h' file not found
#include "no_such_file.h"
^
0 clang 0x02a44305
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1 clang 0x02a436d1
2 libpthread.so.0 0x7f8ed88d3130
3 clang 0x00e77ffc
clang::Sema::BuildCXXDefaultArgExpr(clang::SourceLocation,
clang::FunctionDecl*, clang::ParmVarDecl*) + 1516
4 clang 0x00e826fc
clang::Sema::GatherArgumentsForCall(clang::SourceLocation,
clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int,
llvm::ArrayRef, llvm::SmallVectorImpl&,
clang::Sema::VariadicCallType, bool, bool) + 684
5 clang 0x00e83582
clang::Sema::ConvertArgumentsForCall(clang::CallExpr*, clang::Expr*,
clang::FunctionDecl*, clang::FunctionProtoType const*,
llvm::ArrayRef, clang::SourceLocation, bool) + 2226
6 clang 0x00e84723
clang::Sema::BuildResolvedCallExpr(clang::Expr*, clang::NamedDecl*,
clang::SourceLocation, llvm::ArrayRef, clang::SourceLocation,
clang::Expr*, bool) + 2643
7 clang 0x00fa6e93
8 clang 0x00fa755e
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation,
llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool)
+ 1022
9 clang 0x00e8519a clang::Sema::ActOnCallExpr(clang::Scope*,
clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation, clang::Expr*, bool) + 1754
10 clang 0x00c5b6ee
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult) + 2830
11 clang 0x00c55e1b clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::Parser::TypeCastState) + 107
12 clang 0x00c5850d clang::Parser::ParseCastExpression(bool,
bool, clang::Parser::TypeCastState) + 29
13 clang 0x00c5858f
clang::Parser::ParseAssignmentExpression(clang::
[llvm-bugs] [Bug 26495] New: Inliner fails with negative threshholds
https://llvm.org/bugs/show_bug.cgi?id=26495
Bug ID: 26495
Summary: Inliner fails with negative threshholds
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: david.majne...@gmail.com, era...@google.com,
llvm-bugs@lists.llvm.org
Classification: Unclassified
David reported on IRC the other week that we fail to inline g into f and f into
h here:
target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-windows-msvc"
define void @h(i8* nocapture readnone %this) {
entry:
call void @f(i8* %this)
unreachable
}
define linkonce_odr void @f(i8* nocapture readnone %this) {
entry:
tail call void @g(i8* %this)
unreachable
}
define linkonce_odr void @g(i8* nocapture readnone %this) {
entry:
br label %for.cond
for.cond:
tail call void @foo(i32 1)
br label %for.cond
}
declare void @foo(i32)
$ bin/opt -inline /tmp/a.ll -S -debug
[..]
Analyzing call of g...
NumConstantArgs: 0
NumConstantOffsetPtrArgs: 1
NumAllocaArgs: 0
NumConstantPtrCmps: 0
NumConstantPtrDiffs: 0
NumInstructionsSimplified: 1
NumInstructions: 2
SROACostSavings: 0
SROACostSavingsLost: 0
ContainsNoDuplicateCall: 0
Cost: 30
Threshold: -337
NOT Inlining: cost=30, thres=-337, Call: tail call void @g(i8* %this)
Inliner visiting SCC: h: 1 call sites.
Analyzing call of f...
NumConstantArgs: 0
NumConstantOffsetPtrArgs: 1
NumAllocaArgs: 0
NumConstantPtrCmps: 0
NumConstantPtrDiffs: 0
NumInstructionsSimplified: 0
NumInstructions: 1
SROACostSavings: 0
SROACostSavingsLost: 0
ContainsNoDuplicateCall: 0
Cost: 30
Threshold: -337
NOT Inlining: cost=30, thres=-337, Call: call void @f(i8* %this)
--
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 26496] New: clang-format option for space after operator
https://llvm.org/bugs/show_bug.cgi?id=26496
Bug ID: 26496
Summary: clang-format option for space after operator
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: ashwin_a_jad...@yahoo.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
We have a weird coding standard where there are no spaces before and after
operators.
Eg.,
int variable=0;
if(variable==0) {
// Observe no space before and after ==
}
etc.
I couldn't find a similar bug/enhancement on this.
It would be nice to have this option or a workaround.
--
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 26497] New: [CUDA] call to pow is ambiguous
https://llvm.org/bugs/show_bug.cgi?id=26497
Bug ID: 26497
Summary: [CUDA] call to pow is ambiguous
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: wujing...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Is this intended?
// pow.cu
using namespace std;
__global__ void foo(double* dd) {
dd[0] = pow(dd[1], dd[2]);
}
$ clang++ pow.cu -c
pow.cu:4:11: error: call to 'pow' is ambiguous
dd[0] = pow(dd[1], dd[2]);
^~~
/usr/local/cuda/include/math_functions_dbl_ptx3.hpp:350:41: note: candidate
function
__MATH_FUNCTIONS_DBL_PTX3_DECL__ double pow(double a, double b)
^
/usr/local/google/home/jingyue/Work/llvm/install-git/bin/../lib/clang/3.9.0/include/__clang_cuda_cmath.h:186:19:
note: candidate function
__DEVICE__ double pow(double base, double exp) { return ::pow(base, exp); }
^
/usr/local/google/home/jingyue/Work/llvm/install-git/bin/../lib/clang/3.9.0/include/__clang_cuda_cmath.h:187:19:
note: candidate function
__DEVICE__ double pow(double base, int iexp) { return ::powi(base, iexp); }
^
/usr/local/google/home/jingyue/Work/llvm/install-git/bin/../lib/clang/3.9.0/include/__clang_cuda_cmath.h:184:18:
note: candidate function
__DEVICE__ float pow(float base, float exp) { return ::powf(base, exp); }
^
/usr/local/google/home/jingyue/Work/llvm/install-git/bin/../lib/clang/3.9.0/include/__clang_cuda_cmath.h:185:18:
note: candidate function
__DEVICE__ float pow(float base, int iexp) { return ::powif(base, iexp); }
^
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 26498] New: Extern template function not emitted available_externally while class methods are
https://llvm.org/bugs/show_bug.cgi?id=26498
Bug ID: 26498
Summary: Extern template function not emitted
available_externally while class methods are
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mehdi.am...@apple.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Considering this code:
template F foo() { return 1; }
template struct S { F foo() { return 1; } };
extern template int foo();
extern template struct S;
int bar() { return foo() + S().foo(); }
Compiled with: clang++ -O2 -mllvm -disable-llvm-optzns -S -emit-llvm -o - |
grep foo
We can see:
%2 = call i32 @_Z3fooIiET_v()
%3 = call i32 @_ZN1SIiE3fooEv(%struct.S* %1)
declare i32 @_Z3fooIiET_v() #1
define available_externally i32 @_ZN1SIiE3fooEv(%struct.S* %this) #2 align 2 {
I'm not sure why the extern template class method is emitted
available_externally while the free function is not.
--
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 20142] make install fails
https://llvm.org/bugs/show_bug.cgi?id=20142 Eric Fiselier changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||e...@efcs.ca Resolution|--- |INVALID --- Comment #2 from Eric Fiselier --- The makefile has been removed. -- 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 21917] Error in std::pair default constructor when elements are not default-constructible
https://llvm.org/bugs/show_bug.cgi?id=21917 Eric Fiselier changed: What|Removed |Added Status|REOPENED|RESOLVED CC||e...@efcs.ca Resolution|--- |FIXED --- Comment #3 from Eric Fiselier --- This should be fixed in r256325. -- 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 26499] New: [testcase attached] Compiler crash while compiling 'aseprite'
https://llvm.org/bugs/show_bug.cgi?id=26499 Bug ID: 26499 Summary: [testcase attached] Compiler crash while compiling 'aseprite' Product: clang Version: 3.7 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: y...@tsoft.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org Classification: Unclassified Compilation of the FreeBSD port for https://github.com/aseprite/aseprite version 1.1.1 fails with clang37-3.7_3, see attachments. -- 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 26500] New: PowerPC64: CR spill code causes SEGV
https://llvm.org/bugs/show_bug.cgi?id=26500 Bug ID: 26500 Summary: PowerPC64: CR spill code causes SEGV Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: an...@samba.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified I've seen a few SEGVs when running csmith. In all the cases I have looked at, we've dereferenced what looks like a condition register value: One example: r3 0x4242 => 0x1bdc <+1516>:lhz r3,30996(r3) What is interesting is that the CR spill gets scheduled quite a way into the function, after we've used r12 for something else. Later on we reuse r12 (which has now been contaminated with a CR). Use r12: 1734: ff ff 82 3d addis r12,r2,-1 Spill CR using r12 as scratch: 17fc: 26 00 80 7d mfcrr12 180c: 08 00 81 91 stw r12,8(r1) Use value in r12 later on: 1914: a8 00 9f f9 std r12,168(r31) 1bcc: a8 00 7f e8 ld r3,168(r31) LLVM seems to use r12 unconditionally for CR spill, are we missing some sort of r12 clobber? -- 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 26473] [3.8 rc2] ThreadPoolTest.* fails on SystemZ
https://llvm.org/bugs/show_bug.cgi?id=26473 Ulrich Weigand changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Ulrich Weigand --- Now also fixed on the 3.8 branch. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26497] [CUDA] call to pow is ambiguous
https://llvm.org/bugs/show_bug.cgi?id=26497 Artem Belevich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|C++ |Headers Resolution|--- |FIXED Assignee|t...@google.com |unassignedclangbugs@nondot. ||org --- Comment #3 from Artem Belevich --- Should be fixed in r259944 -- 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 26501] New: error : clang frontend command failed due to signal (use -v to see invocation)
https://llvm.org/bugs/show_bug.cgi?id=26501 Bug ID: 26501 Summary: error : clang frontend command failed due to signal (use -v to see invocation) Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: reupenl...@forward.cat CC: llvm-bugs@lists.llvm.org Classification: Unclassified Using LLVM-3.9.0-r259040-win32.exe. (I have also tried LLVM-3.9.0-r259040-win64.exe and LLVM-3.8.0-r257516-win32.exe.) Using Visual Studio 2015 Update 1, in the x86 Native Tools command prompt, with both Windows SDK 10 and Windows SDK 7.1 installed. This error happens in the middle of compilation, using msbuild: clang-cl.exe : error : clang frontend command failed due to signal (use -v to see invocation) [F:\foobar2000\columns_ui\foobar2000\SDK\foobar2000_SDK.vcxproj] clang version 3.9.0 (trunk) Target: i686-pc-windows-msvc Thread model: posix InstalledDir: C:\Program Files (x86)\LLVM\msbuild-bin clang-cl.exe: 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-cl.exe: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\abort_callback-cbff92.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\advconfig-78cac1.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\album_art-6dd44b.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\app_close_blocker-52f9ba.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\audio_chunk-169ec1.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\audio_chunk_channel_config-9d13e4.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\cfg_var-fe663c.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\chapterizer-544fec.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\commandline-159cf5.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\completion_notify-5e1eb6.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\componentversion-89aa00.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\config_object-5eb327.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\console-6f5271.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\dsp-5a0e99.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\dsp_manager-f32dad.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\file_cached_impl-c311c9.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\file_info-f6ca04.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\file_info_impl-6dc123.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\file_info_merge-bca036.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\file_operation_callback-07c84a.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\filesystem-e72037.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\filesystem_helper-cfe861.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\guids-e675d8.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\hasher_md5-56ed26.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\input-27f0cd.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\input_file_type-ea3dca.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\link_resolver-812ce6.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\mainmenu-6392e3.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\main_thread_callback-67a518.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\mem_block_container-d672f5.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\menu_helpers-fe62cd.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\menu_item-0dc4ff.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\menu_manager-4cab60.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\metadb-941522.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\metadb_handle-94fc9b.cpp clang-cl.exe: note: diagnostic msg: C:\Users\llvm\AppData\Local\Temp\metadb_handle_list-cdb327.cpp clang-cl.exe:
[llvm-bugs] [Bug 26502] New: LLVM ERROR: unable to evaluate offset to undefined symbol
https://llvm.org/bugs/show_bug.cgi?id=26502 Bug ID: 26502 Summary: LLVM ERROR: unable to evaluate offset to undefined symbol Product: libraries Version: 3.8 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: jholaj...@arxan.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 15840 --> https://llvm.org/bugs/attachment.cgi?id=15840&action=edit Bitcode file that reproduces the issue The following IR is causing a failure in llc when lowering to an object file: ; RUN: llc double-alias.bc -filetype=obj -o double-alias.o @bar = global i32 0 @foo2 = alias i32, i32* @bar @foo3 = alias i32, i32* @foo2 @baz = global i32* @foo3 Is redirection through multiple aliases supposed to work? If @baz is modified to reference @foo2 instead of @foo3, the IR lowers to an object file successfully. Without asserts enabled, the following error is seen: LLVM ERROR: unable to evaluate offset to undefined symbol '_foo2' With asserts enabled, the following assert is seen: Assertion failed: ((SymbolContents == SymContentsUnset || SymbolContents == SymContentsOffset) && "Cannot get offset for a common/variable symbol"), function getOffset, file /llvm-3.8-rc1/src/include/llvm/MC/MCSymbol.h, line 317. 0 llc 0x000c2a5e llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46 1 llc 0x000c2e99 PrintStackTraceSignalHandler(void*) + 25 2 llc 0x000bf729 llvm::sys::RunSignalHandlers() + 425 3 llc 0x000c31e2 SignalHandler(int) + 354 4 libsystem_platform.dylib 0x7fff885c2eaa _sigtramp + 26 5 llc 0x000111e06635 ErrorCategory + 87253 6 llc 0x000c2ebb raise + 27 7 llc 0x000c2f62 abort + 18 8 llc 0x000c2f4e __assert_rtn + 126 9 llc 0x000110bb988e llvm::MCSymbol::getOffset() const + 126 10 llc 0x000110bbc25d getLabelOffset(llvm::MCAsmLayout const&, llvm::MCSymbol const&, bool, unsigned long long&) + 221 11 llc 0x000110bba362 getSymbolOffsetImpl(llvm::MCAsmLayout const&, llvm::MCSymbol const&, bool, unsigned long long&) + 322 12 llc 0x000110bba456 llvm::MCAsmLayout::getSymbolOffset(llvm::MCSymbol const&) const + 38 13 llc 0x000110b82f21 llvm::MCAssembler::evaluateFixup(llvm::MCAsmLayout const&, llvm::MCFixup const&, llvm::MCFragment const*, llvm::MCValue&, unsigned long long&) const + 625 14 llc 0x000110b85036 llvm::MCAssembler::handleFixup(llvm::MCAsmLayout const&, llvm::MCFragment&, llvm::MCFixup const&) + 182 15 llc 0x000110b85a7f llvm::MCAssembler::layout(llvm::MCAsmLayout&) + 2223 16 llc 0x000110b85f33 llvm::MCAssembler::Finish() + 83 17 llc 0x000110bd07ff llvm::MCObjectStreamer::FinishImpl() + 191 18 llc 0x000110bc2017 (anonymous namespace)::MCMachOStreamer::FinishImpl() + 807 19 llc 0x000110bdba35 llvm::MCStreamer::Finish() + 149 20 llc 0x000110296a21 llvm::AsmPrinter::doFinalization(llvm::Module&) + 5425 21 llc 0x000110a4e5d4 llvm::FPPassManager::doFinalization(llvm::Module&) + 84 22 llc 0x000110a4f7f3 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) + 3603 23 llc 0x000110a4e766 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 342 24 llc 0x000110a4fd81 llvm::legacy::PassManager::run(llvm::Module&) + 33 25 llc 0x00010eece223 compileModule(char**, llvm::LLVMContext&) + 19363 26 llc 0x00010eec9621 main + 225 27 libdyld.dylib0x7fff85f6a5ad start + 1 28 libdyld.dylib0x0005 start + 2047433305 Stack dump: 0. Program arguments: /llvm-3.8-rc1/build/bin/llc double-alias.ll -filetype=obj -o double-alias.o Illegal instruction: 4 The attached bc and ll files are for LLVM-3.8 RC2, but this is reproducible on older versions of LLVM as well. -- 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 26059] [meta] 3.8.0 Release Blockers
https://llvm.org/bugs/show_bug.cgi?id=26059 Bug 26059 depends on bug 25804, which changed state. Bug 25804 Summary: readability-redundant-smartptr-get doesn't report get() usage in conditions https://llvm.org/bugs/show_bug.cgi?id=25804 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 26503] New: std::quoted doesn't work with char16_t or char32_t strings.
https://llvm.org/bugs/show_bug.cgi?id=26503 Bug ID: 26503 Summary: std::quoted doesn't work with char16_t or char32_t strings. Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: e...@efcs.ca CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified It instantiates some ctype templates which have not yet been defined for these character types. -- 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 26504] New: Overload resolution is strange with constexpr
https://llvm.org/bugs/show_bug.cgi?id=26504
Bug ID: 26504
Summary: Overload resolution is strange with constexpr
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider this:
Nicos-MBP:llvm-build thakis$ cat test.cc
template const T& min(const T& a, const T& b) {
return a < b ? a : b;
}
struct A {
A();
operator int() const;
operator unsigned() const;
A foo() const {
return min(*this, A());
}
};
inline bool operator<(const A &a, const A &b) { return true; }
Nicos-MBP:llvm-build thakis$ bin/clang -c test.cc -std=c++11
This builds fine. Now make max() constexpr:
Nicos-MBP:llvm-build thakis$ bin/clang -c test.cc -std=c++11
test.cc:2:12: error: use of overloaded operator '<' is ambiguous (with operand
types 'const A' and 'const A')
return a < b ? a : b;
~ ^ ~
test.cc:10:12: note: in instantiation of function template specialization
'min' requested here
return min(*this, A());
^
test.cc:2:12: note: because of ambiguity in conversion of 'const A' to 'float'
return a < b ? a : b;
^
test.cc:6:3: note: candidate function
operator int() const;
^
test.cc:7:3: note: candidate function
operator unsigned() const;
^
test.cc:2:12: note: because of ambiguity in conversion of 'const A' to 'float'
return a < b ? a : b;
^
test.cc:6:3: note: candidate function
operator int() const;
^
test.cc:7:3: note: candidate function
operator unsigned() const;
^
test.cc:2:12: note: built-in candidate operator<(float, float)
return a < b ? a : b;
^
test.cc:2:12: note: built-in candidate operator<(float, double)
test.cc:2:12: note: built-in candidate operator<(float, long double)
test.cc:2:12: note: built-in candidate operator<(float, int)
test.cc:2:12: note: built-in candidate operator<(float, long)
test.cc:2:12: note: built-in candidate operator<(float, long long)
test.cc:2:12: note: built-in candidate operator<(float, __int128)
test.cc:2:12: note: built-in candidate operator<(float, unsigned int)
test.cc:2:12: note: built-in candidate operator<(float, unsigned long)
test.cc:2:12: note: built-in candidate operator<(float, unsigned long long)
test.cc:2:12: note: built-in candidate operator<(float, unsigned __int128)
test.cc:2:12: note: built-in candidate operator<(double, float)
test.cc:2:12: note: built-in candidate operator<(double, double)
test.cc:2:12: note: built-in candidate operator<(double, long double)
test.cc:2:12: note: built-in candidate operator<(double, int)
test.cc:2:12: note: built-in candidate operator<(double, long)
test.cc:2:12: note: built-in candidate operator<(double, long long)
test.cc:2:12: note: built-in candidate operator<(double, __int128)
test.cc:2:12: note: built-in candidate operator<(double, unsigned int)
test.cc:2:12: note: built-in candidate operator<(double, unsigned long)
test.cc:2:12: note: built-in candidate operator<(double, unsigned long long)
test.cc:2:12: note: built-in candidate operator<(double, unsigned __int128)
test.cc:2:12: note: built-in candidate operator<(long double, float)
test.cc:2:12: note: built-in candidate operator<(long double, double)
test.cc:2:12: note: built-in candidate operator<(long double, long double)
test.cc:2:12: note: built-in candidate operator<(long double, int)
test.cc:2:12: note: built-in candidate operator<(long double, long)
test.cc:2:12: note: built-in candidate operator<(long double, long long)
test.cc:2:12: note: built-in candidate operator<(long double, __int128)
test.cc:2:12: note: built-in candidate operator<(long double, unsigned int)
test.cc:2:12: note: built-in candidate operator<(long double, unsigned long)
test.cc:2:12: note: built-in candidate operator<(long double, unsigned long
long)
test.cc:2:12: note: built-in candidate operator<(long double, unsigned
__int128)
test.cc:2:12: note: built-in candidate operator<(int, float)
test.cc:2:12: note: built-in candidate operator<(int, double)
test.cc:2:12: note: built-in candidate operator<(int, long double)
test.cc:2:12: note: built-in candidate operator<(int, int)
test.cc:2:12: note: built-in candidate operator<(int, long)
test.cc:2:12: note: built-in candidate operator<(int, long long)
test.cc:2:12: note: built-in candidate operator<(int, __int128)
test.cc:2:12: note: built-in candidate operator<(int, unsigned int)
test.cc:2:12: note: built-in candidate operator<(int, unsigned long)
test.cc:2:12: note: built-in candidate operator<(int, unsigned long long)
test.cc:2:12: note: built-in candidate operator<(int, unsigned __int128)
test.cc:2:12: note: built-in candidate operator<(long, float)
test.cc:2:12: note: built-in candidate operator<(long, double)
te
