[llvm-bugs] Issue 33697 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in MemoryBufferMem::getBufferIdentifier
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-26 Type: Bug New issue 33697 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in MemoryBufferMem::getBufferIdentifier https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33697 Detailed Report: https://oss-fuzz.com/testcase?key=5356517978144768 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffea7d49a68 Crash State: MemoryBufferMem::getBufferIdentifier llvm::MemoryBuffer::getMemBufferRef clang::SrcMgr::ContentCache::getBufferOrNone Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202103160614:202103170627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5356517978144768 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 50122] New: Parser::ParseCastExpression - dodgy unused write
https://bugs.llvm.org/show_bug.cgi?id=50122
Bug ID: 50122
Summary: Parser::ParseCastExpression - dodgy unused write
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: llvm-bugs@lists.llvm.org, martongab...@gmail.com,
neeil...@live.com, richard-l...@metafoo.co.uk,
saar@raz.email
The static analyzer is warning about an unread variable write in
Parser::ParseCastExpression:
switch (SavedKind) {
case tok::l_paren: {
// If this expression is limited to being a unary-expression, the paren can
// not start a cast expression.
ParenParseOption ParenExprType;
switch (ParseKind) {
case CastParseKind::UnaryExprOnly:
if (!getLangOpts().CPlusPlus)
ParenExprType = CompoundLiteral; // UNUSED WRITE WARNING
LLVM_FALLTHROUGH;
case CastParseKind::AnyCastExpr:
ParenExprType = ParenParseOption::CastExpr;
break;
case CastParseKind::PrimaryExprOnly:
ParenExprType = FoldExpr;
break;
}
This looks like it was introduced in https://reviews.llvm.org/D43357
Before that the code looked like:
ParenParseOption ParenExprType =
(isUnaryExpression && !getLangOpts().CPlusPlus) ? CompoundLiteral
: CastExpr;
So maybe we're missing a break ?
--
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 50123] New: [X86] Failure to recognise generic shift from SSE PSLLQ intrinsic
https://bugs.llvm.org/show_bug.cgi?id=50123
Bug ID: 50123
Summary: [X86] Failure to recognise generic shift from SSE
PSLLQ intrinsic
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: david.bolvan...@gmail.com, lebedev...@gmail.com,
llvm-bugs@lists.llvm.org, nikita@gmail.com,
spatel+l...@rotateright.com
We often fail to recognise that the _mm_sll_epi64 shift amount is in bounds,
allowing us to fold it to a generic shift. This happens for all SSE 'shift by
uniform variable' intrinsics.
https://simd.godbolt.org/z/vKT9YE5zM
#include
__m128i shl_v2i64_mod31(__m128i val, __m128i amt) {
amt = _mm_and_si128( amt, _mm_set1_epi32( 31 ) );
return _mm_sll_epi64( val, _mm_unpacklo_epi32( amt, _mm_setzero_si128() ) );
}
__m128i shl_v2i64_mod31_alt(__m128i val, __m128i amt) {
amt = _mm_and_si128( amt, _mm_setr_epi32( 31, 0, 0, 0 ) );
return _mm_sll_epi64( val, amt );
}
define <2 x i64> @shl_v2i64_mod31(<2 x i64> %0, <2 x i64> %1){
%3 = bitcast <2 x i64> %1 to <4 x i32>
%4 = and <4 x i32> %3,
%5 = insertelement <4 x i32> %4, i32 0, i32 1
%6 = bitcast <4 x i32> %5 to <2 x i64>
%7 = tail call <2 x i64> @llvm.x86.sse2.psll.q(<2 x i64> %0, <2 x i64> %6)
ret <2 x i64> %7
}
declare <2 x i64> @llvm.x86.sse2.psll.q(<2 x i64>, <2 x i64>)
define <2 x i64> @shl_v2i64_mod31_alt(<2 x i64> %0, <2 x i64> %1) {
%3 = and <2 x i64> %1,
%4 = shufflevector <2 x i64> %3, <2 x i64> poison, <2 x i32> zeroinitializer
%5 = shl <2 x i64> %0, %4
ret <2 x i64> %5
}
I think we're just missing some bitcast/insertelement vector handling in
ValueTracking.
--
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 50124] New: Crash Clang 12.0
https://bugs.llvm.org/show_bug.cgi?id=50124 Bug ID: 50124 Summary: Crash Clang 12.0 Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: slobodyanu...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Compiler crashed error: Stream Error: The stream is too short to perform the requested operation. *** stack smashing detected ***: terminated PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang --driver-mode=g++ -target i686-w64-mingw32 -rtlib=compiler-rt -stdlib=libc++ -fuse-ld=lld -Qunused-arguments -I/devroot/develop/src -isystem /devroot/develop/src/3rdparty -isystem /devroot/3rdparty/include_4.5 -isystem /devroot/develop/src/3rdparty/efsw/include -isystem /devroot/3rdparty/build_4.1/windows-llvm-i686/include -g -gcodeview -ffunction-sections -fdata-sections -Og -Wno-long-long -Wno-bind-to-temporary-copy -Wno-psabi -Wno-tautological-constant-compare -Wno-keyword-macro -include /devroot/develop/build/windows-llvm-i686-release/config.h -mthreads -Wall -Wextra -Werror -Winit-self -Woverloaded-virtual -Wctor-dtor-privacy -Wnon-virtual-dtor -Wsign-promo -pedantic -std=gnu++14 -MD -MT CMakeFiles/ed_core.dir/http/uri.cpp.obj -MF CMakeFiles/ed_core.dir/http/uri.cpp.obj.d -o CMakeFiles/ed_core.dir/http/uri.cpp.obj -c /devroot/develop/src/http/uri.cpp 1. parser at end of file 2. Code generation #0 0x7fa057afc97c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x20fc97c) #1 0x7fa057afa724 llvm::sys::RunSignalHandlers() (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x20fa724) #2 0x7fa057afa9a5 llvm::sys::CleanupOnSignal(unsigned long) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x20fa9a5) #3 0x7fa057a68fa8 (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x2068fa8) #4 0x7fa0559943c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0) #5 0x7fa05545618b raise /build/glibc-eX1tMB/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1 #6 0x7fa055435859 abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:81:7 #7 0x7fa0554a03ee __libc_message /build/glibc-eX1tMB/glibc-2.31/libio/../sysdeps/posix/libc_fatal.c:155:5 #8 0x7fa055542b4a __fortify_fail /build/glibc-eX1tMB/glibc-2.31/debug/fortify_fail.c:25:9 #9 0x7fa055542b16 (/lib/x86_64-linux-gnu/libc.so.6+0x132b16) #10 0x7fa058577ec0 (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x2b77ec0) #11 0x7fa058591148 (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x2b91148) #12 0x7fa058526e63 llvm::AsmPrinter::doFinalization(llvm::Module&) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x2b26e63) #13 0x7fa05749470c llvm::FPPassManager::doFinalization(llvm::Module&) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x1a9470c) #14 0x7fa05749f978 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x1a9f978) #15 0x7fa057d881f8 (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x23881f8) #16 0x7fa057d89e77 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 >) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x2389e77) #17 0x7fa05891d5fa (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x2f1d5fa) #18 0x7fa05955c2f9 clang::ParseAST(clang::Sema&, bool, bool) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x3b5c2f9) #19 0x7fa05891d6b2 clang::CodeGenAction::ExecuteAction() (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x2f1d6b2) #20 0x7fa058335291 clang::FrontendAction::Execute() (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x2935291) #21 0x7fa0582db0b3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04-x86_64/bin/clang+0x28db0b3) #22 0x7fa0583fd473 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/devroot/toolchain/llvm-mingw-20210423-ucrt-ubuntu-18.04
[llvm-bugs] [Bug 50125] New: Missed conditional tail call opportunity
https://bugs.llvm.org/show_bug.cgi?id=50125
Bug ID: 50125
Summary: Missed conditional tail call opportunity
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org
Based on an example from
https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html
(https://godbolt.org/z/4afYjjPro)
$ cat /tmp/a.c
void *fallback(unsigned char *data);
void *stuff(unsigned char *data);
void *foo(unsigned char *data)
{
if (*data & 0x1) {
return fallback(data);
}
data++;
return stuff(data);
}
$ clang -target x86_64-unknown-linux-gnu -Os -S -o - /tmp/a.c
.text
.file "a.c"
.globl foo # -- Begin function foo
.type foo,@function
foo:# @foo
.cfi_startproc
# %bb.0:# %entry
testb $1, (%rdi)
jne .LBB0_1
# %bb.2:# %if.end
incq%rdi
jmp stuff # TAILCALL
.LBB0_1:# %if.then
jmp fallback# TAILCALL
.Lfunc_end0:
.size foo, .Lfunc_end0-foo
.cfi_endproc
Instead of:
jne .LBB0_1
.LBB0_1:
jmp fallback
It could just do:
jne .LBB0_1
The code in BranchFolding.cpp is supposed to do this:
https://github.com/llvm/llvm-project/blob/e439a463a30833f1c7d366ed722f0f12d1682638/llvm/lib/CodeGen/BranchFolding.cpp#L1520
But it's not firing here.
--
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 50126] New: Codegen regression with sign extensions
https://bugs.llvm.org/show_bug.cgi?id=50126
Bug ID: 50126
Summary: Codegen regression with sign extensions
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: ARM
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@arm.com
struct s {
short x, y;
};
struct s rot90(struct s p)
{
return (struct s) { -p.y, p.x };
}
struct s rot270(struct s p)
{
return (struct s) { p.y, -p.x };
}
Trunk:
rot90: // @rot90
neg w8, w0, lsr #16
lsl w0, w0, #16
bfxil x0, x8, #0, #16
ret
rot270: // @rot270
neg w8, w0, lsl #16
bfxil x8, x0, #16, #16
mov x0, x8
ret
rot90: // @rot90
neg w8, w0, lsr #16
bfi w8, w0, #16, #16
mov x0, x8
ret
rot270: // @rot270
ubfxx8, x0, #16, #16
sub w0, w8, w0, lsl #16
ret
Maybe ideal codegen?:
rot90:
mov w1, w0
neg w0, w1, asr 16
bfi w0, w1, 16, 16
ret
rot270:
neg w1, w0
extrw0, w1, w0, 16
ret
See it live:
https://gcc.godbolt.org/z/4c4ds58v6
--
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 50127] New: Checks not generated for vla-bound when the size is unsigned
https://bugs.llvm.org/show_bug.cgi?id=50127
Bug ID: 50127
Summary: Checks not generated for vla-bound when the size is
unsigned
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ubsan
Assignee: unassignedb...@nondot.org
Reporter: adammagier.l...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 24803
--> https://bugs.llvm.org/attachment.cgi?id=24803&action=edit
Source file with VLAs being instantiated via signed and unsigned types
The vla-bound checker for UBSan does not generate the necessary checks when the
size of the VLA is an unsigned type. Given the following code (vla-bound.c,
also attached):
#include
long int s = 0;
int main(void) {
int w[(size_t)s];
int x[(ssize_t)s];
int y[(unsigned)s];
int z[(int)s];
return 0;
}
Inspecting the IR generated from compiling with `clang -S -emit-llvm -O0
-fsanitize=vla-bound vla-bound.c` we see that there's only two checks generated
for the VLA bounds checking:
$ clang -S -emit-llvm -O0 -fsanitize=vla-bound vla-bound.c
$ grep -P "^handler.vla_bound_not_positive" vla-bound.ll
handler.vla_bound_not_positive: ; preds = %entry
handler.vla_bound_not_positive4: ; preds = %cont
Further comparing this behaviour between clang and gcc, we see that gcc
performs the checking on the VLA size for both signed and unsigned variable
types:
clang:
$ clang -O0 -fsanitize=vla-bound vla-bound.c
$ ./a.out
vla-bound.c:6:9: runtime error: variable length array bound evaluates to
non-positive value 0
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior vla-bound.c:6:9 in
vla-bound.c:8:9: runtime error: variable length array bound evaluates to
non-positive value 0
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior vla-bound.c:8:9 in
gcc:
$ gcc -O0 -fsanitize=vla-bound vla-bound.c
$ ./a.out
vla-bound.c:5:7: runtime error: variable length array bound evaluates to
non-positive value 0
vla-bound.c:6:7: runtime error: variable length array bound evaluates to
non-positive value 0
vla-bound.c:7:7: runtime error: variable length array bound evaluates to
non-positive value 0
vla-bound.c:8:7: runtime error: variable length array bound evaluates to
non-positive value 0
We would expect that the behaviour of both clang and gcc would agree when it
comes to checking the VLA bounds. Reading through the C specification does not
indicate any limitation on whether or not a VLA's size needs to be in the form
of a signed or unsigned type so there seems no reason why this check shouldn't
be performed.
--
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 33586 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 33586 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33586#c1 ClusterFuzz testcase 4783439350988800 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202104250626:202104260613 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 50128] New: Building LLVM trunk for Win32 (32-bit) target crashes MSVC
https://bugs.llvm.org/show_bug.cgi?id=50128 Bug ID: 50128 Summary: Building LLVM trunk for Win32 (32-bit) target crashes MSVC Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: s...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Summary: Building LLVM for 32-bit Win32, using MSVC 2019, on recent trunk builds, crashes the compiler. This is using the most recent MSVC 2019 Community Edition on a Win10 x86-64 box: ``` $ vcvarsall.bat x64_x86 $ cmake -G Ninja C:/path/to/llvm-project/llvm -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:/path/to/llvm-install -DLLVM_BUILD_32_BITS=ON -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_PROJECTS=clang;lld -DLLVM_ENABLE_RTTI=ON -DLLVM_ENABLE_TERMINFO=OFF -DLLVM_TARGETS_TO_BUILD=X86;ARM;NVPTX;AArch64;Mips;Hexagon;PowerPC;WebAssembly $ ninja -C C:/path/to/llvm-build -j 18 install ``` this chugs away for quite some time, but eventually fails building clang-tblgen, with: ``` [2220/3953] Building CXX object tools\clang\utils\TableGen\CMakeFiles\clang-tblgen.dir\ClangOpenCLBuiltinEmitter.cpp.obj FAILED: tools/clang/utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangOpenCLBuiltinEmitter.cpp.obj C:\PROGRA~2\MICROS~2\2019\COMMUN~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x86\cl.exe /nologo /TP -DCLANG_ROUND_TRIP_CC1_ARGS=ON -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0 -D_LARGEFILE_SOURCE -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\clang\utils\TableGen -IC:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\clang\utils\TableGen -IC:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\clang\include -Itools\clang\include -Iinclude -IC:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\llvm\include /DWIN32 /D_WINDOWS /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /bigobj /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD /O2 /Ob2 /EHs-c- /GR -UNDEBUG -std:c++14 /showIncludes /Fotools\clang\utils\TableGen\CMakeFiles\clang-tblgen.dir\ClangOpenCLBuiltinEmitter.cpp.obj /Fdtools\clang\utils\TableGen\CMakeFiles\clang-tblgen.dir\ /FS -c C:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\clang\utils\TableGen\ClangOpenCLBuiltinEmitter.cpp C:\code\build_bot\worker\llvm-13-x86-32-windows\llvm-project\clang\utils\TableGen\ClangOpenCLBuiltinEmitter.cpp(514) : fatal error C1001: Internal compiler error. (compiler file 'd:\A01\_work\3\s\src\vctools\Compiler\Utc\src\p2\main.c', line 212) To work around this problem, try simplifying or changing the program near the locations listed above. If possible please provide a repro here: https://developercommunity.visualstudio.com Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information cl!RaiseException()+0x69 cl!RaiseException()+0x69 cl!CloseTypeServerPDB()+0x22ebf cl!CloseTypeServerPDB()+0xedea9 ``` I don't (yet) have an injection point for when the failure started occurring, but it was sometime within the past week. I'll update this bug if/when I find one. -- 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 33716 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::CppLookupName
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-26 Type: Bug New issue 33716 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::CppLookupName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33716 Detailed Report: https://oss-fuzz.com/testcase?key=4859486763352064 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcf9cf8f20 Crash State: clang::Sema::CppLookupName clang::Sema::LookupName clang::Sema::LookupTemplateName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202011150625:202011160627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4859486763352064 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 50129] New: omp cancel parallel not working as expected
https://bugs.llvm.org/show_bug.cgi?id=50129
Bug ID: 50129
Summary: omp cancel parallel not working as expected
Product: clang
Version: trunk
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: OpenMP
Assignee: unassignedclangb...@nondot.org
Reporter: michael.p.r...@intel.com
CC: llvm-bugs@lists.llvm.org
The following test shows 'omp cancel' is not working as expected. Run with:
OMP_CANCELLATION=true ./a.out
It should quickly print:
Cancel happened as you would expect!
Clang will not cancel.
#include
#include
#include
#include
#include
// Run with environment variable: OMP_CANCELLATION=true
int main(int argc, char **argv) {
int* array;
int nthreads, i, j;
#pragma omp parallel
#pragma omp single nowait
nthreads = omp_get_num_threads();
array = (int*)malloc(sizeof(int)*nthreads);
for (i = 0; i < nthreads; ++i)
array[i] = 0;
assert(omp_get_cancellation() && "Need to set OMP_CANCELLATION=true");
#pragma omp parallel
{
int tid = omp_get_thread_num();
if (tid == 0) {
// Master signals other threads that cancellation is in order
// This thread will go to end of parallel right here
// not at the cancellation point below
#pragma omp cancel parallel
}
// Have worker threads sleep here for "long enough"
usleep(100);
#pragma omp barrier
array[tid] = 1;
}
int errors = 0;
for (i = 0; i < nthreads; ++i) {
if (array[i] != 0) {
printf("Thread %d made it through unexpectedly!\n", i);
errors++;
}
}
if (errors) {
printf("%d errors occurred!\n", errors);
exit(1);
}
printf("Cancel happened as you would expect!\n");
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50130] New: conditional branch to unconditional tailcall not folded to conditional tailcall
https://bugs.llvm.org/show_bug.cgi?id=50130
Bug ID: 50130
Summary: conditional branch to unconditional tailcall not
folded to conditional tailcall
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: ndesaulni...@google.com
CC: chandl...@gmail.com, craig.top...@gmail.com,
h...@chromium.org, jhaber...@gmail.com,
llvm-bugs@lists.llvm.org
The blog post
https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html
and comment thread https://news.ycombinator.com/item?id=26934616#26937585 point
to a test case (reduced):
```
target triple = "x86_64-unknown-linux-gnu"
declare dso_local i8* @foo(i8*, i64)
declare dso_local i8* @bar(i8*, i64)
define i8* @baz(i8* %ptr, i64 %data) {
; CHECK-LABEL: baz:
; CHECK: # %bb.0: # %entry
; CHECK-NEXT:testb %sil, %sil
; CHECK-NEXT:je foo # TAILCALL
; CHECK-NEXT: # %bb.1: # %if.end
; CHECK-NEXT:addq $5, %rdi
; CHECK-NEXT:jmp bar # TAILCALL
entry:
%and = and i64 %data, 255
%tobool.not = icmp eq i64 %and, 0
br i1 %tobool.not, label %if.end, label %if.then
if.then: ; preds = %entry
%call = musttail call i8* @foo(i8* %ptr, i64 %data)
ret i8* %call
if.end: ; preds = %entry
%add.ptr4 = getelementptr inbounds i8, i8* %ptr, i64 5
%call5 = musttail call i8* @bar(i8* nonnull %add.ptr4, i64 %data)
ret i8* %call5
}
```
run through llc will instead produce:
```
baz:
# %bb.0:
testb %sil, %sil
je .LBB0_2
# %bb.1: # %if.then
jmp foo
.LBB0_2: # %if.end
addq$5, %rdi
jmp bar
```
though we could have produced:
```
baz:
# %bb.0: # %entry
testb %sil, %sil
je foo # TAILCALL
# %bb.1: # %if.end
addq $5, %rdi
jmp bar # TAILCALL
```
Some code added in D29856 in llvm/lib/CodeGen/BranchFolding.cpp looks like it
could do the folding. Quick experimentation with removing the guards:
1. OptForSize
2. PredTBB == MBB
enables this optimizations, but seems to regress quite a few tests:
Failed Tests (29):
LLVM :: CodeGen/X86/add.ll
LLVM :: CodeGen/X86/atom-pad-short-functions.ll
LLVM :: CodeGen/X86/avx512-i1test.ll
LLVM :: CodeGen/X86/bmi.ll
LLVM :: CodeGen/X86/brcond.ll
LLVM :: CodeGen/X86/btq.ll
LLVM :: CodeGen/X86/cmp.ll
LLVM :: CodeGen/X86/conditional-tailcall-pgso.ll
LLVM :: CodeGen/X86/conditional-tailcall.ll
LLVM :: CodeGen/X86/copy-eflags.ll
LLVM :: CodeGen/X86/extern_weak.ll
LLVM :: CodeGen/X86/fold-rmw-ops.ll
LLVM :: CodeGen/X86/fp-strict-scalar-cmp.ll
LLVM :: CodeGen/X86/funnel-shift.ll
LLVM :: CodeGen/X86/neg_cmp.ll
LLVM :: CodeGen/X86/or-branch.ll
LLVM :: CodeGen/X86/peep-test-4.ll
LLVM :: CodeGen/X86/pr37063.ll
LLVM :: CodeGen/X86/rd-mod-wr-eflags.ll
LLVM :: CodeGen/X86/sibcall.ll
LLVM :: CodeGen/X86/slow-incdec.ll
LLVM :: CodeGen/X86/sqrt-partial.ll
LLVM :: CodeGen/X86/switch-bt.ll
LLVM :: CodeGen/X86/tail-call-conditional.mir
LLVM :: CodeGen/X86/tail-opts.ll
LLVM :: CodeGen/X86/tailcall-cgp-dup.ll
LLVM :: CodeGen/X86/tailcall-extract.ll
LLVM :: CodeGen/X86/xor-icmp.ll
LLVM :: DebugInfo/COFF/pgo.ll
Some of these are straightforward fixes that I think make sense, but others
like llvm/test/CodeGen/X86/conditional-tailcall.ll look quite wrong (branching
the wrong way, IIUC)!
--
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 33733 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::ASTContext::getIntWidth
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-27 Type: Bug New issue 33733 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::ASTContext::getIntWidth https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33733 Detailed Report: https://oss-fuzz.com/testcase?key=6163434338123776 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe6387aff8 Crash State: clang::ASTContext::getIntWidth IntExprEvaluator::Success clang::StmtVisitorBase::Visit Sanitizer: address (ASAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&revision=202104260613 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6163434338123776 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 50132] New: Crash in ARC backend when calling LLVMTargetMachineEmitToFile
https://bugs.llvm.org/show_bug.cgi?id=50132 Bug ID: 50132 Summary: Crash in ARC backend when calling LLVMTargetMachineEmitToFile Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Register Allocator Assignee: unassignedb...@nondot.org Reporter: wenyong.hu...@intel.com CC: llvm-bugs@lists.llvm.org, quentin.colom...@gmail.com Created attachment 24804 --> https://bugs.llvm.org/attachment.cgi?id=24804&action=edit The LLVM IR file converted from wasm bytecodes Hi, We are developing WebAssembly runtime which uses LLVM as the JIT/AOT codegen backend for ARC CPU, and the runtime JIT/AOT compiler converts wasm bytecodes into LLVM IR, runs optimization passes and finally calls LLVMTargetMachineEmitToFile API to emit the Assembly file. And when calling LLVMTargetMachineEmitToFile for some case, if the opt level is larger than LLVMCodeGenLevelNone, crash occurs and the following error is reported: LLVM ERROR: Error while trying to spill R4 from class GPR32: Cannot scavenge register without an emergency spill slot! For opt level LLVMCodeGenLevelNone, and for other CPU e.g. X86_64 and ARM, it is OK. I uploaded the LLVM IR file, could you please help have a check? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50133] New: [MS] Crush when calling intrinsic __cpuid
https://bugs.llvm.org/show_bug.cgi?id=50133
Bug ID: 50133
Summary: [MS] Crush when calling intrinsic __cpuid
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: pengfei.w...@intel.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
Small reproducer:
#include
#include
#include
struct A {
std::string S;
std::vector> V;
A() {
std::array B;
__cpuid(B.data(), 0);
V.push_back(B);
V.push_back(B);
char C[64];
memset(C, 0, sizeof(C));
S = C;
}
} T;
Commands:
clang-cl -mavx2 /EHs repro.cpp -S
cat repro.asm | grep cpuid -A7
cpuid
#NO_APP
mov r11d, eax
mov rax, qword ptr [rbx + 72] # 8-byte Reload
mov r10d, ebx
mov r9d, ecx
mov rcx, qword ptr [rbx + 80] # 8-byte Reload
mov r8d, edx
--
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 33738 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in ConvertDeclSpecToType
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-04-27 Type: Bug New issue 33738 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in ConvertDeclSpecToType https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33738 Detailed Report: https://oss-fuzz.com/testcase?key=5836468829421568 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdc1a7fd88 Crash State: ConvertDeclSpecToType GetDeclSpecTypeForDeclarator clang::Sema::GetTypeForDeclarator Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202104230600:202104240627 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5836468829421568 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 50135] New: Subtle behavior of OpenMP offload entries table
https://bugs.llvm.org/show_bug.cgi?id=50135
Bug ID: 50135
Summary: Subtle behavior of OpenMP offload entries table
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: vyacheslav.p.zakha...@intel.com
CC: llvm-bugs@lists.llvm.org
Here is an example to demonstrate potential issue in the ordering of OpenMP
offload entries. Since the host and the target compilations may be using
different linkers to link the host and device “object” files, I think the LLVM
OpenMP offload design should at least say something about this.
glob1.c:
#pragma omp declare target
int g1;
int g2;
#pragma omp end declare target
glob2.c:
#pragma omp declare target
int g3;
#pragma omp end declare target
glob3.c:
#include
#pragma omp declare target
extern int g1, g2, g3;
void print() {
printf("%d %d %d\n", g1, g2, g3);
}
#pragma omp end declare target
int main() {
g1 = 1;
g2 = 2;
g3 = 3;
#pragma omp target update to(g1, g2, g3)
#pragma omp target
print();
return 0;
}
I compile it with: clang -fopenmp -fopenmp-targets=x86_64 glob1.c glob2.c
glob3.c
The output is: 1 2 3
So far so good. I redirect the driver’s -### output to bld.sh. The target
link command looks like this:
“gcc" "-shared" "-m64" "-o" "/tmp/glob1-0be2b6.out" "/tmp/glob1-b121d8.o"
"/tmp/glob2-f2cce9.o" "/tmp/glob3-c114b9.o"
To demonstrate the issue, I swap "/tmp/glob1-b121d8.o" and
"/tmp/glob2-f2cce9.o":
“gcc" "-shared" "-m64" "-o" "/tmp/glob1-0be2b6.out" "/tmp/glob2-f2cce9.o"
"/tmp/glob1-b121d8.o" "/tmp/glob3-c114b9.o"
I run bld.sh, and then run the new a.out.
The new output is: 2 3 1
Behavior changed, because the order of entries in the offload entries table has
changed:
1. Host entries order: g1, g2, g3
2. Original target entries order: g1, g2, g3
3. New target entries order: g3, g1, g2
So with the new ordering, host_g1 maps to target_g3, host_g2 maps to target_g1
and host_g3 maps to target_g2, thus, when we print target_g*, we get 2, 3, 1.
P.S. The issue becomes even more serious on Windows, where MSVC host linker may
insert undocumented(?) 0 paddings within data sections (e.g. between two
offload entries). And if a target toolchain uses llvm-link for linking the
target parts, it is hard to guarantee that the final structure of the target
offload entries table matches the host structure.
--
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 50137] New: ad hoc requires-expression being evaluated too eagerly
https://bugs.llvm.org/show_bug.cgi?id=50137
Bug ID: 50137
Summary: ad hoc requires-expression being evaluated too eagerly
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: pilarlati...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following program prints: "Overridden", "Fallback":
```cpp
#include
#include
template
class Base
{
private:
static constexpr bool IsOverridden = requires(T const x) { x.template
f(); };
public:
template requires IsOverridden
void f() const
{ static_cast(this)->f(); }
template
void f() const
{ std::cout << "Fallback" << std::endl; }
};
class A : public Base
{
public:
template
void f() const
{ std::cout << "Overridden" << std::endl; }
};
class B : public Base {};
template
void f(Base const &x)
{ x.f(); }
int main()
{
A const a;
B const b;
f(a);
f(b);
return 0;
}
```
However, if we remove the bool constant and use the requires-expression
directly in the requires-clause, it prints "Fallback", "Fallback":
```cpp
#include
#include
template
class Base
{
public:
template
requires requires(T const x) { x.template f(); };
void f() const
{ static_cast(this)->f(); }
template
void f() const
{ std::cout << "Fallback" << std::endl; }
};
class A : public Base
{
public:
template
void f() const
{ std::cout << "Overridden" << std::endl; }
};
class B : public Base {};
template
void f(Base const &x)
{ x.f(); }
int main()
{
A const a;
B const b;
f(a);
f(b);
return 0;
}
```
GCC consistently prints "Overridden", "Fallback" in both cases, which I believe
is what makes sense. Please let me know if it's a bug, and otherwise I'll
report it to GCC.
Thanks
Pili
--
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
