[llvm-bugs] Issue 15726 in oss-fuzz: llvm/clang-fuzzer: Null-dereference READ in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2019-07-10 Type: Bug New issue 15726 by ClusterFuzz-External: llvm/clang-fuzzer: Null-dereference READ in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15726 Detailed report: https://oss-fuzz.com/testcase?key=5079555997433856 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: llvm::llvm_unreachable_internal clang::Sema::ActOnComment ActionCommentHandler::HandleComment Sanitizer: memory (MSAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5079555997433856 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for instructions to reproduce this bug locally. -- 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 42492] [PowerPC] segment fault for bootstrap
https://bugs.llvm.org/show_bug.cgi?id=42492 Chen Zheng (陈 正) changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Chen Zheng (陈 正) --- https://reviews.llvm.org/D64197 introduces dependancy from Analysis -> TransformUtils. The left hardeware loop checking code in HardwareLoops pass is based on existing of loop preheader and if there is no preheader, HardwareLoops pass inserts one. Inserting a preheader is ok in HardwareLoops pass, but it is nok in TargetTransformInfo.cpp. TargetTransformInfo.cpp is in Analyses library, currently it does not depend on TransformUtils library, so we meet symbol undefined issue if we build with -DBUILD_SHARED_LIBS=ON. Since the build crash should be fixed by https://reviews.llvm.org/rL365104 and it is unavoidable that isHardwareLoopCandidate() returns different value in CanSaveCmp() hook and HardwareLoops pass, I will abandon patch for item 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41208] Crash when compiling
https://bugs.llvm.org/show_bug.cgi?id=41208 Fangrui Song changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC||i...@maskray.me --- Comment #2 from Fangrui Song --- The crash goes away with clang trunk. # Delete "-add-plugin" "find-bad-constructs" "-plugin-arg-find-bad-constructs" from leveldb_scope-33eed2.sh % zsh leveldb_scope-33eed2.sh ... In file included from ../../content/browser/indexed_db/scopes/leveldb_scope.cc:5: In file included from ../../content/browser/indexed_db/scopes/leveldb_scope.h:16: In file included from ../../base/containers/flat_map.h:12: ../../base/containers/flat_tree.h:161:35: error: call to deleted member function 'operator=' flat_tree& operator=(flat_tree&&); -- 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 42560] New: Mangling of pipe is broken for Windows in C++ mode
https://bugs.llvm.org/show_bug.cgi?id=42560
Bug ID: 42560
Summary: Mangling of pipe is broken for Windows in C++ mode
Product: clang
Version: unspecified
Hardware: PC
OS: other
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: marco.antogn...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org,
r...@google.com
As mentioned in
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190708/278270.html,
the pipe types are not properly mangled on Windows.
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\CodeGenOpenCL\pipe_builtin.cl:9:1:
error: cannot mangle this OpenCL pipe type yet
void test1(read_only pipe int p, global int *ptr) {
^~~
1 error generated.
It's unlikely related to D64074, which added the test that triggered the bug
elsewhere: unlike in C mode, in C++ mode we are mangling user-defined
functions.
--
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 42561] New: Incorrect optimization of unique_ptr construction leads to segfault
https://bugs.llvm.org/show_bug.cgi?id=42561
Bug ID: 42561
Summary: Incorrect optimization of unique_ptr construction
leads to segfault
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: jas...@3db-labs.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
This comes from a Stack Overflow question I asked a long time ago:
https://stackoverflow.com/questions/43624400/is-this-unsafe-usage-of-a-braced-initializer-list-in-a-range-based-for-loop
A minimal test case is as follows:
--
#include
#include
struct Test
{
int x;
};
int main()
{
std::unique_ptr a(new Test);
std::unique_ptr b(new Test);
std::unique_ptr c(new Test);
int id = 0;
for(auto t : std::initializer_list({a.get(), b.get(), c.get()}))
t->x = id++;
return 0;
}
--
I compiled the above code with "-O3 -std=c++11". What I'm seeing is that,
since, clang v3.9, the above program crashes with a segfault pn my x86_64
system. From looking at the assembly that is generated, it appears that the
construction of the std::unique_ptr objects is optimized out, but the for loop
that dereferences the unique_ptr objects is not elided. Thus, an uninitialized
pointer is dereferenced and a segfault ensues.
I have the example code up on Compiler Explorer to show how the compiler output
evolves between clang versions:
https://gcc.godbolt.org/z/_7MK9z
It appears to work properly with versions before v3.9 (in which case it
optimizes out the entire program, which is reasonable).
--
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 42562] New: Darwin format archives add white space to the end of extracted members
https://bugs.llvm.org/show_bug.cgi?id=42562 Bug ID: 42562 Summary: Darwin format archives add white space to the end of extracted members Product: tools Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: llvm-ar Assignee: unassignedb...@nondot.org Reporter: gbrey...@gmail.com CC: llvm-bugs@lists.llvm.org When outputting an archive in the darwin format, either explicitly with "--format" or by defualt on macOSX, white space is added to the end of extracted members. I believe this is due to the padding added to members due to alignment being included in the members size. -- 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 29106] [clang-cl] Driver has no good way to refer to original spelling of an aliased option
https://bugs.llvm.org/show_bug.cgi?id=29106 Nico Weber changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Nico Weber --- r365413 -- 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 42563] New: [InstCombine] Dropping pointless masking before left shift
https://bugs.llvm.org/show_bug.cgi?id=42563 Bug ID: 42563 Summary: [InstCombine] Dropping pointless masking before left shift Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org Splitting off from https://bugs.llvm.org/show_bug.cgi?id=42456 just so i can track them separately. There's a bunch of patterns, even if we only look at 'masking'-like pattern. I guess i'm stumbling into a deep untouched woods that no one had in hotpaths.. a,b: https://rise4fun.com/Alive/4zsf c,d,e,f: https://rise4fun.com/Alive/RC49 -- 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 42564] New: calls to operator delete(..., const std::nothrow_t &) are optimized out
https://bugs.llvm.org/show_bug.cgi?id=42564
Bug ID: 42564
Summary: calls to operator delete(..., const std::nothrow_t &)
are optimized out
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: m...@trust-in-soft.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 0
--> https://bugs.llvm.org/attachment.cgi?id=0&action=edit
simple testcase
When a nothrow placement new flavour is used to allocate and initialize an
object, and the object's constructor throws an exception, the matching nothrow
delete operator must be invoked.
However, as soon as optimization is turned on, calls to these operators are
removed.
Consider the following trivial code:
#include
#include
void operator delete(void *, const std::nothrow_t &) noexcept { printf("delete
nothrow\n"); }
void operator delete[](void *, const std::nothrow_t &) noexcept {
printf("delete[] nothrow\n"); }
struct A { A() { throw 42; } };
int
main(int argc, char *argv[])
{
try { A *a = new(std::nothrow) A; } catch (...) { }
try { A *arr = new(std::nothrow) A[2]; } catch (...) { }
}
$ clang++ -O0 -fexceptions test.cpp && ./a.out
delete nothrow
delete[] nothrow
$ clang++ -O2 -fexceptions test.cpp && ./a.out
$
Tested with 7.0, 8.0 and today's godbolts' trunk on linux/x86_64.
FWIW, g++ -O0 and -O2 compile this correctly (with the operators being
invoked).
--
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 14340 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!RS || !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out
Updates: Labels: Deadline-Approaching Comment #2 on issue 14340 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: ASSERT: (!RS | | !RS->isScavengingFrameIndex(FrameIndex)) && "Emergency spill slot is out https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14340#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 14334 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-earlycse: ASSERT: (!LastStore || ParseMemoryInst(LastStore, TTI).getPointerOperand() == MemInst.ge
Updates: Labels: Deadline-Approaching Comment #2 on issue 14334 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-earlycse: ASSERT: (!LastStore || ParseMemoryInst(LastStore, TTI).getPointerOperand() == MemInst.ge https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14334#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 42565] New: Internal error compiling 32-bit i386 -march=atom kernel
https://bugs.llvm.org/show_bug.cgi?id=42565
Bug ID: 42565
Summary: Internal error compiling 32-bit i386 -march=atom
kernel
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: a...@linaro.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Building randconfig Linux kernels, I came across an internal error, which I
reduced to this input:
https://godbolt.org/z/Cjq8VC
void HUF_writeCTable_wksp()
{
unsigned n;
char *bitsToWeight = 0;
n = 1;
for (; n + 1; n++)
bitsToWeight[n] = -n;
}
$ clang-9 -c -O2 -mno-sse -march=atom -fno-delete-null-pointer-checks
huf_compress.c
Stack dump:
0. Program arguments:
/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9 -cc1 -triple
x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name example.c -mrelocation-model static
-mthread-model posix -fno-delete-null-pointer-checks -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu atom
-target-feature -sse -dwarf-column-info -debug-info-kind=limited
-dwarf-version=4 -debugger-tuning=gdb -momit-leaf-frame-pointer
-coverage-notes-file /home/ubuntu/./output.gcno -resource-dir
/opt/compiler-explorer/clang-trunk-20190710/lib/clang/9.0.0 -internal-isystem
/usr/local/include -internal-isystem
/opt/compiler-explorer/clang-trunk-20190710/lib/clang/9.0.0/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2
-fdebug-compilation-dir /home/ubuntu -ferror-limit 19 -fmessage-length 0
-fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics
-vectorize-loops -vectorize-slp -mllvm --x86-asm-syntax=intel -faddrsig -o
./output.s -x c
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module ''.
4. Running pass 'Live DEBUG_VALUE analysis' on function
'@HUF_writeCTable_wksp'
#0 0x55d3dda1a46a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x27ca46a)
#1 0x55d3dda18234 llvm::sys::RunSignalHandlers()
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x27c8234)
#2 0x55d3dda18372 SignalHandler(int)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x27c8372)
#3 0x7fdec6a0e890 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#4 0x55d3dd04bddc (anonymous
namespace)::LiveDebugValues::transferRegisterCopy(llvm::MachineInstr&,
(anonymous namespace)::LiveDebugValues::OpenRangesSet&,
llvm::UniqueVector<(anonymous namespace)::LiveDebugValues::VarLoc>&,
llvm::SmallVector<(anonymous namespace)::LiveDebugValues::TransferDebugPair,
4u>&) (/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x1dfbddc)
#5 0x55d3dd052854 (anonymous
namespace)::LiveDebugValues::ExtendRanges(llvm::MachineFunction&)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x1e02854)
#6 0x55d3dd0e30d0
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x1e930d0)
#7 0x55d3dd40f3d8 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x21bf3d8)
#8 0x55d3dd40f493 llvm::FPPassManager::runOnModule(llvm::Module&)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x21bf493)
#9 0x55d3dd40e731 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x21be731)
#10 0x55d3ddc3f74e (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
std::unique_ptr >)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x29ef74e)
#11 0x55d3ddc413c7 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x29f13c7)
#12 0x55d3de76d361
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x351d361)
#13 0x55d3def3e439 clang::ParseAST(clang::Sema&, bool, bool)
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x3cee439)
#14 0x55d3de76adb7 clang::CodeGenAction::ExecuteAction()
(/opt/compiler-explorer/clang-trunk-20190710/bin/clang-9+0x351adb7)
#15 0x55d3de0e9ea9
[llvm-bugs] Issue 15699 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in llvm::StringMapImpl::LookupBucketFor
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 15699 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in llvm::StringMapImpl::LookupBucketFor https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15699#c1 ClusterFuzz testcase 5679180139724800 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201907090313:201907100314 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 42429] Configure GitHub repository to block merge commits
https://bugs.llvm.org/show_bug.cgi?id=42429 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom Stellard --- Status checks are enabled in the github repository now, and all commits are required to pass the 'rebased' check. -- 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 39393] [meta] Tasks related to hosting source code at GitHub
https://bugs.llvm.org/show_bug.cgi?id=39393 Bug 39393 depends on bug 42429, which changed state. Bug 42429 Summary: Configure GitHub repository to block merge commits https://bugs.llvm.org/show_bug.cgi?id=42429 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42566] New: Broken initialization of objects in __constant AS in C++ mode
https://bugs.llvm.org/show_bug.cgi?id=42566
Bug ID: 42566
Summary: Broken initialization of objects in __constant AS in
C++ mode
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: anastasia.stul...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
When compiling with -cl-std=++ the following test case a number of errors seem
to be produced incorrectly:
struct X {
int x;
X(int x) __constant : x(x) {}
};
kernel void barX() {
__constant X x(0); // error: initializer element is not a compile-time
constant
}
struct Y {
int y;
};
kernel void barY() {
__constant Y y = { 0 }; // Okay
}
struct Z {
Z() __constant = default;
};
kernel void barZ() {
__constant Z z1; // error: variable in constant address space must be
initialized
__constant Z z2 = Z(); // error: no matching constructor for initialization of
'Z'
// note: candidate constructor ignored: cannot be used
to construct an object in address space unqualified
}
--
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 42451] hotcoldsplit makes function broken with "opt -loop-unroll -mergereturn -hotcoldsplit -loop-rotate -sroa -inline -barrier -loop-idiom -early-cse -hotcoldsplit"
https://bugs.llvm.org/show_bug.cgi?id=42451 Vedant Kumar changed: What|Removed |Added Fixed By Commit(s)||365660 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Vedant Kumar --- Fixed in r365660. -- 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 42567] New: Possible miscompilation by clang-cl versions 7, 8, and 9 targeting 32-bit Windows
https://bugs.llvm.org/show_bug.cgi?id=42567 Bug ID: 42567 Summary: Possible miscompilation by clang-cl versions 7, 8, and 9 targeting 32-bit Windows Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: bspen...@blackberry.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 1 --> https://bugs.llvm.org/attachment.cgi?id=1&action=edit Program demonstrating the bug The attached program, when compiled with clang-cl versions 7, 8, and 9 (from apt.llvm.org for Debian stretch) crashes when targeting 32-bit Windows. It does not crash when targeting 64-bit Windows with clang-cl or when using MSVC (15.9.12 and other versions). The attached archive contains a (POSIX) Makefile that can build on Linux using a selection of compilers. Building with MSVC (on Windows or on Linux) always produces an executable that works. Building with clang-cl for 32-bit always produces an executable that fails. For example: $ make clang version 9.0.0-svn364966-1~exp1+0~20190702204433.1332~1.gbpb44072 (trunk) LLD 9.0.0 INCLUDE="/home/bspencer/msvc2017-15.9.12/ucrt/Include/10.0.17134.0/ucrt;/home/bspencer/msvc2017-15.9.12/vc/Tools/MSVC/14.16.27023/include;/home/bspencer/msvc2017-15.9.12/ucrt/Include/10.0.17134.0/shared;/home/bspencer/msvc2017-15.9.12/ucrt/Include/10.0.17134.0/um" clang-cl-9 -Wno-unused-private-field -EHsc -analyze- -O2 -MD -W4 -WX -m32 -Wno-unused-private-field -c -Foprog.obj prog.cc INCLUDE="/home/bspencer/msvc2017-15.9.12/ucrt/Include/10.0.17134.0/ucrt;/home/bspencer/msvc2017-15.9.12/vc/Tools/MSVC/14.16.27023/include;/home/bspencer/msvc2017-15.9.12/ucrt/Include/10.0.17134.0/shared;/home/bspencer/msvc2017-15.9.12/ucrt/Include/10.0.17134.0/um" clang-cl-9 -Wno-unused-private-field -EHsc -analyze- -O2 -MD -W4 -WX -m32 -Wno-unused-private-field -c -Folib.obj lib.cc LIB="/home/bspencer/msvc2017-15.9.12/ucrt/Lib/10.0.17134.0/ucrt/x86;/home/bspencer/msvc2017-15.9.12/vc/Tools/MSVC/14.16.27023/lib/x86;/home/bspencer/msvc2017-15.9.12/ucrt/Lib/10.0.17134.0/um/x86" lld-link-9 /OUT:prog.exe prog.obj lib.obj It fails both under Wine and real Windows: $ wine ./prog.exe Try! Catch! wine: Unhandled page fault on execute access to 0x2f409fde at address 0x2f409fde (thread 0023), starting debugger... C:> prog.exe Try! Catch! (Windows crash dialog box) The crash happens in an std::thread function accessing an exception thrown and caught within that thread. Minimizing the test case further in any way that I tried avoided the 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] [Bug 42568] New: Attribute 'noderef' fails to warn in some cases
https://bugs.llvm.org/show_bug.cgi?id=42568
Bug ID: 42568
Summary: Attribute 'noderef' fails to warn in some cases
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: paul_robin...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
C:\TMP>type test.c
struct S {
int x;
};
struct S __attribute__((noderef)) *s;
void bar() {
struct S *p = s; // warned
int *q = &s->x; // not warned
int *r = &(*s).x; // not warned
}
C:\TMP>clang -c test.c
test.c:8:17: warning: casting to dereferenceable pointer removes 'noderef'
attribute [-Wnoderef]
struct S *p = s; // warned
^
1 warning 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27202] [x86] optimizing for size results in bigger code because of repeated constant
https://bugs.llvm.org/show_bug.cgi?id=27202 Sanjay Patel changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||r365163 --- Comment #9 from Sanjay Patel --- Marking as fixed with: https://reviews.llvm.org/rL365163 There may still be room for improvement with BMI, but that's a separate 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] [Bug 26299] [meta][X86] Size optimization opportunities (in particular for 32-bit Chromium on Windows)
https://bugs.llvm.org/show_bug.cgi?id=26299 Bug 26299 depends on bug 27202, which changed state. Bug 27202 Summary: [x86] optimizing for size results in bigger code because of repeated constant https://bugs.llvm.org/show_bug.cgi?id=27202 What|Removed |Added Status|CONFIRMED |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42569] New: "ran out of registers" while building i386 linux kernel
https://bugs.llvm.org/show_bug.cgi?id=42569
Bug ID: 42569
Summary: "ran out of registers" while building i386 linux
kernel
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: a...@linaro.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
One file in the linux kernel produces an internal error from the register
allocator. I reduced the test case to this:
typedef int (*tune_freq_func_t)(int , void * tuneargs);
static struct {
int power_up;
int power_down;
tune_freq_func_t fm_tune_freq;
tune_freq_func_t am_tune_freq;
int fm_rsq_status;
int agc_status;
int intb_pin_cfg;
} a[1];
int b, c;
int fn1(void) { return a[c].fm_tune_freq(b, fn1); }
$ clang-9 -m32 -mregparm=3 -O2 -fno-strict-overflow -c si476x-cmd.c
error: ran out of registers during register allocation
1 error generated.
See https://godbolt.org/z/aQ96HC
--
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 42570] New: gas warning: ignoring changed section attributes
https://bugs.llvm.org/show_bug.cgi?id=42570
Bug ID: 42570
Summary: gas warning: ignoring changed section attributes
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: a...@linaro.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Building the linux kernel for i386, I get an assembler warning in one file:
/tmp/slab_common-bf04f6.s: Assembler messages:
/tmp/slab_common-bf04f6.s:38: Warning: ignoring changed section attributes for
.data..ro_after_init
I reduced the test case to
int a __attribute__((__section__(".data..ro_after_init")));
static int b[4] __attribute__((__section__(".data..ro_after_init")));
int c;
int fn1(void);
void fn2() { c = b[fn1()]; }
clang-9 -fno-common -no-integrated-as -O2 -fno-strict-overflow -c test.c
Initializing 'a' to zero shuts up the warning, and causes this difference in
the assembler output:
--- slab_common-broken.s2019-07-10 22:36:57.262501626 +0200
+++ slab_common-good.s 2019-07-10 22:37:17.418912892 +0200
@@ -12,36 +12,35 @@
cltq
movlb(,%rax,4), %eax
movl%eax, c(%rip)
popq%rax
.cfi_def_cfa_offset 8
retq
.Lfunc_end0:
.size fn2, .Lfunc_end0-fn2
.cfi_endproc
# -- End function
+ .type a,@object # @a
+ .section.data..ro_after_init,"aw",@progbits
+ .globl a
+ .p2align2
+a:
+ .long 0 # 0x0
+ .size a, 4
+
.type b,@object # @b
- .section.data..ro_after_init,"aM",@progbits,16
.p2align4
b:
.zero 16
.size b, 16
.type c,@object # @c
.bss
.globl c
.p2align2
c:
.long 0 # 0x0
.size c, 4
- .type a,@object # @a
- .section.data..ro_after_init,"aM",@progbits,16
- .globl a
- .p2align2
-a:
- .long 0 # 0x0
- .size a, 4
-
.ident "clang version
9.0.0-svn363902-1~exp1+0~20190620001509.2315~1.gbp76e756 (trunk)"
.section".note.GNU-stack","",@progbits
See also https://godbolt.org/z/hBPgpb
--
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 42378] ThinLTO index only generates very large index files
https://bugs.llvm.org/show_bug.cgi?id=42378 Robbert Haarman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||365537 -- 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 42571] New: [x86] forming subo intrinsic thwarts codegen
https://bugs.llvm.org/show_bug.cgi?id=42571
Bug ID: 42571
Summary: [x86] forming subo intrinsic thwarts codegen
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
Forking this example from bug 42314 because it's not exactly an "isPowerOf2"
pattern:
int foo(int x, int y) {
return x ? (x & (x - 1)) : y;
}
Or as optimized IR (if we should create ctpop from this, then this isn't
strictly an x86 bug):
define i32 @foo(i32 %x, i32 %y) {
%tobool = icmp eq i32 %x, 0
%sub = add nsw i32 %x, -1
%and = and i32 %sub, %x
%cond = select i1 %tobool, i32 %y, i32 %and
ret i32 %cond
}
CGP will transform that to use llvm.usub.with.overflow.i32, and we get:
movl %edi, %eax
subl $1, %eax
andl %edi, %eax
cmpl $1, %edi
cmovbl %esi, %eax
retq
For generic x86, this seems better
leal-1(%rdi), %eax
andl%edi, %eax
testl %edi, %edi
cmove %esi, %eax
And with BMI ('blsr'):
blsr%edi, %eax
testl %edi, %edi
cmove %esi, %eax
https://godbolt.org/z/Wmgyy9
--
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 42314] Missed BLSR for x == (x & -x) && x
https://bugs.llvm.org/show_bug.cgi?id=42314 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #25 from Sanjay Patel --- (In reply to Craig Topper from comment #24) > We're still doing something strange in my case from comment 2. should i open > a separate bug? Oops - missed that 1. Yes, let's handle that separately: bug 42571 -- 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 42066] clang-cl with /P and /Brepro fails with a cryptic error message
https://bugs.llvm.org/show_bug.cgi?id=42066 Nico Weber changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Nico Weber --- https://reviews.llvm.org/rL365703 -- 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 42565] Internal error compiling 32-bit i386 -march=atom kernel
https://bugs.llvm.org/show_bug.cgi?id=42565 Craig Topper changed: What|Removed |Added Fixed By Commit(s)||r365720 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Craig Topper --- Fixed in r365720. -- 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 42565, which changed state. Bug 42565 Summary: Internal error compiling 32-bit i386 -march=atom kernel https://bugs.llvm.org/show_bug.cgi?id=42565 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42564] calls to operator delete(..., const std::nothrow_t &) are optimized out
https://bugs.llvm.org/show_bug.cgi?id=42564 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- This is a permitted optimization. Under C++ [expr.new]p12 (http://eel.is/c++draft/expr.new#12): "An implementation is allowed to omit a call to a replaceable global allocation function ([new.delete.single], [new.delete.array]). When it does so, the storage is instead provided by the implementation or provided by extending the allocation of another new-expression." In this case, the implementation provides storage for the 'new (std::nothrow) A' expression itself rather than calling the allocation function, so it would not be appropriate to call a deallocation function. -- 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 42572] New: std::ofstream silently fails to write files when they can't be created
https://bugs.llvm.org/show_bug.cgi?id=42572
Bug ID: 42572
Summary: std::ofstream silently fails to write files when they
can't be created
Product: libc++
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: y...@tsoft.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The example from cplusplus.com
http://www.cplusplus.com/reference/fstream/ofstream/open/ with the modified
file name fails silently, showing how error-prone the file interface is:
> #include
>
> int main () {
> std::ofstream ofs;
> ofs.open ("nonexistent-noexistent/test.txt", std::ofstream::out |
> std::ofstream::app);
>
> ofs << " more lorem ipsum";
>
> ofs.close();
>
> return 0;
> }
No exception is thrown, no error message is printed.
The kernel trace shows that the error "No such file or directory" is lost by
STL:
> 47377 ofstream CALL
> open(0x20229d,0x209,0666)
> 47377 ofstream NAMI "nonexistent-noexistent/test.txt"
> 47377 ofstream RET open -1 errno 2 No such file or directory
FreeBSD 12 amd64, clang8.
Yuri
--
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 42573] New: Memory leak checker doesn't report leak when constructor dereferences the argument
https://bugs.llvm.org/show_bug.cgi?id=42573
Bug ID: 42573
Summary: Memory leak checker doesn't report leak when
constructor dereferences the argument
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: hiradi...@msn.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Not sure why static analyzer doesn't report memory leak in the following case:
$ cat test.cpp
#include
#include
struct A {
A(const std::shared_ptr &s) {
std::cout << "constructor" << *s;
}
};
int main() {
auto l = std::make_shared(nullptr);
int *p = new int;
int i = *p;
return i;
}
However, if we remove the dereference of `s` it works.
$ cat test-no-deref-s.cpp
#include
#include
struct A {
A(const std::shared_ptr &s) {
std::cout << "constructor"; // removed the deref of s
}
};
int main() {
auto l = std::make_shared(nullptr);
int *p = new int;
int i = *p;
return i;
}
$ clang++ --analyze test-no-deref-s.cpp -std=c++14
test1.cpp:14:3: warning: Potential leak of memory pointed to by 'p'
int i = *p;
^
1 warning 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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42356] __builtin___clear_cache crashes the WebAssembly backend
https://bugs.llvm.org/show_bug.cgi?id=42356 Heejin Ahn changed: What|Removed |Added Fixed By Commit(s)||r365731 Resolution|--- |WONTFIX Status|NEW |RESOLVED CC||ahee...@gmail.com --- Comment #2 from Heejin Ahn --- Thank you for the report! As per Dan's question, I'm also curious about what your usecase for `__builtin___clear_cache` was. Meanwhile, we committed a patch that prints a proper error message rather than just segfaults. (https://reviews.llvm.org/rL365731) I'll close this bug for now, but feel free to repoen this if you'd like to. -- 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 42574] New: Non-deterministic result due to use of SmallPtrSet in llvm::removeUnreachableBlocks
https://bugs.llvm.org/show_bug.cgi?id=42574
Bug ID: 42574
Summary: Non-deterministic result due to use of SmallPtrSet in
llvm::removeUnreachableBlocks
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 2
--> https://bugs.llvm.org/attachment.cgi?id=2&action=edit
reproducer
Running
opt -simplifycfg -o foo.ll in3.ll -S --preserve-ll-uselistorder
a number of times with a clang 8 built opt we see that the produced output
differs now and then like:
< uselistorder i16 0, { 2, 3, 4, 1, 5, 0, 6 }
---
> uselistorder i16 0, { 3, 2, 4, 1, 5, 0, 6 }
I think it's the DeadBlockSet that is the cause:
- // Loop over all of the basic blocks that are not reachable, dropping all of
- // their internal references. Update DTU and LVI if available.
- std::vector Updates;
+ SmallPtrSet DeadBlockSet;
As far as I can see, as long as a SmallPtrSet is "small", the iteration order
is deterministic (== insertion order), but I strongly suspect that when the set
grows to being "big", then it's not deterministic anymore.
DeadBlockSet as above was introduced in r339951:
Update MemorySSA in Local utils removing blocks.
Summary: Extend Local utils to update MemorySSA.
Subscribers: sanjoy, jlebar, Prazek, george.burgess.iv, llvm-commits
Differential Revision: https://reviews.llvm.org/D48790
llvm-svn: 339951
Later this caused SCEV and LSR in llc to draw different conclusions and
produce different code.
--
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
