[llvm-bugs] [Bug 44387] New: memory leak in locale.cpp
https://bugs.llvm.org/show_bug.cgi?id=44387
Bug ID: 44387
Summary: memory leak in locale.cpp
Product: libc++
Version: unspecified
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Standards Issues
Assignee: unassignedclangb...@nondot.org
Reporter: gavin.chang1...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
I am locating a memory leak problem about Android NDK shared library. When I
dlopen libc++_shared.so(which is the same with libc++.so) and dlclose it, there
will be an 8 bytes memory leak. And when I dlopen and dlclose it again, there
will be another 8 bytes memory leak.
And I find the leak is in the locale.cpp file.
In locale.cpp:
locale_t __cloc() {
// In theory this could create a race condition. In practice
// the race condition is non-fatal since it will just create
// a little resource leak. Better approach would be appreciated.
static locale_t result = newlocale(LC_ALL_MASK, "C", 0);
return result;
}
The variable 'result' will be allocated a locale object and never free.
Is it a memory leak 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 18029 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-gvn: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #2 on issue 18029 by sheriff...@chromium.org: llvm:llvm-opt-fuzzer--x86_64-gvn: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18029#c2 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 18009 in oss-fuzz: llvm:clang-fuzzer: ASSERT: (!isa(LookupCtx) || LookupCtx->isDependentContext() || cast(Lo
Updates: Labels: Deadline-Approaching Comment #2 on issue 18009 by sheriff...@chromium.org: llvm:clang-fuzzer: ASSERT: (!isa(LookupCtx) || LookupCtx->isDependentContext() || cast(Lo https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18009#c2 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 18032 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: I.use_empty() && "Cannot erase instruction that is used!"
Updates: Labels: Deadline-Approaching Comment #2 on issue 18032 by sheriff...@chromium.org: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: I.use_empty() && "Cannot erase instruction that is used!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18032#c2 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 18028 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: TRI.getRegSizeInBits(*getRegClass(DstReg)) == TRI.getRegSizeInBits(*getRegClass(
Updates: Labels: Deadline-Approaching Comment #2 on issue 18028 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: TRI.getRegSizeInBits(*getRegClass(DstReg)) == TRI.getRegSizeInBits(*getRegClass( https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18028#c2 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44388] New: memcpyopt adds incorrect align to memset
https://bugs.llvm.org/show_bug.cgi?id=44388
Bug ID: 44388
Summary: memcpyopt adds incorrect align to memset
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: juneyoung@sf.snu.ac.kr
CC: llvm-bugs@lists.llvm.org
Created attachment 22966
--> https://bugs.llvm.org/attachment.cgi?id=22966&action=edit
memset.src.ll
```
$ cat memset.src.ll
; Transforms/MemCpyOpt/form-memset.ll
define void @test6(i32* nocapture %P) nounwind ssp {
entry:
%0 = bitcast i32* %P to i8*
tail call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 12, i1 false)
%add.ptr = getelementptr inbounds i32, i32* %P, i64 3
%1 = bitcast i32* %add.ptr to i8*
tail call void @llvm.memset.p0i8.i64(i8* %1, i8 0, i64 12, i1 false)
ret void
}
declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i1) nounwind
$ ../llvm/build/bin/opt -memcpyopt memset.src.ll -S -o -
; ModuleID = 'memset.src.ll'
source_filename = "memset.src.ll"
; Function Attrs: nounwind ssp
define void @test6(i32* nocapture %P) #0 {
entry:
%0 = bitcast i32* %P to i8*
%add.ptr = getelementptr inbounds i32, i32* %P, i64 3
%1 = bitcast i32* %add.ptr to i8*
%2 = bitcast i32* %P to i8*
call void @llvm.memset.p0i8.i64(i8* align 4 %2, i8 0, i64 24, i1 false)
ret void
}
; Function Attrs: argmemonly nounwind willreturn
declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1 immarg)
#1
attributes #0 = { nounwind ssp }
attributes #1 = { argmemonly nounwind willreturn }
```
memcpyopt merges two memsets if they overlap and write the same value.
After merging, align 4 is added, which is incorrect because %P is not
guaranteed to have alignment 4.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44389] New: Missed constant folding for llvm.x86.bmi.pext.32
https://bugs.llvm.org/show_bug.cgi?id=44389 Bug ID: 44389 Summary: Missed constant folding for llvm.x86.bmi.pext.32 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: david.bolvan...@gmail.com CC: llvm-bugs@lists.llvm.org LLVM is unable to optimize %d = tail call i32 @llvm.x86.bmi.pext.32(i32 16371, i32 43690) https://gcc.godbolt.org/z/pZQaRc -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44390] New: Incorrect OpenMP target offload code at > -O0 optimization
https://bugs.llvm.org/show_bug.cgi?id=44390 Bug ID: 44390 Summary: Incorrect OpenMP target offload code at > -O0 optimization Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: csda...@lbl.gov CC: llvm-bugs@lists.llvm.org Created attachment 22968 --> https://bugs.llvm.org/attachment.cgi?id=22968&action=edit Source file, bitcode files and PTX files. I have ported an application named HPGMG from CUDA to OpenMP target offload. I have found that there are 4 functions containing OpenMP target offload which give incorrect floating point results (outside of expected floating point discrepancies) when using LLVM/Clang. The floating point results are only expected when compiling with -O0 optimization. The host versions of the functions are correct at -O1, -O2 and -O3 optimization levels (tested by setting OMP_TARGET_OFFLOAD=disabled). I have managed to isolate 1 expression in 1 of the 4 functions which produces incorrect floating point results when using LLVM/Clang. I have placed this expression in a function named apply_op_fn() in a separate file named smooth-debug-apply-op-ijk.c. I only need to compile this one file at -O0 optimization to give the correct results for this function. It seems that LLVM/Clang is generating incorrect PTX for the function apply_op_fn(). I believe it is this step because I only need to use -O0 optimization for the LLVM bitcode to PTX compilation step to get the correct results. I have attached a tarball containing the source file and the LLVM bitcode files and PTX files at -O0 and -O1 optimization levels. Results are correct when using -O0 and incorrect when using -O1. My test platform consists of Intel Skylake CPUs and NVIDIA V100 GPUs. I have tested two versions of LLVM/Clang: master branch from 23 December 2019 and 28 August 2019. Both have the same issue. I have also tested the IBM XLC compiler. The IBM XLC compiler gives expected results when compiling with either -O0 or -Ofast optimization levels. I appreciate any help here. My expectation is that all 4 functions are affected by the same compiler issue. Thanks, Chris -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44391] New: [Aarch64] Wshadow and vcopy intrinsic
https://bugs.llvm.org/show_bug.cgi?id=44391
Bug ID: 44391
Summary: [Aarch64] Wshadow and vcopy intrinsic
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: aleyz...@magicleap.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Here the code:
/// vcopy.c
#include
float32x4_t insert00(float32x4_t v1, float32x4_t v2) {
return vcopyq_laneq_f32(v1, 0, v2, 0);
}
$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ clang --target=aarch64-linux-gnu vcopy.c -c -I
/usr/aarch64-linux-gnu/include/ -E
# 2 "vcopy.c" 2
float32x4_t insert00(float32x4_t v1, float32x4_t v2) {
return __extension__ ({ float32x4_t __s0_70 = v1; float32x4_t __s2_70 = v2;
float32x4_t __ret_70; __ret_70 = __extension__ ({ float32_t __s0 =
__extension__ ({ float32x4_t __s0 = __s2_70; float32_t __ret; __ret =
(float32_t) __builtin_neon_vgetq_lane_f32((int8x16_t)__s0, 0); __ret; });
float32x4_t __s1 = __s0_70; float32x4_t __ret; __ret = (float32x4_t)
__builtin_neon_vsetq_lane_f32(__s0, (int8x16_t)__s1, 0); __ret; }); __ret_70;
});
Notice that code:
{ float32_t __s0 = __extension__ ({ float32x4_t __s0 = __s2_70; .
Should report a shadowing issue, but does fails to do so:
$ clang --target=aarch64-linux-gnu vcopy.c -c -I
/usr/aarch64-linux-gnu/include/ -Werror -Wshadow
does not report any issue at all.
But this code here (as the result of the clang -E > t1.c and reedited for
clarity)
t1.c
#include
float32x4_t insert00(float32x4_t v1, float32x4_t v2) {
return __extension__ ({ float32x4_t __s0_70 = v1; float32x4_t __s2_70 = v2;
float32x4_t __ret_70; __ret_70 = __extension__ ({ float32_t __s0 =
__extension__ ({ float32x4_t __s0 = __s2_70; float32_t __ret; __ret =
(float32_t) __builtin_neon_vgetq_lane_f32((int8x16_t)__s0, 0); __ret; });
float32x4_t __s1 = __s0_70; float32x4_t __ret; __ret = (float32x4_t)
__builtin_neon_vsetq_lane_f32(__s0, (int8x16_t)__s1, 0); __ret; }); __ret_70;
});
}
$ clang --target=aarch64-linux-gnu t1.c -c -I /usr/aarch64-linux-gnu/include/
-Werror -Wshadow
t1.c:4:176: error: declaration shadows a local variable [-Werror,-Wshadow]
...({ float32_t __s0 = __extension__ ({ float32x4_t __s0 = __s2_70;
float32...
^
t1.c:4:140: note: previous declaration is here
...float32x4_t __ret_70; __ret_70 = __extension__ ({ float32_t __s0 =
__ext...
^
1 error generated.
[Note: though I use clang 6.0, this can be reproduced with trunk clang]
Now. multiple questions obviously come to mind:
1- By what magic does clang remove the error in the first compilation (the one
of vcopy.c), but fails in the second case. Are those shadow errors inconsistent
or just deliberately trapped for some pattern and silently ignored?
2- Why so many neon intrinsics not functions? Does the compiler fails at
inlining them?
The reason for filing this bug is that I believe ccache (heavily used in the
context of building chromium) reuses the preprocessed C/C++ code and reinjects
them into the compilation process. And it fails when vcopy is used in the code.
There is an obvious workaround though (but only for clang), so make it a low
priority.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44392] New: In PTX inline assembly, special registers prefixed by `%` are rejected but those prefixed by `%%` are accepted
https://bugs.llvm.org/show_bug.cgi?id=44392 Bug ID: 44392 Summary: In PTX inline assembly, special registers prefixed by `%` are rejected but those prefixed by `%%` are accepted Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: CUDA Assignee: unassignedclangb...@nondot.org Reporter: brycelelb...@gmail.com CC: llvm-bugs@lists.llvm.org NVIDIA's PTX assembly language has special registers, which are read-only variables accessible through the `mov` or `cvt` instructions. Special registers have alphanumeric names, and are referenced in PTX assembly in the same way that registers are; by prefixing the special register name with `%`. However, Clang CUDA seems to reject the use of PTX special registers in inline assembly when they are prefixed with only a single `%`. Clang CUDA does accept the use of special registers when they are prefixed with '%%' instead. NVCC appears to also accept this, although it is not documented. My guess is that '%%' is an escape sequence in both cases, passing a single `%` through to the actual assembler. It would be nice if Clang CUDA supported the use of PTX special registers prefixed by a single `%` for consistency with NVCC. https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#special-registers https://godbolt.org/z/AEU3Fa -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44393] New: Wmissing-variable-declarations fires for static variable in module
https://bugs.llvm.org/show_bug.cgi?id=44393
Bug ID: 44393
Summary: Wmissing-variable-declarations fires for static
variable in module
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: da...@doublewise.net
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
The following translation unit:
```
export module foo;
namespace {
static constexpr int x = 5;
} // namespace
```
warns when compiled with `clang++ -std=c++2a -Wmissing-variable-declarations`
See it live: https://godbolt.org/z/YBPr-b
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
