[llvm-bugs] [Bug 41131] int-to-string conversions significantly slower in libc++ compared to MSVC STL

2019-03-19 Thread via llvm-bugs
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 41149] New: Compiling wasm simd bitcode w/o +simd128 can fail

2019-03-19 Thread via llvm-bugs
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=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


[llvm-bugs] [Bug 41148] New: llvm-lib.exe breaks with /LTCG argument

2019-03-19 Thread via llvm-bugs
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 41147] New: Visual Studio LLVM toolset uses "lib.exe" instead of "llvm-lib.exe"

2019-03-19 Thread via llvm-bugs
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 41145] New: [Codegen] convert select+store to conditional stores or vice-versa?

2019-03-19 Thread via llvm-bugs
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

2019-03-19 Thread via llvm-bugs
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 41144] New: Target.h #defines the inline keyword

2019-03-19 Thread via llvm-bugs
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 41137] missed opt: target-feature propagation

2019-03-19 Thread via llvm-bugs
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 41137] New: missed opt: target-feature propagation

2019-03-19 Thread via llvm-bugs
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 40999] clang-format messes up indentation when using JavaScript private fields and methods

2019-03-19 Thread via llvm-bugs
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 41138] New: missed opt: target-feature propagation

2019-03-19 Thread via llvm-bugs
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 41136] New: Windows on Arm: Clang doesn't follow the ABI for Indirect Arguments

2019-03-19 Thread via llvm-bugs
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 41135] New: Windows on Arm: X0 corrupted when returning values indirectly

2019-03-19 Thread via llvm-bugs
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{>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 41134] New: Analyzer crash in C++17 mode

2019-03-19 Thread via llvm-bugs
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

[llvm-bugs] [Bug 41140] New: [MemorySSA] wrong code

2019-03-19 Thread via llvm-bugs
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=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 = 
*volatile *c = 
static **d = 
short e;
main() {
  for (; e <= 1; e++) {
**c = 2;
*d = 
  }
  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

2019-03-19 Thread sheriff… via monorail via llvm-bugs

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 41139] New: Frontend crashes passing a function pointer/ref.s to template class constructor

2019-03-19 Thread via llvm-bugs
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=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()(Args...) ) {}
// S1( R(&)(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 41142] New: Assertion failure in RegionStoreManager::bindStruct(...): CRD->isAggregate() && "Non-aggregates are constructed with a constructor!"

2019-03-19 Thread via llvm-bugs
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 41069] multiple isnan() checks enhancement

2019-03-19 Thread via llvm-bugs
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 41141] New apparent clang-tidy false positive from code using boost::is_any_of

2019-03-19 Thread via llvm-bugs
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