[llvm-bugs] [Bug 41134] New: Analyzer crash in C++17 mode
https://bugs.llvm.org/show_bug.cgi?id=41134
Bug ID: 41134
Summary: Analyzer crash in C++17 mode
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: compile-fail, regression
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: v.reich...@netcologne.de
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
The following valid testcase triggers an assertion when compiled with
"--analyze -std=c++17":
===
struct A
{
A() {}
};
A get()
{
return { A() };
}
void foo(A&&);
void bar()
{
foo(get());
}
===
clang-9: llvm/tools/clang/lib/StaticAnalyzer/Core/RegionStore.cpp:2362:
{anonymous}::RegionBindingsRef
{anonymous}::RegionStoreManager::bindStruct(RegionBindingsConstRef, const
clang::ento::TypedValueRegion*, clang::ento::SVal): Assertion
`CRD->isAggregate() && "Non-aggregates are constructed with a constructor!"'
failed.
Stack dump:
0. Program arguments: LLVM/LLVM-trunk-356359/bin/clang-9 -cc1 -triple
x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name CLbug.cc
-analyzer-store=region -analyzer-opt-analyze-nested-blocks
-analyzer-checker=core -analyzer-checker=apiModeling -analyzer-checker=unix
-analyzer-checker=deadcode -analyzer-checker=cplusplus
-analyzer-checker=security.insecureAPI.UncheckedReturn
-analyzer-checker=security.insecureAPI.getpw
-analyzer-checker=security.insecureAPI.gets
-analyzer-checker=security.insecureAPI.mktemp
-analyzer-checker=security.insecureAPI.mkstemp
-analyzer-checker=security.insecureAPI.vfork
-analyzer-checker=nullability.NullPassedToNonnull
-analyzer-checker=nullability.NullReturnedFromNonnull -analyzer-output plist -w
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -resource-dir
LLVM/LLVM-trunk-356359/lib/clang/9.0.0 -internal-isystem
/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../include/c++/5.3.1
-internal-isystem
/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../include/c++/5.3.1/x86_64-redhat-linux
-internal-isystem
/opt/rh/devtoolset-4/root/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../include/c++/5.3.1/backward
-internal-isystem /usr/local/include -internal-isystem
LLVM/LLVM-trunk-356359/lib/clang/9.0.0/include -internal-externc-isystem
/include -internal-externc-isystem /usr/include -std=c++17 -fdeprecated-macro
-fdebug-compilation-dir /home/vreichelt -ferror-limit 19 -fmessage-length 0
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o
CLbug.plist -x c++ CLbug.cc -faddrsig
1. parser at end of file
2. While analyzing stack:
#0 Calling bar
3. CLbug.cc:21:7: Error evaluating statement
4. CLbug.cc:21:7: Error evaluating statement
#0 0x0244a19a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(LLVM/LLVM-trunk-356359/bin/clang-9+0x244a19a)
...
#9 0x039c1233 (anonymous
namespace)::RegionStoreManager::bind((anonymous namespace)::RegionBindingsRef
const&, clang::ento::Loc, clang::ento::SVal)
(LLVM/LLVM-trunk-356359/bin/clang-9+0x39c1233)
#10 0x039c17d5 (anonymous namespace)::RegionStoreManager::Bind(void
const*, clang::ento::Loc, clang::ento::SVal)
(LLVM/LLVM-trunk-356359/bin/clang-9+0x39c17d5)
#11 0x039a742c clang::ento::ProgramState::bindLoc(clang::ento::Loc,
clang::ento::SVal, clang::LocationContext const*, bool) const
(LLVM/LLVM-trunk-356359/bin/clang-9+0x39a742c)
#12 0x039383c5
clang::ento::ExprEngine::createTemporaryRegionIfNeeded(llvm::IntrusiveRefCntPtr, clang::LocationContext const*, clang::Expr const*, clang::Expr const*,
clang::ento::SubRegion const**) (LLVM/LLVM-trunk-356359/bin/clang-9+0x39383c5)
#13 0x0395ab93
clang::ento::ExprEngine::CreateCXXTemporaryObject(clang::MaterializeTemporaryExpr
const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
(LLVM/LLVM-trunk-356359/bin/clang-9+0x395ab93)
#14 0x0394628e clang::ento::ExprEngine::Visit(clang::Stmt const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&)
(LLVM/LLVM-trunk-356359/bin/clang-9+0x394628e)
#15 0x03947c72 clang::ento::ExprEngine::ProcessStmt(clang::Stmt const*,
clang::ento::ExplodedNode*) (LLVM/LLVM-trunk-356359/bin/clang-9+0x3947c72)
#16 0x03947e2a
clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*)
(LLVM/LLVM-trunk-356359/bin/clang-9+0x3947e2a)
#17 0x0391aaa6 clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock
const*, unsigned int, clang::ento::ExplodedNode*)
(LLVM/LLVM-trunk-356359/bin/clang-9+0x391aaa6)
#18 0x0391ad35
clang::ento::CoreEngine::dispatchW
[llvm-bugs] [Bug 41135] New: Windows on Arm: X0 corrupted when returning values indirectly
https://bugs.llvm.org/show_bug.cgi?id=41135
Bug ID: 41135
Summary: Windows on Arm: X0 corrupted when returning values
indirectly
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: llc
Assignee: unassignedb...@nondot.org
Reporter: sjoerd.mei...@arm.com
CC: llvm-bugs@lists.llvm.org
We think that we miscompile code targeting aarch64-pc-windows-msvc. It looks
like the problem is in Clang/LLVM not obeying the Windows ARM64 ABI, which says
that:
"For return-by-value that cannot be passed via registers, the caller shall
reserve a block of memory of sufficient size and alignment to hold the result.
The address of the memory block shall be passed as an additional argument to
the function in x8 for POD type, or in x0 (or x1 if $this is passed in x0) for
non-POD type."
The problem is that we do not preserve x0 when the result value is passed
through X0 and another function call is made.
Here's a reproducer:
template
class MaybeLocal {
public:
T* ptr = nullptr;
};
extern int FOO(bool);
template
class Maybe {
public:
bool hasValue = false;
T value = false;
MaybeLocal Invert() {
Maybe ret;
ret.value = ~this->value;
FOO(hasValue);
return MaybeLocal{&this->value};
}
};
int main(void) {
Maybe m;
m.hasValue = true;
m.value = 7;
return (m.Invert().ptr == nullptr);
}
Compiling this e.g. with:
clang++ --target=aarch64-pc-windows-msvc -S -Os fno-inline
Generates this for function Invert:
.globl "?Invert@?$Maybe@_N@@QEAA?AV?$MaybeLocal@_N@@XZ" ; -- Begin function
?Invert@?$Maybe@_N@@QEAA?AV?$MaybeLocal@_N@@XZ
.p2align2
"?Invert@?$Maybe@_N@@QEAA?AV?$MaybeLocal@_N@@XZ": ;
@"?Invert@?$Maybe@_N@@QEAA?AV?$MaybeLocal@_N@@XZ"
.seh_proc "?Invert@?$Maybe@_N@@QEAA?AV?$MaybeLocal@_N@@XZ"
; %bb.0:; %entry
stp x19, x20, [sp, #-32]!
str x30, [sp, #16]
mov x20, x0 <~~~ MOV X0 TO X20
add x0, sp, #24
mov x19, x1
bl "??0?$Maybe@_N@@QEAA@XZ"
orr w8, wzr, #0x1
strbw8, [sp, #25]
ldrbw0, [x20], #1<~~~ LOAD W0 HERE
bl "?FOO@@YAH_N@Z"
str x20, [x19] <~~~ DON'T RELOAD X0 HERE SOMEWHERE
ldr x30, [sp, #16]
ldp x19, x20, [sp], #32
ret
As annotated in the assembly code above, we move X0 to X20, but don't seem to
reload X0 after the call to FOO.
--
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 41136] New: Windows on Arm: Clang doesn't follow the ABI for Indirect Arguments
https://bugs.llvm.org/show_bug.cgi?id=41136
Bug ID: 41136
Summary: Windows on Arm: Clang doesn't follow the ABI for
Indirect Arguments
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: llc
Assignee: unassignedb...@nondot.org
Reporter: sjoerd.mei...@arm.com
CC: llvm-bugs@lists.llvm.org
The Windows on ARM64 ABI specifies the following (under Return Values):
"For return-by-value that cannot be passed via registers, the caller shall
reserve a block of memory of sufficient size and alignment to hold the result.
The address of the memory block shall be passed as an additional argument to
the function in x8 for POD type, or in x0 (or x1 if $this is passed in x0) for
non-POD type. The callee may modify the result memory block at any point during
the execution of the subroutine (there is no requirement for the callee to
preserve the value stored in x8, but for non-POD, the address of this buffer
must also be returned in x0 by callee)."
This means (AFAICT) that when it's impossible to return a value in the native
registers, it instead allocates an indirect location on the stack, and passes
it into the callee function via x0, x1 or x8. MSVC and Clang disagree on when
this is required.
Main file:
template
class Maybe {
public:
bool hasValue = false;
T value = false;
};
Maybe f(int x, int y);
int main(void) {
bool v = f(5, 6).value;
bool hv = f(5, 6).hasValue;
printf("main(): value = %d, hasValue = %d\n", v, hv);
}
Callee file:
Maybe f(int x, int y) {
printf("f(): x = %d, y = %d\n", x, y);
Maybe m;
m.hasValue = x < 7;
m.value = y < 7;
return m;
}
Clang passes x and y in w1, w2, indirect buffer passed in x0. Called MSVC
function expects arguments in w0, w1 and therefore receives wrong argument
values. We think this is incorrect behaviour.
--
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 41137] New: missed opt: target-feature propagation
https://bugs.llvm.org/show_bug.cgi?id=41137
Bug ID: 41137
Summary: missed opt: target-feature propagation
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org
Minimal working example - this Rust code:
extern "C" {
#[target_feature(enable = "avx2")]
pub fn foo();
}
pub unsafe fn bar() { foo() }
generated the following LLVM-IR (https://rust.godbolt.org/z/fzcraS):
define void @bar() unnamed_addr #0 {
tail call void @foo()
ret void
}
declare void @foo() unnamed_addr #1
attributes #0 = { nounwind nonlazybind uwtable
"probe-stack"="__rust_probestack" "target-cpu"="x86-64" }
attributes #1 = { nounwind nonlazybind uwtable
"probe-stack"="__rust_probestack" "target-cpu"="x86-64"
"target-features"="+avx2" }
which `opt` does not optimize further (https://rust.godbolt.org/z/XgMyCJ).
Note that `foo` does get the "target-features"="+avx2" attribute added, which
in general can significantly impact code generation.
This optimization is sound, because if `foo` is called on a platform without
`avx2` support, the behavior is undefined. That is, LLVM can always assume that
`foo` will only be called on platforms where `avx2` is enabled.
--
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 41137] missed opt: target-feature propagation
https://bugs.llvm.org/show_bug.cgi?id=41137 Gonzalo BG changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 41138] New: missed opt: target-feature propagation
https://bugs.llvm.org/show_bug.cgi?id=41138
Bug ID: 41138
Summary: missed opt: target-feature propagation
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org
Minimal working example - this Rust code:
extern "C" {
#[target_feature(enable = "avx2")] pub fn foo();
}
pub unsafe fn bar() { foo() }
generates the following LLVM-IR (https://rust.godbolt.org/z/fzcraS):
define void @bar() unnamed_addr #0 {
tail call void @foo()
ret void
}
declare void @foo() unnamed_addr #1
attributes #0 = { nounwind nonlazybind uwtable
"probe-stack"="__rust_probestack" "target-cpu"="x86-64" }
attributes #1 = { nounwind nonlazybind uwtable
"probe-stack"="__rust_probestack" "target-cpu"="x86-64"
"target-features"="+avx2" }
which `opt` does not optimize further (https://rust.godbolt.org/z/XgMyCJ).
Note that `foo` has the "target-features"="+avx2", but this is not propagated
to `bar`, which can significantly impact code generation and other
optimizations (e.g. if `bar` contained loops, those could use AVX2
instructions).
Propagating `avx2` to `bar` in this case is sound, because if `foo` is called
on a platform without `avx2` support, the behavior is undefined. That is, we
can assume that `foo` will only be called on platforms where `avx2` is enabled.
In general, if a function is unconditionally called, we can propagate its
target-features to the caller. If a function is only conditionally called, more
complex analysis is required, e.g., for this code
extern "C" {
#[target_feature(enable = "avx2")] pub fn foo();
#[target_feature(enable = "avx2")] pub fn baz();
}
pub unsafe fn bar(x: i32) {
if x == 0 { foo() } else { baz() }
}
which produces this LLVM-IR (https://rust.godbolt.org/z/XT4Hpo):
define void @bar(i32 %x) unnamed_addr #0 {
%0 = icmp eq i32 %x, 0
br i1 %0, label %bb1, label %bb2
bb1: ; preds = %start
tail call void @foo()
br label %bb3
bb2: ; preds = %start
tail call void @baz()
br label %bb3
bb3: ; preds = %bb2, %bb1
ret void
}
declare void @foo() unnamed_addr #1
declare void @baz() unnamed_addr #1
attributes #0 = { nounwind nonlazybind uwtable
"probe-stack"="__rust_probestack" "target-cpu"="x86-64" }
attributes #1 = { nounwind nonlazybind uwtable
"probe-stack"="__rust_probestack" "target-cpu"="x86-64"
"target-features"="+avx2" }
The optimization is also sound: `bar` should also have the `+avx2`
target-feature.
--
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 40999] clang-format messes up indentation when using JavaScript private fields and methods
https://bugs.llvm.org/show_bug.cgi?id=40999 MyDeveloperDay changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||r356449 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 41139] New: Frontend crashes passing a function pointer/ref.s to template class constructor
https://bugs.llvm.org/show_bug.cgi?id=41139
Bug ID: 41139
Summary: Frontend crashes passing a function pointer/ref.s to
template class constructor
Product: clang
Version: 7.0
Hardware: PC
OS: other
Status: NEW
Severity: normal
Priority: P
Component: C++'17
Assignee: unassignedclangb...@nondot.org
Reporter: yapoo...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Created attachment 21628
--> https://bugs.llvm.org/attachment.cgi?id=21628&action=edit
run script
Clang(7.0.1) frontend crashes to compile these constractors.
//
int f1( unsigned ) { return 0; }
/
template
struct S1 {
S1( R(*f)(Args...) ) {}
// S1( R(&f)(Args...) ) {}
// S1( R(&&f)(Args...) ) {}
};
//
int main() {
S1 s1( f1 );
// F1(f1);
return 0;
}
invocation command line
$ clang -std=c++17 a.cpp
--
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 41140] New: [MemorySSA] wrong code
https://bugs.llvm.org/show_bug.cgi?id=41140
Bug ID: 41140
Summary: [MemorySSA] wrong code
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: pauls...@linux.vnet.ibm.com
CC: llvm-bugs@lists.llvm.org
Created attachment 21630
--> https://bugs.llvm.org/attachment.cgi?id=21630&action=edit
reduced test case
gcc -O3 -march=z13 ./wrong0.i -o a.out -w ; ./a.out
checksum = 2
gcc -O0 -march=z13 ./wrong0.i -o a.out -w ; ./a.out
checksum = 2
bin/clang -O3 -march=z13 ./wrong0.i -o a.out -w ; ./a.out
checksum = 2
bin/clang -O3 -march=z13 ./wrong0.i -o a.out -w -mllvm
-enable-mssa-loop-dependency; ./a.out
checksum = 0
a, f;
*b = &a;
*volatile *c = &b;
static **d = &b;
short e;
main() {
for (; e <= 1; e++) {
**c = 2;
*d = &f;
}
printf("checksum = %X\n", a);
}
(also attached)
--
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 12239 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: Out-of-memory in llvm-opt-fuzzer--x86_64-loop_unroll
Updates: Labels: Deadline-Approaching Comment #4 on issue 12239 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-loop_unroll: Out-of-memory in llvm-opt-fuzzer--x86_64-loop_unroll https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12239#c4 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 41053] Recursive use of .set crashes the MIPS backend
https://bugs.llvm.org/show_bug.cgi?id=41053 Simon Atanasyan changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #1 from Simon Atanasyan --- Fixed at https://reviews.llvm.org/rL356461. -- 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 41142] New: Assertion failure in RegionStoreManager::bindStruct(...): CRD->isAggregate() && "Non-aggregates are constructed with a constructor!"
https://bugs.llvm.org/show_bug.cgi?id=41142
Bug ID: 41142
Summary: Assertion failure in
RegionStoreManager::bindStruct(...):
CRD->isAggregate() && "Non-aggregates are constructed
with a constructor!"
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: noqnoq...@gmail.com
Reporter: ale...@google.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
$ cat t.cc
struct a {};
class b : a {};
b c() { b d{c()}; }
$ ./clang-tidy -checks="-*,clang-analyzer*" t.cc -- -std=c++17
assert.h assertion failed at
tools/clang/lib/StaticAnalyzer/Core/RegionStore.cpp:2362 in (anonymous
namespace)::RegionBindingsRef (anonym
ous namespace)::RegionStoreManager::bindStruct(RegionBindingsConstRef, const
clang::ento::TypedValueRegion *, clang::ento::SVal): CRD->isAggregate() &&
"Non-aggregates are constructed with a constructor!"
@ 0x559908170326 __assert_fail
@ 0x5599068d4854 (anonymous
namespace)::RegionStoreManager::bindStruct()
@ 0x5599068c93c8 (anonymous namespace)::RegionStoreManager::Bind()
@ 0x5599068b409f clang::ento::ProgramState::bindLoc()
@ 0x559906865935
clang::ento::ExprEngine::processPointerEscapedOnBind()
@ 0x55990685d4b3 clang::ento::ExprEngine::evalBind()
@ 0x559906872a43 clang::ento::ExprEngine::VisitDeclStmt()
@ 0x55990685c16f clang::ento::ExprEngine::Visit()
@ 0x559906858b1f clang::ento::ExprEngine::ProcessStmt()
@ 0x559906858808 clang::ento::ExprEngine::processCFGElement()
@ 0x55990684cb65 clang::ento::CoreEngine::HandlePostStmt()
@ 0x55990684bf5c clang::ento::CoreEngine::ExecuteWorkList()
@ 0x5599065b635b (anonymous namespace)::AnalysisConsumer::HandleCode()
@ 0x5599065a0135 (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit()
@ 0x559906bb7cbc clang::MultiplexConsumer::HandleTranslationUnit()
@ 0x559906d226d4 clang::ParseAST()
@ 0x559906b98a83 clang::FrontendAction::Execute()
@ 0x559906b31cd1 clang::CompilerInstance::ExecuteAction()
@ 0x559906a9cf61
clang::tooling::FrontendActionFactory::runInvocation()
@ 0x55990620cc07
clang::tidy::runClangTidy()::ActionFactory::runInvocation()
@ 0x559906a9ccca clang::tooling::ToolInvocation::runInvocation()
@ 0x559906a9c646 clang::tooling::ToolInvocation::run()
@ 0x559906a9ef22 clang::tooling::ClangTool::run()
@ 0x559906207ecf clang::tidy::runClangTidy()
@ 0x559902d47c45 main
--
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 41141] New apparent clang-tidy false positive from code using boost::is_any_of
https://bugs.llvm.org/show_bug.cgi?id=41141 Eugene Zelenko changed: What|Removed |Added Product|clang-tools-extra |clang Component|clang-tidy |Static Analyzer CC||dcough...@apple.com, ||eugene.zele...@gmail.com, ||llvm-bugs@lists.llvm.org Assignee|unassignedclangbugs@nondot. |dcough...@apple.com |org | -- 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 41069] multiple isnan() checks enhancement
https://bugs.llvm.org/show_bug.cgi?id=41069 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||356471 --- Comment #3 from Sanjay Patel --- Should be fixed with: https://reviews.llvm.org/rG5b820323ca11 -- 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 41144] New: Target.h #defines the inline keyword
https://bugs.llvm.org/show_bug.cgi?id=41144 Bug ID: 41144 Summary: Target.h #defines the inline keyword Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: brucedaw...@chromium.org CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk In llvm\include\llvm-c\Target.h there is a conditional #define of inline as __inline. Doing a #define of C++ keywords is illegal and the VC++ 2017 keycheck.h enforces this. This has led to a build break in ARM64 Win32 builds of Chromium (see crbug.com/943373). The #define should either be removed or should be scoped to only occur when compiling for C, or some-such. -- 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 41131] int-to-string conversions significantly slower in libc++ compared to MSVC STL
https://bugs.llvm.org/show_bug.cgi?id=41131 Thomas Anderson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Thomas Anderson --- Fixed by https://reviews.llvm.org/rCXX356512 -- 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 41145] New: [Codegen] convert select+store to conditional stores or vice-versa?
https://bugs.llvm.org/show_bug.cgi?id=41145
Bug ID: 41145
Summary: [Codegen] convert select+store to conditional stores
or vice-versa?
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
This is a reduction of 1 part of the problem noted in the post-commit thread
for r355741 - [x86] scalarize extract element 0 of FP cmp:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190311/635516.html
In that case, we have IR with a select and repeated identical compare
conditions (courtesy of CGP), and we're generating the x86 SSE (no blendv)
bitwise select sequence for it, but before r355741 it was getting converted to
compare and branch.
We don't appear to do that transform consistently, so I'm not sure if we want
to blame that exact example on something else, but here's a generalization:
target triple = "x86_64-unknown-unknown"
define void @select_store(double %x, double %y, double %z, double %w, double*
%p) {
entry:
%cmp = fcmp ult double %x, %y
%sel = select i1 %cmp, double %z, double %w
store double %sel, double* %p
ret void
}
define void @branch_store(double %x, double %y, double %z, double %w, double*
%p) {
entry:
%cmp = fcmp ult double %x, %y
br i1 %cmp, label %t, label %f
t:
store double %z, double* %p
ret void
f:
store double %w, double* %p
ret void
}
-
select_store:
cmpnlesd%xmm0, %xmm1
andpd %xmm1, %xmm2
andnpd %xmm3, %xmm1
orpd%xmm2, %xmm1
movsd %xmm1, (%rdi)
retq
branch_store:
ucomisd %xmm1, %xmm0
jae .LBB1_2
# %bb.1:# %t
movsd %xmm2, (%rdi)
retq
.LBB1_2:# %f
movsd %xmm3, (%rdi)
retq
-
Absent any profile info, we should be picking one form or the other?
Note: SimplifyCFG doesn't appear to do anything with these in IR either. There
are a bunch of debug options that would seem to apply, but I don't see any
differences using those.
--
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 41144] Target.h #defines the inline keyword
https://bugs.llvm.org/show_bug.cgi?id=41144 Reid Kleckner changed: What|Removed |Added CC||r...@google.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Reid Kleckner --- Fixed by r356524. It basically undoes http://reviews.llvm.org/rL193256. We haven't needed this since VC 2015 was our minimum requirement. -- 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 41147] New: Visual Studio LLVM toolset uses "lib.exe" instead of "llvm-lib.exe"
https://bugs.llvm.org/show_bug.cgi?id=41147
Bug ID: 41147
Summary: Visual Studio LLVM toolset uses "lib.exe" instead of
"llvm-lib.exe"
Product: new-bugs
Version: 7.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ste...@uplinklabs.net
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
This affects at least LLVM 7.0 onwards, through trunk.
I noticed that when I compiled objects with "clang-cl -flto", it wasn't able to
create a static library with them. It was apparently using the Visual Studio
provided "lib.exe", which doesn't understand these objects and just spits out
an error message:
foo.obj : fatal error LNK1107: invalid or corrupt file: cannot read at 0x1A4C
It looks like the LLVM.Cpp.Common.{props,targets} files are missing a tool
executable definition for llvm-lib.exe:
diff --git a/tools/msbuild/LLVM.Cpp.Common.props
b/tools/msbuild/LLVM.Cpp.Common.props
index 3420b77cfff..bc021b3b9e1 100644
--- a/tools/msbuild/LLVM.Cpp.Common.props
+++ b/tools/msbuild/LLVM.Cpp.Common.props
@@ -42,8 +42,10 @@
$(LLVMInstallDir)\
$(LLVMInstallDir)bin\clang-cl.exe
$(LLVMInstallDir)bin\lld-link.exe
+$(LLVMInstallDir)bin\llvm-lib.exe
true
true
+true
diff --git a/tools/msbuild/LLVM.Cpp.Common.targets
b/tools/msbuild/LLVM.Cpp.Common.targets
index 5870a3d4c59..74a98d6439b 100644
--- a/tools/msbuild/LLVM.Cpp.Common.targets
+++ b/tools/msbuild/LLVM.Cpp.Common.targets
@@ -9,6 +9,7 @@
that the user may have overridden in the UI. -->
$(ClangClExecutable)
$(LldLinkExecutable)
+$(LlvmLibExecutable)
Adding the above allowed my .lib with LTO objects to be created properly.
--
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 41148] New: llvm-lib.exe breaks with /LTCG argument
https://bugs.llvm.org/show_bug.cgi?id=41148 Bug ID: 41148 Summary: llvm-lib.exe breaks with /LTCG argument Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ste...@uplinklabs.net CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org After adding llvm-lib.exe to the toolset definition (bug 41147), I found that llvm-lib.exe doesn't eat and ignore the /LTCG argument: 1>/LTCG: no such file or directory 1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(1144,5): error MSB6006: "C:\LLVM\current\bin\llvm-lib.exe" exited with code 1. This presumably affects LLVM 7.0+, but I only tested the recent snapshot build of trunk. -- 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 41149] New: Compiling wasm simd bitcode w/o +simd128 can fail
https://bugs.llvm.org/show_bug.cgi?id=41149 Bug ID: 41149 Summary: Compiling wasm simd bitcode w/o +simd128 can fail Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: s...@google.com CC: llvm-bugs@lists.llvm.org Created attachment 21631 --> https://bugs.llvm.org/attachment.cgi?id=21631&action=edit Bitcode file demonstrating bug Enclosed is some bitcode that was generated using vector types. Building with llc --mtriple=wasm32-unknown--wasm -mattr=simd128 < /tmp/mod.bc works fine; building without simd128 like so: llc --mtriple=wasm32-unknown--wasm < /tmp/mod.bc fails with ScalarizeVectorResult #0: t104: v1i8 = abs t97 LLVM ERROR: Do not know how to scalarize the result of this operator! -- 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
