[PATCH] D81920: [clangd] Change FSProvider::getFileSystem to take CurrentWorkingDirectory

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang-tools-extra/clangd/Preamble.cpp:242
   llvm::IntrusiveRefCntPtr
-  getFileSystem() const override {
+  getFileSystem(llvm::NoneType) const override {
 return VFS;

A warning here too
```
23:51:14 
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/sdk_1_20_ki_dev_test/clang-tools-extra/clangd/Preamble.cpp:234:5:
 warning:   by 'virtual llvm::IntrusiveRefCntPtr 
clang::clangd::{anonymous}::scanPreamble(llvm::StringRef, const 
clang::tooling::CompileCommand&)::EmptyFS::view(llvm::NoneType) const' 
[-Woverloaded-virtual]
23:51:14  view(llvm::NoneType) const override {
23:51:14  ^~~~
```



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81920/new/

https://reviews.llvm.org/D81920



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81920: [clangd] Change FSProvider::getFileSystem to take CurrentWorkingDirectory

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang-tools-extra/clangd/support/FSProvider.h:39
+  virtual llvm::IntrusiveRefCntPtr
+  getFileSystem(PathRef CWD) const;
 };

I noticed that gcc (7.4) warns on this line:

```
/data/repo/master/clang-tools-extra/clangd/support/FSProvider.h:39:3: warning: 
'virtual llvm::IntrusiveRefCntPtr 
clang::clangd::FileSystemProvider::getFileSystem(clang::clangd::PathRef) const' 
was hidden [-Woverloaded-virtual]
   getFileSystem(PathRef CWD) const;
   ^
```



Comment at: clang-tools-extra/clangd/support/FSProvider.h:45
   llvm::IntrusiveRefCntPtr
-  getFileSystem() const override;
+  getFileSystem(llvm::NoneType) const override;
 };

Similar warning here as well:
```
/data/repo/master/clang-tools-extra/clangd/support/FSProvider.h:45:7: warning:  
 by 'virtual llvm::IntrusiveRefCntPtr 
clang::clangd::RealFileSystemProvider::getFileSystem(llvm::NoneType) const' 
[-Woverloaded-virtual]
   getFileSystem(llvm::NoneType) const override;
   ^
```



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81920/new/

https://reviews.llvm.org/D81920



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82029: [Coroutines] Ensure co_await promise.final_suspend() does not throw

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi!

I see a bunch of failures when I run libcxx testcases with this patch. Should 
there be "noexcept" on a number of more places?

Failed Tests (8):

  libc++ :: 
libcxx/experimental/language.support/support.coroutines/dialect_support.pass.cpp
  libc++ :: 
std/experimental/language.support/support.coroutines/coroutine.handle/coroutine.handle.prom/promise.pass.cpp
  libc++ :: 
std/experimental/language.support/support.coroutines/end.to.end/await_result.pass.cpp
  libc++ :: 
std/experimental/language.support/support.coroutines/end.to.end/bool_await_suspend.pass.cpp
  libc++ :: 
std/experimental/language.support/support.coroutines/end.to.end/expected.pass.cpp
  libc++ :: 
std/experimental/language.support/support.coroutines/end.to.end/fullexpr-dtor.pass.cpp
  libc++ :: 
std/experimental/language.support/support.coroutines/end.to.end/generator.pass.cpp
  libc++ :: 
std/experimental/language.support/support.coroutines/end.to.end/go.pass.cpp


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82029/new/

https://reviews.llvm.org/D82029



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82029: [Coroutines] Ensure co_await promise.final_suspend() does not throw

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D82029#2109167 , @lxfind wrote:

> Test failures are being fixed in https://reviews.llvm.org/D82338/new/


Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82029/new/

https://reviews.llvm.org/D82029



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81920: [clangd] Change FSProvider::getFileSystem to take CurrentWorkingDirectory

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D81920#2109901 , @kadircet wrote:

> Can you check if you see the warning with different versions of gcc?


Originally I got them with 7.4.0 and now I tried with 9.3.0 and got them there 
as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81920/new/

https://reviews.llvm.org/D81920



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72841: Add support for pragma float_control, to control precision and exception behavior at the source level

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi @mibintc ,

I think I'm seeing some oddities with this patch (current trunk, 0054c46095 
).
With

  clang -S -Xclang -emit-llvm bbi-42553.c -o -

on the input

  float rintf(float x);
  #pragma STDC FENV_ACCESS ON
  
  void t()
  {
  (void)rintf(0.0f);
  }

I get

  bbi-42553.c:2:14: warning: pragma STDC FENV_ACCESS ON is not supported, 
ignoring pragma [-Wunknown-pragmas]
  #pragma STDC FENV_ACCESS ON
   ^
  ; ModuleID = 'bbi-42553.c'
  source_filename = "bbi-42553.c"
  target datalayout = 
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
  target triple = "x86_64-unknown-linux-gnu"
  
  ; Function Attrs: noinline nounwind optnone strictfp uwtable
  define dso_local void @t() #0 {
  entry:
%0 = call float @llvm.experimental.constrained.rint.f32(float 0.00e+00, 
metadata !"round.tonearest", metadata !"fpexcept.ignore") #2
ret void
  }

and if I remove the pragma I instead get

  define dso_local void @t() #0 {
  entry:
%0 = call float @llvm.rint.f32(float 0.00e+00)
ret void
  }

Before this patch I got the call to llvm.rint.f32 in both cases.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72841/new/

https://reviews.llvm.org/D72841



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72841: Add support for pragma float_control, to control precision and exception behavior at the source level

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

It seems to be this change in SemaStmt.cpp that makes the FENV-pragma have some 
effect regardless of the warning saying that the pragma  doesn't have any 
effect:

  index aa0d89ac09c3..f76994a6dab3 100644
  @@ -394,6 +394,11 @@ StmtResult Sema::ActOnCompoundStmt(SourceLocation L, 
SourceLocation R,
  ArrayRef Elts, bool isStmtExpr) {
 const unsigned NumElts = Elts.size();
   
  +  // Mark the current function as usng floating point constrained intrinsics
  +  if (getCurFPFeatures().isFPConstrained())
  +if (FunctionDecl *F = dyn_cast(CurContext))
  +  F->setUsesFPIntrin(true);
  +


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72841/new/

https://reviews.llvm.org/D72841



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79510: [PATCH] When pragma FENV_ACCESS is ignored do not modify Sema.CurFPFeatures

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Great! Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79510/new/

https://reviews.llvm.org/D79510



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77644: [clangd] Handle additional includes while parsing ASTs

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1034
   const PreambleData &Preamble;
-  const PreamblePatch &Patch;
+  llvm::Optional Patch;
   llvm::StringRef Contents;

Hi!

When compiling with gcc 7.4 I see a warning that I think originates from this 
line:

```
[4032/4668] Building CXX object 
tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CodeComplete.cpp.o
In file included from /data/repo/master/llvm/include/llvm/ADT/STLExtras.h:19:0,
 from /data/repo/master/llvm/include/llvm/ADT/StringRef.h:12,
 from /data/repo/master/clang-tools-extra/clangd/URI.h:12,
 from /data/repo/master/clang-tools-extra/clangd/Protocol.h:26,
 from /data/repo/master/clang-tools-extra/clangd/Headers.h:12,
 from 
/data/repo/master/clang-tools-extra/clangd/CodeComplete.h:18,
 from 
/data/repo/master/clang-tools-extra/clangd/CodeComplete.cpp:20:
/data/repo/master/llvm/include/llvm/ADT/Optional.h: In instantiation of 'void 
llvm::optional_detail::OptionalStorage >::emplace(Args&& ...) 
[with Args = {const clang::clangd::PreamblePatch}; T = const 
clang::clangd::PreamblePatch; bool  = false]':
/data/repo/master/llvm/include/llvm/ADT/Optional.h:55:14:   required from 
'llvm::optional_detail::OptionalStorage 
>::OptionalStorage(llvm::optional_detail::OptionalStorage >&&) 
[with T = const clang::clangd::PreamblePatch; bool  = false]'
/data/repo/master/llvm/include/llvm/ADT/Optional.h:228:3:   required from here
/data/repo/master/llvm/include/llvm/ADT/Optional.h:89:12: warning: cast from 
type 'const clang::clangd::PreamblePatch*' to type 'void*' casts away 
qualifiers [-Wcast-qual]
 ::new ((void *)std::addressof(value)) T(std::forward(args)...);
^
```



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77644/new/

https://reviews.llvm.org/D77644



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81408: [builtins] Improve compatibility with 16 bit targets

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Our out-of-tree target also have 16 bit ints and we've had to change a whole 
bunch of __builtin_clz to clzsi and __builtin_ctz to ctzsi to make things work 
so this patch is a step in the right direction for us too.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81408/new/

https://reviews.llvm.org/D81408



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76856: Fix TBAA for unsigned fixed-point types

[Mikael Holmén via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7d482e921353: Fix TBAA for unsigned fixed-point types 
(authored by uabelho).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76856/new/

https://reviews.llvm.org/D76856

Files:
  clang/lib/CodeGen/CodeGenTBAA.cpp
  clang/test/CodeGen/fixed-point-tbaa.c

Index: clang/test/CodeGen/fixed-point-tbaa.c
===
--- /dev/null
+++ clang/test/CodeGen/fixed-point-tbaa.c
@@ -0,0 +1,109 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin -O1 -ffixed-point %s -emit-llvm -o - | FileCheck %s  -check-prefixes=CHECK
+//
+// Check that we generate correct TBAA metadata for fixed-point types.
+
+void sfract(unsigned short _Fract *p, short _Fract *q,
+unsigned _Sat short _Fract *r, _Sat short _Fract *s) {
+  // CHECK-LABEL: define void @sfract
+  // CHECK: store i8 -128, i8* %p, align 1, !tbaa [[TAG_sf:!.*]]
+  // CHECK: store i8 -64, i8* %q, align 1, !tbaa [[TAG_sf]]
+  // CHECK: store i8 -128, i8* %r, align 1, !tbaa [[TAG_sat_sf:!.*]]
+  // CHECK: store i8 -64, i8* %s, align 1, !tbaa [[TAG_sat_sf]]
+  *p = 0.5hur;
+  *q = -0.5hr;
+  *r = 0.5hur;
+  *s = -0.5hr;
+}
+
+void fract(unsigned _Fract *p, _Fract *q,
+   unsigned _Sat _Fract *r, _Sat _Fract *s) {
+  // CHECK-LABEL: define void @fract
+  // CHECK: store i16 -32768, i16* %p, align 2, !tbaa [[TAG_f:!.*]]
+  // CHECK: store i16 -16384, i16* %q, align 2, !tbaa [[TAG_f]]
+  // CHECK: store i16 -32768, i16* %r, align 2, !tbaa [[TAG_sat_f:!.*]]
+  // CHECK: store i16 -16384, i16* %s, align 2, !tbaa [[TAG_sat_f]]
+  *p = 0.5ur;
+  *q = -0.5r;
+  *r = 0.5ur;
+  *s = -0.5r;
+}
+
+void lfract(unsigned long _Fract *p, long _Fract *q,
+unsigned _Sat long _Fract *r, _Sat long _Fract *s) {
+  // CHECK-LABEL: define void @lfract
+  // CHECK: store i32 -2147483648, i32* %p, align 4, !tbaa [[TAG_lf:!.*]]
+  // CHECK: store i32 -1073741824, i32* %q, align 4, !tbaa [[TAG_lf]]
+  // CHECK: store i32 -2147483648, i32* %r, align 4, !tbaa [[TAG_sat_lf:!.*]]
+  // CHECK: store i32 -1073741824, i32* %s, align 4, !tbaa [[TAG_sat_lf]]
+  *p = 0.5ulr;
+  *q = -0.5lr;
+  *r = 0.5ulr;
+  *s = -0.5lr;
+}
+
+void saccum(unsigned short _Accum *p, short _Accum *q,
+unsigned _Sat short _Accum *r, _Sat short _Accum *s) {
+  // CHECK-LABEL: define void @saccum
+  // CHECK: store i16 128, i16* %p, align 2, !tbaa [[TAG_sk:!.*]]
+  // CHECK: store i16 -64, i16* %q, align 2, !tbaa [[TAG_sk]]
+  // CHECK: store i16 128, i16* %r, align 2, !tbaa [[TAG_sat_sk:!.*]]
+  // CHECK: store i16 -64, i16* %s, align 2, !tbaa [[TAG_sat_sk]]
+  *p = 0.5huk;
+  *q = -0.5hk;
+  *r = 0.5huk;
+  *s = -0.5hk;
+}
+
+void accum(unsigned _Accum *p, _Accum *q,
+   unsigned _Sat _Accum *r, _Sat _Accum *s) {
+  // CHECK-LABEL: define void @accum
+  // CHECK: store i32 32768, i32* %p, align 4, !tbaa [[TAG_k:!.*]]
+  // CHECK: store i32 -16384, i32* %q, align 4, !tbaa [[TAG_k]]
+  // CHECK: store i32 32768, i32* %r, align 4, !tbaa [[TAG_sat_k:!.*]]
+  // CHECK: store i32 -16384, i32* %s, align 4, !tbaa [[TAG_sat_k]]
+  *p = 0.5uk;
+  *q = -0.5k;
+  *r = 0.5uk;
+  *s = -0.5k;
+}
+
+void laccum(unsigned long _Accum *p, long _Accum *q,
+unsigned _Sat long _Accum *r, _Sat long _Accum *s) {
+  // CHECK-LABEL: define void @laccum
+  // CHECK: store i64 2147483648, i64* %p, align 8, !tbaa [[TAG_lk:!.*]]
+  // CHECK: store i64 -1073741824, i64* %q, align 8, !tbaa [[TAG_lk]]
+  // CHECK: store i64 2147483648, i64* %r, align 8, !tbaa [[TAG_sat_lk:!.*]]
+  // CHECK: store i64 -1073741824, i64* %s, align 8, !tbaa [[TAG_sat_lk]]
+  *p = 0.5ulk;
+  *q = -0.5lk;
+  *r = 0.5ulk;
+  *s = -0.5lk;
+}
+
+// CHECK-DAG: [[TAG_sf]] = !{[[TYPE_sf:!.*]], [[TYPE_sf]], i64 0}
+// CHECK-DAG: [[TYPE_sf]] = !{!"short _Fract"
+// CHECK-DAG: [[TAG_f]] = !{[[TYPE_f:!.*]], [[TYPE_f]], i64 0}
+// CHECK-DAG: [[TYPE_f]] = !{!"_Fract"
+// CHECK-DAG: [[TAG_lf]] = !{[[TYPE_lf:!.*]], [[TYPE_lf]], i64 0}
+// CHECK-DAG: [[TYPE_lf]] = !{!"long _Fract"
+
+// CHECK-DAG: [[TAG_sat_sf]] = !{[[TYPE_sat_sf:!.*]], [[TYPE_sat_sf]], i64 0}
+// CHECK-DAG: [[TYPE_sat_sf]] = !{!"_Sat short _Fract"
+// CHECK-DAG: [[TAG_sat_f]] = !{[[TYPE_sat_f:!.*]], [[TYPE_sat_f]], i64 0}
+// CHECK-DAG: [[TYPE_sat_f]] = !{!"_Sat _Fract"
+// CHECK-DAG: [[TAG_sat_lf]] = !{[[TYPE_sat_lf:!.*]], [[TYPE_sat_lf]], i64 0}
+// CHECK-DAG: [[TYPE_sat_lf]] = !{!"_Sat long _Fract"
+
+// CHECK-DAG: [[TAG_sk]] = !{[[TYPE_sk:!.*]], [[TYPE_sk]], i64 0}
+// CHECK-DAG: [[TYPE_sk]] = !{!"short _Accum"
+// CHECK-DAG: [[TAG_k]] = !{[[TYPE_k:!.*]], [[TYPE_k]], i64 0}
+// CHECK-DAG: [[TYPE_k]] = !{!"_Accum"
+// CHECK-DAG: [[TAG_lk]] = !{[[TYPE_lk:!.*]], [[TYPE_lk]], i64 0}
+// CHECK-DAG: [[TYPE_lk]] = !{!"long _Accum"
+
+// CHECK-DAG: [[TAG_sat_sk]] = !{[[TYPE_sat_sk:!.*]], [[TYPE_sat_sk]], i64 0}
+// CHECK-DAG: [[TYPE_sat_sk]] = !{!"_Sat short _Accum"
+// CHECK-DAG: [[TAG

[PATCH] D69935: [DeclCXX] Remove unknown external linkage specifications

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Don't you need to also remove

  case LinkageSpecDecl::lang_cxx_11:
  case LinkageSpecDecl::lang_cxx_14:

from VisitLinkageSpecDecl in clang-tools-extra/modularize/Modularize.cpp? 
(added in r372714 / e07376a320d to silence a clang warning).
I can't see how that code would compile otherwise?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69935/new/

https://reviews.llvm.org/D69935



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69935: [DeclCXX] Remove unknown external linkage specifications

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D69935#1739235 , @dblaikie wrote:

> In D69935#1738273 , @uabelho wrote:
>
> > Don't you need to also remove
> >
> >   case LinkageSpecDecl::lang_cxx_11:
> >   case LinkageSpecDecl::lang_cxx_14:
> >   
> >
> > from VisitLinkageSpecDecl in clang-tools-extra/modularize/Modularize.cpp? 
> > (added in r372714 / e07376a320d to silence a clang warning).
> >  I can't see how that code would compile otherwise?
>
>
> +1 to this


Did you see the above?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69935/new/

https://reviews.llvm.org/D69935



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59528: [clang-tidy] Expand modular headers for PPCallbacks

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I noticed that with this commit I get a whole bunch (~40) of warnings like the 
below when compiling with gcc 7.4:

  [10/16] Building CXX object 
tools/clang/tools/extra/clang-tidy/utils/CMakeFiles/clangTidyUtils.dir/HeaderGuard.cpp.o
  In file included from 
../tools/clang/tools/extra/clang-tidy/utils/HeaderGuard.h:12:0,
   from 
../tools/clang/tools/extra/clang-tidy/utils/HeaderGuard.cpp:9:
  ../tools/clang/tools/extra/clang-tidy/utils/../ClangTidy.h:161:16: warning: 
'virtual void clang::tidy::ClangTidyCheck::registerPPCallbacks(const 
clang::SourceManager&, clang::Preprocessor*, clang::Preprocessor*)' was hidden 
[-Woverloaded-virtual]
 virtual void registerPPCallbacks(const SourceManager &SM, Preprocessor *PP,
  ^~~
  In file included from 
../tools/clang/tools/extra/clang-tidy/utils/HeaderGuard.cpp:9:0:
  ../tools/clang/tools/extra/clang-tidy/utils/HeaderGuard.h:35:8: warning:   by 
'virtual void 
clang::tidy::utils::HeaderGuardCheck::registerPPCallbacks(clang::CompilerInstance&)'
 [-Woverloaded-virtual]
 void registerPPCallbacks(CompilerInstance &Compiler) override;
  ^~~

One of the registerPPCallbacks methods has the following comment

  /// DEPRECATED: Use the other overload.
  virtual void registerPPCallbacks(CompilerInstance &Compiler) {}

so I suppose it will be removed at some point?

I'm not super familiar with the warning, but there is at least one discussion 
about it here:
https://stackoverflow.com/questions/9995421/gcc-woverloaded-virtual-warnings


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59528/new/

https://reviews.llvm.org/D59528



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62476: [clangd] Support offsets for parameters in signatureHelp

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang-tools-extra/trunk/clangd/CodeComplete.cpp:925
+// FIXME: this should only be set on CK_CurrentParameter.
+Signal.ContainsActiveParameter = true;
+  }

Hi!

gcc (7.4) warns on this code:

```
error: parameter 'Signal' set but not used [-Werror=unused-but-set-parameter]
  SignatureQualitySignals Signal) const {
  ^~
```
Should Signal be a reference? Or is it specifically not a reference right now 
due to the FIXME?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62476/new/

https://reviews.llvm.org/D62476



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62476: [clangd] Support offsets for parameters in signatureHelp

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang-tools-extra/trunk/clangd/CodeComplete.cpp:925
+// FIXME: this should only be set on CK_CurrentParameter.
+Signal.ContainsActiveParameter = true;
+  }

ilya-biryukov wrote:
> ilya-biryukov wrote:
> > uabelho wrote:
> > > Hi!
> > > 
> > > gcc (7.4) warns on this code:
> > > 
> > > ```
> > > error: parameter 'Signal' set but not used 
> > > [-Werror=unused-but-set-parameter]
> > >   SignatureQualitySignals Signal) const {
> > >   ^~
> > > ```
> > > Should Signal be a reference? Or is it specifically not a reference right 
> > > now due to the FIXME?
> > Should be a reference, thanks for bringing that up! I'll send a fix.
> Removed this flag altogether in r362686, it is not used and has we have no 
> tests for it.
Thanks!


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62476/new/

https://reviews.llvm.org/D62476



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67613: [DWARF-5] Support for DWARF-5 C++ language tags

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D67613#1679879 , @xbolva00 wrote:

> /srv/llvm-buildbot-srcatch/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/tools/clang/tools/extra/modularize/Modularize.cpp:583:13:
>  warning: enumeration values 'lang_cxx_11' and 'lang_cxx_14' not handled in 
> switch [-Wswitch]
>  1 warning generated.


We also get that warning when compiling with clang 8:

../../clang-tools-extra/modularize/Modularize.cpp:583:13: error: enumeration 
values 'lang_cxx_11' and 'lang_cxx_14' not handled in switch [-Werror,-Wswitch]

  switch (D->getLanguage()) {
  ^

1 error generated.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67613/new/

https://reviews.llvm.org/D67613



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67613: [DWARF-5] Support for DWARF-5 C++ language tags

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D67613#1680176 , @uabelho wrote:

> In D67613#1679879 , @xbolva00 wrote:
>
> > /srv/llvm-buildbot-srcatch/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/tools/clang/tools/extra/modularize/Modularize.cpp:583:13:
> >  warning: enumeration values 'lang_cxx_11' and 'lang_cxx_14' not handled in 
> > switch [-Wswitch]
> >  1 warning generated.
>
>
> We also get that warning when compiling with clang 8:
>
>   ../../clang-tools-extra/modularize/Modularize.cpp:583:13: error: 
> enumeration values 'lang_cxx_11' and 'lang_cxx_14' not handled in switch 
> [-Werror,-Wswitch]
>   switch (D->getLanguage()) {
>   ^
>   1 error generated.
>


I did something about it in r372714. Please take a look and see if it should be 
fixed differently.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67613/new/

https://reviews.llvm.org/D67613



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28983: clang-format: remove tests that assume no config file will be found as this is not always the case

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Great! This patch solves the problems we saw. Thanks!


https://reviews.llvm.org/D28983



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86547: [compiler-rt][builtins] Use c[tl]zsi macro instead of __builtin_c[tl]z

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

We've run with changes like this for a long time to make the routines work for 
our out of tree target where int is also 16 bits so thumbs up from me even if 
I'm not sure I can formally LGTM it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86547/new/

https://reviews.llvm.org/D86547

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I'm seeing what I think is a miscompile with this:

  opt -S -dse -o - dse.ll

on

  @x = global [10 x [10 x i16]] zeroinitializer, align 1
  
  define i16 @f() {
  entry:
br label %do.body
  
  do.body:  ; preds = %if.end, %entry
%i.0 = phi i16 [ 0, %entry ], [ %inc, %if.end ]
%j.0 = phi i16 [ 0, %entry ], [ %add, %if.end ]
%arrayidx2 = getelementptr inbounds [10 x [10 x i16]], [10 x [10 x i16]]* 
@x, i16 0, i16 %i.0, i16 %j.0
store i16 2, i16* %arrayidx2, align 1
%exitcond = icmp eq i16 %i.0, 4
br i1 %exitcond, label %if.end10, label %if.end
  
  if.end:   ; preds = %do.body
%inc = add nuw nsw i16 %i.0, 1
%add = add nuw nsw i16 %j.0, 2
br label %do.body
  
  if.end10: ; preds = %do.body
store i16 1, i16* %arrayidx2, align 1
ret i16 0
  }

gives

  x = global [10 x [10 x i16]] zeroinitializer, align 1
  
  define i16 @f() {
  entry:
br label %do.body
  
  do.body:  ; preds = %if.end, %entry
%i.0 = phi i16 [ 0, %entry ], [ %inc, %if.end ]
%j.0 = phi i16 [ 0, %entry ], [ %add, %if.end ]
%arrayidx2 = getelementptr inbounds [10 x [10 x i16]], [10 x [10 x i16]]* 
@x, i16 0, i16 %i.0, i16 %j.0
%exitcond = icmp eq i16 %i.0, 4
br i1 %exitcond, label %if.end10, label %if.end
  
  if.end:   ; preds = %do.body
%inc = add nuw nsw i16 %i.0, 1
%add = add nuw nsw i16 %j.0, 2
br label %do.body
  
  if.end10: ; preds = %do.body
store i16 1, i16* %arrayidx2, align 1
ret i16 0
  }

So the store in the loop has been removed, which I think is incorrect.
The

  store i16 2

in the loop should be carried out at (i,j) == (0,0), (1,2), (2,4), (3,6) och 
(4,8) and then the last of them should be overwritten by the

  store i16 1

after the loop, but now the store in the loop is removed so we're only left 
with a written 1 at (4,8).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87163/new/

https://reviews.llvm.org/D87163

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D87163#2270860 , @fhahn wrote:

> In D87163#2270568 , @uabelho wrote:
>
>> Hi,
>>
>> I'm seeing what I think is a miscompile with this:
>
> Thanks for the reproducer. We have to be more careful around pointers that 
> may reference multiple locations in memory. I pushed f715d81c9df3 
>  which 
> limits elimination to stores that only reference a single location (or are in 
> the same BB). The check is conservative and can be improved in the future, 
> but the impact on the number of stores eliminated seems very low in practice. 
> It would be great if you could check if that fixes the original reproducer.

Great! I'll check and get back during the day.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87163/new/

https://reviews.llvm.org/D87163

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D87163#2270918 , @uabelho wrote:

> In D87163#2270860 , @fhahn wrote:
>
>> In D87163#2270568 , @uabelho wrote:
>>
>>> Hi,
>>>
>>> I'm seeing what I think is a miscompile with this:
>>
>> Thanks for the reproducer. We have to be more careful around pointers that 
>> may reference multiple locations in memory. I pushed f715d81c9df3 
>>  which 
>> limits elimination to stores that only reference a single location (or are 
>> in the same BB). The check is conservative and can be improved in the 
>> future, but the impact on the number of stores eliminated seems very low in 
>> practice. It would be great if you could check if that fixes the original 
>> reproducer.
>
> Great! I'll check and get back during the day.

Yep, the original reproducer passes now. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87163/new/

https://reviews.llvm.org/D87163

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87528: Enable '#pragma STDC FENV_ACCESS' in frontend

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

We got similar problems for our downstream target. We worked around that by 
bailing out early in PragmaSTDC_FENV_ACCESSHandler::HandlePragma for our target 
but perhaps one could check hasStrictFP() instead and ignore the pragma if that 
is false?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87528/new/

https://reviews.llvm.org/D87528

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi!

I found a new problem after this was turned on again in 51ff04567b2f 
.
With

  opt -S -o - bbi-49235.ll -memoryssa -gvn -dse -verify-memoryssa

I hit

  opt: ../lib/Analysis/MemorySSA.cpp:2063: void 
llvm::MemorySSA::verifyOrderingDominationAndDefUses(llvm::Function &) const: 
Assertion `&*ALI == *AAI && "Not the same accesses in the same order"' failed.

with bbi-49235.ll being

  define void @k() {
  entry:
%tobool = icmp ne i16 1, 0
%0 = xor i1 %tobool, true
call void @llvm.assume(i1 %0)
call void @f()
ret void
  }
  
  declare void @f() local_unnamed_addr
  
  ; Function Attrs: nofree nosync nounwind willreturn
  declare void @llvm.assume(i1 noundef) #0
  
  attributes #0 = { nofree nosync nounwind willreturn }


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87163/new/

https://reviews.llvm.org/D87163

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D87163#2373580 , @uabelho wrote:

> Hi!
>
> I found a new problem after this was turned on again in 51ff04567b2f 
> .

I wrote https://bugs.llvm.org/show_bug.cgi?id=48072 about it


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87163/new/

https://reviews.llvm.org/D87163

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I'm seeing a miscompile with this patch. I'm not very good at the semantic 
differences between undef and poison so I don't know really where it goes wrong.

Before Early CSE I see this in the input:

  entry:
%cmp1 = icmp uge i16 1015, 16, !dbg !9
%shr = lshr i16 -1, 1015
%cmp2 = icmp ugt i16 2, %shr
%or.cond = or i1 %cmp1, %cmp2, !dbg !10
br i1 %or.cond, label %if.then3, label %if.else4, !dbg !10

This corresponds to the following C-code:

  int16_t y1 = 1022;
  uint16_t res1 = 0;
  if (y1 < 0)
res1 = 0;
  else
res1 = 1015;
  
  if ((res1 >= 16) || (2 > (65535u >> res1)))
res2 = 42;
  else
res2 = 1;

So in the C input, the right shift is guarded and won't be carried out if res1 
is too large to avoid UB, but in the ll file the lshr is executed 
unconditionally.

Then after Early CSE I instead get

  entry:
br i1 poison, label %if.then3, label %if.else4, !dbg !9

So I suppose, with this patch the lshr will result in poison, and that poison 
will then make both %cmp2 and %or.cond be poison. And then we don't know where 
to jump so res2 gets the wrong value.

I'm not very good at poison semantics, but it seems to me that either the input 
to ewarly cse is invalid, or the patch has broken the semantics of "or"?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D92270#2422625 , @aqjune wrote:

> Hi,
>
> It seems it is related to two optimizations:
> (1) `select i1 x, true, y` -> `or i1 x, y`
> (2) `or i1 x, poison` -> `poison`
>
> Semantically, the first one is broken. It needs to freeze y. But, it will 
> introduce a lot of freeze instructions. The clang patches that introduce 
> noundef to function arguments is still ongoing.
> Another workaround is to weaken (2) to `or i1 x, poison` -> `x`. This fixes 
> the miscompilation; I'll push a commit that does this.

Should langref also be updated to describe this? Or does it already?
I just found this "An instruction that depends on a poison value, produces a 
poison value itself.".


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D92270#2422741 , @aqjune wrote:

> In D92270#2422661 , @uabelho wrote:
>
>> Should langref also be updated to describe this? Or does it already?
>> I just found this
>>  "An instruction that depends on a poison value, produces a poison value 
>> itself."
>> here
>>  http://llvm.org/docs/LangRef.html#poison-values
>
> I think "Values other than phi nodes and select instructions depend on their 
> operands." was supposed to say that. :)

I see. Ok, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D91927: [X86] Add x86_amx type for intel AMX.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: llvm/include/llvm/IR/Type.h:68
 X86_MMXTyID,   ///< MMX vectors (64 bits, X86 specific)
+X86_AMXTyID,   ///< AMX vectors (8192 bits, X86 specific)
 TokenTyID, ///< Tokens

This addition causes a compilation warning in HexagonTargetObjectFile.cpp:

```
../lib/Target/Hexagon/HexagonTargetObjectFile.cpp:297:11: error: enumeration 
value 'X86_AMXTyID' not handled in switch [-Werror,-Wswitch]
  switch (Ty->getTypeID()) {
  ^
1 error generated.
```
Seen in build bots, e.g. here:
http://lab.llvm.org:8011/#/builders/57/builds/2889/steps/6/logs/stdio


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91927/new/

https://reviews.llvm.org/D91927

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D91927: [X86] Add x86_amx type for intel AMX.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: llvm/include/llvm/IR/Type.h:68
 X86_MMXTyID,   ///< MMX vectors (64 bits, X86 specific)
+X86_AMXTyID,   ///< AMX vectors (8192 bits, X86 specific)
 TokenTyID, ///< Tokens

pengfei wrote:
> uabelho wrote:
> > This addition causes a compilation warning in HexagonTargetObjectFile.cpp:
> > 
> > ```
> > ../lib/Target/Hexagon/HexagonTargetObjectFile.cpp:297:11: error: 
> > enumeration value 'X86_AMXTyID' not handled in switch [-Werror,-Wswitch]
> >   switch (Ty->getTypeID()) {
> >   ^
> > 1 error generated.
> > ```
> > Seen in build bots, e.g. here:
> > http://lab.llvm.org:8011/#/builders/57/builds/2889/steps/6/logs/stdio
> Thanks Mikael for pointing it out. I think we just need to put the type in 
> the switch table. I've posted a patch to fix it. rG16c2067cf212.
Yep, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91927/new/

https://reviews.llvm.org/D91927

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103314: [Analyzer][solver] Simplify existing constraints when a new constraint is added

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I'm seeing a failed assertion with this patch.
Reproduce with

  clang --analyze bbi-57338.c

Result:

  clang: /repo/uabelho/master-github/llvm/include/llvm/ADT/APSInt.h:148: bool 
llvm::APSInt::operator<(const llvm::APSInt &) const: Assertion `IsUnsigned == 
RHS.IsUnsigned && "Signedness mismatch!"' failed.

F17516582: bbi-57338.c 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103314/new/

https://reviews.llvm.org/D103314

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103314: [Analyzer][solver] Simplify existing constraints when a new constraint is added

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

Another failed assertion that started appearing with this patch:

  clang --analyze bbi-57589.c

which results in:

  clang: ../lib/Support/APInt.cpp:284: int llvm::APInt::compareSigned(const 
llvm::APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Bit widths must 
be same for comparison"' failed.

F17570813: bbi-57589.c 
Maybe it's the same root problem, but please make sure you fix both.
Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103314/new/

https://reviews.llvm.org/D103314

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94376: [MemCpyOpt] Enable MemorySSA by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

I ran into a crash in memcpyopt with this patch.
Running

  opt -S -o - bbi-53212.ll -memcpyopt

yields

  opt: ../include/llvm/Support/Casting.h:104: static bool 
llvm::isa_impl_cl::doit(const 
From *) [To = llvm::MemoryUse, From = const llvm::MemoryUseOrDef *]: Assertion 
`Val && "isa<> used on a null pointer"' failed.
  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace.
  Stack dump:
  0.Program arguments: /data/repo/master/llvm/build-all/bin/opt -S -o - 
bbi-53212.ll -memcpyopt
   #0 0x029461e3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/data/repo/master/llvm/build-all/bin/opt+0x29461e3)
   #1 0x02943e9e llvm::sys::RunSignalHandlers() 
(/data/repo/master/llvm/build-all/bin/opt+0x2943e9e)
   #2 0x029466a6 SignalHandler(int) Signals.cpp:0:0
   #3 0x7ff087446980 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
   #4 0x7ff084517fb7 raise 
/build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
   #5 0x7ff084519921 abort 
/build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
   #6 0x7ff08450948a __assert_fail_base 
/build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0
   #7 0x7ff084509502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
   #8 0x019f8722 llvm::MemoryUseOrDef::getDefiningAccess() const 
(/data/repo/master/llvm/build-all/bin/opt+0x19f8722)
   #9 0x02766c6d 
llvm::MemCpyOptPass::processByValArgument(llvm::CallBase&, unsigned int) 
(/data/repo/master/llvm/build-all/bin/opt+0x2766c6d)
  #10 0x02767810 
llvm::MemCpyOptPass::iterateOnFunction(llvm::Function&) 
(/data/repo/master/llvm/build-all/bin/opt+0x2767810)
  #11 0x02768280 llvm::MemCpyOptPass::runImpl(llvm::Function&, 
llvm::MemoryDependenceResults*, llvm::TargetLibraryInfo*, llvm::AAResults*, 
llvm::AssumptionCache*, llvm::DominatorTree*, llvm::MemorySSA*) 
(/data/repo/master/llvm/build-all/bin/opt+0x2768280)
  #12 0x02767c69 llvm::MemCpyOptPass::run(llvm::Function&, 
llvm::AnalysisManager&) 
(/data/repo/master/llvm/build-all/bin/opt+0x2767c69)
  #13 0x02bf031d llvm::detail::PassModel >::run(llvm::Function&, 
llvm::AnalysisManager&) 
(/data/repo/master/llvm/build-all/bin/opt+0x2bf031d)
  #14 0x021720c9 llvm::PassManager >::run(llvm::Function&, 
llvm::AnalysisManager&) 
(/data/repo/master/llvm/build-all/bin/opt+0x21720c9)
  #15 0x00a7cbfd llvm::detail::PassModel >, 
llvm::PreservedAnalyses, llvm::AnalysisManager 
>::run(llvm::Function&, llvm::AnalysisManager&) 
(/data/repo/master/llvm/build-all/bin/opt+0xa7cbfd)
  #16 0x021768b6 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, 
llvm::AnalysisManager&) 
(/data/repo/master/llvm/build-all/bin/opt+0x21768b6)
  #17 0x0076c61d llvm::detail::PassModel >::run(llvm::Module&, 
llvm::AnalysisManager&) 
(/data/repo/master/llvm/build-all/bin/opt+0x76c61d)
  #18 0x02170f2b llvm::PassManager >::run(llvm::Module&, 
llvm::AnalysisManager&) 
(/data/repo/master/llvm/build-all/bin/opt+0x2170f2b)
  #19 0x00764fe1 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, 
llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, 
llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, 
llvm::ArrayRef, llvm::opt_tool::OutputKind, 
llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool) 
(/data/repo/master/llvm/build-all/bin/opt+0x764fe1)
  #20 0x00776b32 main 
(/data/repo/master/llvm/build-all/bin/opt+0x776b32)
  #21 0x7ff0844fabf7 __libc_start_main 
/build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:344:0
  #22 0x0075e76a _start 
(/data/repo/master/llvm/build-all/bin/opt+0x75e76a)

F15612676: bbi-53212.ll 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94376/new/

https://reviews.llvm.org/D94376

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94376: [MemCpyOpt] Enable MemorySSA by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D94376#2579242 , @nikic wrote:

> @uabelho Thanks for the report! This issue should be resolved by 
> https://github.com/llvm/llvm-project/commit/4125afc35723b490556f7a38f7835f0914f70292.

Yep, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94376/new/

https://reviews.llvm.org/D94376

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

I wrote
 https://bugs.llvm.org/show_bug.cgi?id=49859
about a miscompile that started occuring when turning on memoryssa again in DSE.
I suspect that licm doesn't keep memoryssa updated properly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87163/new/

https://reviews.llvm.org/D87163

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105692: [analyzer][solver][NFC] Introduce ConstraintAssignor

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

When compiling with gcc I see the following new warnings with this patch:

  [4/22] Building CXX object 
tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/obj.clangStaticAnalyzerCore.dir/RangeConstraintManager.cpp.o
  
/repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2395:17:
 warning: 'clang::ento::ProgramStateRef 
{anonymous}::RangeConstraintManager::setRange(clang::ento::ProgramStateRef, 
{anonymous}::EquivalenceClass, clang::ento::RangeSet)' defined but not used 
[-Wunused-function]
   2395 | ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef 
State,
| ^~
  
/repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2384:10:
 warning: 'clang::ento::RangeSet 
{anonymous}::RangeConstraintManager::getRange(clang::ento::ProgramStateRef, 
{anonymous}::EquivalenceClass)' defined but not used [-Wunused-function]
   2384 | RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
|  ^~

Will those methods be used or can they be removed?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105692/new/

https://reviews.llvm.org/D105692

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105692: [analyzer][solver][NFC] Introduce ConstraintAssignor

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D105692#2879983 , @martong wrote:

> In D105692#2879186 , @uabelho wrote:
>
>> Hi,
>>
>> When compiling with gcc I see the following new warnings with this patch:
>>
>>   [4/22] Building CXX object 
>> tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/obj.clangStaticAnalyzerCore.dir/RangeConstraintManager.cpp.o
>>   
>> /repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2395:17:
>>  warning: 'clang::ento::ProgramStateRef 
>> {anonymous}::RangeConstraintManager::setRange(clang::ento::ProgramStateRef, 
>> {anonymous}::EquivalenceClass, clang::ento::RangeSet)' defined but not used 
>> [-Wunused-function]
>>2395 | ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef 
>> State,
>> | ^~
>>   
>> /repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2384:10:
>>  warning: 'clang::ento::RangeSet 
>> {anonymous}::RangeConstraintManager::getRange(clang::ento::ProgramStateRef, 
>> {anonymous}::EquivalenceClass)' defined but not used [-Wunused-function]
>>2384 | RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
>> |  ^~
>>
>> Will those methods be used or can they be removed?
>
> I think they can be removed, waiting for Valeriy's approval.
> https://reviews.llvm.org/D106063

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105692/new/

https://reviews.llvm.org/D105692

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79714: [Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment operator is defined as deleted (PR45634)

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

With this commit I get failures in the following testcases when building 
check-runtimes on trunk:

  Failed Tests (29):
libc++ :: libcxx/debug/containers/db_sequence_container_iterators.pass.cpp
libc++ :: libcxx/gdb/gdb_pretty_printer_test.sh.cpp
libc++ :: std/containers/sequences/vector.bool/assign_copy.pass.cpp
libc++ :: std/containers/sequences/vector.bool/assign_move.pass.cpp
libc++ :: std/containers/sequences/vector.bool/copy.pass.cpp
libc++ :: std/containers/sequences/vector.bool/copy_alloc.pass.cpp
libc++ :: std/containers/sequences/vector.bool/emplace.pass.cpp
libc++ :: std/containers/sequences/vector.bool/erase_iter.pass.cpp
libc++ :: std/containers/sequences/vector.bool/erase_iter_iter.pass.cpp
libc++ :: 
std/containers/sequences/vector.bool/insert_iter_initializer_list.pass.cpp
libc++ :: 
std/containers/sequences/vector.bool/insert_iter_iter_iter.pass.cpp
libc++ :: 
std/containers/sequences/vector.bool/insert_iter_size_value.pass.cpp
libc++ :: std/containers/sequences/vector.bool/insert_iter_value.pass.cpp
libc++ :: std/containers/sequences/vector.bool/iterators.pass.cpp
libc++ :: std/containers/sequences/vector.bool/move.pass.cpp
libc++ :: std/containers/sequences/vector.bool/move_alloc.pass.cpp
libc++ :: std/containers/sequences/vector.bool/resize_size.pass.cpp
libc++ :: std/containers/sequences/vector.bool/resize_size_value.pass.cpp
libc++ :: std/containers/sequences/vector.bool/shrink_to_fit.pass.cpp
libc++ :: std/containers/sequences/vector.bool/size.pass.cpp
libc++ :: std/containers/sequences/vector/vector.cons/deduct.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/left_shift.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/op_eq_eq.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/right_shift.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/to_ullong.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.members/to_ulong.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.operators/op_and.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.operators/op_not.pass.cpp
libc++ :: std/utilities/template.bitset/bitset.operators/op_or.pass.cpp

They all get -Wdeprecated-copy warnigns and then with -Werror they fail.
Is this something you've seen or considered?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79714/new/

https://reviews.llvm.org/D79714

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79714: [Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment operator is defined as deleted (PR45634)

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D79714#2711898 , @xbolva00 wrote:

> Can you try this fix?
>
>   diff --git a/libcxx/utils/libcxx/test/params.py 
> b/libcxx/utils/libcxx/test/params.py
>   index ddf277dea246..abf712e78a61 100644
>   --- a/libcxx/utils/libcxx/test/params.py
>   +++ b/libcxx/utils/libcxx/test/params.py
>   @@ -12,6 +12,7 @@ from libcxx.test.features import _isMSVC
>_warningFlags = [
>  '-Werror',
>  '-Wall',
>   +  '-Wno-deprecated-copy',
>  '-Wextra',
>  '-Wshadow',
>  '-Wundef',

The above doesn't help but if I add it in the list after -Wextra the warning 
goes away. Can you submit something like that?
Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79714/new/

https://reviews.llvm.org/D79714

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79714: [Diagnostics] Restore -Wdeprecated warning when user-declared copy assignment operator is defined as deleted (PR45634)

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D79714#2713610 , @xbolva00 wrote:

> I pushed a fix to just disable this warning for googlemock/gtest.

Unfortunately that fix breaks compiling llvm with clang8. I commented in
 https://reviews.llvm.org/rG9658d045926545e62cc3f963fe611d7c5d0c9d98


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79714/new/

https://reviews.llvm.org/D79714

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

I noticed that with this patch
 libcxx/test/std/strings/basic.string/string.cons/iter_alloc_deduction.fail.cpp
fails:

  error: 'warning' diagnostics seen but not expected: 
File 
/repo/uabelho/master-github/libcxx/test/std/strings/basic.string/string.cons/iter_alloc_deduction.fail.cpp
 Line 51: variable 's' set but not used
  1 error generated.

(I don't know anything about the testcase I just noticed it failed when trying 
to uplift my downstream repo.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100581/new/

https://reviews.llvm.org/D100581

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98278: [test] Add ability to get error messages from CMake for errc substitution

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I'm seeing a problem with this. Compiling with gcc 9.3.0 the compilation of the 
test program works, but then when I run it I get

  
/repo/uabelho/master-github/llvm/build-all-bbigcc/CMakeFiles/CMakeTmp/cmTC_00188:
 /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by 
/repo/uabelho/master-github/llvm/build-all-bbigcc/CMakeFiles/CMakeTmp/cmTC_00188)

and this causes everything to fail with

  llvm-lit: 
/repo/uabelho/master-github/llvm/utils/lit/lit/TestingConfig.py:100: fatal: 
unable to parse config file 
'/repo/uabelho/master-github/llvm/build-all-bbigcc/tools/clang/test/lit.site.cfg.py',
 traceback: Traceback (most recent call last):
File 
"/repo/uabelho/master-github/llvm/build-all-bbigcc/bin/../../utils/lit/lit/TestingConfig.py",
 line 89, in load_from_path
  exec(compile(data, path, 'exec'), cfg_globals, None)
File 
"/repo/uabelho/master-github/llvm/build-all-bbigcc/tools/clang/test/lit.site.cfg.py",
 line 19
  config.errc_messages = 
"/repo/uabelho/master-github/llvm/build-all-bbigcc/CMakeFiles/CMakeTmp/cmTC_00188:
 /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by 
/repo/uabelho/master-github/llvm/build-all-bbigcc/CMakeFiles/CMakeTmp/cmTC_00188)

so perhaps there should be some additional error handling when running the 
compiled program doesn't work?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98278/new/

https://reviews.llvm.org/D98278

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98278: [test] Add ability to get error messages from CMake for errc substitution

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D98278#2628482 , @zero9178 wrote:

> In D98278#2628477 , @uabelho wrote:
>
>> so perhaps there should be some additional error handling when running the 
>> compiled program doesn't work?
>
> Could you try changing line 32 of llvm/cmake/modules/GetErrcMessages.cmake 
> from `if (errc_compiled)` to `if (errc_compiled AND "${errc_exit_code}" 
> STREQUAL "0")` and report back if it changes anything? I think that should 
> fix your issue, although it'll fall back to using python's strerror messages. 
> Indeed an oversight of mine.

Yes that helps, please submit. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98278/new/

https://reviews.llvm.org/D98278

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D119479: [clang][extract-api] Add global record support

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hello,

Did you see this sanitizer error when running global_record.c?

https://lab.llvm.org/buildbot/#/builders/5/builds/20765/steps/13/logs/stdio


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119479/new/

https://reviews.llvm.org/D119479

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121678: [pseudo] Split greatergreater token.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hello,

It seems like the new testcase fails when run with sanitizers:
https://lab.llvm.org/buildbot/#/builders/5/builds/20833


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121678/new/

https://reviews.llvm.org/D121678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D119479: [clang][extract-api] Add global record support

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D119479#3389684 , @zixuw wrote:

> In D119479#3388498 , @uabelho wrote:
>
>> Hello,
>>
>> Did you see this sanitizer error when running global_record.c?
>>
>> https://lab.llvm.org/buildbot/#/builders/5/builds/20765/steps/13/logs/stdio
>
> Hi @uabelho, I've disabled the test for now in 
> 54b145d5cac2b008380828e8f67c439038ea370b 
> .

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119479/new/

https://reviews.llvm.org/D119479

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D119655: [Driver][NetBSD] -r: imply -nostdlib like GCC

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.
Herald added a project: All.



Comment at: clang/test/Driver/netbsd.c:477
+// RELOCATABLE-NOT: "-l
+// RELOCATABLE-NOT: crt{{[^.]+}}.o

Hi,

I see this CHECK-NOT fail every now and then due to bad luck:

13:48:46 
/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-gcc/clang/test/Driver/netbsd.c:477:21:
 error: RELOCATABLE-NOT: excluded string found in input
13:48:46 // RELOCATABLE-NOT: crt{{[^.]+}}.o
13:48:46 ^
13:48:46 :6:286: note: found here
13:48:46  
"/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler/bin/ld" 
"--sysroot=/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/llvm-main-gcc/clang/test/Driver/Inputs/basic_netbsd_tree"
 "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld.elf_so" "-o" "a.out" "-r" "-r" 
"/tmp/lit-tmp-crtcq7cs/netbsd-94b421.o"
13:48:46


  ^~~~

Same thing with

13:59:16 Failed Tests (5):
13:59:16   Clang :: Driver/freebsd.c
13:59:16   Clang :: Driver/fuchsia.c
13:59:16   Clang :: Driver/linux-cross.cpp
13:59:16   Clang :: Driver/netbsd.c
13:59:16   Clang :: Driver/openbsd.c

Perhaps the CHECK-NOT can be made stricter to avoid these matches due to bad 
luck?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119655/new/

https://reviews.llvm.org/D119655

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129242: [clang-repl] Add host exception support check utility flag.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hello,

The new testcase added in this patch fails for me all the time.
I'm compiling on a linux RHEL 7 machine.
When I run the clang-repl command in the test I get

  JIT session error: Symbols not found: [ _ZTIPKc ]
  error: Failed to materialize symbols: { (main, { _Z14checkExceptionv, 
$.incr_module_9.__inits.0, __orc_init_func.incr_module_9, r1 }) }
  error: Failed to materialize symbols: { (main, { 
__orc_init_func.incr_module_9 }) }
  clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> 
clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> clang-repl> 
clang-repl> clang-repl>

Any idea?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129242/new/

https://reviews.llvm.org/D129242

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129242: [clang-repl] Add host exception support check utility flag.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D129242#3686610 , @sunho wrote:

> @uabelho Hi, that's a typeinfo symbol of libc++ abi. It's quite weird that 
> __cxa_throw is availble while _ZTIPKc is not. Do you have some special 
> setting regarding libc++ in your environment?

We compile with clang 8 on a RHEL7 machine, but since we then got too old libs 
we do

  
--gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler

since we have newer libs there. This is seen in the cmake command:

  cmake command: CC='/proj/flexasic/app/llvm/8.0/bin/clang -march=corei7 
--gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler'
 CXX='/proj/flexasic/app/llvm/8.0/bin/clang++ -march=corei7 
--gcc-toolchain=/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.9.3.0/crosscompiler'
 LDFLAGS='-Wl,-R/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1/lib64' 
PATH=/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin:$PATH  
/app/vbuild/RHEL7-x86_64/cmake/3.16.4/bin/cmake /repo/uabelho/main-github/llvm 
--debug-trycompile -G Ninja 
-DCMAKE_MAKE_PROGRAM=/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin/ninja 
-DCMAKE_BUILD_TYPE=Release 
-DCMAKE_C_FLAGS='-Wno-error=unused-command-line-argument' 
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_INSTALL_PREFIX=/compiler-clang 
-DLLVM_APPEND_VC_REV=OFF -DLLVM_CCACHE_DIR=/repo/uabelho/.ccache/ 
-DLLVM_CCACHE_BUILD=ON 
-DLLVM_CCACHE_PROGRAM=/app/vbuild/RHEL7-x86_64/ccache/3.2.2/bin/ccache 
-DLLVM_CCACHE_NOHASHDIR=ON -DLLVM_CCACHE_BASEDIR=/repo 
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_WERROR=ON 
-DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld' -DLLVM_ENABLE_Z3_SOLVER=ON 
-DLLVM_Z3_INSTALL_DIR=/proj/bbi_twh/wh_bbi/x86_64-Linux3/z3/4.8.8-1 
-DLLVM_ENABLE_LIBPFM=OFF -DLLVM_ENABLE_LIBXML2=OFF -DLLVM_ENABLE_TERMINFO=OFF 
-DLLVM_ENABLE_LIBEDIT=OFF -DLLVM_STATIC_LINK_CXX_STDLIB=ON 
-DCLANG_ENABLE_ARCMT=OFF -DCLANG_TOOLING_BUILD_AST_INTROSPECTION=OFF

Could it be something like that there is a mismatch somewhere so the support 
checks will use some libs but then the actual libs used when compiling/running 
is something else?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129242/new/

https://reviews.llvm.org/D129242

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128158: [AMDGPU] Add amdgcn_sched_group_barrier builtin

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: llvm/lib/Target/AMDGPU/AMDGPUIGroupLP.cpp:314
+
+bool SchedGroup::isFull() const {
+  return MaxSize && Collection.size() >= *MaxSize;

Compiling with gcc, I get a warning that this function is unused.
I'm wondering, there seems to be both a const and a non-const version of the 
isFull method now, but they are identical? Perhaps the non-const version could 
be removed?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128158/new/

https://reviews.llvm.org/D128158

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128569: Start support for HLSL `RWBuffer`

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hello,

Compiling with gcc I get the following warning with this patch:

  [1832/2330] Building CXX object 
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/HLSLExternalSemaSource.cpp.o
  In file included from ../../clang/include/clang/Sema/ExternalSemaSource.h:15,
   from 
../../clang/include/clang/Sema/HLSLExternalSemaSource.h:17,
   from ../../clang/lib/Sema/HLSLExternalSemaSource.cpp:12:
  ../../clang/include/clang/AST/ExternalASTSource.h:211:16: warning: 'virtual 
void clang::ExternalASTSource::CompleteType(clang::ObjCInterfaceDecl*)' was 
hidden [-Woverloaded-virtual]
211 |   virtual void CompleteType(ObjCInterfaceDecl *Class);
|^~~~
  In file included from ../../clang/lib/Sema/HLSLExternalSemaSource.cpp:12:
  ../../clang/include/clang/Sema/HLSLExternalSemaSource.h:49:8: warning:   by 
'virtual void clang::HLSLExternalSemaSource::CompleteType(clang::TagDecl*)' 
[-Woverloaded-virtual]
 49 |   void CompleteType(TagDecl *Tag) override;
|^~~~




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128569/new/

https://reviews.llvm.org/D128569

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129242: [clang-repl] Add host exception support check utility flag.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D129242#3687968 , @sunho wrote:

> https://reviews.llvm.org/D130788 this is the patch fyi.

Great, the patch works for us. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129242/new/

https://reviews.llvm.org/D129242

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I noticed this produces broken code:
clang -cc1 -triple amdgcn-- -emit-llvm -o - -x c op.c

with op.c being

  void bar();
  
  void foo() {
bar();
  }

The result is

  define dso_local void @foo() #0 {
  entry:
call void @bar(i32 noundef 42)
ret void
  }
  
  declare void @bar(...) #1

and feeding it to e.g. opt we get

  build-all-builtins/bin/opt: :9:13: error: invalid forward reference to 
function 'bar' with wrong type: expected 'void (...)*' but was 'void ()*'
call void @bar()
  ^

Probably the same for several targets.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123300/new/

https://reviews.llvm.org/D123300

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D123300#3451087 , @nikic wrote:

> @uabelho The IR is correct, but requires using `opt -opaque-pointers` 
> explicitly. Normally, opaque pointer mode is automatically enabled, but there 
> is no explicit mention of `ptr` in the IR. Not sure if we can do anything to 
> improve that before the default on the opt side is switched.

Oh, didn't realize this. Yes we'll need to start passing -opaque-pointers to 
opt (and llc I suppose) explicitly then.
Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123300/new/

https://reviews.llvm.org/D123300

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124658: [analyzer] Canonicalize SymIntExpr so the RHS is positive when possible

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D124658#3495973 , @steakhal wrote:

> This patch triggers a crash with this minimized example.
> assertion at L205: `"The result operation type must have at least the same 
> number of bits as its operands."`
> [...]
> Please investigate this @tomasz-kaminski-sonarsource

Hi,

I've stumbled on this crash as well with this patch.
So

  clang --analyze foo.c

crashes with

  clang: ../../clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:207: 
clang::ento::SVal (anonymous namespace)::SimpleSValBuilder::MakeSymIntVal(const 
clang::ento::SymExpr *, BinaryOperator::Opcode, const llvm::APSInt &, 
clang::QualType): Assertion `resultIntTy.getBitWidth() >= RHS.getBitWidth() && 
"The result operation type must have at least the same " "number of bits as its 
operands."' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: /repo/uabelho/master-github/llvm/build-all/bin/clang 
--analyze foo.c
  1. parser at end of file
  2.While analyzing stack: 
#0 Calling h
  3.foo.c:9:9: Error evaluating statement
  4.foo.c:9:9: Error evaluating statement
   #0 0x02e4fbf3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x2e4fbf3)
   #1 0x02e4d86e llvm::sys::RunSignalHandlers() 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x2e4d86e)
   #2 0x02e4ef92 llvm::sys::CleanupOnSignal(unsigned long) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x2e4ef92)
   #3 0x02db4e03 (anonymous 
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) 
CrashRecoveryContext.cpp:0:0
   #4 0x02db4fbd CrashRecoverySignalHandler(int) 
CrashRecoveryContext.cpp:0:0
   #5 0x7fd21e2ce630 __restore_rt sigaction.c:0:0
   #6 0x7fd21ba15387 raise (/lib64/libc.so.6+0x36387)
   #7 0x7fd21ba16a78 abort (/lib64/libc.so.6+0x37a78)
   #8 0x7fd21ba0e1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6)
   #9 0x7fd21ba0e252 (/lib64/libc.so.6+0x2f252)
  #10 0x0467e0bb (anonymous 
namespace)::SimpleSValBuilder::MakeSymIntVal(clang::ento::SymExpr const*, 
clang::BinaryOperatorKind, llvm::APSInt const&, clang::QualType) 
SimpleSValBuilder.cpp:0:0
  #11 0x0467a94f (anonymous 
namespace)::SimpleSValBuilder::evalBinOpNN(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::NonLoc, clang::ento::NonLoc, 
clang::QualType) SimpleSValBuilder.cpp:0:0
  #12 0x04688f46 
clang::ento::SValBuilder::evalBinOp(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::SVal, clang::ento::SVal, 
clang::QualType) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x4688f46)
  #13 0x0467f28e clang::ento::SymExprVisitor<(anonymous 
namespace)::SimpleSValBuilder::simplifySValOnce(llvm::IntrusiveRefCntPtr, clang::ento::SVal)::Simplifier, 
clang::ento::SVal>::Visit(clang::ento::SymExpr const*) SimpleSValBuilder.cpp:0:0
  #14 0x0467eccc (anonymous 
namespace)::SimpleSValBuilder::simplifySValOnce(llvm::IntrusiveRefCntPtr, clang::ento::SVal) SimpleSValBuilder.cpp:0:0
  #15 0x0467d814 (anonymous 
namespace)::SimpleSValBuilder::simplifySVal(llvm::IntrusiveRefCntPtr, clang::ento::SVal) SimpleSValBuilder.cpp:0:0
  #16 0x04679ec3 (anonymous 
namespace)::SimpleSValBuilder::evalBinOpNN(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::NonLoc, clang::ento::NonLoc, 
clang::QualType) SimpleSValBuilder.cpp:0:0
  #17 0x04688f46 
clang::ento::SValBuilder::evalBinOp(llvm::IntrusiveRefCntPtr, clang::BinaryOperatorKind, clang::ento::SVal, clang::ento::SVal, 
clang::QualType) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x4688f46)
  #18 0x045f509c 
clang::ento::ExprEngine::VisitBinaryOperator(clang::BinaryOperator const*, 
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x45f509c)
  #19 0x045e201a clang::ento::ExprEngine::Visit(clang::Stmt const*, 
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x45e201a)
  #20 0x045dd27e clang::ento::ExprEngine::ProcessStmt(clang::Stmt 
const*, clang::ento::ExplodedNode*) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x45dd27e)
  #21 0x045dcf99 
clang::ento::ExprEngine::processCFGElement(clang::CFGElement, 
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x45dcf99)
  #22 0x045c5300 
clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int, 
clang::ento::ExplodedNode*) 
(/repo/uabelho/master-github/llvm/build-all/bin/clang+0x45c5300)
  #23 0x045c437a 
clang::ento::CoreEngine::ExecuteWorkList(clang::

[PATCH] D124658: [analyzer] Canonicalize SymIntExpr so the RHS is positive when possible

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Not sure if I'm doing something wrong but I can't apply this patch on current 
top of tree (a4190037fac0 
)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124658/new/

https://reviews.llvm.org/D124658

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124658: [analyzer] Canonicalize SymIntExpr so the RHS is positive when possible

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D124658#3500467 , @steakhal wrote:

> 

[...]

> Could you please give this another shoot at this @uabelho?

Yes, the case that crashed for me works with the updated patch. Haven't done 
other testing.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124658/new/

https://reviews.llvm.org/D124658

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124341: [clang-tidy][NFC] Replace many instances of std::string where a StringRef would suffice.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I noticed that this patch isn't NFC.

If I run

  clang-tidy -checks='*' empty.c --

on an empty file empty.c I get the following printouts with this patch:

  'addr=address'
  'arr=array'
  'attr=attribute'
  'buf=buffer'
  'cl=client'
  'cnt=count'
  'col=column'
  'cpy=copy'
  'dest=destination'
  'dist=distancedst=distance'
  'elem=element'
  'hght=height'
  'i=index'
  'idx=index'
  'len=length'
  'ln=line'
  'lst=list'
  'nr=number'
  'num=number'
  'pos=position'
  'ptr=pointer'
  'ref=reference'
  'src=source'
  'srv=server'
  'stmt=statement'
  'str=string'
  'val=value'
  'var=variable'
  'vec=vector'
  'wdth=width'

but without this patch it's completely silent.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124341/new/

https://reviews.llvm.org/D124341

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122271: [Clang] -Wunused-but-set-variable warning - handle also pre/post unary operators

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I noticed these to warning when compiling libunwind/src/UnwindLevel1.c with 
this patch:

  00:22:48 
/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:175:12:
 warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
  00:22:48   unsigned framesWalked = 1;
  00:22:48^
  00:22:48 
/repo/bbiswjenk/fem2s10-eiffel176/workspace/llvm/sdk_1_20_ki_dev_test/libunwind/src/UnwindLevel1.c:293:12:
 warning: variable 'framesWalked' set but not used [-Wunused-but-set-variable]
  00:22:48   unsigned framesWalked = 1;
  00:22:48^
  00:22:48 2 warnings generated.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122271/new/

https://reviews.llvm.org/D122271

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hello,

No idea what is happening yet but I've seen some pretty nasty memory 
consumption by opt that I bisected to this patch.

Any idea what could be going on?

I'll see if I can see if I can extract some reproducer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122471/new/

https://reviews.llvm.org/D122471

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D122471#3416528 , @uabelho wrote:

> Hello,
>
> No idea what is happening yet but I've seen some pretty nasty memory 
> consumption by opt that I bisected to this patch.
>
> Any idea what could be going on?
>
> I'll see if I can see if I can extract some reproducer.

It seems like it's the actual reading of the input file that hangs and just 
eats more and more memory. So

  opt foo.bc -o foo.opt.bc

hangs, and this happens when the input contains a call to an intrinsic we've 
added downstream that returns a named struct type-
Do we need to update our intrinsic definitions?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122471/new/

https://reviews.llvm.org/D122471

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D122471#3416797 , @nikic wrote:

> @uabelho Can you please check whether 
> https://github.com/llvm/llvm-project/commit/d6887256c2cae1b1b721bd47459be6d86003db6f
>  fixes the problem you're seeing?

Hi @nikic

Yes, that patch solves the problem. Great, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122471/new/

https://reviews.llvm.org/D122471

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124341: [clang-tidy][NFC] Replace many instances of std::string where a StringRef would suffice.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D124341#3504427 , @njames93 wrote:

> In D124341#3502659 , @uabelho wrote:
>
>> Hi,
>>
>> I noticed that this patch isn't NFC.
>
> Whoops, good catch. I left in some debugging code, fixed in 
> rGa308a55720249749 
> 

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124341/new/

https://reviews.llvm.org/D124341

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122734: [CUDA][HIP] Fix mangling number for local struct

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I noticed when compiling with gcc 9.3.0 that we get a bunch of new warnings 
with this patch:

  [1/351] Building CXX object 
tools/clang/lib/AST/CMakeFiles/obj.clangAST.dir/MicrosoftCXXABI.cpp.o
  ../../clang/lib/AST/MicrosoftCXXABI.cpp:57:12: warning: 'virtual unsigned int 
{anonymous}::MicrosoftNumberingContext::getManglingNumber(const 
clang::VarDecl*, unsigned int)' was hidden [-Woverloaded-virtual]
 57 |   unsigned getManglingNumber(const VarDecl *VD,
|^
  ../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual 
unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const 
clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
 80 |   unsigned getManglingNumber(const TagDecl *TD,
|^
  ../../clang/lib/AST/MicrosoftCXXABI.cpp:46:12: warning: 'virtual unsigned int 
{anonymous}::MicrosoftNumberingContext::getManglingNumber(const 
clang::BlockDecl*)' was hidden [-Woverloaded-virtual]
 46 |   unsigned getManglingNumber(const BlockDecl *BD) override {
|^
  ../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual 
unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const 
clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
 80 |   unsigned getManglingNumber(const TagDecl *TD,
|^
  ../../clang/lib/AST/MicrosoftCXXABI.cpp:42:12: warning: 'virtual unsigned int 
{anonymous}::MicrosoftNumberingContext::getManglingNumber(const 
clang::CXXMethodDecl*)' was hidden [-Woverloaded-virtual]
 42 |   unsigned getManglingNumber(const CXXMethodDecl *CallOperator) 
override {
|^
  ../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual 
unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const 
clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
 80 |   unsigned getManglingNumber(const TagDecl *TD,
|^

No idea if it's important or if gcc is overly picky.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122734/new/

https://reviews.llvm.org/D122734

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122734: [CUDA][HIP] Fix mangling number for local struct

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D122734#3509187 , @yaxunl wrote:

> In D122734#3509096 , @yaxunl wrote:
>
>> In D122734#3508294 , @uabelho 
>> wrote:
>>
>>> Hi,
>>>
>>> I noticed when compiling with gcc 9.3.0 that we get a bunch of new warnings 
>>> with this patch:
>>>
>>>   [1/351] Building CXX object 
>>> tools/clang/lib/AST/CMakeFiles/obj.clangAST.dir/MicrosoftCXXABI.cpp.o
>>>   ../../clang/lib/AST/MicrosoftCXXABI.cpp:57:12: warning: 'virtual unsigned 
>>> int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const 
>>> clang::VarDecl*, unsigned int)' was hidden [-Woverloaded-virtual]
>>>  57 |   unsigned getManglingNumber(const VarDecl *VD,
>>> |^
>>>   ../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual 
>>> unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const 
>>> clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
>>>  80 |   unsigned getManglingNumber(const TagDecl *TD,
>>> |^
>
> fixed by 0f292141aadb0489231de31de966c239486e019d 
> 

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122734/new/

https://reviews.llvm.org/D122734

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114887: [Analyzer][solver] Simplification: Do a fixpoint iteration before the eq class merge

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.
Herald added a project: All.

Hello,

I wrote an issue about a crash with this patch:
 https://github.com/llvm/llvm-project/issues/55546


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114887/new/

https://reviews.llvm.org/D114887

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123674: Clang-Repl Error Recovery Bug Fix

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I noticed that the testcase Interpreter/execute.cpp starts failing with this 
patch when run/compiled with asan:

  Failed Tests (1):
Clang :: Interpreter/execute.cpp

Seen in the buildbot run
 https://lab.llvm.org/buildbot/#/builders/5/builds/24221

The run on the commit before passed:
 https://lab.llvm.org/buildbot/#/builders/5/builds/24220


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123674/new/

https://reviews.llvm.org/D123674

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126198: [analyzer][NFCi] Annotate major nonnull returning functions

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I see crashes like this with this patch:

  clang: 
../../clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:94:
 clang::ento::PointerToMemberData::PointerToMemberData(const clang::NamedDecl 
*, llvm::ImmutableList): Assertion `D' failed.

Anyhting known or familiar?

Unfortunately I don't have any reproducer to share (yet).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126198/new/

https://reviews.llvm.org/D126198

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126198: [analyzer][NFCi] Annotate major nonnull returning functions

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D126198#3549790 , @uabelho wrote:

> Hi,
>
> I see crashes like this with this patch:
>
>   clang: 
> ../../clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:94:
>  clang::ento::PointerToMemberData::PointerToMemberData(const clang::NamedDecl 
> *, llvm::ImmutableList): Assertion `D' failed.
>
> Anyhting known or familiar?
>
> Unfortunately I don't have any reproducer to share (yet).

Reproducer:

  clang -cc1 -analyze -analyzer-checker=core bbi-70461.C

on bbi-70461.C being

  class B{
  };
  
  class D: public B{
  };
  
  int f(int D::* pd);
  
  int test(void)
  {
int B::* pb = 0;
  
return f(pb);
  }


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126198/new/

https://reviews.llvm.org/D126198

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126198: [analyzer][NFCi] Annotate major nonnull returning functions

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

@steakhal : Thanks for the quick fix!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126198/new/

https://reviews.llvm.org/D126198

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126689: [IR] Enable opaque pointers by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Is anyone here ever using llvm-stress?
I noticed that with this patch, llvm-stress seems to start producing code that 
llc crashes on, and it crashes even if I run on older llc versions.
One example:

  llc -o /dev/null stress.ll

crashes with

  llc: ../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5974: llvm::SDValue 
llvm::SelectionDAG::getNode(unsigned int, const llvm::SDLoc &, llvm::EVT, 
llvm::SDValue, llvm::SDValue, const llvm::SDNodeFlags): Assertion 
`VT.isInteger() && N2.getValueType().isInteger() && "Shifts only work on 
integers"' failed.

Or is the X86 backend just not up to date with opaque pointers yet?
F23291141: stress.ll 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126689/new/

https://reviews.llvm.org/D126689

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126689: [IR] Enable opaque pointers by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D126689#3553292 , @nikic wrote:

> @uabelho Here's a slightly cleaned up test case that does not use opaque 
> pointers:
>
>   target triple = "x86_64-unknown-linux-gnu"
>   
>   define void @test(i1 %cond, <1 x i16>* %p) {
> br label %loop
>   
>   loop:
> %v = load <1 x i16>, <1 x i16>* %p, align 2
> %ins = insertelement <4 x double> zeroinitializer, double 0.00e+00, 
> i32 0
> %cmp = fcmp uge <4 x double> %ins, zeroinitializer
> %ashr = ashr <1 x i16> %v, %v
> %shuf = shufflevector <4 x i1> %cmp, <4 x i1> zeroinitializer, <4 x i32> 
> zeroinitializer
> br i1 %cond, label %loop, label %exit
>   
>   exit:
> %use1 = add <4 x i1> %shuf, zeroinitializer
> %use2 = add <1 x i16> %ashr, zeroinitializer
> ret void
>   }
>
> llvm-stress can probably generate certain code patterns when opaque pointers 
> are enabled, which it does not produce when typed pointers are used. In this 
> case at least, the used pointer type doesn't matter in the end.

Yes llvm-stress must generate something unusual with opaque pointers because 
normally I very rarely see that it finds something, and after the switch done 
here I get several different crashes. The one I posted above was just one 
example.
Next crash here: https://github.com/llvm/llvm-project/issues/55846


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126689/new/

https://reviews.llvm.org/D126689

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126536: [pseudo] Add grammar annotations support.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp:235
 
   Out.Sequence.push_back({Chunk});
 }

I get a warning/error on this line with this commit:
```
13:31:17 ../../clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp:235:36: 
error: missing field 'Attributes' initializer 
[-Werror,-Wmissing-field-initializers]
13:31:17   Out.Sequence.push_back({Chunk});
13:31:17^
13:31:17 1 error generated.
```
I see the warning when compiling with clang 8.0.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126536/new/

https://reviews.llvm.org/D126536

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126536: [pseudo] Add grammar annotations support.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp:235
 
   Out.Sequence.push_back({Chunk});
 }

hokein wrote:
> uabelho wrote:
> > I get a warning/error on this line with this commit:
> > ```
> > 13:31:17 ../../clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp:235:36: 
> > error: missing field 'Attributes' initializer 
> > [-Werror,-Wmissing-field-initializers]
> > 13:31:17   Out.Sequence.push_back({Chunk});
> > 13:31:17^
> > 13:31:17 1 error generated.
> > ```
> > I see the warning when compiling with clang 8.0.
> sorry (I don't this warning enabled), should be fixed in 
> 9ce232fba99c47c3246f06fcbe37c24b9d90585f.
Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126536/new/

https://reviews.llvm.org/D126536

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122258: [MC] Omit DWARF unwind info if compact unwind is present where eligible

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I noticed that on one of our downstream (not public) buildbots the

  clang/test/Driver/femit-dwarf-unwind.s

test seems to fail rather randomly.
So if I run

  clang -target x86_64-apple-macos11.0 -c 
../clang/test/Driver/femit-dwarf-unwind.s -o foo.o
  llvm-objdump --macho --dwarf=frames foo.o

a couple of times I sometimes get

  .debug_frame contents:
  
  
  .eh_frame contents:

and sometimes I get

  .debug_frame contents:
  
  
  .eh_frame contents:
  
   0014  CIE
Format:DWARF32
Version:   1
Augmentation:  "zR"
Code alignment factor: 1
Data alignment factor: -8
Return address column: 16
Augmentation data: 10
  
DW_CFA_def_cfa: reg7 +8
DW_CFA_offset: reg16 -8
DW_CFA_nop:
DW_CFA_nop:
  
CFA=reg7+8: reg16=[CFA-8]
  
  0018 001c 001c FDE cie= pc=...0001
Format:   DWARF32
DW_CFA_def_cfa_offset: +8
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
DW_CFA_nop:
  
0x0: CFA=reg7+8: reg16=[CFA-8]

On another machine I don't seem to get that problem though, even if I compile 
in the same way so I really don't know what the difference is or why it is 
happening at all.
Any ideas? Anything anyone else is seeing?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122258/new/

https://reviews.llvm.org/D122258

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122258: [MC] Omit DWARF unwind info if compact unwind is present where eligible

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang/tools/driver/cc1as_main.cpp:323-329
+  if (auto *A = Args.getLastArg(OPT_femit_dwarf_unwind_EQ)) {
+Opts.EmitDwarfUnwind =
+llvm::StringSwitch(A->getValue())
+.Case("always", EmitDwarfUnwindType::Always)
+.Case("no-compact-unwind", EmitDwarfUnwindType::NoCompactUnwind)
+.Case("default", EmitDwarfUnwindType::Default);
+  }

int3 wrote:
> still building ASAN but this looks sus -- if no flag gets passed, we never 
> initialize `EmitDwarfUnwind` before using it on line 381
> 
> also it occurred to me that if the buildbots haven't flagged anything, ASAN 
> probably can't detect this. Let me just put up a patch
We have bots running ASAN on this without complaining.

A patch sounds good! Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122258/new/

https://reviews.llvm.org/D122258

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127630: [MC] Fix likely uninitialized memory bug

[Mikael Holmén via Phabricator via cfe-commits]

uabelho accepted this revision.
uabelho added a comment.
This revision is now accepted and ready to land.

As I haven't been able to reproduce the problem manually myself I can't confirm 
that this fixes the problem, but it does seem likely.
Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127630/new/

https://reviews.llvm.org/D127630

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123235: [OpenMP] atomic compare fail : Parser & AST support

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang/lib/Basic/OpenMPKinds.cpp:444
+OpenMPClauseKind CK = static_cast(Type);
+switch (CK) {
+case OMPC_unknown:

Hi @koops ,
clang complains on this patch with
```
../../clang/lib/Basic/OpenMPKinds.cpp:444:13: error: 97 enumeration values not 
handled in switch: 'OMPC_adjust_args', 'OMPC_affinity', 'OMPC_align'... 
[-Werror,-Wswitch]
switch (CK) {
^~
1 error generated.
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123235/new/

https://reviews.llvm.org/D123235

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123235: [OpenMP] atomic compare fail : Parser & AST support

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D123235#4656427 , @koops wrote:

> To avoid build error in ppc64 adding a "default" to switch statement.

I don't think it has anything particular to do with ppc64.

I see the warning/error when i compile with clang 15 on a RHEL7 machine.

If you compile without -Werror you just get a warning.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123235/new/

https://reviews.llvm.org/D123235

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123235: [OpenMP] atomic compare fail : Parser & AST support

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Btw, a bit confusing (to me at least) to reopen this review since it's already 
landed.




Comment at: clang/lib/Basic/OpenMPKinds.cpp:450
+case OMPC_unknown:
+default:
+  return "unknown";

Adding "default:" here silences the warning.
But looks like @ABataev commented on something similar earlier and said that's 
not recommended?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123235/new/

https://reviews.llvm.org/D123235

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126689: [IR] Enable opaque pointers by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.
Herald added subscribers: gysit, Dinistro, bviyer, jplehr, Moerafaat, 
kmitropoulou, zero9178, StephenFan.
Herald added a reviewer: dcaballe.

Hi @nikic,

I know I'm very late to the party with this, but I just noticed that since 
opaque pointers got turned on by default, the following program does not yield 
an error anymore when read by opt or llc:

  declare void @bar(i16)
  
  define void @foo() {
  entry:
call void @bar(float 1.00e+0)
ret void
  }

With typed pointers opt and llc would fail directly with

  opt: test.ll:5:13: error: '@bar' defined with type 'void (i16)*' but expected 
'void (float)*'
call void @bar(float 1.00e+00)
  ^

but now, since all pointers are just pointers, noone seems to bother about the 
mismatching parameter type.

The verifier doesn't complain either. Maybe it should be improved to explicitly 
check parameter types now that we won't get that for free via the function 
pointer type?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126689/new/

https://reviews.llvm.org/D126689

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126689: [IR] Enable opaque pointers by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

@nikic: Thanks, nothing to do there then even if I'm surprised.

I'm not sure but I *think* that llvm-reduce may have some problems with this. 
For my out of tree target I recently saw a case where llvm-reduced crashed with

  llvm-reduce: ../tools/llvm-reduce/deltas/ReduceOperandsToArgs.cpp:64: void 
replaceFunctionCalls(llvm::Function *, llvm::Function *): Assertion 
`CI->getCalledFunction() == OldF' failed.

and when I looked at the reduced result so far, I saw a call where parameters 
didn't match the declaration. So I guess it may now reduce in ways that it 
unexpected for it and then crash.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126689/new/

https://reviews.llvm.org/D126689

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D126689: [IR] Enable opaque pointers by default

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D126689#4654126 , @nikic wrote:

> In D126689#4654124 , @uabelho wrote:
>
>> @nikic: Thanks, nothing to do there then even if I'm surprised.
>>
>> I'm not sure but I *think* that llvm-reduce may have some problems with 
>> this. For my out of tree target I recently saw a case where llvm-reduced 
>> crashed with
>>
>>   llvm-reduce: ../tools/llvm-reduce/deltas/ReduceOperandsToArgs.cpp:64: void 
>> replaceFunctionCalls(llvm::Function *, llvm::Function *): Assertion 
>> `CI->getCalledFunction() == OldF' failed.
>>
>> and when I looked at the reduced result so far, I saw a call where 
>> parameters didn't match the declaration. So I guess it may now reduce in 
>> ways that it unexpected for it and then crash.
>
> Can you please file an issue for the llvm-reduce bug? I just took a quick 
> look at the code, and it indeed has a mismatch in checks between 
> canReplaceFunction() and replaceFunctionCalls() -- the conditions in both 
> need to be the same, but aren't.

Yeah I can do that. Unfortunately I don't have any reproducer I can share 
though but if you think you know at least one problem in the vicinity maybe 
it's good enough.

In D126689#4654126 , @nikic wrote:

> In D126689#4654124 , @uabelho wrote:
>
>> @nikic: Thanks, nothing to do there then even if I'm surprised.
>>
>> I'm not sure but I *think* that llvm-reduce may have some problems with 
>> this. For my out of tree target I recently saw a case where llvm-reduced 
>> crashed with
>>
>>   llvm-reduce: ../tools/llvm-reduce/deltas/ReduceOperandsToArgs.cpp:64: void 
>> replaceFunctionCalls(llvm::Function *, llvm::Function *): Assertion 
>> `CI->getCalledFunction() == OldF' failed.
>>
>> and when I looked at the reduced result so far, I saw a call where 
>> parameters didn't match the declaration. So I guess it may now reduce in 
>> ways that it unexpected for it and then crash.
>
> Can you please file an issue for the llvm-reduce bug? I just took a quick 
> look at the code, and it indeed has a mismatch in checks between 
> canReplaceFunction() and replaceFunctionCalls() -- the conditions in both 
> need to be the same, but aren't.

Sure, I wrote
 https://github.com/llvm/llvm-project/issues/69312
which is pretty useless since I can't share any reproducer but anyway there it 
is.
Good if you saw something in the vicinity that indeed looks related.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126689/new/

https://reviews.llvm.org/D126689

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54438: [analyzer] Reimplement dependencies between checkers

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td:230
 
 def NullReturnedFromNonnullChecker : Checker<"NullReturnedFromNonnull">,
   HelpText<"Warns when a null pointer is returned from a function that has "

Any reason this checker shouldn't get a dependecy too?

If I run it with

 clang -cc1 -analyze -analyzer-checker=core 
-analyzer-checker=nullability.NullReturnedFromNonnull empty.c

on an empty file empty.c I get

clang: ../tools/clang/include/clang/StaticAnalyzer/Core/CheckerManager.h:171: 
CHECKER *clang::ento::CheckerManager::getChecker() [CHECKER = (anonymous 
namespace)::NullabilityChecker]: Assertion `CheckerTags.count(tag) != 0 && 
"Requested checker is not registered! Maybe you should add it as a " 
"dependency in Checkers.td?"' failed.

If I add
 Dependencies<[NullabilityBase]>,
to it, then it doesn't trigger the assert.

I don't know anything about this code, what do you think about it?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54438/new/

https://reviews.llvm.org/D54438



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54438: [analyzer] Reimplement dependencies between checkers

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td:230
 
 def NullReturnedFromNonnullChecker : Checker<"NullReturnedFromNonnull">,
   HelpText<"Warns when a null pointer is returned from a function that has "

Szelethus wrote:
> uabelho wrote:
> > Any reason this checker shouldn't get a dependecy too?
> > 
> > If I run it with
> > 
> >  clang -cc1 -analyze -analyzer-checker=core 
> > -analyzer-checker=nullability.NullReturnedFromNonnull empty.c
> > 
> > on an empty file empty.c I get
> > 
> > clang: 
> > ../tools/clang/include/clang/StaticAnalyzer/Core/CheckerManager.h:171: 
> > CHECKER *clang::ento::CheckerManager::getChecker() [CHECKER = (anonymous 
> > namespace)::NullabilityChecker]: Assertion `CheckerTags.count(tag) != 0 && 
> > "Requested checker is not registered! Maybe you should add it as a " 
> > "dependency in Checkers.td?"' failed.
> > 
> > If I add
> >  Dependencies<[NullabilityBase]>,
> > to it, then it doesn't trigger the assert.
> > 
> > I don't know anything about this code, what do you think about it?
> Yup, should be there. Thanks for catching this one! I'll be able to commit 
> the fix in about 4ish hours, or if it blocks you, feel free to so before that.
> 
> Since I didnt add test for each and every affected checker, I wonder whether 
> there is any more of these that I forgot/messed up while rebasing.
> 
> Thanks again! :)
Sounds good, no panic!

Thanks!


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54438/new/

https://reviews.llvm.org/D54438



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D55085: Avoid emitting redundant or unusable directories in DIFile metadata entries

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,
A late question about this change. I notice that this change sometimes gives me 
additional DIFiles in the clang output compared to before.
E.g. if I have a file

/tmp/bar/foo.c

containing just

void foo() {
 }

and I stand in /tmp/ and do

clang -emit-llvm -S -g /tmp/bar/foo.c -o -

then I get two DIFiles in the output:

!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang 
version 8.0.0 (trunk 348738) (llvm/trunk 348737)", isOptimized: false, 
runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
 !1 = !DIFile(filename: "/tmp/bar/foo.c", directory: "/tmp")
 [...]
 !8 = !DIFile(filename: "bar/foo.c", directory: "/tmp")

where !1 is only used in !DICompileUnit and !8 is used everywhere else. Before 
this change the only DIFile I got was

!1 = !DIFile(filename: "/tmp/bar/foo.c", directory: "/tmp")

so in the clang output we actually got more tuff with the change than before.

Also, for my out-of-tree target the two DIFiles later caused confusion for gdb 
since there then was a mismatch between the compilation unit name
in the debug line section and in the debug info section. Due to that mismatch 
gdb dropped the prologue_end so in cases where foo had a more interesting body
I would stop at the wrong place if I set a breakpoint with
 break foo

I haven't seen the problem with a breakpoint ending up at the wrong place when 
compiling for X86 though and I'm not sure
if it's because I haven't tried hard enough or if it's something special with 
my backend.

Anyway, is the above as expected or should the filename in !1 be shortened as 
well?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55085/new/

https://reviews.llvm.org/D55085



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53651: [clangd] Use thread pool for background indexing.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

I've got a post-review comment about the use of SCHED_IDLE vs the needed gcc 
version.




Comment at: clang-tools-extra/trunk/clangd/Threading.cpp:110
+  T.native_handle(),
+  Priority == ThreadPriority::Low ? SCHED_IDLE : SCHED_OTHER, &priority);
+#endif

I noticed that when I compile this with gcc 5.4.0, I get a compilation error 
about SCHED_IDLE not being defined.
Indeed, if I look in sched.h used with gcc 5.4.0, these are the SCHED_* 
definitions:

```
/* Scheduling algorithms.  */
#define SCHED_OTHER 0
#define SCHED_FIFO  1
#define SCHED_RR2
#ifdef __USE_GNU
# define SCHED_BATCH3
#endif
```
I suppose SCHED_IDLE was added in some later version...

On
 
https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library
it says that gcc 4.8 should work, but it doesn't now then?



Repository:
  rL LLVM

https://reviews.llvm.org/D53651



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D131632: [clang] Enable output of SARIF diagnostics

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added inline comments.



Comment at: clang/test/Frontend/sarif-diagnostics.cpp:8
+// Omit filepath to llvm project directory
+// CHECK: 
clang/test/Frontend/sarif-diagnostics.cpp"},"mimeType":"text/plain","roles":["resultFile"]}],"columnKind":"unicodeCodePoints","results":[{"level":"error","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":1,"startColumn":1,"startLine":12}}}],"message":{"text":"'main'
 must return 
'int'"},"ruleId":"3465","ruleIndex":0},{"level":"error","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":11,"startColumn":11,"startLine":13}}}],"message":{"text":"use
 of undeclared identifier 
'hello'"},"ruleId":"4604","ruleIndex":1},{"level":"error","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":17,"startColumn":17,"startLine":15}}}],"message":{"text":"invalid
 digit 'a' in decimal 
constant"},"ruleId":"898","ruleIndex":2},{"level":"warning","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":5,"startColumn":5,"startLine":19}}}],"message":{"text":"misleading
 indentation; statement is not part of the previous 
'if'"},"ruleId":"1806","ruleIndex":3},{"level":"note","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":3,"startColumn":3,"startLine":17}}}],"message":{"text":"previous
 statement is 
here"},"ruleId":"1730","ruleIndex":4},{"level":"warning","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":10,"startColumn":10,"startLine":18}}}],"message":{"text":"unused
 variable 
'Yes'"},"ruleId":"6539","ruleIndex":5},{"level":"error","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":12,"startColumn":12,"startLine":21}}}],"message":{"text":"use
 of undeclared identifier 
'hi'"},"ruleId":"4604","ruleIndex":6},{"level":"error","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":1,"startColumn":1,"startLine":23}}}],"message":{"text":"extraneous
 closing brace 
('}')"},"ruleId":"1399","ruleIndex":7},{"level":"error","locations":[{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":6,"endLine":27,"startColumn":5,"startLine":27}}},{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":10,"endLine":27,"startColumn":9,"startLine":27}}},{"physicalLocation":{"artifactLocation":{"index":0},"region":{"endColumn":7,"startColumn":7,"startLine":27}}}],"message":{"text":"invalid
 operands to binary expression ('t1' and 
't1')"},"ruleId":"4539","ruleIndex":8}],"tool":{"driver":{"fullName":"","informationUri":"https://clang.llvm.org/docs/UsersManual.html","language":"en-US","name":"clang","rules":[{"defaultConfiguration":{"enabled":true,"level":"error","rank":50},"fullDescription":{"text":""},"id":"3465","name":""},{"defaultConfiguration":{"enabled":true,"level":"error","rank":50},"fullDescription":{"text":""},"id":"4604","name":""},{"defaultConfiguration":{"enabled":true,"level":"error","rank":50},"fullDescription":{"text":""},"id":"898","name":""},{"defaultConfiguration":{"enabled":true,"level":"warning","rank":-1},"fullDescription":{"text":""},"id":"1806","name":""},{"defaultConfiguration":{"enabled":true,"level":"note","rank":-1},"fullDescription":{"text":""},"id":"1730","name":""},{"defaultConfiguration":{"enabled":true,"level":"warning","rank":-1},"fullDescription":{"text":""},"id":"6539","name":""},{"defaultConfiguration":{"enabled":true,"level":"error","rank":50},"fullDescription":{"text":""},"id":"4604","name":""},{"defaultConfiguration":{"enabled":true,"level":"error","rank":50},"fullDescription":{"text":""},"id":"1399","name":""},{"defaultConfiguration":{"enabled":true,"level":"error","rank":50},"fullDescription":{"text":""},"id":"4539","name":""}],"version":"16.0.0"}}}],"version":"2.1.0"}
+// CHECK: 2 warnings and 6 errors generated.

dyung wrote:
> dyung wrote:
> > Can this CHECK line be broken into smaller pieces? This test is failing on 
> > our internal bot, and I'm going crosseyed trying to figure out what the 
> > difference is because the line is 3741 characters long!
> Is there any significance to the "ruleId" and "Id" values in this test? If 
> not, can we just use a regex to check for a number? Our internal build with 
> private changes is failing due to slightly different numbers in some of the 
> "ruleId" fields
+1 on this. We also get different "ruleId" and "Id" values downstream and it's 
quite painful trying to figure out where the diffs are in a +3700 character 
CHECK.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131632/new/

https://reviews.llvm.org/D131632

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136090: Handle errors in expansion of response files

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hello,

I'm wondering if this is really working as expected/intended.

With this patch, if I do

  clang empty.c @atfileesc.txt -dry-run

on an empty file empty.c and atfileesc.txt containing just

  -I @name-with-at/

then I get the following error

  cannot open file: /repo/uabelho/main-github/llvm/atfileesc.txt
  Program aborted due to an unhandled Error:
  cannot open file: /repo/uabelho/main-github/llvm/atfileesc.txt
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: build-all/bin/clang empty.c @atfileesc.txt -dry-run
   #0 0x02fc9873 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(build-all/bin/clang+0x2fc9873)
   #1 0x02fc758e llvm::sys::RunSignalHandlers() 
(build-all/bin/clang+0x2fc758e)
   #2 0x02fc9bf6 SignalHandler(int) (build-all/bin/clang+0x2fc9bf6)
   #3 0x7f678e7ae630 __restore_rt (/lib64/libpthread.so.0+0xf630)
   #4 0x7f678bef5387 raise (/lib64/libc.so.6+0x36387)
   #5 0x7f678bef6a78 abort (/lib64/libc.so.6+0x37a78)
   #6 0x02f39d00 llvm::Error::fatalUncheckedError() const 
(build-all/bin/clang+0x2f39d00)
   #7 0x009d5e3a clang_main(int, char**) (build-all/bin/clang+0x9d5e3a)
   #8 0x7f678bee1555 __libc_start_main (/lib64/libc.so.6+0x22555)
   #9 0x009d233b _start (build-all/bin/clang+0x9d233b)
  Abort (core dumped)

Note that the file it is complaining about indeed exists:

  -> ls -l /repo/uabelho/main-github/llvm/atfileesc.txt
  -rw-r--r-- 1 uabelho eusers 18 Nov  1 11:15 
/repo/uabelho/main-github/llvm/atfileesc.txt

and as I wrote above it contains

  -> cat /repo/uabelho/main-github/llvm/atfileesc.txt
  -I @name-with-at/


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136090/new/

https://reviews.llvm.org/D136090

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136090: Handle errors in expansion of response files

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D136090#3905845 , @sepavloff wrote:

> Thank you for reporting the issue. It was fixed in fdab9f1203ee 
> .

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136090/new/

https://reviews.llvm.org/D136090

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130510: Missing tautological compare warnings due to unary operators

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D130510#3821641 , @aaron.ballman 
wrote:

> In D130510#3817148 , @ebevhan wrote:
>
>> Hi! A bit of late feedback on this patch. We found a failure in our 
>> downstream testing likely originating from here.
>
> Thank you for the feedback! I've addressed the issue in 
> 96a79cb308d1b8c00a83b180d9fecc5d54bacb9c 
> .

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130510/new/

https://reviews.llvm.org/D130510

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86844: [LoopDeletion] Allows deletion of possibly infinite side-effect free loops

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.
Herald added a project: All.

I wrote
 https://github.com/llvm/llvm-project/issues/58123
about a crash that I bisected to this patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86844/new/

https://reviews.llvm.org/D86844

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112621: [analyzer][solver] Introduce reasoning for not equal to operator

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

The following starts crashing with this patch:

  clang -cc1 -analyze -analyzer-checker=core bbi-77010.c

It crashes with

  bbi-77010.c:6:1: warning: non-void function does not return a value 
[-Wreturn-type]
  }
  ^
  clang: ../../clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1622: 
clang::ento::RangeSet (anonymous 
namespace)::SymbolicRangeInferrer::VisitBinaryOperator(clang::ento::RangeSet, 
clang::ento::RangeSet, clang::QualType): Assertion `!LHS.isEmpty() && 
!RHS.isEmpty() && "Both ranges should be non-empty"' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: ../../main-github/llvm/build-all/bin/clang -cc1 
-analyze -analyzer-checker=core bbi-77010.c
  1. parser at end of file
  2.While analyzing stack: 
#0 Calling g
  3.bbi-77010.c:13:12: Error evaluating statement
  4.bbi-77010.c:13:12: Error evaluating statement
   #0 0x02fddbb3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(../../main-github/llvm/build-all/bin/clang+0x2fddbb3)
   #1 0x02fdb8de llvm::sys::RunSignalHandlers() 
(../../main-github/llvm/build-all/bin/clang+0x2fdb8de)
   #2 0x02fddf36 SignalHandler(int) Signals.cpp:0:0
   #3 0x7fe701eb8630 __restore_rt sigaction.c:0:0
   #4 0x7fe6ff5ff387 raise (/lib64/libc.so.6+0x36387)
   #5 0x7fe6ff600a78 abort (/lib64/libc.so.6+0x37a78)
   #6 0x7fe6ff5f81a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6)
   #7 0x7fe6ff5f8252 (/lib64/libc.so.6+0x2f252)
   #8 0x049caed2 (anonymous 
namespace)::SymbolicRangeInferrer::VisitBinaryOperator(clang::ento::RangeSet, 
clang::BinaryOperatorKind, clang::ento::RangeSet, clang::QualType) 
RangeConstraintManager.cpp:0:0
   #9 0x049c9867 (anonymous 
namespace)::SymbolicRangeInferrer::infer(clang::ento::SymExpr const*) 
RangeConstraintManager.cpp:0:0
  #10 0x049bebf5 (anonymous 
namespace)::RangeConstraintManager::assumeSymNE(llvm::IntrusiveRefCntPtr, clang::ento::SymExpr const*, llvm::APSInt const&, llvm::APSInt const&) 
RangeConstraintManager.cpp:0:0
  #11 0x049d368c 
clang::ento::RangedConstraintManager::assumeSymUnsupported(llvm::IntrusiveRefCntPtr, clang::ento::SymExpr const*, bool) 
(../../main-github/llvm/build-all/bin/clang+0x49d368c)
  #12 0x049f0b09 
clang::ento::SimpleConstraintManager::assumeAux(llvm::IntrusiveRefCntPtr, clang::ento::NonLoc, bool) 
(../../main-github/llvm/build-all/bin/clang+0x49f0b09)
  #13 0x049f096a 
clang::ento::SimpleConstraintManager::assume(llvm::IntrusiveRefCntPtr, clang::ento::NonLoc, bool) 
(../../main-github/llvm/build-all/bin/clang+0x49f096a)
  #14 0x049f086d 
clang::ento::SimpleConstraintManager::assumeInternal(llvm::IntrusiveRefCntPtr, clang::ento::DefinedSVal, bool) 
(../../main-github/llvm/build-all/bin/clang+0x49f086d)
  #15 0x0492d3e3 
clang::ento::ConstraintManager::assumeDual(llvm::IntrusiveRefCntPtr, clang::ento::DefinedSVal) 
(../../main-github/llvm/build-all/bin/clang+0x492d3e3)
  #16 0x04955b6d 
clang::ento::ExprEngine::evalEagerlyAssumeBinOpBifurcation(clang::ento::ExplodedNodeSet&,
 clang::ento::ExplodedNodeSet&, clang::Expr const*) 
(../../main-github/llvm/build-all/bin/clang+0x4955b6d)
  #17 0x049514b6 clang::ento::ExprEngine::Visit(clang::Stmt const*, 
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) 
(../../main-github/llvm/build-all/bin/clang+0x49514b6)
  #18 0x0494c73e clang::ento::ExprEngine::ProcessStmt(clang::Stmt 
const*, clang::ento::ExplodedNode*) 
(../../main-github/llvm/build-all/bin/clang+0x494c73e)
  #19 0x0494c459 
clang::ento::ExprEngine::processCFGElement(clang::CFGElement, 
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) 
(../../main-github/llvm/build-all/bin/clang+0x494c459)
  #20 0x0492f3d0 
clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int, 
clang::ento::ExplodedNode*) 
(../../main-github/llvm/build-all/bin/clang+0x492f3d0)
  #21 0x0492e1f6 
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, 
unsigned int, llvm::IntrusiveRefCntPtr) 
(../../main-github/llvm/build-all/bin/clang+0x492e1f6)
  #22 0x0454d931 (anonymous 
namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int, 
clang::ento::ExprEngine::InliningModes, llvm::DenseSet>*) AnalysisConsumer.cpp:0:0
  #23 0x0453034e (anonymous 
namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&) 
AnalysisConsumer.cpp:0:0
  #24 0x04a441a5 clang::ParseAST(clang::Sema&, bool, bool) 
(../../main-github/llvm/build-all/bin/clang+0x4a441a5)
  #25 0x03ac97f6 clang::FrontendAction::Execute() 
(../../main-github/llvm/build-all/bin/clang+0x3ac97f6)
  #26 0x03a3b8a4 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) 

[PATCH] D112621: [analyzer][solver] Introduce reasoning for not equal to operator

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D112621#4004409 , @steakhal wrote:

> In D112621#4004372 , @uabelho wrote:
>
>> Hi,
>>
>> The following starts crashing with this patch:
>>
>>   clang -cc1 -analyze -analyzer-checker=core bbi-77010.c
>>
>> It crashes with
>>
>>   bbi-77010.c:6:1: warning: non-void function does not return a value 
>> [-Wreturn-type]
>>   }
>>   ^
>>   clang: 
>> ../../clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1622: 
>> clang::ento::RangeSet (anonymous 
>> namespace)::SymbolicRangeInferrer::VisitBinaryOperator(clang::ento::RangeSet,
>>  clang::ento::RangeSet, clang::QualType): Assertion `!LHS.isEmpty() && 
>> !RHS.isEmpty() && "Both ranges should be non-empty"' failed.
>>   PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
>> and include the crash backtrace, preprocessed source, and associated run 
>> script.
>>   Abort (core dumped)
>>
>> F25730184: bbi-77010.c 
>
> Thanks for the report. I'll fix it ASAP.
> I think I'll replace the assertion with an early return.
>
> BTW, was this uncovered by fuzzing? @uabelho

We found it compiling some random programs generated by Csmith.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112621/new/

https://reviews.llvm.org/D112621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138253: [-Wunsafe-buffer-usage] NFC: Implement fix-strategies and variable-use-claiming.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hello,

I noticed that the following crashes with this patch:

  clang -Weverything bbi-77071.c

Result:

  clang-16: ../../clang/lib/Analysis/UnsafeBufferUsage.cpp:248: void (anonymous 
namespace)::DeclUseTracker::discoverDecl(const clang::DeclStmt *): Assertion 
`Defs.count(VD) == 0 && "Definition already discovered!"' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: 
/repo/uabelho/main-github/llvm/build-all/bin/clang-16 -cc1 -triple 
x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations 
-disable-free -clear-ast-before-backend -main-file-name bbi-77071.c 
-mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all 
-fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases 
-funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -mllvm 
-treat-scalable-fixed-error-as-warning -debugger-tuning=gdb 
-fcoverage-compilation-dir=/repo/uabelho/llvm-dev2/llvm -resource-dir 
/repo/uabelho/main-github/llvm/build-all/lib/clang/16 -internal-isystem 
/repo/uabelho/main-github/llvm/build-all/lib/clang/16/include -internal-isystem 
/usr/local/include -internal-isystem 
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../x86_64-redhat-linux/include 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-Weverything -fdebug-compilation-dir=/repo/uabelho/llvm-dev2/llvm -ferror-limit 
19 -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig 
-D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/bbi-77071-6173ad.o -x c bbi-77071.c
  1. parser at end of file
  2.bbi-77071.c:5:9: parsing function body 'fn1'
   #0 0x02fdf843 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x2fdf843)
   #1 0x02fdd56e llvm::sys::RunSignalHandlers() 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x2fdd56e)
   #2 0x02fdfbc6 SignalHandler(int) Signals.cpp:0:0
   #3 0x7fcfa502a630 __restore_rt sigaction.c:0:0
   #4 0x7fcfa2771387 raise (/lib64/libc.so.6+0x36387)
   #5 0x7fcfa2772a78 abort (/lib64/libc.so.6+0x37a78)
   #6 0x7fcfa276a1a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6)
   #7 0x7fcfa276a252 (/lib64/libc.so.6+0x2f252)
   #8 0x05520daf findGadgets(clang::Decl 
const*)::GadgetFinderCallback::run(clang::ast_matchers::MatchFinder::MatchResult
 const&) UnsafeBufferUsage.cpp:0:0
   #9 0x0554c862 clang::ast_matchers::internal::(anonymous 
namespace)::MatchASTVisitor::MatchVisitor::visitMatch(clang::ast_matchers::BoundNodes
 const&) ASTMatchFinder.cpp:0:0
  #10 0x0557d27b 
clang::ast_matchers::internal::BoundNodesTreeBuilder::visitMatches(clang::ast_matchers::internal::BoundNodesTreeBuilder::Visitor*)
 (/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x557d27b)
  #11 0x0554be73 clang::ast_matchers::internal::(anonymous 
namespace)::MatchASTVisitor::matchWithFilter(clang::DynTypedNode const&) 
ASTMatchFinder.cpp:0:0
  #12 0x05524f9c 
clang::ast_matchers::MatchFinder::match(clang::DynTypedNode const&, 
clang::ASTContext&) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x5524f9c)
  #13 0x0551eb53 clang::checkUnsafeBufferUsage(clang::Decl const*, 
clang::UnsafeBufferUsageHandler&) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x551eb53)
  #14 0x053f48e5 
clang::sema::AnalysisBasedWarnings::IssueWarnings(clang::sema::AnalysisBasedWarnings::Policy,
 clang::sema::FunctionScopeInfo*, clang::Decl const*, clang::QualType) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x53f48e5)
  #15 0x04b91a53 
clang::Sema::PopFunctionScopeInfo(clang::sema::AnalysisBasedWarnings::Policy 
const*, clang::Decl const*, clang::QualType) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x4b91a53)
  #16 0x04d14f6f clang::Sema::ActOnFinishFunctionBody(clang::Decl*, 
clang::Stmt*, bool) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x4d14f6f)
  #17 0x04b29135 
clang::Parser::ParseFunctionStatementBody(clang::Decl*, 
clang::Parser::ParseScope&) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x4b29135)
  #18 0x04a50d95 
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, 
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x4a50d95)
  #19 0x04a6d637 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, 
clang::DeclaratorContext, clang::ParsedAttributes&, clang::SourceLocation*, 
clang::Parser::ForRangeInit*) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16+0x4a6d637)
  #20 0x04a4f9a7 
clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, 
clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) 
(/repo/uabelho/main-github/llvm/build-all/bin/clang-16

[PATCH] D138253: [-Wunsafe-buffer-usage] NFC: Implement fix-strategies and variable-use-claiming.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D138253#4006197 , @NoQ wrote:

> Also if you're compiling your code with `-Weverything` by default, I do 
> recommend explicitly disabling `-Wunsafe-buffer-usage` for at least a month 
> or so, until we land all the basic functionality and you can make an informed 
> decision whether you actually need it (more reading in 
> https://discourse.llvm.org/t/rfc-c-buffer-hardening/65734 and D136811 
> ).
>
> But, yeah, we still shouldn't break users who simply want to enable 
> `-Weverything` temporarily just to see what warnings are there, that's really 
> bad and I hope I'll patch this up today.

Thanks for the warning. In our fuzzy testing we sometimes randomly use 
-Weverything just to make sure it doesn't crash. And well, it did crash here, 
so I guess the testing was succesful :)
So it's no panic for us, but good to sort out the crash.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138253/new/

https://reviews.llvm.org/D138253

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112621: [analyzer][solver] Introduce reasoning for not equal to operator

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D112621#4004586 , @steakhal wrote:

> Fixed by f61a08b67f5c8b0202dd30821766ee029e880b7c 
> 

Yep, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112621/new/

https://reviews.llvm.org/D112621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138253: [-Wunsafe-buffer-usage] NFC: Implement fix-strategies and variable-use-claiming.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

It crashes on this as well:

  void f(int a[])
  {
  int b = {a[1]};
  }

with

  clang -cc1 foo.c -Weverything

I get

  clang: ../../clang/lib/Analysis/UnsafeBufferUsage.cpp:233: void (anonymous 
namespace)::DeclUseTracker::claimUse(const clang::DeclRefExpr *): Assertion 
`Uses->count(DRE) && "DRE not found or claimed by multiple matchers!"' failed.

But now I will indeed add -Wno-unsafe-buffer-usage. :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138253/new/

https://reviews.llvm.org/D138253

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D159486: Fix build error in CI.

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi @zahiraam ,

I have a couple of downstream testcases that fail with this patch.
Before

  > clang bbi-86364.c -lm -O3
  > ./a.out

passed but with the patch the assert in the program fails:

  a.out: bbi-86364.c:9: int main(): Assertion `(*__errno_location ()) == 33' 
failed.

Is this as expected?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159486/new/

https://reviews.llvm.org/D159486

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits