[llvm-bugs] [Bug 39021] llvm-exegesis build on x86 doesn't set LLVM_EXEGESIS_INITIALIZE_NATIVE_TARGET
https://bugs.llvm.org/show_bug.cgi?id=39021 Clement Courbet changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassignedb...@nondot.org |clement.cour...@gmail.com --- Comment #3 from Clement Courbet --- Fixed by D52343/r342865. -- 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] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #4 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c4 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-47802a32-ef2e-4387-87a1-d0d91d1894ca.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39058] New: warning: SubRegIndex SystemZ::subreg_h64 and SystemZ::subreg_h32 compose ambiguously as SystemZ::subreg_hh32 or SystemZ::subreg_h32
https://bugs.llvm.org/show_bug.cgi?id=39058 Bug ID: 39058 Summary: warning: SubRegIndex SystemZ::subreg_h64 and SystemZ::subreg_h32 compose ambiguously as SystemZ::subreg_hh32 or SystemZ::subreg_h32 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: SystemZ Assignee: unassignedb...@nondot.org Reporter: franci...@yahoo.com CC: llvm-bugs@lists.llvm.org While building trunk at r342870, I get the following warning: [2131/7124] Building SystemZGenRegisterInfo.inc... warning: SubRegIndex SystemZ::subreg_h64 and SystemZ::subreg_h32 compose ambiguously as SystemZ::subreg_hh32 or SystemZ::subreg_h32 I suspect this is https://llvm.org/r339778. -- 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 39059] New: wrong code at -O3 on x86_64-linux-gnu (generated code hangs)
https://bugs.llvm.org/show_bug.cgi?id=39059
Bug ID: 39059
Summary: wrong code at -O3 on x86_64-linux-gnu (generated code
hangs)
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Tested with trunk revision 342871.
$ clangpolly -v
clang version 8.0.0 (http://llvm.org/git/clang.git
4eca03e7d21186125ac4503bd7579bbb10a36961) (http://llvm.org/git/llvm.git
2948bf4bf86331542d2829f9164d54f4fb267e3d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/su/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.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.4
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.5
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
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clangpolly -O2 small.c
$ ./a.out
$
$ clangpolly -O3 small.c
$ timeout -s 9 5 ./a.out
Killed
$
--
int printf (const char *, ...);
struct
{
int a;
} *b;
int c, d = 1, e, f;
int main ()
{
int g = 1, h = 1, i = 129, j = 1;
L1:;
int l = i;
i = d;
L2:
if (c)
while (b->a)
h = 2;
if (d < 0)
{
printf ("%d\n", i);
f = j >> l || e << e;
}
if (!i)
j = 0;
int n = g;
g = 0;
if (h > 2)
goto L2;
if (!n)
goto L1;
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 39060] New: WebRTC miscompile after ARMCodeGenPrepare was enabled
https://bugs.llvm.org/show_bug.cgi?id=39060
Bug ID: 39060
Summary: WebRTC miscompile after ARMCodeGenPrepare was enabled
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org, sam.par...@arm.com
Consider the following:
typedef unsigned short uint16_t;
uint16_t a = 0x;
uint16_t b = 0;
void f();
void g();
void test() {
if (a != static_cast(b-1)) {
f(); // Shouldn't reach this point.
} else {
g();
}
}
With clang+llvm at r341931
$ clang -S -o - --target=arm-linux-androideabi -Oz /tmp/a.cc -mthumb
-march=armv7-a -mfloat-abi=softfp -mtune=generic-armv7-a -mfpu=neon
...
ldrhr0, [r0]
ldrhr1, [r1]
subsr0, #1<--- subtract
uxthr0, r0<--- truncate to 16-bit
cmp r1, r0<--- compare
it eq
beq _Z1gv
b _Z1fv
...
At r341932:
...
ldrhr0, [r0]
ldrhr1, [r1]
subsr0, #1
cmp r1, r0
it eq
beq _Z1gv
b _Z1fv
...
The UXTH instruction has gone missing. The comparison will fail because it's
comparing 0x (32-bit -1) against 0x.
Chromium ran into this when running WebRTC tests on Android.
--
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 36084] [X86] IMUL instructions missing from Sandybridge scheduler model
https://bugs.llvm.org/show_bug.cgi?id=36084 Clement Courbet changed: 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 36931] [X86] Split WriteIMul into 8/16/32/64 implementations
https://bugs.llvm.org/show_bug.cgi?id=36931 Bug 36931 depends on bug 36084, which changed state. Bug 36084 Summary: [X86] IMUL instructions missing from Sandybridge scheduler model https://bugs.llvm.org/show_bug.cgi?id=36084 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 32325] [META][X86] Improve implementation and use of X86 scheduler models
https://bugs.llvm.org/show_bug.cgi?id=32325 Bug 32325 depends on bug 36084, which changed state. Bug 36084 Summary: [X86] IMUL instructions missing from Sandybridge scheduler model https://bugs.llvm.org/show_bug.cgi?id=36084 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] Issue 9239 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-sccp: Heap-use-after-free in SCCPSolver::visitCmpInst
Updates: Labels: Deadline-Approaching Comment #3 on issue 9239 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-sccp: Heap-use-after-free in SCCPSolver::visitCmpInst https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9239#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 36550] Derive TTI instruction costs from scheduling models
https://bugs.llvm.org/show_bug.cgi?id=36550 Bug 36550 depends on bug 36931, which changed state. Bug 36931 Summary: [X86] Split WriteIMul into 8/16/32/64 implementations https://bugs.llvm.org/show_bug.cgi?id=36931 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 32325] [META][X86] Improve implementation and use of X86 scheduler models
https://bugs.llvm.org/show_bug.cgi?id=32325 Bug 32325 depends on bug 36931, which changed state. Bug 36931 Summary: [X86] Split WriteIMul into 8/16/32/64 implementations https://bugs.llvm.org/show_bug.cgi?id=36931 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 36931] [X86] Split WriteIMul into 8/16/32/64 implementations
https://bugs.llvm.org/show_bug.cgi?id=36931 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|rL331770|rL331770, rL342892 Status|NEW |RESOLVED --- Comment #2 from Simon Pilgrim --- rL342892 splits WriteIMul by size and also by IMUL multiply-by-imm and multiply-by-reg cases, removing all overrides in the scheduler models. -- 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 36908] [meta][x86] Improve scheduler classes instruction coverage
https://bugs.llvm.org/show_bug.cgi?id=36908 Bug 36908 depends on bug 36931, which changed state. Bug 36931 Summary: [X86] Split WriteIMul into 8/16/32/64 implementations https://bugs.llvm.org/show_bug.cgi?id=36931 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 37131] [X86] Review current scheduler classes to minimise need for InstRW overrides
https://bugs.llvm.org/show_bug.cgi?id=37131 Bug 37131 depends on bug 36931, which changed state. Bug 36931 Summary: [X86] Split WriteIMul into 8/16/32/64 implementations https://bugs.llvm.org/show_bug.cgi?id=36931 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 39048] NRVO (elide-constructors) code generation is running in the C compiler
https://bugs.llvm.org/show_bug.cgi?id=39048
Reid Kleckner changed:
What|Removed |Added
CC||r...@google.com
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #1 from Reid Kleckner ---
The optimization applies to C in cases like this:
struct BigStruct { long x, y, z, w; };
struct BigStruct foo(int a) {
struct BigStruct rv = {};
return rv;
}
You can see the LLVM IR difference by adding and removing the flag more clearly
on godbolt: https://gcc.godbolt.org/z/TuzhSJ
In this case, the optimization will avoid allocating memory for rv in foo, and
will use the out parameter allocated in the caller's stack frame.
It is by design that we do this by default in C as well as C++. It has nothing
to do with constructors, really. My understanding of the history is that Clang
implemented NRVO by default, and then someone came along and added the
non-default -fno-elide-constructors option for code bases that needed it.
Marking "invalid" to mean "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 34474] Failure to multiply 'pow2 +/-1' vectors with shl+add/sub
https://bugs.llvm.org/show_bug.cgi?id=34474 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Simon Pilgrim --- (In reply to Sanjay Patel from comment #8) > Negative constant support added here: > http://llvm.org/viewvc/llvm-project?view=revision&revision=342844 > > (Looks like Phab-equivalent notifications/links for commits haven't been > generated since sometime yesterday.) > > Still not sure if we want to address the pmullw/pmulld questions within this > report? Thanks Sanjay, I think we can close this. Re PMULLW/PMULLD - this maybe useful for some cases (FeatureSlowPMULLD, constant pool size, broadcast-vs-hoisted-vs-non-hoisted constants etc.) but that can wait for 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 39061] New: internal-linkage variable named 'main' rejected
https://bugs.llvm.org/show_bug.cgi?id=39061 Bug ID: 39061 Summary: internal-linkage variable named 'main' rejected Product: clang Version: 5.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: dgre...@apple.com, llvm-bugs@lists.llvm.org A program containing this is ill-formed: int main = /*...*/; However, this appears to be valid: static int main = /*...*/; Clang rejects both. -- 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 33306] LTO doesn't store -mcmodel= information in the bitcode files
https://bugs.llvm.org/show_bug.cgi?id=33306 Caroline Tice changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Caroline Tice --- I believe https://reviews.llvm.org/D52322 and https://reviews.llvm.org/D52323 fix this problem. They definitely fix the issue of passing the mcmodel information to LTO. -- 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 39062] New: bracket vs. vector-cast precedence for OpenCL
https://bugs.llvm.org/show_bug.cgi?id=39062
Bug ID: 39062
Summary: bracket vs. vector-cast precedence for OpenCL
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: pjc...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 20911
--> https://bugs.llvm.org/attachment.cgi?id=20911&action=edit
.cl precedence difference
We ran into the following difference. The behavior here seemed to change
between LLVM 4 and LLVM 5.
On the attached, there is a difference in compiling:
typedef int int4 __attribute__((ext_vector_type(4)));
void s(int4 *x, const int* y) {
x[0] = (int4)(y)[0];
}
with clang -x c vs. clang -x cl
clang -O2 -x c -S -emit-llvm gives:
%3 = load i32, i32* %1, align 4, !tbaa !3
%4 = insertelement <4 x i32> undef, i32 %3, i32 0
%5 = shufflevector <4 x i32> %4, <4 x i32> undef, <4 x i32> zeroinitializer
while clang -O2 -x cl -S -emit-llvm gives:
%3 = ptrtoint i32* %1 to i32
%4 = insertelement <4 x i32> undef, i32 %3, i32 0
%5 = shufflevector <4 x i32> %4, <4 x i32> undef, <4 x i32> zeroinitializer
Is this intentional?
--
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 39063] New: 32-bit and 64-bit pre-built binaries for Windows are invalid
https://bugs.llvm.org/show_bug.cgi?id=39063 Bug ID: 39063 Summary: 32-bit and 64-bit pre-built binaries for Windows are invalid Product: clang Version: 7.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: j...@teamqsi.com CC: llvm-bugs@lists.llvm.org Created attachment 20912 --> https://bugs.llvm.org/attachment.cgi?id=20912&action=edit Dialog box received when attempting to install LLVM 7.0.0 I have tried multiple downloads. All of them for a given platform (32-bit/64-bit) were the same size and all gave an error message during installation that they were invalid due to a failed integrity check. The 64-bit installation is about 25 MB smaller than the one for 6.0.1 (95 MB vs 120 MB). -- 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 39064] New: scan-build reports a false positive nullptr dereference because it apparently incorrectly tracks the value of a class member
https://bugs.llvm.org/show_bug.cgi?id=39064
Bug ID: 39064
Summary: scan-build reports a false positive nullptr
dereference because it apparently incorrectly tracks
the value of a class member
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: thomas.ullm...@mpibpc.mpg.de
CC: llvm-bugs@lists.llvm.org
Created attachment 20913
--> https://bugs.llvm.org/attachment.cgi?id=20913&action=edit
The full source and output of scan-build including the html-output
Scan-build warns for a nullptr dereference which can not
happen because a conditional makes sure that this branch
is never executed.
In the below example program the value of a boolean member
variable is assumed to be true although it is for the sake
of the example even declared const and initialized to false.
As a result, scan-build assumes that a condition that checks
the value of this bool is true, which would result in a nullptr
dereference.
/*-
a simple example program for debugging scan-build
---*/
#include
#include
/* --
A stripped-down version of a 3D array for debugging scan-build
-- */
template >
class IrregArray3D
{
public:
//! the data type stored in the array
typedef T value_type;
//! the allocator type to allocate value_type**
typedef typename std::allocator_traits::template
rebind_alloc p2_allocator_type;
//! the allocator type to allocate value_type*
typedef typename std::allocator_traits::template
rebind_alloc p_allocator_type;
//! the allocator type to allocate value_type
typedef typename std::allocator_traits::template
rebind_alloc allocator_type;
//! the allocator type to allocate value_type*
typedef typename std::allocator_traits::pointer
allocator_return_ptr_type;
//! the allocator type to allocate size_type
typedef typename std::allocator_traits::template
rebind_alloc allocator_size_type;
private:
//! ending index of dimension 1
size_t last1_;
//! ending index of dimension 2
size_t last2_;
//! ending index of dimension 3
size_t last3_;
//! irreg_ is constant nullptr
//! an array that would contain information on non-uniform array stripe
lengths
const size_t* irreg_;
//! array storing the the actual data
value_type ***arr_;
//! the allocator_ used to allocate arr_
p2_allocator_type p2_allocator_;
//! the allocator_ used to allocate arr_[i]
p_allocator_typep_allocator_;
//! the allocator_ used to allocate arr_[i][j]
allocator_type allocator_;
public:
//! this flag is const and set to false in the constructor
//! but scan-build considers it true
const bool isIrreg_;
IrregArray3D()
: last1_(-1), last2_(-1), last3_(-1),
isIrreg_(false), irreg_(nullptr), arr_(nullptr) { }
/*! \brief constructor for a regularly shaped data data with
initialization
\param[in]x2 last index in dimension 1
\param[in]y2 last index in dimension 2
\param[in]z2 last index in dimension 3
\param[in]ini initialization value for the data array
elements
*/
IrregArray3D(const size_t x2,
const size_t y2,
const size_t z2)
: IrregArray3D()
{
deallocateArray();
last1_ = x2;
last2_ = y2;
last3_ = z2;
allocateArray();
}
//! number of elements in dimension 1
size_t getLength1() const { return (last1_ + 1); }
//! number of elements in dimension 2 at lower dimension index x
//! \param[in]x index in dimension 1 for which the array
length in dimension 2 is requested
size_t getLength2() const { return (last2_ + 1); }
//! number of elements in dimension 3 at lower dimension indices x, y
//! \param[in]x index in dimension 1
//! \param[in]y index in dimension 2
size_t getLength3() const { return (last3_ + 1); }
//! get the last index of dimension 1
size_t getLast1() const { return last1_; }
//! get the last index of dimension 2 at lower dimension index x
//! \p
[llvm-bugs] [Bug 39065] New: clang does not support compilation with CUDA 10.0
https://bugs.llvm.org/show_bug.cgi?id=39065 Bug ID: 39065 Summary: clang does not support compilation with CUDA 10.0 Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: CUDA Assignee: unassignedclangb...@nondot.org Reporter: fwyz...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 20916 --> https://bugs.llvm.org/attachment.cgi?id=20916&action=edit Patch to add preliminary support for CUDA 10.0 Clang 7.0 and trunk do not support compiling CUDA code with the CUDA 10.0 SDK that has just been released. The attached path adds preliminary support for building with CUDA 10.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 39066] New: Clang should warn on returning a lambda which captures locals by reference.
https://bugs.llvm.org/show_bug.cgi?id=39066 Bug ID: 39066 Summary: Clang should warn on returning a lambda which captures locals by reference. Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: chandl...@gmail.com CC: llvm-bugs@lists.llvm.org, rtr...@google.com consider: https://gcc.godbolt.org/z/uB6Xar Clang should warn on returning a lambda with a local captured by reference. This seems ... really unlikely to be correct (although technically possible). -- 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 38865] x32: error in backend: Unable to copy EFLAGS physical register!
https://bugs.llvm.org/show_bug.cgi?id=38865 Craig Topper changed: What|Removed |Added Fixed By Commit(s)|r342015, r341972|r342015, r341972, r342796 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Craig Topper --- Fixed a memset bug in r342796. Closing based on the 3 fixed bugs. I'm sure there are more x32 bugs out there, but they should be filed separately. -- 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 38819] [X86] Crash compiling sitofp with sse1, no-x87, and 32-bit mode
https://bugs.llvm.org/show_bug.cgi?id=38819 Craig Topper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r342934 --- Comment #1 from Craig Topper --- Fixed in r342934 -- 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 39067] New: The keyword "try" in C++ function-try-blocks doesn't obey BraceWrapping settings
https://bugs.llvm.org/show_bug.cgi?id=39067
Bug ID: 39067
Summary: The keyword "try" in C++ function-try-blocks doesn't
obey BraceWrapping settings
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: owenpi...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
With the configuration file:
BreakBeforeBraces: Custom
BraceWrapping:
AfterControlStatement: true
The code below (https://en.cppreference.com/w/cpp/language/function-try-block)
int f(int n = 2) try {
++n; // increments the function parameter
throw n;
}
is incorrectly formatted to:
int f(int n = 2) try
{
++n; // increments the function parameter
throw n;
}
--
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
