[clang] 47ef09e - Revert "clang-format: support aligned nested conditionals formatting"

2020-04-23 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2020-04-23T09:25:01+02:00
New Revision: 47ef09e4848a970c530928496b54085cfdba5a76

URL: 
https://github.com/llvm/llvm-project/commit/47ef09e4848a970c530928496b54085cfdba5a76
DIFF: 
https://github.com/llvm/llvm-project/commit/47ef09e4848a970c530928496b54085cfdba5a76.diff

LOG: Revert "clang-format: support aligned nested conditionals formatting"

This reverts 3d61b1120e8267aa39f4c9a33d618dbaec4ec6fa, 
5daa25fd7a184524759b6ad065a8bd7e95aa149a

The clang-format test (FormatTest.ConfigurableUseOfTab) is failing in the 
buildbot:

http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/31811/steps/ninja%20check%201/logs/stdio

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/include/clang/Format/Format.h
clang/lib/Format/ContinuationIndenter.cpp
clang/lib/Format/ContinuationIndenter.h
clang/lib/Format/Format.cpp
clang/lib/Format/WhitespaceManager.cpp
clang/lib/Format/WhitespaceManager.h
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/FormatTestJS.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index e5a69fdb9c5a..6d486224e3c2 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -270,49 +270,17 @@ the configuration (without a prefix: ``Auto``).
 
 
 
-**AlignOperands** (``OperandAlignmentStyle``)
+**AlignOperands** (``bool``)
   If ``true``, horizontally align operands of binary and ternary
   expressions.
 
-  Possible values:
-
-  * ``OAS_DontAlign`` (in configuration: ``DontAlign``)
-Do not align operands of binary and ternary expressions.
-The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
-the start of the line.
-
-  * ``OAS_Align`` (in configuration: ``Align``)
-Horizontally align operands of binary and ternary expressions.
-
-Specifically, this aligns operands of a single expression that needs
-to be split over multiple lines, e.g.:
-
-.. code-block:: c++
-
-  int aaa = bbb +
-ccc;
-
-When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
-aligned with the operand on the first line.
-
-.. code-block:: c++
-
-  int aaa = bbb
-+ ccc;
-
-  * ``OAS_AlignAfterOperator`` (in configuration: ``AlignAfterOperator``)
-Horizontally align operands of binary and ternary expressions.
-
-This is similar to ``AO_Align``, except when
-``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
-that the wrapped operand is aligned with the operand on the first line.
-
-.. code-block:: c++
-
-  int aaa = bbb
-  + ccc;
+  Specifically, this aligns operands of a single expression that needs to be
+  split over multiple lines, e.g.:
 
+  .. code-block:: c++
 
+int aaa = bbb +
+  ccc;
 
 **AlignTrailingComments** (``bool``)
   If ``true``, aligns trailing comments.

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index f5fa6b44a127..2b2edc4adc11 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -153,43 +153,16 @@ struct FormatStyle {
   /// Options for aligning backslashes in escaped newlines.
   EscapedNewlineAlignmentStyle AlignEscapedNewlines;
 
-  /// Different styles for aligning operands.
-  enum OperandAlignmentStyle {
-/// Do not align operands of binary and ternary expressions.
-/// The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
-/// the start of the line.
-OAS_DontAlign,
-/// Horizontally align operands of binary and ternary expressions.
-///
-/// Specifically, this aligns operands of a single expression that needs
-/// to be split over multiple lines, e.g.:
-/// \code
-///   int aaa = bbb +
-/// ccc;
-/// \endcode
-///
-/// When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
-/// aligned with the operand on the first line.
-/// \code
-///   int aaa = bbb
-/// + ccc;
-/// \endcode
-OAS_Align,
-/// Horizontally align operands of binary and ternary expressions.
-///
-/// This is similar to ``AO_Align``, except when
-/// ``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
-/// that the wrapped operand is aligned with the operand on the first line.
-/// \code
-///   int aaa = bbb
-///   + ccc;
-/// \endcode
-OAS_AlignAfterOperator,
-  };
-
   /// If ``true``, horizontally align operands of binary and ternary
   /// expressions.
-  OperandAlignmentStyle AlignOperands;
+  ///
+  /// Specifically, this aligns 

[PATCH] D74813: [RFC] Add hash of block contents to function block names

2020-04-23 Thread James Henderson via Phabricator via cfe-commits
jhenderson added inline comments.



Comment at: llvm/test/tools/llvm-cxxfilt/invalid.test:1
-RUN: llvm-cxxfilt -n _Z1fi __Z1fi f ___ZSt1ff_block_invoke | FileCheck %s
+RUN: llvm-cxxfilt -n _Z1fi __Z1fi f ___ZSt1ff_block_invoke 
___Z7my_mainv_block_invoke_ZTSi_ZTSj_ZTSPVK3sss | FileCheck %s
 

I'm not sure this test needs updating with an additional case?

This test is just to show what llvm-cxxfilt prints when an input is not a valid 
mangled name (I think). I think the existing block_invoke example is there 
merely to show triple underscores can be handled, but I actually am doubtful 
that it really belongs here, as that sounds more like belonging in the 
demangler testing.

NB. I haven't actually looked at the history of this test or the source code to 
verify anything I just said.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813



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


[PATCH] D50078: clang-format: support aligned nested conditionals formatting

2020-04-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

In D50078#1998520 , @Typz wrote:

> In D50078#1998398 , @dyung wrote:
>
> > Hi, this change that you submitted in commit 
> > 5daa25fd7a184524759b6ad065a8bd7e95aa149a 
> >  seems 
> > to be causing the test "Clang-Unit :: 
> > Format/./FormatTests.exe/FormatTest.ConfigurableUseOfTab" to randomly fail 
> > about 50% of the time on Windows.
> >
> > Take the most recent 5 runs of the 
> > llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast buildbot. Builds #31973 
> > ,
> >  31975 
> > 
> >  and 31976 
> > 
> >  all failed because of that test failing.
> >
> > On my local Windows computer, if I build your commit and run the FormatTest 
> > unit test multiple times (the same binary without changing anything or 
> > rebuilding), that above test fails roughly 50% of the time.
> >
> > Can you take a look to figure out why your change might be causing this 
> > instability?
>
>
> Hi,
>  That is very strange indeed, nothing is supposed to be random here...
>  I will try to have a look, but I don't have a windows computer to test, and 
> never seen this issue on linux/macos :-/


The linux (s390x arch) buildbot is also failing, 
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/31811/steps/ninja%20check%201/logs/stdio.
I reverted it in 47ef09e4848a970c530928496b54085cfdba5a76 
 to make 
buildbot happy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50078



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


[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-04-23 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware marked 2 inline comments as done.
baloghadamsoftware added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1044
 
+class ParamWithoutVarRegion : public TypedValueRegion {
+  friend class MemRegionManager;

baloghadamsoftware wrote:
> NoQ wrote:
> > There should be only one way to express the parameter region. Let's call 
> > this one simply `ParamRegion` or something like that, and 
> > `assert(!isa(D))` in the constructor of `VarRegion`.
> Do you mean that we should use `ParamRegion` in every case, thus also when we 
> have the definitioan for the function? I wonder whether it breaks too many 
> things.
This will surely not work. The common handling of `ParamVarDecl` and `VarDecl` 
is soo deeply rooted in the whole analyzer that separating them means creation 
of a totally new analyzer engine from scratch.


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

https://reviews.llvm.org/D77229



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


[PATCH] D31130: B32239 clang-tidy should not warn about array to pointer decay on system macros

2020-04-23 Thread fiesh via Phabricator via cfe-commits
fiesh added a comment.

@JonasToth could you please clarify if the original author's comment is 
sufficient grants of rights?

If so, from what I can tell if the commit message was adapted to reflect that 
this removes false positives with system macros like `assert`, this would be 
good to go?


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

https://reviews.llvm.org/D31130



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


[PATCH] D77940: [AArch64] Add NVIDIA Carmel support

2020-04-23 Thread Raul Tambre via Phabricator via cfe-commits
tambre added a comment.

sdesmalen: Could you please take another look?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77940



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


[PATCH] D78374: [Analyzer][StreamChecker] Added evaluation of fread and fwrite.

2020-04-23 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 259491.
balazske added a comment.

- Stream error is stored in separate boolean flags instead of enum.
- Removed `PossibleErrors`.
- Added "FilePositionIndeterminate".
- Updated fread, fwrite, fseek, clearerr.
- Added tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78374

Files:
  clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
  clang/test/Analysis/stream-error.c

Index: clang/test/Analysis/stream-error.c
===
--- clang/test/Analysis/stream-error.c
+++ clang/test/Analysis/stream-error.c
@@ -3,6 +3,7 @@
 #include "Inputs/system-header-simulator.h"
 
 void clang_analyzer_eval(int);
+void clang_analyzer_warnIfReached();
 void StreamTesterChecker_make_feof_stream(FILE *);
 void StreamTesterChecker_make_ferror_stream(FILE *);
 
@@ -53,6 +54,73 @@
   fclose(F);
 }
 
+void error_fread() {
+  FILE *F = tmpfile();
+  if (!F)
+return;
+  int Ret = fread(0, 1, 10, F);
+  if (Ret == 10) {
+clang_analyzer_eval(feof(F) || ferror(F)); // expected-warning {{FALSE}}
+  } else {
+clang_analyzer_eval(feof(F) || ferror(F)); // expected-warning {{TRUE}}
+if (feof(F)) {
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+  fread(0, 1, 10, F); // no warning
+}
+if (ferror(F)) {
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+  fread(0, 1, 10, F); // expected-warning {{Stream might be in indeterminate state}}
+}
+  }
+  fclose(F);
+  Ret = fread(0, 1, 10, F); // expected-warning {{Stream might be already closed}}
+}
+
+void error_fwrite() {
+  FILE *F = tmpfile();
+  if (!F)
+return;
+  int Ret = fwrite(0, 1, 10, F);
+  if (Ret == 10) {
+clang_analyzer_eval(feof(F) || ferror(F)); // expected-warning {{FALSE}}
+  } else {
+clang_analyzer_eval(feof(F));   // expected-warning {{FALSE}}
+clang_analyzer_eval(ferror(F)); // expected-warning {{TRUE}}
+fwrite(0, 1, 10, F);// expected-warning {{Stream might be in indeterminate state}}
+  }
+  fclose(F);
+  Ret = fwrite(0, 1, 10, F); // expected-warning {{Stream might be already closed}}
+}
+
+void freadwrite_zerosize(FILE *F) {
+  fwrite(0, 1, 0, F);
+  fwrite(0, 0, 1, F);
+  fread(0, 1, 0, F);
+  fread(0, 0, 1, F);
+}
+
+void error_fread_fwrite_zerosize() {
+  FILE *F = fopen("file", "r");
+  if (!F)
+return;
+
+  freadwrite_zerosize(F);
+  clang_analyzer_eval(feof(F));   // expected-warning {{FALSE}}
+  clang_analyzer_eval(ferror(F)); // expected-warning {{FALSE}}
+
+  StreamTesterChecker_make_ferror_stream(F);
+  freadwrite_zerosize(F);
+  clang_analyzer_eval(feof(F));   // expected-warning {{FALSE}}
+  clang_analyzer_eval(ferror(F)); // expected-warning {{TRUE}}
+
+  StreamTesterChecker_make_feof_stream(F);
+  freadwrite_zerosize(F);
+  clang_analyzer_eval(feof(F));   // expected-warning {{TRUE}}
+  clang_analyzer_eval(ferror(F)); // expected-warning {{FALSE}}
+
+  fclose(F);
+}
+
 void error_fseek() {
   FILE *F = fopen("file", "r");
   if (!F)
@@ -83,3 +151,34 @@
   }
   fclose(F);
 }
+
+void error_fseek_indeterminate() {
+  FILE *F = fopen("file", "r");
+  if (!F)
+return;
+  int rc = fseek(F, 0, SEEK_SET);
+  if (rc) {
+if (feof(F)) {
+  fwrite(0, 1, 10, F); // no warning
+} else if (ferror(F)) {
+  fwrite(0, 1, 10, F); // expected-warning {{Stream might be in indeterminate state}}
+} else {
+  fwrite(0, 1, 10, F); // expected-warning {{Stream might be in indeterminate state}}
+}
+  }
+  fclose(F);
+}
+
+void error_clearerr_indeterminate() {
+  FILE *F = fopen("file", "r");
+  if (!F)
+return;
+  int rc = fseek(F, 0, SEEK_SET);
+  if (rc) {
+if (!feof(F)) {
+  clearerr(F);
+  fwrite(0, 1, 10, F); // expected-warning {{Stream might be in indeterminate state}}
+}
+  }
+  fclose(F);
+}
Index: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -19,15 +19,64 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h"
+#include 
 
 using namespace clang;
 using namespace ento;
+using namespace std::placeholders;
 
 namespace {
 
 struct FnDescription;
 
+/// State of the stream related error flags.
+/// It indicates possibility of different error states.
+/// In other sense, every set flag means a separate execution path.
+/// At least one of the bool flags must be set to have a valid StreamErrorState.
+/// Note: A stream has either FEOF or FERROR set but not both at the same time.
+struct StreamErrorState {
+  /// There is an execution path with none of the error flags s

[PATCH] D78192: Support compiler extensions as a normal component

2020-04-23 Thread serge via Phabricator via cfe-commits
serge-sans-paille added a comment.

In D78192#1997698 , @Meinersbur wrote:

> Is this ready to try out?


It is!

> 
> 
> In D78192#1996859 , 
> @serge-sans-paille wrote:
> 
>> Note that this should solve in an elegant (?) way the multiple link errors 
>> found when linking clang with LLVM_DYLIB.
> 
> 
> Aren't these fixed already?

Indeed, but the fix is not generic (it made change to the polly Cmake code), 
and it's not compatible with Polly declaring component dependencies (see 
https://reviews.llvm.org/D78358).
Anyway, that's just a side effect of the cleanup, didn't want to emphazise too 
much on that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78192



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


[PATCH] D78192: Support compiler extensions as a normal component

2020-04-23 Thread serge via Phabricator via cfe-commits
serge-sans-paille updated this revision to Diff 259495.
serge-sans-paille added a comment.

Fix dependency order for extension libraries, as spotted by @Meinersbur


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

https://reviews.llvm.org/D78192

Files:
  clang/lib/CodeGen/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/lib/CMakeLists.txt
  llvm/lib/Extensions/CMakeLists.txt
  llvm/lib/Extensions/Extensions.cpp
  llvm/lib/Extensions/LLVMBuild.txt
  llvm/lib/LLVMBuild.txt
  llvm/lib/LTO/CMakeLists.txt
  llvm/lib/LTO/LLVMBuild.txt
  llvm/tools/bugpoint/CMakeLists.txt
  llvm/tools/llvm-config/llvm-config.cpp
  llvm/tools/opt/CMakeLists.txt

Index: llvm/tools/opt/CMakeLists.txt
===
--- llvm/tools/opt/CMakeLists.txt
+++ llvm/tools/opt/CMakeLists.txt
@@ -9,6 +9,7 @@
   CodeGen
   Core
   Coroutines
+  Extensions
   IPO
   IRReader
   InstCombine
@@ -33,8 +34,6 @@
   PrintSCC.cpp
   opt.cpp
 
-  ENABLE_PLUGINS
-
   DEPENDS
   intrinsics_gen
   SUPPORT_PLUGINS
Index: llvm/tools/llvm-config/llvm-config.cpp
===
--- llvm/tools/llvm-config/llvm-config.cpp
+++ llvm/tools/llvm-config/llvm-config.cpp
@@ -46,6 +46,10 @@
 // create entries for pseudo groups like x86 or all-targets.
 #include "LibraryDependencies.inc"
 
+// Built-in extensions also register their dependencies, but in a separate file,
+// later in the process.
+#include "ExtensionDependencies.inc"
+
 // LinkMode determines what libraries and flags are returned by llvm-config.
 enum LinkMode {
   // LinkModeAuto will link with the default link mode for the installation,
@@ -110,6 +114,25 @@
GetComponentLibraryPath, Missing, DirSep);
   }
 
+  // Special handling for the special 'extensions' component. Its content is
+  // not populated by llvm-build, but later in the process and loaded from
+  // ExtensionDependencies.inc.
+  if (Name == "extensions") {
+for (auto const &AvailableExtension : AvailableExtensions) {
+  for (const char *const *Iter = &AvailableExtension.RequiredLibraries[0];
+   *Iter; ++Iter) {
+AvailableComponent *AC = ComponentMap.lookup(*Iter);
+if (!AC) {
+  RequiredLibs.push_back(*Iter);
+} else {
+  VisitComponent(*Iter, ComponentMap, VisitedComponents, RequiredLibs,
+ IncludeNonInstalled, GetComponentNames,
+ GetComponentLibraryPath, Missing, DirSep);
+}
+  }
+}
+  }
+
   if (GetComponentNames) {
 RequiredLibs.push_back(Name);
 return;
Index: llvm/tools/bugpoint/CMakeLists.txt
===
--- llvm/tools/bugpoint/CMakeLists.txt
+++ llvm/tools/bugpoint/CMakeLists.txt
@@ -6,6 +6,7 @@
   Analysis
   BitWriter
   CodeGen
+  Extensions
   Core
   IPO
   IRReader
@@ -32,8 +33,6 @@
   ToolRunner.cpp
   bugpoint.cpp
 
-  ENABLE_PLUGINS
-
   DEPENDS
   intrinsics_gen
   SUPPORT_PLUGINS
Index: llvm/lib/LTO/LLVMBuild.txt
===
--- llvm/lib/LTO/LLVMBuild.txt
+++ llvm/lib/LTO/LLVMBuild.txt
@@ -26,6 +26,7 @@
  BitWriter
  CodeGen
  Core
+ Extensions
  IPO
  InstCombine
  Linker
Index: llvm/lib/LTO/CMakeLists.txt
===
--- llvm/lib/LTO/CMakeLists.txt
+++ llvm/lib/LTO/CMakeLists.txt
@@ -10,9 +10,6 @@
 
   ADDITIONAL_HEADER_DIRS
   ${LLVM_MAIN_INCLUDE_DIR}/llvm/LTO
-
-  ENABLE_PLUGINS
-
   DEPENDS
   intrinsics_gen
   llvm_vcsrevision_h
Index: llvm/lib/LLVMBuild.txt
===
--- llvm/lib/LLVMBuild.txt
+++ llvm/lib/LLVMBuild.txt
@@ -25,6 +25,7 @@
  Demangle
  DWARFLinker
  ExecutionEngine
+ Extensions
  Frontend
  FuzzMutate
  LineEditor
Index: llvm/lib/Extensions/LLVMBuild.txt
===
--- /dev/null
+++ llvm/lib/Extensions/LLVMBuild.txt
@@ -0,0 +1,21 @@
+;===- ./lib/Extensions/LLVMBuild.txt ---*- Conf -*--===;
+;
+; Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+; See https://llvm.org/LICENSE.txt for license information.
+; SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+;
+;======;
+;
+; This is an LLVMBuild description file for the components in this subdirectory.
+;
+; For more information on the LLVMBuild system, please see:
+;
+;   http://llvm.org/docs/LLVMBuild.html
+;
+;======;
+
+[component_0]
+type = Library
+name = Extensions
+parent = Libraries
+required_libraries =
Index: llvm/lib/Extensions/CMakeLists.txt
===
--- /dev/null
+++ llvm/lib/Extensions/CMakeLists.txt
@@ -0,0 +1,3 @@
+add

[clang-tools-extra] bbb7921 - [clang-tidy] Add option to use alpha checkers from clang-analyzer when using `run-clang-tidy.py`

2020-04-23 Thread Andi-Bogdan Postelnicu via cfe-commits

Author: Andi-Bogdan Postelnicu
Date: 2020-04-23T11:36:50+03:00
New Revision: bbb7921da97ce03d2933e185a525c4e452b146b0

URL: 
https://github.com/llvm/llvm-project/commit/bbb7921da97ce03d2933e185a525c4e452b146b0
DIFF: 
https://github.com/llvm/llvm-project/commit/bbb7921da97ce03d2933e185a525c4e452b146b0.diff

LOG: [clang-tidy] Add option to use alpha checkers from clang-analyzer when 
using `run-clang-tidy.py`

Summary: Add option to use alpha checkers from clang-analyzer when using 
`run-clang-tidy.py`.

Reviewers: JonasToth

Subscribers: xazax.hun, baloghadamsoftware, a.sidorin, Szelethus, donat.nagy, 
dkrupp, Charusso, ASDenysPetrov, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D77882

Added: 


Modified: 
clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
clang-tools-extra/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py 
b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
index 1eb135295754..1c4f3ad59ac8 100755
--- a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -78,10 +78,12 @@ def make_absolute(f, directory):
 
 
 def get_tidy_invocation(f, clang_tidy_binary, checks, tmpdir, build_path,
-header_filter, extra_arg, extra_arg_before, quiet,
-config):
+header_filter, allow_enabling_alpha_checkers,
+extra_arg, extra_arg_before, quiet, config):
   """Gets a command line for clang-tidy."""
   start = [clang_tidy_binary]
+  if allow_enabling_alpha_checkers is not None:
+start.append('-allow-enabling-analyzer-alpha-checkers')
   if header_filter is not None:
 start.append('-header-filter=' + header_filter)
   if checks:
@@ -159,6 +161,7 @@ def run_tidy(args, tmpdir, build_path, queue, lock, 
failed_files):
 name = queue.get()
 invocation = get_tidy_invocation(name, args.clang_tidy_binary, args.checks,
  tmpdir, build_path, args.header_filter,
+ args.allow_enabling_alpha_checkers,
  args.extra_arg, args.extra_arg_before,
  args.quiet, args.config)
 
@@ -179,6 +182,9 @@ def main():
'in a compilation database. Requires '
'clang-tidy and clang-apply-replacements in 
'
'$PATH.')
+  parser.add_argument('-allow-enabling-alpha-checkers',
+  action='store_true', help='allow alpha checkers from '
+'clang-analyzer.')
   parser.add_argument('-clang-tidy-binary', metavar='PATH',
   default='clang-tidy',
   help='path to clang-tidy binary')
@@ -238,6 +244,8 @@ def main():
 
   try:
 invocation = [args.clang_tidy_binary, '-list-checks']
+if args.allow_enabling_alpha_checkers:
+  invocation.append('-allow-enabling-analyzer-alpha-checkers')
 invocation.append('-p=' + build_path)
 if args.checks:
   invocation.append('-checks=' + args.checks)

diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index d3c3bb0520d1..011962ea1d05 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -188,6 +188,11 @@ Renamed checks
 - The 'fuchsia-restrict-system-headers' check was renamed to 
:doc:`portability-restrict-system-includes
   `
 
+Other improvements
+^^
+
+- For 'run-clang-tidy.py' add option to use alpha checkers from clang-analyzer.
+
 Improvements to include-fixer
 -
 
@@ -210,4 +215,3 @@ The improvements are...
 
 Clang-tidy visual studio plugin
 ---
-



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


[PATCH] D77882: [clang-tidy] Add option to use alpha checkers from clang-analyzer when using `run-clang-tidy.py`

2020-04-23 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbbb7921da97c: [clang-tidy] Add option to use alpha checkers 
from clang-analyzer when using… (authored by Andi-Bogdan Postelnicu 
).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77882

Files:
  clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  clang-tools-extra/docs/ReleaseNotes.rst


Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -188,6 +188,11 @@
 - The 'fuchsia-restrict-system-headers' check was renamed to 
:doc:`portability-restrict-system-includes
   `
 
+Other improvements
+^^
+
+- For 'run-clang-tidy.py' add option to use alpha checkers from clang-analyzer.
+
 Improvements to include-fixer
 -
 
@@ -210,4 +215,3 @@
 
 Clang-tidy visual studio plugin
 ---
-
Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -78,10 +78,12 @@
 
 
 def get_tidy_invocation(f, clang_tidy_binary, checks, tmpdir, build_path,
-header_filter, extra_arg, extra_arg_before, quiet,
-config):
+header_filter, allow_enabling_alpha_checkers,
+extra_arg, extra_arg_before, quiet, config):
   """Gets a command line for clang-tidy."""
   start = [clang_tidy_binary]
+  if allow_enabling_alpha_checkers is not None:
+start.append('-allow-enabling-analyzer-alpha-checkers')
   if header_filter is not None:
 start.append('-header-filter=' + header_filter)
   if checks:
@@ -159,6 +161,7 @@
 name = queue.get()
 invocation = get_tidy_invocation(name, args.clang_tidy_binary, args.checks,
  tmpdir, build_path, args.header_filter,
+ args.allow_enabling_alpha_checkers,
  args.extra_arg, args.extra_arg_before,
  args.quiet, args.config)
 
@@ -179,6 +182,9 @@
'in a compilation database. Requires '
'clang-tidy and clang-apply-replacements in 
'
'$PATH.')
+  parser.add_argument('-allow-enabling-alpha-checkers',
+  action='store_true', help='allow alpha checkers from '
+'clang-analyzer.')
   parser.add_argument('-clang-tidy-binary', metavar='PATH',
   default='clang-tidy',
   help='path to clang-tidy binary')
@@ -238,6 +244,8 @@
 
   try:
 invocation = [args.clang_tidy_binary, '-list-checks']
+if args.allow_enabling_alpha_checkers:
+  invocation.append('-allow-enabling-analyzer-alpha-checkers')
 invocation.append('-p=' + build_path)
 if args.checks:
   invocation.append('-checks=' + args.checks)


Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -188,6 +188,11 @@
 - The 'fuchsia-restrict-system-headers' check was renamed to :doc:`portability-restrict-system-includes
   `
 
+Other improvements
+^^
+
+- For 'run-clang-tidy.py' add option to use alpha checkers from clang-analyzer.
+
 Improvements to include-fixer
 -
 
@@ -210,4 +215,3 @@
 
 Clang-tidy visual studio plugin
 ---
-
Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -78,10 +78,12 @@
 
 
 def get_tidy_invocation(f, clang_tidy_binary, checks, tmpdir, build_path,
-header_filter, extra_arg, extra_arg_before, quiet,
-config):
+header_filter, allow_enabling_alpha_checkers,
+extra_arg, extra_arg_before, quiet, config):
   """Gets a command line for clang-tidy."""
   start = [clang_tidy_binary]
+  if allow_enabling_alpha_checkers is not None:
+start.append('-allow-enabling-analyzer-alpha-checkers')
   if header_filter is not None:
 start.append('-header-filter=' + header_filter)
   if checks:
@@ -159,6 +161,7 @@
 name = queue.get()
 invocation = get_tidy_invocation(name, args.clang_tidy_binary, args.checks,
  tmpdir, build_path, args.header_filte

[PATCH] D76996: [analyzer] Improve PlacementNewChecker

2020-04-23 Thread Karasev Nikita via Phabricator via cfe-commits
f00kat updated this revision to Diff 259499.
f00kat added a comment.

1. Rewroted ElementRegion processing and fixed tests for this cases.
2. Simplified the code a bit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76996

Files:
  clang/lib/StaticAnalyzer/Checkers/CheckPlacementNew.cpp
  clang/test/Analysis/placement-new.cpp

Index: clang/test/Analysis/placement-new.cpp
===
--- clang/test/Analysis/placement-new.cpp
+++ clang/test/Analysis/placement-new.cpp
@@ -155,3 +155,309 @@
   (void)dp;
 }
 } // namespace testHierarchy
+
+namespace testArrayTypesAllocation {
+void f1() {
+  struct S {
+short a;
+  };
+
+  // bad (not enough space).
+  const unsigned N = 32;
+  alignas(S) unsigned char buffer1[sizeof(S) * N]; // expected-note {{'buffer1' initialized here}}
+  ::new (buffer1) S[N];// expected-warning{{Storage provided to placement new is only 64 bytes, whereas the allocated array type requires more space for internal needs}} expected-note 1 {{}}
+}
+
+void f2() {
+  struct S {
+short a;
+  };
+
+  // maybe ok but we need to warn.
+  const unsigned N = 32;
+  alignas(S) unsigned char buffer2[sizeof(S) * N + sizeof(int)]; // expected-note {{'buffer2' initialized here}}
+  ::new (buffer2) S[N];  // expected-warning{{68 bytes is possibly not enough for array allocation which requires 64 bytes. Current overhead requires the size of 4 bytes}} expected-note 1 {{}}
+}
+} // namespace testArrayTypesAllocation
+
+namespace testStructAlign {
+void f1() {
+  struct X {
+char a[9];
+  } Xi; // expected-note {{'Xi' initialized here}}
+
+  // bad (struct X is aligned to char).
+  ::new (&Xi.a) long; // expected-warning{{Storage type is aligned to 1 bytes but allocated type is aligned to 8 bytes}} expected-note 1 {{}}
+}
+
+void f2() {
+  struct X {
+char a;
+char b;
+long c;
+  } Xi;
+
+  // ok (struct X is aligned to long).
+  ::new (&Xi.a) long;
+}
+
+void f3() {
+  struct X {
+char a;
+char b;
+long c;
+  } Xi; // expected-note {{'Xi' initialized here}}
+
+  // bad (struct X is aligned to long but field 'b' is aligned to 1 because of its offset)
+  ::new (&Xi.b) long; // expected-warning{{Storage type is aligned to 1 bytes but allocated type is aligned to 8 bytes}} expected-note 1 {{}}
+}
+
+void f4() {
+  struct X {
+char a;
+struct alignas(alignof(short)) Y {
+  char b;
+  char c;
+} y;
+long d;
+  } Xi; // expected-note {{'Xi' initialized here}}
+
+  // bad. 'b' is aligned to short
+  ::new (&Xi.y.b) long; // expected-warning{{Storage type is aligned to 2 bytes but allocated type is aligned to 8 bytes}} expected-note 1 {{}}
+}
+
+void f5() {
+  short b[10]; // expected-note {{'b' initialized here}}
+
+  ::new (&b) long; // expected-warning{{Storage type is aligned to 2 bytes but allocated type is aligned to 8 bytes}} expected-note 1 {{}}
+}
+
+void f6() {
+  short b[10]; // expected-note {{'b' initialized here}}
+
+  // bad (same as previous but checks ElementRegion case)
+  ::new (&b[0]) long; // expected-warning{{Storage type is aligned to 2 bytes but allocated type is aligned to 8 bytes}} expected-note 1 {{}}
+}
+
+void f7() {
+  alignas(alignof(long)) short b[10];
+
+  // ok. aligned to long(ok). offset 4*2(ok)
+  ::new (&b[4]) long;
+}
+
+void f8() {
+  alignas(alignof(long)) short b[10]; // expected-note {{'b' initialized here}}
+
+  // ok. aligned to long(ok). offset 3*2(ok)
+  ::new (&b[3]) long; // expected-warning{{Storage type is aligned to 6 bytes but allocated type is aligned to 8 bytes}} expected-note 1 {{}}
+}
+
+void f9() {
+  struct X {
+char a;
+alignas(alignof(long)) char b[20];
+  } Xi; // expected-note {{'Xi' initialized here}}
+
+  // ok. aligned to long(ok). offset 8*1(ok)
+  ::new (&Xi.b[8]) long;
+
+  // bad. aligned to long(ok). offset 1*1(ok)
+  ::new (&Xi.b[1]) long; // expected-warning{{Storage type is aligned to 1 bytes but allocated type is aligned to 8 bytes}} expected-note 1 {{}}
+}
+
+void f10() {
+  struct X {
+char a[8];
+alignas(2) char b;
+  } Xi; // expected-note {{'Xi' initialized here}}
+
+  // bad (struct X is aligned to 2).
+  ::new (&Xi.a) long; // expected-warning{{Storage type is aligned to 2 bytes but allocated type is aligned to 8 bytes}} expected-note 1 {{}}
+}
+
+void f11() {
+  struct X {
+char a;
+char b;
+struct Y {
+  long c;
+} d;
+  } Xi;
+
+  // ok (struct X is aligned to long).
+  ::new (&Xi.a) long;
+}
+
+void f12() {
+  struct alignas(alignof(long)) X {
+char a;
+char b;
+  } Xi;
+
+  // ok (struct X is aligned to long).
+  ::new (&Xi.a) long;
+}
+
+void test13() {
+  struct Y {
+char a[10];
+  };
+
+  struct X {
+Y b[10];
+  } Xi; // expected-note {{'Xi' initialized here}}
+
+  // bad. X,A are aligned to 'char'
+  ::new (&Xi.b[0

[PATCH] D77871: [AArch64] Armv8.6-a Matrix Mult Assembly + Intrinsics

2020-04-23 Thread Kerry McLaughlin via Phabricator via cfe-commits
kmclaughlin accepted this revision.
kmclaughlin added a comment.
This revision is now accepted and ready to land.

Thanks for the updates, @LukeGeeson, LGTM


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

https://reviews.llvm.org/D77871



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


[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-04-23 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware marked an inline comment as done.
baloghadamsoftware added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1044
 
+class ParamWithoutVarRegion : public TypedValueRegion {
+  friend class MemRegionManager;

baloghadamsoftware wrote:
> baloghadamsoftware wrote:
> > NoQ wrote:
> > > There should be only one way to express the parameter region. Let's call 
> > > this one simply `ParamRegion` or something like that, and 
> > > `assert(!isa(D))` in the constructor of `VarRegion`.
> > Do you mean that we should use `ParamRegion` in every case, thus also when 
> > we have the definitioan for the function? I wonder whether it breaks too 
> > many things.
> This will surely not work. The common handling of `ParamVarDecl` and 
> `VarDecl` is soo deeply rooted in the whole analyzer that separating them 
> means creation of a totally new analyzer engine from scratch.
More specifically: whenever a function is inlined, its parameters are used as 
variables via `DeclRefExpr`s. A `DeclRefExpr` refers to a `Decl` which is a 
`ParamVarDecl` but that has reference neither for the `CallExpr` (since it is 
not related to the call, but to the `FunctionDecl` or `ObjCMethodDecl`) nore 
for its `Index` in the call. The former is the real problem that cannot be 
solved even on theoretical level: a function which is inlined cannot depend on 
the different `CallExpr`s where it is called. Even worse, if the function is 
analyzed top-level it has not `CallExpr` at all so using `ParamRegion` for its 
parameters is completely impossible.


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

https://reviews.llvm.org/D77229



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


[clang] 0021644 - [SveEmitter] Add builtins for FP conversions

2020-04-23 Thread Sander de Smalen via cfe-commits

Author: Sander de Smalen
Date: 2020-04-23T10:49:06+01:00
New Revision: 002164461b52e0ff13fa677a535991f89da0f633

URL: 
https://github.com/llvm/llvm-project/commit/002164461b52e0ff13fa677a535991f89da0f633
DIFF: 
https://github.com/llvm/llvm-project/commit/002164461b52e0ff13fa677a535991f89da0f633.diff

LOG: [SveEmitter] Add builtins for FP conversions

This adds the flag IsOverloadCvt which tells CGBulitin to use
the result type and the type of the last operand as the
overloaded types for the LLVM IR intrinsic.

This also adds the flag IsFPConvert, which is needed to avoid
converting the predicate of the operation from svbool_t to
a predicate with fewer lanes, as the LLVM IR intrinsics use
the  as the predicate.

Reviewers: SjoerdMeijer, efriedma

Reviewed By: efriedma

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78239

Added: 
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cvt.c
clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtlt.c
clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtnt.c
clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtx.c
clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtxnt.c

Modified: 
clang/include/clang/Basic/TargetBuiltins.h
clang/include/clang/Basic/arm_sve.td
clang/lib/CodeGen/CGBuiltin.cpp
clang/utils/TableGen/SveEmitter.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/TargetBuiltins.h 
b/clang/include/clang/Basic/TargetBuiltins.h
index 661691e3d2a5..bfc50535fce4 100644
--- a/clang/include/clang/Basic/TargetBuiltins.h
+++ b/clang/include/clang/Basic/TargetBuiltins.h
@@ -237,6 +237,8 @@ namespace clang {
 bool isOverloadWhile() const { return Flags & IsOverloadWhile; }
 bool isOverloadDefault() const { return !(Flags & OverloadKindMask); }
 bool isOverloadWhileRW() const { return Flags & IsOverloadWhileRW; }
+bool isOverloadCvt() const { return Flags & IsOverloadCvt; }
+bool isFPConvert() const { return Flags & IsFPConvert; }
 
 uint64_t getBits() const { return Flags; }
 bool isFlagSet(uint64_t Flag) const { return Flags & Flag; }

diff  --git a/clang/include/clang/Basic/arm_sve.td 
b/clang/include/clang/Basic/arm_sve.td
index 1feeeba6d780..517be0544c94 100644
--- a/clang/include/clang/Basic/arm_sve.td
+++ b/clang/include/clang/Basic/arm_sve.td
@@ -170,10 +170,10 @@ def IsZExtReturn  : FlagType<0x0008>; // 
Return value is sign-ex
 def IsOverloadNone: FlagType<0x0010>; // Intrinsic does not 
take any overloaded types.
 def IsOverloadWhile   : FlagType<0x0020>; // Use {default type, 
typeof(operand1)} as overloaded types.
 def IsOverloadWhileRW : FlagType<0x0040>; // Use {pred(default 
type), typeof(operand0)} as overloaded types.
+def IsOverloadCvt : FlagType<0x0080>; // Use 
{typeof(operand0), typeof(last operand)} as overloaded types.
 def OverloadKindMask  : FlagType<0x00E0>; // When the masked 
values are all '0', the default type is used as overload type.
-//  : :
-//  : :
-def IsByteIndexed : FlagType<0x0200>;
+def IsByteIndexed : FlagType<0x0100>;
+def IsFPConvert   : FlagType<0x0200>;
 
 // These must be kept in sync with the flags in 
include/clang/Basic/TargetBuiltins.h
 class ImmCheckType {
@@ -553,6 +553,102 @@ def SVTMAD  : SInst<"svtmad[_{d}]",  "dddi", "hfd", 
MergeNone, "aarch64_sve_ftma
 def SVMLA_LANE  : SInst<"svmla_lane[_{d}]",  "i",  "hfd", MergeNone, 
"aarch64_sve_fmla_lane", [], [ImmCheck<3, ImmCheckLaneIndex, 2>]>;
 def SVCMLA_LANE : SInst<"svcmla_lane[_{d}]", "ii", "hf",  MergeNone, 
"aarch64_sve_fcmla_lane", [], [ImmCheck<3, ImmCheckLaneIndexCompRotate, 2>,

 ImmCheck<4, ImmCheckComplexRotAll90>]>;
+
+// Floating-point conversions
+
+multiclass SInstCvtMXZ<
+string name, string m_types, string xz_types, string types,
+string intrinsic, list flags = [IsFPConvert, IsOverloadNone]> {
+  def _M : SInst;
+  def _X : SInst;
+  def _Z : SInst;
+}
+
+multiclass SInstCvtMX flags = [IsFPConvert, IsOverloadNone]> {
+  def _M : SInst;
+  def _X : SInst;
+}
+
+// svcvt_s##_f16
+defm SVFCVTZS_S16_F16 : SInstCvtMXZ<"svcvt_s16[_f16]", "ddPO", "dPO", "s",  
"aarch64_sve_fcvtzs", [IsOverloadCvt]>;
+defm SVFCVTZS_S32_F16 : SInstCvtMXZ<"svcvt_s32[_f16]", "ddPO", "dPO", "i",  
"aarch64_sve_fcvtzs_i32f16">;
+defm SVFCVTZS_S64_F16 : SInstCvtMXZ<"svcvt_s64[_f16]", "ddPO", "dPO", "l",  
"aarch64_sve_fcvtzs_i64f16">;
+
+// svcvt_s##_f32
+defm SVFCVTZS_S32_F32 : SInstCvtMXZ<"svcvt_s32[_f32]", "ddPM", "dPM", "i",  
"aarch64_sve_fcvtzs", [IsOverloadCvt]>;
+defm SVFCVTZS_S64_F32

[PATCH] D75665: [analyzer] On-demand parsing capability for CTU

2020-04-23 Thread Whisperity via Phabricator via cfe-commits
whisperity added inline comments.



Comment at: clang/docs/analyzer/user-docs/CrossTranslationUnit.rst:391
+Currently On-demand analysis is not supported with `scan-build-py`.
\ No newline at end of file


What's this line? Is this added by Phab, or is this a weird merge conflict / 
parsing error of the patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75665



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


[PATCH] D78642: [clang-format] Handle C# property accessors when parsing lines

2020-04-23 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir accepted this revision.
krasimir added a comment.
This revision is now accepted and ready to land.

Thank you!


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

https://reviews.llvm.org/D78642



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


[PATCH] D78239: [SveEmitter] Add builtins for FP conversions

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG002164461b52: [SveEmitter] Add builtins for FP conversions 
(authored by sdesmalen).

Changed prior to commit:
  https://reviews.llvm.org/D78239?vs=258426&id=259504#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78239

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cvt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtlt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtnt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtx.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtxnt.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -564,6 +564,21 @@
 ElementBitwidth = Bitwidth = 64;
 NumVectors = 0;
 break;
+  case 'O':
+Predicate = false;
+Float = true;
+ElementBitwidth = 16;
+break;
+  case 'M':
+Predicate = false;
+Float = true;
+ElementBitwidth = 32;
+break;
+  case 'N':
+Predicate = false;
+Float = true;
+ElementBitwidth = 64;
+break;
   case 'S':
 Constant = true;
 Pointer = true;
@@ -1020,6 +1035,17 @@
   if (!InGuard.empty())
 OS << "#endif  //" << InGuard << "\n";
 
+  OS << "#if defined(__ARM_FEATURE_SVE2)\n";
+  OS << "#define svcvtnt_f16_x  svcvtnt_f16_m\n";
+  OS << "#define svcvtnt_f16_f32_x  svcvtnt_f16_f32_m\n";
+  OS << "#define svcvtnt_f32_x  svcvtnt_f32_m\n";
+  OS << "#define svcvtnt_f32_f64_x  svcvtnt_f32_f64_m\n\n";
+
+  OS << "#define svcvtxnt_f32_x svcvtxnt_f32_m\n";
+  OS << "#define svcvtxnt_f32_f64_x svcvtxnt_f32_f64_m\n\n";
+
+  OS << "#endif /*__ARM_FEATURE_SVE2 */\n\n";
+
   OS << "#ifdef __cplusplus\n";
   OS << "} // extern \"C\"\n";
   OS << "#endif\n\n";
Index: clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtxnt.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtxnt.c
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE2 -triple aarch64-none-linux-gnu -target-feature +sve2 -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE2 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve2 -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify -verify-ignore-unexpected=error %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify=overload -verify-ignore-unexpected=error %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1,A2,A3,A4) A1##A2##A3##A4
+#endif
+
+svfloat32_t test_svcvtxnt_f32_f64_m(svfloat32_t inactive, svbool_t pg, svfloat64_t op)
+{
+  // CHECK-LABEL: test_svcvtxnt_f32_f64_m
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.fcvtxnt.f32f64( %inactive,  %pg,  %op)
+  // CHECK: ret  %[[INTRINSIC]]
+  // overload-warning@+2 {{implicit declaration of function 'svcvtxnt_f32_m'}}
+  // expected-warning@+1 {{implicit declaration of function 'svcvtxnt_f32_f64_m'}}
+  return SVE_ACLE_FUNC(svcvtxnt_f32,_f64,_m,)(inactive, pg, op);
+}
+
+svfloat32_t test_svcvtxnt_f32_f64_x(svfloat32_t even, svbool_t pg, svfloat64_t op)
+{
+  // CHECK-LABEL: test_svcvtxnt_f32_f64_x
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.fcvtxnt.f32f64( %even,  %pg,  %op)
+  // CHECK: ret  %[[INTRINSIC]]
+  // overload-warning@+2 {{implicit declaration of function 'svcvtxnt_f32_x'}}
+  // expected-warning@+1 {{implicit declaration of function 'svcvtxnt_f32_f64_x'}}
+  return SVE_ACLE_FUNC(svcvtxnt_f32,_f64,_x,)(even, pg, op);
+}
Index: clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtx.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtx.c
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE2 -triple aarch64-none-linux-gnu -target-feature +sve2 -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE2 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve2 -fallo

[PATCH] D78569: [SVE][CodeGen] Lower SDIV & UDIV to SVE intrinsics

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:7670
+ Mask, Op.getOperand(0), Op.getOperand(1));
+}
+

efriedma wrote:
> sdesmalen wrote:
> > efriedma wrote:
> > > If we're going to support these operations, we might as well just add 
> > > isel patterns; that's what we've been doing for other arithmetic 
> > > operations.
> > Just to provide a bit of context to this approach:
> > 
> > For unpredicated ISD nodes for which there is no predicated instruction, 
> > the predicate needs to be generated. For scalable vectors this will be a 
> > `ptrue all`, but for fixed-width vectors may take some other predicate such 
> > as VL8 for fixed `8` elements.
> > 
> > Rather than creating new predicated AArch64 ISD nodes for each operation 
> > such as `AArch64ISD::UDIV_PRED`, the idea is to reuse the intrinsic layer 
> > we already added to support the ACLE - which are predicated and for which 
> > we already have the patterns - and map directly onto those.
> > 
> > By doing the expansion in ISelLowering, the patterns stay simple and we can 
> > generalise `getPtrue` method so that it generates the right predicate for 
> > any scalable/fixed vector size as done in D71760 avoiding the need to write 
> > multiple patterns for different vector lengths.
> > 
> > This patch was meant as the proof of concept of that idea (as discussed in 
> > the sync-up call of Apr 2). 
> Using INTRINSIC_WO_CHAIN is a little annoying; it's hard to read in DAG 
> dumps, and it gives weird error messages if we fail in selection.  But there 
> aren't really any other immediate downsides I can think of, vs. doing it the 
> other way (converting the intrinsic to AArch64ISD::UDIV_PRED).
> 
> Long-term, we're going to have a target-independent ISD::UDIV_PRED.  We 
> probably want to start using those nodes at some point, to get 
> target-independent optimizations. Not sure if that impacts what we want to do 
> right now.
I agree that using INTRINSIC_WO_CHAIN will be a bit annoying for more 
complicated patterns. The reuse of the intrinsics was merely for convenience 
because we already have the patterns, and was not a critical part of the 
design. It shouldn't be a big effort to create AArch64ISD nodes and use these 
for the intrinsics as well.

If we use AArch64-specific nodes we can implement what's needed now for SVE 
codegen and I expect we can easily migrate to target-independent nodes when 
they get added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78569



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


[PATCH] D20689: [clang-tidy] Add 'readability-suspicious-call-argument' check

2020-04-23 Thread Whisperity via Phabricator via cfe-commits
whisperity updated this revision to Diff 259508.
whisperity retitled this revision from "[clang-tidy] Suspicious Call Argument 
checker" to "[clang-tidy] Add 'readability-suspicious-call-argument' check".
whisperity edited the summary of this revision.
whisperity removed reviewers: varjujan, barancsuk.
whisperity set the repository for this revision to rG LLVM Github Monorepo.
whisperity edited subscribers, added: varjujan, zporky; removed: gsd.
whisperity added a comment.
Herald added a project: clang.

First things first, we were 50 thousand (!) patches behind reality. Rebased to 
`master`. Fixed it to compile, too. Otherwise, NFC so far.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D20689

Files:
  clang-tools-extra/clang-tidy/readability/CMakeLists.txt
  clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
  clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp
  clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-suspicious-call-argument.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-suspicious-call-argument.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-suspicious-call-argument.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-suspicious-call-argument.cpp
@@ -0,0 +1,392 @@
+// RUN: %check_clang_tidy %s readability-suspicious-call-argument %t -- -- -std=c++11
+
+void foo_1(int aa, int bb) {}
+
+void foo_2(int source, int aa) {}
+
+void foo_3(int valToRet, int aa) {}
+
+void foo_4(int pointer, int aa) {}
+
+void foo_5(int aa, int bb, int cc, ...) {}
+
+void foo_6(const int dd, bool &ee) {}
+
+void foo_7(int aa, int bb, int cc, int ff = 7) {}
+
+// Test functions for convertible argument--parameter types.
+void fun(const int &m);
+void fun2() {
+  int m = 3;
+  fun(m);
+}
+
+// Test cases for parameters of const reference and value.
+void value_const_reference(int ll, const int &kk);
+
+void const_ref_value_swapped() {
+  const int &kk = 42;
+  const int &ll = 42;
+  value_const_reference(kk, ll);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: kk (ll) is swapped with ll (kk). [readability-suspicious-call-argument]
+}
+
+// Const, non const references.
+void const_nonconst_parameters(const int &mm, int &nn);
+
+void const_nonconst_swap1() {
+  const int &nn = 42;
+  int mm;
+  // Do not check, because non-const reference parameter cannot bind to const reference argument.
+  const_nonconst_parameters(nn, mm);
+}
+
+void const_nonconst_swap3() {
+  const int nn = 42;
+  int m = 42;
+  int &mm = m;
+  // Do not check, const int does not bind to non const reference.
+  const_nonconst_parameters(nn, mm);
+}
+
+void const_nonconst_swap2() {
+  int nn;
+  int mm;
+  // Check for swapped arguments. (Both arguments are non-const.)
+  const_nonconst_parameters(
+  nn,
+  mm);
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: nn (mm) is swapped with mm (nn). [readability-suspicious-call-argument]
+}
+
+void const_nonconst_pointers(const int *mm, int *nn);
+void const_nonconst_pointers2(const int *mm, const int *nn);
+
+void const_nonconst_pointers_swapped() {
+  int *mm;
+  const int *nn;
+  const_nonconst_pointers(nn, mm);
+}
+
+void const_nonconst_pointers_swapped2() {
+  const int *mm;
+  int *nn;
+  const_nonconst_pointers2(nn, mm);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: nn (mm) is swapped with mm (nn). [readability-suspicious-call-argument]
+}
+
+// Test cases for pointers and arrays.
+void pointer_array_parameters(
+int *pp, int qq[4]);
+
+void pointer_array_swap() {
+  int qq[5];
+  int *pp;
+  // Check for swapped arguments. An array implicitly converts to a pointer.
+  pointer_array_parameters(qq, pp);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: qq (pp) is swapped with pp (qq). [readability-suspicious-call-argument]
+}
+
+// Test cases for multilevel pointers.
+void multilevel_pointer_parameters(int *const **pp,
+   const int *const *volatile const *qq);
+void multilevel_pointer_parameters2(
+char *nn, char *volatile *const *const *const *const &mm);
+
+typedef float T;
+typedef T *S;
+typedef S *const volatile R;
+typedef R *Q;
+typedef Q *P;
+typedef P *O;
+void multilevel_pointer_parameters3(float **const volatile ***rr, O &ss);
+
+void multilevel_pointer_swap() {
+  int *const **qq;
+  int *const **pp;
+  multilevel_pointer_parameters

[PATCH] D20689: [clang-tidy] Add 'readability-suspicious-call-argument' check

2020-04-23 Thread Whisperity via Phabricator via cfe-commits
whisperity commandeered this revision.
whisperity added a reviewer: barancsuk.
whisperity added a comment.
Herald added subscribers: martong, Charusso, gamesh411, Szelethus.

Assuming direct control. Previous colleagues and university mates departed for 
snowier pastures, time to try to do something with this check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D20689



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


[PATCH] D78694: [clang-format] Fix lambda with ellipsis in return type

2020-04-23 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added a comment.

Could you please update the patch with full context: 
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
This helps out when reviewing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78694



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


[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-23 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 259513.
balazske marked 5 inline comments as done.
balazske added a comment.

Updated tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809

Files:
  clang/lib/Analysis/CFG.cpp
  clang/test/Analysis/cfg.cpp

Index: clang/test/Analysis/cfg.cpp
===
--- clang/test/Analysis/cfg.cpp
+++ clang/test/Analysis/cfg.cpp
@@ -568,6 +568,102 @@
   return 2;
 }
 
+// CHECK-LABEL: void vla_simple(int x)
+// CHECK: [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: int vla[x];
+void vla_simple(int x) {
+  int vla[x];
+}
+
+// CHECK-LABEL: void vla_typedef(int x)
+// CHECK: [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: typedef int VLA[x];
+void vla_typedef(int x) {
+  typedef int VLA[x];
+}
+
+// CHECK-LABEL: void vla_typealias(int x)
+// CHECK: [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: using VLA = int [x];
+void vla_typealias(int x) {
+  using VLA = int[x];
+}
+
+// CHECK-LABEL: void vla_typedef_multi(int x, int y)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: y
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: x
+// CHECK-NEXT:   4: [B1.3] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   5: typedef int VLA[x][y];
+void vla_typedef_multi(int x, int y) {
+  typedef int VLA[x][y];
+}
+
+// CHECK-LABEL: void vla_typedefname_multi(int x, int y)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: typedef int VLA[x];
+// CHECK-NEXT:   4: y
+// CHECK-NEXT:   5: [B1.4] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   6: typedef VLA VLA1[y];
+// CHECK-NEXT:   7: 3
+// CHECK-NEXT:   8: using VLA2 = VLA1 [3];
+// CHECK-NEXT:   9: 4
+// CHECK-NEXT:  10: VLA2 vla[4];
+void vla_typedefname_multi(int x, int y) {
+  typedef int VLA[x];
+  typedef VLA VLA1[y];
+  using VLA2 = VLA1[3];
+  VLA2 vla[4];
+}
+
+// CHECK-LABEL: void vla_embedded(int x)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: void (*vla)(int *);
+void vla_embedded(int x) {
+  // FIXME: 'x' is not generated but should be.
+  void (*vla)(int[x]);
+}
+
+// CHECK-LABEL: int vla_evaluate(int x)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: ++[B1.1]
+// CHECK-NEXT:   3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   4: typedef int VLA[++x];
+// CHECK-NEXT:   5: x
+// CHECK-NEXT:   6: ++[B1.5]
+// CHECK-NEXT:   7: [B1.6] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   8: sizeof(int [++x])
+// CHECK-NEXT:   9: x
+// CHECK-NEXT:  10: ++[B1.9]
+// CHECK-NEXT:  11: [B1.10] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:  12: alignof(int [++x])
+// CHECK-NEXT:  13: 0
+// CHECK-NEXT:  14: x
+// CHECK-NEXT:  15: [B1.14] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:  16: return [B1.15];
+int vla_evaluate(int x) {
+  // Evaluates the ++x
+  typedef int VLA[++x];
+  sizeof(int[++x]);
+
+  // Do not evaluate the ++x
+  // FIXME: Still evaluates for _Alignof
+  _Alignof(int[++x]);
+  _Generic((int(*)[++x])0, default : 0);
+
+  return x;
+}
+
 // CHECK-LABEL: template<> int *PR18472()
 // CHECK: [B2 (ENTRY)]
 // CHECK-NEXT:   Succs (1): B1
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -2839,11 +2839,30 @@
 /// DeclStmts and initializers in them.
 CFGBlock *CFGBuilder::VisitDeclSubExpr(DeclStmt *DS) {
   assert(DS->isSingleDecl() && "Can handle single declarations only.");
+
+  if (const auto *TND = dyn_cast(DS->getSingleDecl())) {
+// If we encounter a VLA, process its size expressions.
+const Type *T = TND->getUnderlyingType().getTypePtr();
+if (!T->isVariablyModifiedType())
+  return Block;
+
+autoCreateBlock();
+appendStmt(Block, DS);
+
+CFGBlock *LastBlock = Block;
+for (const VariableArrayType *VA = FindVA(T); VA != nullptr;
+ VA = FindVA(VA->getElementType().getTypePtr())) {
+  if (CFGBlock *newBlock = addStmt(VA->getSizeExpr()))
+LastBlock = newBlock;
+}
+return LastBlock;
+  }
+
   VarDecl *VD = dyn_cast(DS->getSingleDecl());
 
   if (!VD) {
-// Of everything that can be declared in a DeclStmt, only VarDecls impact
-// runtime semantics.
+// Of everything that can be declared in a DeclStmt, only VarDecls and the
+// exceptions above impact runtime semantics.
 return Block;
   }
 
@@ -2905,6 +2924,8 @@
   }
 
   // If the type of VD is a VLA, then we must process its size expressions.
+  // FIXME: This does not find the VLA if it is embedded in other types,
+  // like here: `void (*vla)(int[x]);`
   for (const Vari

[PATCH] D78350: [AST] Build recovery expressions by default for C++.

2020-04-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 259514.
hokein added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78350

Files:
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_namespace_1.cpp
  clang/test/CXX/class.access/p4.cpp
  clang/test/CXX/special/class.ctor/p5-0x.cpp
  clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
  clang/test/OpenMP/target_update_from_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp
  clang/test/Parser/objcxx0x-lambda-expressions.mm
  clang/test/Parser/objcxx11-invalid-lambda.cpp
  clang/test/SemaCXX/cast-conversion.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/constructor-initializer.cpp
  clang/test/SemaCXX/cxx0x-deleted-default-ctor.cpp
  clang/test/SemaCXX/cxx1z-copy-omission.cpp
  clang/test/SemaCXX/decltype-crash.cpp
  clang/test/SemaCXX/for-range-dereference.cpp
  clang/test/SemaCXX/varargs.cpp
  clang/test/SemaCXX/virtual-base-used.cpp
  clang/test/SemaObjCXX/arc-0x.mm
  clang/test/SemaOpenCLCXX/address-space-references.cl
  clang/test/SemaTemplate/instantiate-init.cpp

Index: clang/test/SemaTemplate/instantiate-init.cpp
===
--- clang/test/SemaTemplate/instantiate-init.cpp
+++ clang/test/SemaTemplate/instantiate-init.cpp
@@ -108,7 +108,7 @@
 integral_c<1> ic1 = array_lengthof(Description::data);
 (void)sizeof(array_lengthof(Description::data));
 
-sizeof(array_lengthof( // expected-error{{no matching function for call to 'array_lengthof'}}
+(void)sizeof(array_lengthof( // expected-error{{no matching function for call to 'array_lengthof'}}
   Description::data // expected-note{{in instantiation of static data member 'PR7985::Description::data' requested here}}
   ));
 
Index: clang/test/SemaOpenCLCXX/address-space-references.cl
===
--- clang/test/SemaOpenCLCXX/address-space-references.cl
+++ clang/test/SemaOpenCLCXX/address-space-references.cl
@@ -11,7 +11,7 @@
 int bar(const unsigned int &i);
 
 void foo() {
-  bar(1) // expected-error{{binding reference of type 'const __global unsigned int' to value of type 'int' changes address space}}
+  bar(1); // expected-error{{binding reference of type 'const __global unsigned int' to value of type 'int' changes address space}}
 }
 
 // Test addr space conversion with nested pointers
Index: clang/test/SemaObjCXX/arc-0x.mm
===
--- clang/test/SemaObjCXX/arc-0x.mm
+++ clang/test/SemaObjCXX/arc-0x.mm
@@ -116,13 +116,13 @@
   // Implicitly-declared special functions of a union are deleted by default if
   // ARC is enabled and the union has an ObjC pointer field.
   union U0 {
-id f0; // expected-note 7 {{'U0' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+id f0; // expected-note 6 {{'U0' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
   };
 
   union U1 {
-__weak id f0; // expected-note 13 {{'U1' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+__weak id f0; // expected-note 12 {{'U1' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
 U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
-~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note 2{{explicitly defaulted function was implicitly deleted here}}
+~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
 U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
 U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}}
 U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
@@ -154,15 +154,15 @@
   // functions of the containing class.
   struct S0 {
 union {
-  id f0; // expected-note 7 {{'' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+  id f0; // expected-note 6 {{'' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
   char f1;
 };
   };
 
   struct S1 {
 union {
-  union { // expected-note 2 {{'S1' is implicitly deleted

[PATCH] D65543: [Windows] Autolink with basenames and add libdir to libpath

2020-04-23 Thread Hans Wennborg via Phabricator via cfe-commits
hans accepted this revision.
hans added a comment.
This revision is now accepted and ready to land.

I agree with the sentiment that it's annoying when clang doesn't just work out 
of the box. But it will still do, except for asan and profile info etc, for 
which I think it's reasonable to add to the documentation what the user needs 
to do. I think the place to do that is 
https://clang.llvm.org/docs/UsersManual.html#clang-cl (and a release note). It 
would be great if the doc includes the error message one would get when the 
link fails, to make it easy to find through web search.

> One last idea is that we could teach LLD to automatically add this directory 
> to library search path, but then users who link with Visual C++ (not many 
> anymore) will run into this as a corner case issue.

I thought about that too, and I think it's a good idea. Having the linker in a 
toolchain know about the runtime libs seems pretty reasonable I think?




Comment at: clang/docs/ReleaseNotes.rst:63
+  clang-cl embedded paths to these libraries in object files, but now the
+  compiler no longer embeds a full path.
 

Could this be expanded to a more explain-like-I'm-five style example?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65543



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


[PATCH] D78214: [libclang]: visit C++17 if init statements

2020-04-23 Thread Milian Wolff via Phabricator via cfe-commits
milianw added a comment.

ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78214



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


[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-23 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

Thanks, this looks much better now.
Could you also update the description of the revision to match the current 
status? (E.g. type aliases are now supported.)
If you do not plan to solve the alignof issue in the near future, maybe it 
would be worth to also open a bug report. 
Please wait for one more approval before commiting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D78213: [libclang]: visit BindingDecl in DecompositionDecl

2020-04-23 Thread Milian Wolff via Phabricator via cfe-commits
milianw added a comment.

ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78213



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


[PATCH] D78289: [analyzer] Stability improvements for IteratorModeling functions

2020-04-23 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov updated this revision to Diff 259521.
ASDenysPetrov edited the summary of this revision.
ASDenysPetrov added a comment.

@baloghadamsoftware
I've added a test for unscoped SVal, but still can't come up with `if (!LPos || 
!RPos)`
Could you, please, suggest me something?


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

https://reviews.llvm.org/D78289

Files:
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/test/Analysis/iterator-range.cpp


Index: clang/test/Analysis/iterator-range.cpp
===
--- clang/test/Analysis/iterator-range.cpp
+++ clang/test/Analysis/iterator-range.cpp
@@ -810,6 +810,19 @@
   auto j = std::prev(i, 0); // no-warning
 }
 
+// std::prev() with int* for checking Loc value argument
+namespace std {
+template 
+T prev(T, int *);
+}
+
+void prev_loc_value(const std::vector &V, int o) {
+
+  auto i = return_any_iterator(V.begin());
+  int *offset = &o;
+  auto j = std::prev(i, offset); // no-warning
+}
+
 //
 // Structure member dereference operators
 //
Index: clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
@@ -402,7 +402,7 @@
   if (!Cont)
 return;
 
-  // At least one of the iterators have recorded positions. If one of them has
+  // At least one of the iterators has recorded positions. If one of them does
   // not then create a new symbol for the offset.
   SymbolRef Sym;
   if (!LPos || !RPos) {
@@ -422,9 +422,14 @@
 RPos = getIteratorPosition(State, RVal);
   }
 
-  // We cannot make assumpotions on `UnknownVal`. Let us conjure a symbol
+  if (!LPos || !RPos)
+return;
+
+  // We cannot make assumptions on `UnknownVal`. Let us conjure a symbol
   // instead.
   if (RetVal.isUnknown()) {
+if (!State)
+  return;
 auto &SymMgr = C.getSymbolManager();
 auto *LCtx = C.getLocationContext();
 RetVal = nonloc::SymbolVal(SymMgr.conjureSymbol(
@@ -532,8 +537,9 @@
 return;
 
   const auto *value = &RHS;
+  SVal val;
   if (auto loc = RHS.getAs()) {
-const auto val = State->getRawSVal(*loc);
+val = State->getRawSVal(*loc);
 value = &val;
   }
 


Index: clang/test/Analysis/iterator-range.cpp
===
--- clang/test/Analysis/iterator-range.cpp
+++ clang/test/Analysis/iterator-range.cpp
@@ -810,6 +810,19 @@
   auto j = std::prev(i, 0); // no-warning
 }
 
+// std::prev() with int* for checking Loc value argument
+namespace std {
+template 
+T prev(T, int *);
+}
+
+void prev_loc_value(const std::vector &V, int o) {
+
+  auto i = return_any_iterator(V.begin());
+  int *offset = &o;
+  auto j = std::prev(i, offset); // no-warning
+}
+
 //
 // Structure member dereference operators
 //
Index: clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
@@ -402,7 +402,7 @@
   if (!Cont)
 return;
 
-  // At least one of the iterators have recorded positions. If one of them has
+  // At least one of the iterators has recorded positions. If one of them does
   // not then create a new symbol for the offset.
   SymbolRef Sym;
   if (!LPos || !RPos) {
@@ -422,9 +422,14 @@
 RPos = getIteratorPosition(State, RVal);
   }
 
-  // We cannot make assumpotions on `UnknownVal`. Let us conjure a symbol
+  if (!LPos || !RPos)
+return;
+
+  // We cannot make assumptions on `UnknownVal`. Let us conjure a symbol
   // instead.
   if (RetVal.isUnknown()) {
+if (!State)
+  return;
 auto &SymMgr = C.getSymbolManager();
 auto *LCtx = C.getLocationContext();
 RetVal = nonloc::SymbolVal(SymMgr.conjureSymbol(
@@ -532,8 +537,9 @@
 return;
 
   const auto *value = &RHS;
+  SVal val;
   if (auto loc = RHS.getAs()) {
-const auto val = State->getRawSVal(*loc);
+val = State->getRawSVal(*loc);
 value = &val;
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D77940: [AArch64] Add NVIDIA Carmel support

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added a comment.

It seems a NVIDIA Developer Program Membership is needed in order to download 
the TRM. I'm not sure if that is just a matter of creating an account, but 
without it I can't really verify that the architecture version and the features 
are correct and complete.




Comment at: clang/test/Preprocessor/aarch64-target-features.c:183
 // CHECK-MCPU-A64FX: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+v8.2a" "-target-feature" "+fp-armv8" "-target-feature" "+neon" 
"-target-feature" "+crc" "-target-feature" "+crypto" "-target-feature" 
"+fullfp16" "-target-feature" "+ras" "-target-feature" "+lse" "-target-feature" 
"+rdm" "-target-feature" "+sve" "-target-feature" "+sha2"
+// CHECK-MCPU-CARMEL: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+v8.2a" "-target-feature" "+fp-armv8" "-target-feature" "+neon" 
"-target-feature" "+crc" "-target-feature" "+crypto" "-target-feature" 
"+fullfp16" "-target-feature" "+ras" "-target-feature" "+lse" "-target-feature" 
"+rdm" "-target-feature" "+sve" "-target-feature" "+sha2" "-target-feature" 
"+aes"
 

This test references unsupported features.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:181
+AARCH64_CPU_NAME("carmel", ARMV8_2A, FK_CRYPTO_NEON_FP_ARMV8, false,
+ (AArch64::AEK_FP16 | AArch64::AEK_SVE))
 // Invalid CPU

This still references `AEK_SVE`.



Comment at: llvm/unittests/Support/TargetParserTest.cpp:980
+  AArch64::AEK_CRC | AArch64::AEK_CRYPTO | AArch64::AEK_FP |
+  AArch64::AEK_SIMD | AArch64::AEK_FP16 | AArch64::AEK_RAS |
+  AArch64::AEK_LSE | AArch64::AEK_SVE | AArch64::AEK_RDM,

tambre wrote:
> sdesmalen wrote:
> > nit: odd indentation here, have you used clang-format?
> Fixed manually. Using clang-format results in unpleasant formatting similar 
> to "apple-a10" and "apple-a11" above.
Okay, that's fine, thanks for fixing.



Comment at: llvm/unittests/Support/TargetParserTest.cpp:1134
AArch64::ArchKind::INVALID, "sve2"));
+  EXPECT_TRUE(
+  testAArch64Extension("carmel", AArch64::ArchKind::INVALID, "fp16"));

nit: It seems a bit arbitrary to only check for fp16 here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77940



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


[PATCH] D78693: Make "#pragma clang attribute" support uninitialized attribute.

2020-04-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!




Comment at: clang/test/CodeGenCXX/trivial-auto-var-init-attribute.cpp:38-50
+// UNINIT-LABEL:  test_pragma_attribute_uninitialized_f2(
+// UNINIT:  alloca
+// UNINIT-NEXT: call void
+// ZERO-LABEL:test_pragma_attribute_uninitialized_f2(
+// ZERO:  alloca
+// ZERO-NEXT: call void
+// PATTERN-LABEL: test_pragma_attribute_uninitialized_f2(

I think you can remove this test case as it's basically identical to the 
previous one.



Comment at: clang/test/Parser/pragma-attribute.cpp:190
+#pragma clang attribute pop
+#pragma clang attribute push([[clang::uninitialized]], apply_to = variable) // 
expected-error {{attribute 'uninitialized' can't be applied to 'variable'}}
+#pragma clang attribute pop

jfb wrote:
> Should variable work? Since it’s a superset of local it seems like maybe? But 
> then again only local works, so ok not sure. 
I think this is correct. Requiring an explicit `is_local` here is a 
conservative approach. It means we can start supporting 
`[[clang::uninitialized]]` in other contexts without breaking code that uses 
`#pragma clang attribute` to apply it to more entities unexpectedly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78693



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


[PATCH] D78704: [analyzer][NFC] Add unittest for FalsePositiveRefutationBRVisitor

2020-04-23 Thread Balázs Benics via Phabricator via cfe-commits
steakhal created this revision.
steakhal added reviewers: NoQ, xazax.hun, rnkovacs, Szelethus, 
baloghadamsoftware, mikhail.ramalho.
Herald added subscribers: cfe-commits, ASDenysPetrov, martong, Charusso, 
dkrupp, donat.nagy, a.sidorin, szepet, whisperity, mgorny.
Herald added a project: clang.
steakhal added a child revision: D78457: [analyzer][Z3-refutation] Fix 
refutation BugReporterVisitor bug and refactor.
steakhal updated this revision to Diff 259531.
steakhal added a comment.

Upload the right diff.


Adds the test infrastructure for testing the `FalsePositiveRefutationBRVisitor`.

It will be extended later, to demonstrate a bug in the visitor.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78704

Files:
  clang/unittests/StaticAnalyzer/CMakeLists.txt
  clang/unittests/StaticAnalyzer/CheckerRegistration.h
  clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp

Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- /dev/null
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -0,0 +1,171 @@
+//===- unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "CheckerRegistration.h"
+#include "Reusables.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"
+#include "clang/StaticAnalyzer/Frontend/CheckerRegistry.h"
+#include "llvm/Config/config.h"
+#include "gtest/gtest.h"
+
+#define SKIP_WITHOUT_Z3\
+  do   \
+if (!LLVM_WITH_Z3) \
+  return;  \
+  while (0)
+
+namespace clang {
+namespace ento {
+namespace {
+
+class FalsePositiveGenerator : public Checker {
+  using Self = FalsePositiveGenerator;
+  const BuiltinBug FalsePositiveGeneratorBug{this, "FalsePositiveGenerator"};
+  using HandlerFn = bool (Self::*)(const CallEvent &Call, CheckerContext &,
+   ProgramStateRef State) const;
+  CallDescriptionMap Callbacks = {
+  {{"reachedWithContradiction", 0}, &Self::reachedWithContradiction},
+  {{"reachedWithNoContradiction", 0}, &Self::reachedWithNoContradiction},
+  {{"reportIfCanBeZero", 1}, &Self::reportIfCanBeZero},
+  };
+
+  bool report(CheckerContext &C, ProgramStateRef State,
+  StringRef Description) const {
+ExplodedNode *Node = C.generateNonFatalErrorNode(State);
+if (!Node)
+  return false;
+
+auto Report = std::make_unique(
+FalsePositiveGeneratorBug, Description, Node);
+C.emitReport(std::move(Report));
+return true;
+  }
+
+  bool reachedWithNoContradiction(const CallEvent &, CheckerContext &C,
+  ProgramStateRef State) const {
+return report(C, State, "REACHED_WITH_NO_CONTRADICTION");
+  }
+
+  bool reachedWithContradiction(const CallEvent &, CheckerContext &C,
+ProgramStateRef State) const {
+return report(C, State, "REACHED_WITH_CONTRADICTION");
+  }
+
+  bool reportIfCanBeZero(const CallEvent &Call, CheckerContext &C,
+ ProgramStateRef State) const {
+ProgramStateRef ArgIsZero, ArgIsNotZero;
+std::tie(ArgIsZero, ArgIsNotZero) = assumeArgEqZero(Call, C, State);
+
+if (ArgIsZero)
+  return report(C, ArgIsZero, "ZERO_STATE_SHOULD_NOT_EXIST");
+return false;
+  }
+
+  std::pair
+  assumeArgEqZero(const CallEvent &Call, CheckerContext &C,
+  ProgramStateRef State) const {
+SValBuilder &SVB = C.getSValBuilder();
+const QualType ArgType = Call.getArgExpr(0)->getType();
+const DefinedOrUnknownSVal Zero = SVB.makeZeroVal(ArgType);
+const SVal ArgEqZero = SVB.evalEQ(State, Call.getArgSVal(0), Zero);
+return State->assume(ArgEqZero.castAs());
+  }
+
+public:
+  bool evalCall(const CallEvent &Call, CheckerContext &C) const {
+if (const HandlerFn *Callback = Callbacks.lookup(Call))
+  return (this->*(*Callback))(Call, C, C.getState());
+return false;
+  }
+};
+
+void addFalsePositiveGenerator(AnalysisASTConsumer &AnalysisConsumer,
+   Analyzer

[PATCH] D78704: [analyzer][NFC] Add unittest for FalsePositiveRefutationBRVisitor

2020-04-23 Thread Balázs Benics via Phabricator via cfe-commits
steakhal updated this revision to Diff 259531.
steakhal added a comment.

Upload the right diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78704

Files:
  clang/unittests/StaticAnalyzer/CMakeLists.txt
  clang/unittests/StaticAnalyzer/CheckerRegistration.h
  clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp

Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- /dev/null
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -0,0 +1,171 @@
+//===- unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "CheckerRegistration.h"
+#include "Reusables.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"
+#include "clang/StaticAnalyzer/Frontend/CheckerRegistry.h"
+#include "llvm/Config/config.h"
+#include "gtest/gtest.h"
+
+#define SKIP_WITHOUT_Z3\
+  do   \
+if (!LLVM_WITH_Z3) \
+  return;  \
+  while (0)
+
+namespace clang {
+namespace ento {
+namespace {
+
+class FalsePositiveGenerator : public Checker {
+  using Self = FalsePositiveGenerator;
+  const BuiltinBug FalsePositiveGeneratorBug{this, "FalsePositiveGenerator"};
+  using HandlerFn = bool (Self::*)(const CallEvent &Call, CheckerContext &,
+   ProgramStateRef State) const;
+  CallDescriptionMap Callbacks = {
+  {{"reachedWithContradiction", 0}, &Self::reachedWithContradiction},
+  {{"reachedWithNoContradiction", 0}, &Self::reachedWithNoContradiction},
+  {{"reportIfCanBeZero", 1}, &Self::reportIfCanBeZero},
+  };
+
+  bool report(CheckerContext &C, ProgramStateRef State,
+  StringRef Description) const {
+ExplodedNode *Node = C.generateNonFatalErrorNode(State);
+if (!Node)
+  return false;
+
+auto Report = std::make_unique(
+FalsePositiveGeneratorBug, Description, Node);
+C.emitReport(std::move(Report));
+return true;
+  }
+
+  bool reachedWithNoContradiction(const CallEvent &, CheckerContext &C,
+  ProgramStateRef State) const {
+return report(C, State, "REACHED_WITH_NO_CONTRADICTION");
+  }
+
+  bool reachedWithContradiction(const CallEvent &, CheckerContext &C,
+ProgramStateRef State) const {
+return report(C, State, "REACHED_WITH_CONTRADICTION");
+  }
+
+  bool reportIfCanBeZero(const CallEvent &Call, CheckerContext &C,
+ ProgramStateRef State) const {
+ProgramStateRef ArgIsZero, ArgIsNotZero;
+std::tie(ArgIsZero, ArgIsNotZero) = assumeArgEqZero(Call, C, State);
+
+if (ArgIsZero)
+  return report(C, ArgIsZero, "ZERO_STATE_SHOULD_NOT_EXIST");
+return false;
+  }
+
+  std::pair
+  assumeArgEqZero(const CallEvent &Call, CheckerContext &C,
+  ProgramStateRef State) const {
+SValBuilder &SVB = C.getSValBuilder();
+const QualType ArgType = Call.getArgExpr(0)->getType();
+const DefinedOrUnknownSVal Zero = SVB.makeZeroVal(ArgType);
+const SVal ArgEqZero = SVB.evalEQ(State, Call.getArgSVal(0), Zero);
+return State->assume(ArgEqZero.castAs());
+  }
+
+public:
+  bool evalCall(const CallEvent &Call, CheckerContext &C) const {
+if (const HandlerFn *Callback = Callbacks.lookup(Call))
+  return (this->*(*Callback))(Call, C, C.getState());
+return false;
+  }
+};
+
+void addFalsePositiveGenerator(AnalysisASTConsumer &AnalysisConsumer,
+   AnalyzerOptions &AnOpts) {
+  AnOpts.CheckersAndPackages = {{"test.FalsePositiveGenerator", true},
+{"debug.ViewExplodedGraph", false},
+{"debug.ExprInspection", false}};
+  AnalysisConsumer.AddCheckerRegistrationFn([](CheckerRegistry &Registry) {
+Registry.addChecker(
+"test.FalsePositiveGenerator", "EmptyDescription", "EmptyDocsUri");
+  });
+}
+
+const std::vector CrossCheckArgs{
+"-Xclang", "-analyzer-config", "-Xclang"

[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

2020-04-23 Thread Balázs Benics via Phabricator via cfe-commits
steakhal updated this revision to Diff 259532.
steakhal added a comment.

- keep the visitor
- fix the bug
- add test demonstrating the bug and the fix


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp

Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -166,6 +166,53 @@
 "test.FalsePositiveGenerator:ZERO_STATE_SHOULD_NOT_EXIST\n");
 }
 
+TEST(FalsePositiveRefutationBRVisitor,
+ UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
+  SKIP_WITHOUT_Z3;
+  std::string Diags;
+  constexpr auto Code = R"(
+void reportIfCanBeZero(int);
+void reachedWithNoContradiction();
+void test(unsigned x, unsigned n) {
+  if (n >= 1 && n <= 2) {
+if (x >= 3)
+  return;
+// x: [0,2] and n: [1,2]
+int y = x + n; // y: ($x+$n) Which is in approximately between 1 and 4.
+
+// Registers the symbol '($x+$n)' with the constraint [1, MAX] in the
+// true branch.
+if (y > 0) {
+  // Since the x: [0,2] and n: [1,2] the ($x+$n) is indeed greater than
+  // zero. If we emit a warning here, the constraints on the bugpath is
+  // SAT. Therefore that bugreport is NOT invalidated.
+  reachedWithNoContradiction(); // ($x+$n) can be grater than zero. OK
+
+  // If we ask the analyzer whether the 'y-5' can be zero. It won't know,
+  // therefore the state will be created where the 'y-5' expression is 0.
+  // This assumption is false!
+  // 'y' can not be 5 if the maximal value of both x and y is 2.
+  // This bugreport must be caught by the visitor, since the constraints
+  // of the bugpath are UnSAT.
+  reportIfCanBeZero(y - 5);
+}
+  }
+})";
+
+  // Only the first diagnostic is visible.
+  EXPECT_TRUE(runFalsePositiveGeneratorOnCode(Code, Diags, CrossCheckArgs));
+  EXPECT_EQ(Diags,
+"test.FalsePositiveGenerator:REACHED_WITH_NO_CONTRADICTION\n");
+
+  // Without enabling the crosscheck-with-z3 the BugPath is not invalidated.
+  // Both diagnostics are visible.
+  std::string Diags2;
+  EXPECT_TRUE(runFalsePositiveGeneratorOnCode(Code, Diags2));
+  EXPECT_EQ(Diags2,
+"test.FalsePositiveGenerator:REACHED_WITH_NO_CONTRADICTION\n"
+"test.FalsePositiveGenerator:ZERO_STATE_SHOULD_NOT_EXIST\n");
+}
+
 } // namespace
 } // namespace ento
 } // namespace clang
Index: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -2820,7 +2820,7 @@
 BugReporterContext &BRC, const ExplodedNode *EndPathNode,
 PathSensitiveBugReport &BR) {
   // Collect new constraints
-  VisitNode(EndPathNode, BRC, BR);
+  addConstraints(EndPathNode, /*OnlyForNewSymbols=*/false);
 
   // Create a refutation manager
   llvm::SMTSolverRef RefutationSolver = llvm::CreateZ3Solver();
@@ -2831,30 +2831,30 @@
 const SymbolRef Sym = I.first;
 auto RangeIt = I.second.begin();
 
-llvm::SMTExprRef Constraints = SMTConv::getRangeExpr(
+llvm::SMTExprRef SMTConstraints = SMTConv::getRangeExpr(
 RefutationSolver, Ctx, Sym, RangeIt->From(), RangeIt->To(),
 /*InRange=*/true);
 while ((++RangeIt) != I.second.end()) {
-  Constraints = RefutationSolver->mkOr(
-  Constraints, SMTConv::getRangeExpr(RefutationSolver, Ctx, Sym,
- RangeIt->From(), RangeIt->To(),
- /*InRange=*/true));
+  SMTConstraints = RefutationSolver->mkOr(
+  SMTConstraints, SMTConv::getRangeExpr(RefutationSolver, Ctx, Sym,
+RangeIt->From(), RangeIt->To(),
+/*InRange=*/true));
 }
 
-RefutationSolver->addConstraint(Constraints);
+RefutationSolver->addConstraint(SMTConstraints);
   }
 
   // And check for satisfiability
-  Optional isSat = RefutationSolver->check();
-  if (!isSat.hasValue())
+  Optional IsSAT = RefutationSolver->check();
+  if (!IsSAT.hasValue())
 return;
 
-  if (!isSat.getValue())
+  if (!IsSAT.getValue())
 BR.markInvalid("Infeasible constraints", EndPathNode->getLocationContext());
 }
 
-PathDiagnosticPieceRef FalsePositiveRefutationBRVisitor::VisitN

[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

2020-04-23 Thread Balázs Benics via Phabricator via cfe-commits
steakhal marked an inline comment as done.
steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2871
+  // Overwrite the associated constraint of the Symbol.
+  Constraints = CF.remove(Constraints, Sym);
   Constraints = CF.add(Constraints, Sym, C.second);

How can we simplify this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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


[clang] 2f9fc8d - [clang-format] Handle C# property accessors when parsing lines

2020-04-23 Thread Jonathan Coe via cfe-commits

Author: Jonathan Coe
Date: 2020-04-23T13:25:10+01:00
New Revision: 2f9fc8d9718fb19c04e169f7ba7ae26ea6a05085

URL: 
https://github.com/llvm/llvm-project/commit/2f9fc8d9718fb19c04e169f7ba7ae26ea6a05085
DIFF: 
https://github.com/llvm/llvm-project/commit/2f9fc8d9718fb19c04e169f7ba7ae26ea6a05085.diff

LOG: [clang-format] Handle C# property accessors when parsing lines

Summary:
Improve C# `{ get; set; } = default;` formatting by handling it in the 
UnwrappedLineParser rather than trying to merge lines later.

Remove old logic to merge lines.

Update tests as formatting output has changed (as intended).

Reviewers: krasimir, MyDeveloperDay

Reviewed By: krasimir

Subscribers: cfe-commits

Tags: #clang-format, #clang

Differential Revision: https://reviews.llvm.org/D78642

Added: 


Modified: 
clang/lib/Format/UnwrappedLineFormatter.cpp
clang/lib/Format/UnwrappedLineParser.cpp
clang/lib/Format/UnwrappedLineParser.h
clang/unittests/Format/FormatTestCSharp.cpp

Removed: 




diff  --git a/clang/lib/Format/UnwrappedLineFormatter.cpp 
b/clang/lib/Format/UnwrappedLineFormatter.cpp
index c16c16c4f26a..e86f9ecb4b90 100644
--- a/clang/lib/Format/UnwrappedLineFormatter.cpp
+++ b/clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -294,13 +294,6 @@ class LineJoiner {
   }
 }
 
-// Try to merge a CSharp property declaration like `{ get; private set }`.
-if (Style.isCSharp()) {
-  unsigned CSPA = tryMergeCSharpPropertyAccessor(I, E, Limit);
-  if (CSPA > 0)
-return CSPA;
-}
-
 // Try to merge a function block with left brace unwrapped
 if (TheLine->Last->is(TT_FunctionLBrace) &&
 TheLine->First != TheLine->Last) {
@@ -430,64 +423,6 @@ class LineJoiner {
 return 0;
   }
 
-  // true for lines of the form [access-modifier] {get,set} [;]
-  bool isMergeablePropertyAccessor(const AnnotatedLine *Line) {
-auto *Tok = Line->First;
-if (!Tok)
-  return false;
-
-if (Tok->isOneOf(tok::kw_public, tok::kw_protected, tok::kw_private,
- Keywords.kw_internal))
-  Tok = Tok->Next;
-
-if (!Tok || (Tok->TokenText != "get" && Tok->TokenText != "set"))
-  return false;
-
-if (!Tok->Next || Tok->Next->is(tok::semi))
-  return true;
-
-return false;
-  }
-
-  unsigned tryMergeCSharpPropertyAccessor(
-  SmallVectorImpl::const_iterator I,
-  SmallVectorImpl::const_iterator E, unsigned /*Limit*/) {
-
-auto CurrentLine = I;
-// Does line start with `{`
-if (!(*CurrentLine)->Last || 
(*CurrentLine)->Last->isNot(TT_FunctionLBrace))
-  return 0;
-++CurrentLine;
-
-unsigned MergedLines = 0;
-bool HasGetOrSet = false;
-while (CurrentLine != E) {
-  bool LineIsGetOrSet = isMergeablePropertyAccessor(*CurrentLine);
-  HasGetOrSet = HasGetOrSet || LineIsGetOrSet;
-  if (LineIsGetOrSet) {
-++CurrentLine;
-++MergedLines;
-continue;
-  }
-  auto *Tok = (*CurrentLine)->First;
-  if (Tok && Tok->is(tok::r_brace)) {
-++CurrentLine;
-++MergedLines;
-// See if the next line is a default value so that we can merge `{ get;
-// set } = 0`
-if (CurrentLine != E && (*CurrentLine)->First &&
-(*CurrentLine)->First->is(tok::equal)) {
-  ++MergedLines;
-}
-break;
-  }
-  // Not a '}' or a get/set line so do not merege lines.
-  return 0;
-}
-
-return HasGetOrSet ? MergedLines : 0;
-  }
-
   unsigned
   tryMergeSimplePPDirective(SmallVectorImpl::const_iterator I,
 SmallVectorImpl::const_iterator E,

diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index 18899314512e..c84c951fcaa8 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -1334,7 +1334,7 @@ void UnwrappedLineParser::parseStructuralElement() {
 parseChildBlock();
   break;
 case tok::l_brace:
-  if (!tryToParseBracedList()) {
+  if (!tryToParsePropertyAccessor() && !tryToParseBracedList()) {
 // A block outside of parentheses must be the last part of a
 // structural element.
 // FIXME: Figure out cases where this is not true, and add projections
@@ -1487,6 +1487,75 @@ void UnwrappedLineParser::parseStructuralElement() {
   } while (!eof());
 }
 
+bool UnwrappedLineParser::tryToParsePropertyAccessor() {
+  assert(FormatTok->is(tok::l_brace));
+  if (!Style.isCSharp())
+return false;
+  // See if it's a property accessor.
+  if (FormatTok->Previous->isNot(tok::identifier))
+return false;
+
+  // Try to parse the property accessor braces and contents:
+  // `{ get; set; } = new MyType(defaultValue);`
+  //  ^
+  //
+  // Record the current tokenPosition so that we can advance and
+  // reset the current token. `Next` is not set yet s

[PATCH] D78704: [analyzer][NFC] Add unittest for FalsePositiveRefutationBRVisitor

2020-04-23 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

Thanks! Having more tests is always welcome!

I mentioned some nits inline, but I wonder if you actually need to add a new 
check. Can't you just reuse existing debug checks?
We have the expr inspeciton checker that supports the following functions:

  clang_analyzer_warnIfReached
  clang_analyzer_eval




Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:24
+  do   
\
+if (!LLVM_WITH_Z3) 
\
+  return;  
\

I think this might not be the idiomatic way to skip a test. Consider using ` 
GTEST_SKIP();`.



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:65
+
+  bool reportIfCanBeZero(const CallEvent &Call, CheckerContext &C,
+ ProgramStateRef State) const {

Maybe `reportIfArgCanBeZero`?



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:115
+  llvm::raw_string_ostream OS(Diags);
+  return tooling::runToolOnCodeWithArgs(
+  std::make_unique>(OS), Code, Args,

Wasn't `runCheckerOnCodeWithArgs` created for this purpose?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78704



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


[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

2020-04-23 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:438-442
+  Optional getReturnValueUnderConstruction(unsigned BlockCount) const;
+
+  Optional getArgObject(unsigned Index, unsigned BlockCount) const;
+
+  Optional getReturnObject(unsigned BlockCount) const;

baloghadamsoftware wrote:
> NoQ wrote:
> > I believe these functions don't need to be optional. There's always a 
> > parameter location and a location to return to (even if the latter is 
> > incorrect due to unimplemented construction context, it'll still be some 
> > dummy temporary region that you can use).
> Do you mean we should return the original `SVal` if parameter or return value 
> location fails? (Thus `LazyCompoundVal` in worst case?
It simply should not fail.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1044
 
+class ParamWithoutVarRegion : public TypedValueRegion {
+  friend class MemRegionManager;

baloghadamsoftware wrote:
> baloghadamsoftware wrote:
> > baloghadamsoftware wrote:
> > > NoQ wrote:
> > > > There should be only one way to express the parameter region. Let's 
> > > > call this one simply `ParamRegion` or something like that, and 
> > > > `assert(!isa(D))` in the constructor of `VarRegion`.
> > > Do you mean that we should use `ParamRegion` in every case, thus also 
> > > when we have the definitioan for the function? I wonder whether it breaks 
> > > too many things.
> > This will surely not work. The common handling of `ParamVarDecl` and 
> > `VarDecl` is soo deeply rooted in the whole analyzer that separating them 
> > means creation of a totally new analyzer engine from scratch.
> More specifically: whenever a function is inlined, its parameters are used as 
> variables via `DeclRefExpr`s. A `DeclRefExpr` refers to a `Decl` which is a 
> `ParamVarDecl` but that has reference neither for the `CallExpr` (since it is 
> not related to the call, but to the `FunctionDecl` or `ObjCMethodDecl`) nore 
> for its `Index` in the call. The former is the real problem that cannot be 
> solved even on theoretical level: a function which is inlined cannot depend 
> on the different `CallExpr`s where it is called. Even worse, if the function 
> is analyzed top-level it has not `CallExpr` at all so using `ParamRegion` for 
> its parameters is completely impossible.
> A `DeclRefExpr` refers to a `Decl` which is a `ParamVarDecl` but that has 
> reference neither for the `CallExpr` (since it is not related to the call, 
> but to the `FunctionDecl` or `ObjCMethodDecl`)

The call site is available as part of the current location context.

> nore for its Index in the call

It's available as part of `ParmVarDecl`.

> The former is the real problem that cannot be solved even on theoretical 
> level: a function which is inlined cannot depend on the different `CallExpr`s 
> where it is called

It already depends on the `CallExpr`. `ParmVarDecl`-based `VarRegion`s are 
different for different call sites even if `ParmVarDecl` is the same; moreover, 
they reside in non-overlapping memory spaces.

> Even worse, if the function is analyzed top-level it has not `CallExpr` at 
> all so using `ParamRegion` for its parameters is completely impossible.

Ok, let's make an exception for this case and either use the old `VarRegion` 
(given that there's no redecl confusion in this case) or allow the `CallExpr` 
to be null (it's still trivially easy to extract all the necessary information).

> The common handling of `ParamVarDecl` and `VarDecl` is soo deeply rooted in 
> the whole analyzer that separating them means creation of a totally new 
> analyzer engine from scratch.

I don't see any indication of that yet.


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

https://reviews.llvm.org/D77229



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


[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-23 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added inline comments.



Comment at: clang/test/Analysis/cfg.cpp:570
 }
 
+// CHECK-LABEL: void vla_simple(int x)

aaron.ballman wrote:
> NoQ wrote:
> > balazske wrote:
> > > balazske wrote:
> > > > aaron.ballman wrote:
> > > > > Can you also add tests for:
> > > > > ```
> > > > > int vla_unevaluated(int x) {
> > > > >   // Evaluates the ++x
> > > > >   sizeof(int[++x]);
> > > > >   // Does not evaluate the ++x
> > > > >   _Alignof(int[++x]);
> > > > >   _Generic((int(*)[++x])0, default : 0);
> > > > >   
> > > > >   return x;
> > > > > }
> > > > > ```
> > > > > 
> > > > > Also, it's a bit strange to find these VLA tests in a .cpp file. VLAs 
> > > > > are a C++ extension and we should have some testing for them for 
> > > > > constructs that are C++-specific, but I would have expected many of 
> > > > > these tests to be in a C file instead.
> > > > Could be there platforms (on buildbot?) where the VLA code (in cpp 
> > > > file) does not compile? Is it worth to have a test with VLA type alias 
> > > > then?
> > > I have this output for the test above (without the new code), is it 
> > > correct?
> > > (The `++` seems to be evaluated for the `alignof` statement too.)
> > > ```
> > > int vla_unevaluated(int x)
> > >  [B2 (ENTRY)]
> > >Succs (1): B1
> > > 
> > >  [B1]
> > >1: x
> > >2: ++[B1.1]
> > >3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
> > >4: sizeof(int [++x])
> > >5: x
> > >6: ++[B1.5]
> > >7: [B1.6] (ImplicitCastExpr, LValueToRValue, int)
> > >8: alignof(int [++x])
> > >9: 0
> > >   10: x
> > >   11: [B1.10] (ImplicitCastExpr, LValueToRValue, int)
> > >   12: return [B1.11];
> > >Preds (1): B2
> > >Succs (1): B0
> > > 
> > >  [B0 (EXIT)]
> > >Preds (1): B1
> > > 
> > > ```
> > > Could be there platforms (on buildbot?) where the VLA code (in cpp file) 
> > > does not compile? Is it worth to have a test with VLA type alias then?
> > 
> > That's unlikely; the problems with VLAs in C++ are IIRC about the 
> > bureaucracy of the Standard (i.e., they couldn't solve enough cornercases, 
> > like whether `T` and `T` the same template when `x == y` at 
> > run-time?), not about platform support.
> > Could be there platforms (on buildbot?) where the VLA code (in cpp file) 
> > does not compile? Is it worth to have a test with VLA type alias then?
> 
> I think the type alias test is a good idea (as are any other C++-specific 
> tests) because we support VLAs in C++ mode as an extension, my concern was 
> more that this is a C feature and so if I was hunting for tests for VLAs, I'd 
> look  in a .c file first. It's not a huge concern, more like a style nit.
> 
> > (The ++ seems to be evaluated for the alignof statement too.)
> 
> That seems wrong per C17 6.5.3.4p3. It also doesn't seem to match the 
> behavior I'm seeing: https://godbolt.org/z/rVaGnb
> 
There is a //cfg.cpp// test file but not a //cfg.c// so the new tests are added 
to the cpp file. I do not like to make a new //cfg.c// because it will contain 
a part of the VLA tests only because the type alias cases. It is better to have 
all VLA tests in the same file.

The case in `vla_unevaluated` is probably wrong but an independent problem. 
This change would be only about adding the VLA related parts.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D78642: [clang-format] Handle C# property accessors when parsing lines

2020-04-23 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2f9fc8d9718f: [clang-format] Handle C# property accessors 
when parsing lines (authored by Jonathan Coe ).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78642

Files:
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/unittests/Format/FormatTestCSharp.cpp

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -245,13 +245,11 @@
"}");
 
   verifyFormat("[TestMethod]\n"
-   "public string Host\n"
-   "{ set; get; }");
+   "public string Host { set; get; }");
 
   verifyFormat("[TestMethod(\"start\", HelpText = \"Starts the server "
"listening on provided host\")]\n"
-   "public string Host\n"
-   "{ set; get; }");
+   "public string Host { set; get; }");
 
   verifyFormat(
   "[DllImport(\"Hello\", EntryPoint = \"hello_world\")]\n"
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -132,6 +132,7 @@
   void parseCSharpGenericTypeConstraint();
   bool tryToParseLambda();
   bool tryToParseLambdaIntroducer();
+  bool tryToParsePropertyAccessor();
   void tryToParseJSFunction();
   void addUnwrappedLine();
   bool eof() const;
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1334,7 +1334,7 @@
 parseChildBlock();
   break;
 case tok::l_brace:
-  if (!tryToParseBracedList()) {
+  if (!tryToParsePropertyAccessor() && !tryToParseBracedList()) {
 // A block outside of parentheses must be the last part of a
 // structural element.
 // FIXME: Figure out cases where this is not true, and add projections
@@ -1487,6 +1487,75 @@
   } while (!eof());
 }
 
+bool UnwrappedLineParser::tryToParsePropertyAccessor() {
+  assert(FormatTok->is(tok::l_brace));
+  if (!Style.isCSharp())
+return false;
+  // See if it's a property accessor.
+  if (FormatTok->Previous->isNot(tok::identifier))
+return false;
+
+  // Try to parse the property accessor braces and contents:
+  // `{ get; set; } = new MyType(defaultValue);`
+  //  ^
+  //
+  // Record the current tokenPosition so that we can advance and
+  // reset the current token. `Next` is not set yet so we need
+  // another way to advance along the token stream.
+  unsigned int StoredPosition = Tokens->getPosition();
+  FormatToken *Tok = Tokens->getNextToken();
+
+  bool HasGetOrSet = false;
+  while (!eof()) {
+if (Tok->isOneOf(tok::semi, tok::kw_public, tok::kw_private,
+ tok::kw_protected, Keywords.kw_internal, Keywords.kw_get,
+ Keywords.kw_set)) {
+  if (Tok->isOneOf(Keywords.kw_get, Keywords.kw_set))
+HasGetOrSet = true;
+  Tok = Tokens->getNextToken();
+  continue;
+}
+if (Tok->is(tok::r_brace))
+  break;
+Tokens->setPosition(StoredPosition);
+return false;
+  }
+
+  if (!HasGetOrSet) {
+Tokens->setPosition(StoredPosition);
+return false;
+  }
+
+  Tokens->setPosition(StoredPosition);
+  while (FormatTok->isNot(tok::r_brace)) {
+nextToken();
+  }
+
+  // Try to parse (optional) assignment to default value:
+  // `{ get; set; } = new MyType(defaultValue);`
+  //^^^
+  // There may be some very complicated expressions inside default value
+  // assignment, the simple parse block below will not handle them.
+  // The parse block below would need extending to handle opening parens etc.
+  StoredPosition = Tokens->getPosition();
+  Tok = Tokens->getNextToken();
+  bool NextTokenIsEqual = Tok->is(tok::equal);
+  Tokens->setPosition(StoredPosition);
+
+  if (NextTokenIsEqual) {
+do {
+  nextToken();
+  if (FormatTok->is(tok::semi))
+break;
+} while (!eof());
+  }
+
+  // Add an unwrapped line for the whole property accessor.
+  nextToken();
+  addUnwrappedLine();
+  return true;
+}
+
 bool UnwrappedLineParser::tryToParseLambda() {
   if (!Style.isCpp()) {
 nextToken();
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -294,13 +294,6 @@
   }
 }
 
-// Try to merge a CSharp property declaration like `{ get; private set }`.
-if

[clang] 3a53806 - Add extension links for VSCode

2020-04-23 Thread via cfe-commits

Author: Kumar Harsh
Date: 2020-04-23T14:56:36+02:00
New Revision: 3a5380618e8284efd513228036ca98e550ea0abf

URL: 
https://github.com/llvm/llvm-project/commit/3a5380618e8284efd513228036ca98e550ea0abf
DIFF: 
https://github.com/llvm/llvm-project/commit/3a5380618e8284efd513228036ca98e550ea0abf.diff

LOG: Add extension links for VSCode

The clang-format docs were missing mention or links for the VSCode extension, 
which have been added.

Added: 


Modified: 
clang/docs/ClangFormat.rst

Removed: 




diff  --git a/clang/docs/ClangFormat.rst b/clang/docs/ClangFormat.rst
index 1138b2332670..2b0d6424e0a8 100644
--- a/clang/docs/ClangFormat.rst
+++ b/clang/docs/ClangFormat.rst
@@ -173,7 +173,7 @@ shortcut in the BBEdit preferences, under Menus & Shortcuts.
 
 
 CLion Integration
-==
+=
 
 :program:`clang-format` is integrated into `CLion `_ as an alternative code formatter. It is disabled by default and
@@ -192,6 +192,12 @@ Download the latest Visual Studio extension from the 
`alpha build site
 `_. The default key-binding is Ctrl-R,Ctrl-F.
 
 
+Visual Studio Code Integration
+==
+
+Get the latest Visual Studio Code extension from the `Visual Studio 
Marketplace 
_`. The 
default key-binding is Alt-Shift-F.
+
+
 Script for patch reformatting
 =
 



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


[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

2020-04-23 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporter.cpp:2751
 
+Optional hasContradictionUsingZ3(BugReporterContext &BRC,
+   const ExplodedNode *EndPathNode) {

Is this function used anywhere?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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


[PATCH] D75917: Expose llvm fence instruction as clang intrinsic

2020-04-23 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 259545.
saiislam added a comment.

Added check and test for sync scope to be a constant literal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75917

Files:
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGenCXX/builtin-amdgcn-fence.cpp
  clang/test/Sema/builtin-amdgcn-fence-failure.cpp
  clang/test/SemaOpenCL/builtins-amdgcn-error.cl

Index: clang/test/SemaOpenCL/builtins-amdgcn-error.cl
===
--- clang/test/SemaOpenCL/builtins-amdgcn-error.cl
+++ clang/test/SemaOpenCL/builtins-amdgcn-error.cl
@@ -128,3 +128,14 @@
   *out = __builtin_amdgcn_ds_fmaxf(out, src, 0, a, false); // expected-error {{argument to '__builtin_amdgcn_ds_fmaxf' must be a constant integer}}
   *out = __builtin_amdgcn_ds_fmaxf(out, src, 0, 0, a); // expected-error {{argument to '__builtin_amdgcn_ds_fmaxf' must be a constant integer}}
 }
+
+void test_fence() {
+  __builtin_amdgcn_fence(__ATOMIC_SEQ_CST + 1, "workgroup"); // expected-warning {{memory order argument to atomic operation is invalid}}
+  __builtin_amdgcn_fence(__ATOMIC_ACQUIRE - 1, "workgroup"); // expected-warning {{memory order argument to atomic operation is invalid}}
+  __builtin_amdgcn_fence(4); // expected-error {{too few arguments to function call, expected 2}}
+  __builtin_amdgcn_fence(4, 4, 4); // expected-error {{too many arguments to function call, expected 2}}
+  __builtin_amdgcn_fence(3.14, ""); // expected-warning {{implicit conversion from 'double' to 'unsigned int' changes value from 3.14 to 3}}
+
+  const char ptr[] = "workgroup";
+  __builtin_amdgcn_fence(__ATOMIC_ACQUIRE, ptr); // expected-error {{expression is not a string literal}}
+}
Index: clang/test/Sema/builtin-amdgcn-fence-failure.cpp
===
--- /dev/null
+++ clang/test/Sema/builtin-amdgcn-fence-failure.cpp
@@ -0,0 +1,9 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: not %clang_cc1 %s -S \
+// RUN:   -triple=amdgcn-amd-amdhsa 2>&1 | FileCheck %s
+
+void test_amdgcn_fence_failure() {
+
+  // CHECK: error: Unsupported atomic synchronization scope
+  __builtin_amdgcn_fence(__ATOMIC_SEQ_CST, "foobar");
+}
Index: clang/test/CodeGenCXX/builtin-amdgcn-fence.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/builtin-amdgcn-fence.cpp
@@ -0,0 +1,22 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 %s -emit-llvm -O0 -o - \
+// RUN:   -triple=amdgcn-amd-amdhsa  | opt -S | FileCheck %s
+
+void test_memory_fence_success() {
+// CHECK-LABEL: test_memory_fence_success
+
+  // CHECK: fence syncscope("workgroup") seq_cst
+  __builtin_amdgcn_fence(__ATOMIC_SEQ_CST,  "workgroup");
+
+   // CHECK: fence syncscope("agent") acquire
+  __builtin_amdgcn_fence(__ATOMIC_ACQUIRE, "agent");
+
+  // CHECK: fence seq_cst
+  __builtin_amdgcn_fence(__ATOMIC_SEQ_CST, "");
+
+  // CHECK: fence syncscope("agent") acq_rel
+  __builtin_amdgcn_fence(4, "agent");
+
+// CHECK: fence syncscope("workgroup") release
+  __builtin_amdgcn_fence(3, "workgroup");
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1920,6 +1920,10 @@
 if (CheckPPCBuiltinFunctionCall(BuiltinID, TheCall))
   return ExprError();
 break;
+  case llvm::Triple::amdgcn:
+if (CheckAMDGCNBuiltinFunctionCall(BuiltinID, TheCall))
+  return ExprError();
+break;
   default:
 break;
 }
@@ -2921,6 +2925,45 @@
   return SemaBuiltinConstantArgRange(TheCall, i, l, u);
 }
 
+bool Sema::CheckAMDGCNBuiltinFunctionCall(unsigned BuiltinID, CallExpr *TheCall) {
+  switch (BuiltinID) {
+case AMDGPU::BI__builtin_amdgcn_fence: {
+  ExprResult Arg = TheCall->getArg(0);
+  auto ArgExpr = Arg.get();
+  Expr::EvalResult ArgResult;
+
+  if(!ArgExpr->EvaluateAsInt(ArgResult, Context))
+return Diag(ArgExpr->getExprLoc(), diag::err_typecheck_expect_int)
+  << ArgExpr->getType();
+  int ord = ArgResult.Val.getInt().getZExtValue();
+
+  // Check valididty of memory ordering as per C11 / C++11's memody model.
+  switch (static_cast(ord)) {
+case llvm::AtomicOrderingCABI::acquire:
+case llvm::AtomicOrderingCABI::release:
+case llvm::AtomicOrderingCABI::acq_rel:
+case llvm::AtomicOrderingCABI::seq_cst:
+  break;
+default: {
+  return Diag(ArgExpr->getBeginLoc(),
+diag::warn_atomic_op_has_invalid_memory_order)
+  << ArgExpr->getSourceRange();
+}
+  }
+
+  Arg = TheCall->getArg(1);
+  ArgExpr = Arg.get();
+  Expr::EvalRes

[PATCH] D70500: [WebAssembly] Enable use of wasm-opt and LTO-enabled system libraries

2020-04-23 Thread bernhard via Phabricator via cfe-commits
bernhard added a comment.

Are there plans to offer a way to disable this behavior (or have it optional in 
the first place)?
We'd like to run some custom processing between wasm-ld and wasm-opt which 
can't happen after the latter due to some of its one-way destructive 
optimizations (i.e. memory-packing or simplify-globals passes).
The only way now is to tell our users to place wasm-opt somewhere where clang 
can't find it. Or instead of using one clang super-command to manually call 
-cc1 and wasm-ld separately which is disappointing.

Also, is it even common to place wasm-opt next to the clang executable? Who is 
this for? Is this documented?
I only stumbled into this by pure luck and was very confused for a while until 
I ran with -v.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70500



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


[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/Analysis/cfg.cpp:570
 }
 
+// CHECK-LABEL: void vla_simple(int x)

balazske wrote:
> aaron.ballman wrote:
> > NoQ wrote:
> > > balazske wrote:
> > > > balazske wrote:
> > > > > aaron.ballman wrote:
> > > > > > Can you also add tests for:
> > > > > > ```
> > > > > > int vla_unevaluated(int x) {
> > > > > >   // Evaluates the ++x
> > > > > >   sizeof(int[++x]);
> > > > > >   // Does not evaluate the ++x
> > > > > >   _Alignof(int[++x]);
> > > > > >   _Generic((int(*)[++x])0, default : 0);
> > > > > >   
> > > > > >   return x;
> > > > > > }
> > > > > > ```
> > > > > > 
> > > > > > Also, it's a bit strange to find these VLA tests in a .cpp file. 
> > > > > > VLAs are a C++ extension and we should have some testing for them 
> > > > > > for constructs that are C++-specific, but I would have expected 
> > > > > > many of these tests to be in a C file instead.
> > > > > Could be there platforms (on buildbot?) where the VLA code (in cpp 
> > > > > file) does not compile? Is it worth to have a test with VLA type 
> > > > > alias then?
> > > > I have this output for the test above (without the new code), is it 
> > > > correct?
> > > > (The `++` seems to be evaluated for the `alignof` statement too.)
> > > > ```
> > > > int vla_unevaluated(int x)
> > > >  [B2 (ENTRY)]
> > > >Succs (1): B1
> > > > 
> > > >  [B1]
> > > >1: x
> > > >2: ++[B1.1]
> > > >3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
> > > >4: sizeof(int [++x])
> > > >5: x
> > > >6: ++[B1.5]
> > > >7: [B1.6] (ImplicitCastExpr, LValueToRValue, int)
> > > >8: alignof(int [++x])
> > > >9: 0
> > > >   10: x
> > > >   11: [B1.10] (ImplicitCastExpr, LValueToRValue, int)
> > > >   12: return [B1.11];
> > > >Preds (1): B2
> > > >Succs (1): B0
> > > > 
> > > >  [B0 (EXIT)]
> > > >Preds (1): B1
> > > > 
> > > > ```
> > > > Could be there platforms (on buildbot?) where the VLA code (in cpp 
> > > > file) does not compile? Is it worth to have a test with VLA type alias 
> > > > then?
> > > 
> > > That's unlikely; the problems with VLAs in C++ are IIRC about the 
> > > bureaucracy of the Standard (i.e., they couldn't solve enough 
> > > cornercases, like whether `T` and `T` the same template 
> > > when `x == y` at run-time?), not about platform support.
> > > Could be there platforms (on buildbot?) where the VLA code (in cpp file) 
> > > does not compile? Is it worth to have a test with VLA type alias then?
> > 
> > I think the type alias test is a good idea (as are any other C++-specific 
> > tests) because we support VLAs in C++ mode as an extension, my concern was 
> > more that this is a C feature and so if I was hunting for tests for VLAs, 
> > I'd look  in a .c file first. It's not a huge concern, more like a style 
> > nit.
> > 
> > > (The ++ seems to be evaluated for the alignof statement too.)
> > 
> > That seems wrong per C17 6.5.3.4p3. It also doesn't seem to match the 
> > behavior I'm seeing: https://godbolt.org/z/rVaGnb
> > 
> There is a //cfg.cpp// test file but not a //cfg.c// so the new tests are 
> added to the cpp file. I do not like to make a new //cfg.c// because it will 
> contain a part of the VLA tests only because the type alias cases. It is 
> better to have all VLA tests in the same file.
> 
> The case in `vla_unevaluated` is probably wrong but an independent problem. 
> This change would be only about adding the VLA related parts.
> There is a cfg.cpp test file but not a cfg.c so the new tests are added to 
> the cpp file. I do not like to make a new cfg.c because it will contain a 
> part of the VLA tests only because the type alias cases. It is better to have 
> all VLA tests in the same file.

I don't see why it matters having all VLA tests in the same file when the file 
name has nothing to do with VLAs, but if you insist, I can hold my nose.

> The case in vla_unevaluated is probably wrong but an independent problem. 
> This change would be only about adding the VLA related parts.

I'm not super familiar with the analyzer parts of thing, but I'm not certain 
why this is an independent problem. I thought the purpose to this patch was to 
ensure VLAs are evaluated when necessary in otherwise unevaluated contexts. The 
VLA within _Alignof should not be evaluated, so it seems related to this patch. 
That said, I'm fine if it's handled in a follow-up patch if that's easier.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D75917: Expose llvm fence instruction as clang intrinsic

2020-04-23 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam marked an inline comment as done.
saiislam added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:2958
+  // Check that sync scope is a constant literal
+  if(!ArgExpr->EvaluateAsConstantExpr(ArgResult1,
+  Expr::EvaluateForCodeGen, Context))

@sameerds here is the check for sync scope to be constant literal


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75917



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


Re: [clang] 2214b90 - [clangd] Make signatureHelp work with stale preambles

2020-04-23 Thread Mikael Holmén via cfe-commits
Hi Kadir,

I start seeing some sanitizer complaints with this commit for the
following two testcases:
  ./ClangdTests/PreamblePatchTest.ContainsNewIncludes
  ./ClangdTests/PreamblePatchTest.IncludeParsing

The complaints look like this:

=
==75126==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 369 byte(s) in 4 object(s) allocated from:
#0 0x5bbe40 in operator new(unsigned long, std::nothrow_t const&)
/repo/uabkaka/tmp/llvm/projects/compiler-
rt/lib/asan/asan_new_delete.cc:112
#1 0x149a3e9 in
llvm::WritableMemoryBuffer::getNewUninitMemBuffer(unsigned long,
llvm::Twine const&) /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../lib/Support/MemoryBuffer.cpp:298:34
#2 0x1498db3 in getMemBufferCopyImpl /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../lib/Support/MemoryBuffer.cpp:127:14
#3 0x1498db3 in
llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, llvm::Twine
const&) /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-asan/../lib/Support/MemoryBuffer.cpp:136
#4 0x506012e in
clang::clangd::PreamblePatch::apply(clang::CompilerInvocation&) const
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-asan/../../clang-tools-
extra/clangd/Preamble.cpp:337:7
#5 0xf910e6 in clang::clangd::(anonymous
namespace)::PreamblePatchTest_IncludeParsing_Test::TestBody()
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-asan/../../clang-tools-
extra/clangd/unittests/PreambleTests.cpp:91:57
#6 0x164e8e0 in HandleExceptionsInMethodIfSupported /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc
#7 0x164e8e0 in testing::Test::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2474
#8 0x1651fc5 in testing::TestInfo::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2656:11
#9 0x1653440 in testing::TestCase::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2774:28
#10 0x1671e64 in testing::internal::UnitTestImpl::RunAllTests()
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:4649:43
#11 0x1671010 in
HandleExceptionsInMethodIfSupported /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc
#12 0x1671010 in testing::UnitTest::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:4257
#13 0x1633040 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
#14 0x1633040 in main /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
#15 0x7f7dfdfe6544 in __libc_start_main (/lib64/libc.so.6+0x22544)

SUMMARY: AddressSanitizer: 369 byte(s) leaked in 4 allocation(s).

Regards,
Mikael

On Tue, 2020-04-21 at 01:34 -0700, Kadir Cetinkaya via cfe-commits
wrote:
> Author: Kadir Cetinkaya
> Date: 2020-04-21T10:27:26+02:00
> New Revision: 2214b9076f1d3a4784820c4479e2417685e5c980
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/2214b9076f1d3a4784820c4479e2417685e5c980
> DIFF: 
> https://github.com/llvm/llvm-project/commit/2214b9076f1d3a4784820c4479e2417685e5c980.diff
> 
> LOG: [clangd] Make signatureHelp work with stale preambles
> 
> Summary:
> This is achieved by calculating newly added includes and implicitly
> parsing them as if they were part of the main file.
> 
> This also gets rid of the need for consistent preamble reads.
> 
> Reviewers: sammccall
> 
> Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, mgrang,
> arphaman, jfb, usaxena95, cfe-commits
> 
> Tags: #clang
> 
> Differential Revision: https://reviews.llvm.org/D77392
> 
> Added: 
> clang-tools-extra/clangd/unittests/PreambleTests.cpp
> 
> Modified: 
> clang-tools-extra/clangd/ClangdServer.cpp
> clang-tools-extra/clangd/CodeComplete.cpp
> clang-tools-extra/clangd/Preamble.cpp
> clang-tools-extra/clangd/Preamble.h
> clang-tools-extra/clangd/TUScheduler.cpp
> clang-tools-extra/clangd/TUScheduler.h
> clang-tools-extra/clangd/unittests/CMakeLists.txt
> clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
> clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-23 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

Actually, sorry. I just realized that the alignof problem is introduced by this 
patch. I'd love to see the solution committed together with this patch (it 
could be a separate patch but preferably, they should be committed together.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-23 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev added inline comments.



Comment at: clang-tools-extra/clangd/index/remote/Index.cpp:97
+std::unique_ptr connect(llvm::StringRef Address) {
+#ifdef CLANGD_REMOTE
+  return std::unique_ptr(new IndexClient(Address));

sammccall wrote:
> if  remote is disabled we can't compile the rest of this file.
> Rather than ifdefs here, I'd suggest doing it at the cmake level:
> 
> ```
> if(CLANGD_ENABLE_REMOTE)
>   add_clang_library(... Index.cpp)
> else()
>   add_clang_library(... IndexUnimplemented.cpp)
> endif()
> ```
I would argue that including `index/remote/Client.h` without 
`CLANGD_ENABLE_REMOTE` is not correct. We would still have to put `#ifdefs` in 
the user code regardless of whether what you proposed is implemented. I don't 
see any benefits in allowing users to include `index/remote/Client.h`, link 
`clangdRemoteIndex` and getting a runtime error. All of those steps have 
_remote_ in them and if _remote mode_ is not enabled, something certainly went 
wrong.

Also, this will complicate CMake structure as I can't put files that are 
conditionally added/excluded from the clang library and I would either have to 
make a separate directory with an "empty" library, or put a bunch of `#ifdefs` 
in here. Either is not optimal and I think it'd be better to leave it like 
this. WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521



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


[PATCH] D78642: [clang-format] Handle C# property accessors when parsing lines

2020-04-23 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1344
   addUnwrappedLine();
 FormatTok->Type = TT_FunctionLBrace;
 parseBlock(/*MustBeDeclaration=*/false);

previously set and get would break based on the setting of AfterFunction 
correct? now I assume it doesn't?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78642



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


[PATCH] D78642: [clang-format] Handle C# property accessors when parsing lines

2020-04-23 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/FormatTestCSharp.cpp:249
+   "public string Host { set; get; }");
 
   verifyFormat("[TestMethod(\"start\", HelpText = \"Starts the server "

is this just a personal choice? or based on some rule that it shouldn't break?

I don't like us changing tests unless we understand otherwise we just keep 
flip-flopping the style?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78642



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


[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-23 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 259547.
kbobyrev marked 13 inline comments as done.
kbobyrev added a comment.

Address the remaining comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Features.inc.in
  clang-tools-extra/clangd/index/Serialization.h
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.h
  clang-tools-extra/clangd/index/remote/Index.cpp
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/Marshalling.h
  clang-tools-extra/clangd/index/remote/client/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/client/Client.cpp
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/Server.cpp

Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -8,6 +8,7 @@
 
 #include "index/Index.h"
 #include "index/Serialization.h"
+#include "index/remote/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/LineEditor/LineEditor.h"
@@ -23,6 +24,7 @@
 
 namespace clang {
 namespace clangd {
+namespace remote {
 namespace {
 
 static const std::string Overview = R"(
@@ -33,42 +35,78 @@
 llvm::cl::opt IndexPath(llvm::cl::desc(""),
  llvm::cl::Positional, llvm::cl::Required);
 
-llvm::cl::opt ServerAddress("server-address",
- llvm::cl::init("0.0.0.0:50051"));
+llvm::cl::opt ServerAddress(
+"server-address", llvm::cl::init("0.0.0.0:50051"),
+llvm::cl::desc("Address of the invoked server. Defaults to 0.0.0.0:50051"));
 
-std::unique_ptr openIndex(llvm::StringRef Index) {
+std::unique_ptr openIndex(llvm::StringRef Index) {
   return loadIndex(Index, /*UseIndex=*/true);
 }
 
-class RemoteIndexServer final : public remote::Index::Service {
+class RemoteIndexServer final : public SymbolIndex::Service {
 public:
-  RemoteIndexServer(std::unique_ptr Index)
+  RemoteIndexServer(std::unique_ptr Index)
   : Index(std::move(Index)) {}
 
 private:
   grpc::Status Lookup(grpc::ServerContext *Context,
-  const remote::LookupRequest *Request,
-  grpc::ServerWriter *Reply) override {
-llvm::outs() << "Lookup of symbol with ID " << Request->id() << '\n';
-LookupRequest Req;
-auto SID = SymbolID::fromStr(Request->id());
-if (!SID) {
-  llvm::outs() << llvm::toString(SID.takeError()) << "\n";
-  return grpc::Status::CANCELLED;
+  const LookupRequest *Request,
+  grpc::ServerWriter *Reply) override {
+clangd::LookupRequest Req;
+for (const auto &ID : Request->ids()) {
+  auto SID = SymbolID::fromStr(StringRef(ID));
+  if (!SID)
+return grpc::Status::CANCELLED;
+  Req.IDs.insert(*SID);
 }
-Req.IDs.insert(*SID);
-Index->lookup(Req, [&](const Symbol &Sym) {
-  remote::LookupReply NextSymbol;
-  NextSymbol.set_symbol_yaml(toYAML(Sym));
+Index->lookup(Req, [&](const clangd::Symbol &Sym) {
+  Symbol NextSymbol;
+  NextSymbol.set_yaml_serializatiton(toYAML(Sym));
   Reply->Write(NextSymbol);
 });
 return grpc::Status::OK;
   }
 
-  std::unique_ptr Index;
+  grpc::Status FuzzyFind(grpc::ServerContext *Context,
+ const FuzzyFindRequest *Request,
+ grpc::ServerWriter *Reply) override {
+const auto Req = fromProtobuf(Request);
+bool HasMore = Index->fuzzyFind(Req, [&](const clangd::Symbol &Sym) {
+  FuzzyFindReply NextMessage;
+  NextMessage.mutable_stream_result()->set_yaml_serializatiton(toYAML(Sym));
+  Reply->Write(NextMessage);
+});
+FuzzyFindReply LastMessage;
+LastMessage.set_final_result(HasMore);
+Reply->Write(LastMessage);
+return grpc::Status::OK;
+  }
+
+  grpc::Status Refs(grpc::ServerContext *Context, const RefsRequest *Request,
+grpc::ServerWriter *Reply) override {
+clangd::RefsRequest Req;
+for (const auto &ID : Request->ids()) {
+  auto SID = SymbolID::fromStr(StringRef(ID));
+  if (!SID)
+return grpc::Status::CANCELLED;
+  Req.IDs.insert(*SID);
+}
+bool HasMore = Index->refs(Req, [&](const clangd::Ref &Reference) {
+  RefsReply NextMessage;
+  NextMessage.mutable_stream_result()->set_yaml_serializatiton(
+  toYAML(Reference));
+  Reply->

[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-23 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 259553.
kbobyrev added a comment.

Convert plain function pointers to std::function in templates.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Features.inc.in
  clang-tools-extra/clangd/index/Serialization.h
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.h
  clang-tools-extra/clangd/index/remote/Index.cpp
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/Marshalling.h
  clang-tools-extra/clangd/index/remote/client/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/client/Client.cpp
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/Server.cpp

Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -8,6 +8,7 @@
 
 #include "index/Index.h"
 #include "index/Serialization.h"
+#include "index/remote/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/LineEditor/LineEditor.h"
@@ -23,6 +24,7 @@
 
 namespace clang {
 namespace clangd {
+namespace remote {
 namespace {
 
 static const std::string Overview = R"(
@@ -33,42 +35,78 @@
 llvm::cl::opt IndexPath(llvm::cl::desc(""),
  llvm::cl::Positional, llvm::cl::Required);
 
-llvm::cl::opt ServerAddress("server-address",
- llvm::cl::init("0.0.0.0:50051"));
+llvm::cl::opt ServerAddress(
+"server-address", llvm::cl::init("0.0.0.0:50051"),
+llvm::cl::desc("Address of the invoked server. Defaults to 0.0.0.0:50051"));
 
-std::unique_ptr openIndex(llvm::StringRef Index) {
+std::unique_ptr openIndex(llvm::StringRef Index) {
   return loadIndex(Index, /*UseIndex=*/true);
 }
 
-class RemoteIndexServer final : public remote::Index::Service {
+class RemoteIndexServer final : public SymbolIndex::Service {
 public:
-  RemoteIndexServer(std::unique_ptr Index)
+  RemoteIndexServer(std::unique_ptr Index)
   : Index(std::move(Index)) {}
 
 private:
   grpc::Status Lookup(grpc::ServerContext *Context,
-  const remote::LookupRequest *Request,
-  grpc::ServerWriter *Reply) override {
-llvm::outs() << "Lookup of symbol with ID " << Request->id() << '\n';
-LookupRequest Req;
-auto SID = SymbolID::fromStr(Request->id());
-if (!SID) {
-  llvm::outs() << llvm::toString(SID.takeError()) << "\n";
-  return grpc::Status::CANCELLED;
+  const LookupRequest *Request,
+  grpc::ServerWriter *Reply) override {
+clangd::LookupRequest Req;
+for (const auto &ID : Request->ids()) {
+  auto SID = SymbolID::fromStr(StringRef(ID));
+  if (!SID)
+return grpc::Status::CANCELLED;
+  Req.IDs.insert(*SID);
 }
-Req.IDs.insert(*SID);
-Index->lookup(Req, [&](const Symbol &Sym) {
-  remote::LookupReply NextSymbol;
-  NextSymbol.set_symbol_yaml(toYAML(Sym));
+Index->lookup(Req, [&](const clangd::Symbol &Sym) {
+  Symbol NextSymbol;
+  NextSymbol.set_yaml_serializatiton(toYAML(Sym));
   Reply->Write(NextSymbol);
 });
 return grpc::Status::OK;
   }
 
-  std::unique_ptr Index;
+  grpc::Status FuzzyFind(grpc::ServerContext *Context,
+ const FuzzyFindRequest *Request,
+ grpc::ServerWriter *Reply) override {
+const auto Req = fromProtobuf(Request);
+bool HasMore = Index->fuzzyFind(Req, [&](const clangd::Symbol &Sym) {
+  FuzzyFindReply NextMessage;
+  NextMessage.mutable_stream_result()->set_yaml_serializatiton(toYAML(Sym));
+  Reply->Write(NextMessage);
+});
+FuzzyFindReply LastMessage;
+LastMessage.set_final_result(HasMore);
+Reply->Write(LastMessage);
+return grpc::Status::OK;
+  }
+
+  grpc::Status Refs(grpc::ServerContext *Context, const RefsRequest *Request,
+grpc::ServerWriter *Reply) override {
+clangd::RefsRequest Req;
+for (const auto &ID : Request->ids()) {
+  auto SID = SymbolID::fromStr(StringRef(ID));
+  if (!SID)
+return grpc::Status::CANCELLED;
+  Req.IDs.insert(*SID);
+}
+bool HasMore = Index->refs(Req, [&](const clangd::Ref &Reference) {
+  RefsReply NextMessage;
+  NextMessage.mutable_stream_result()->set_yaml_serializatiton(
+  toYAML(Reference));
+  Reply->Write(NextMes

[PATCH] D78190: Add Bfloat IR type

2020-04-23 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer accepted this revision.
SjoerdMeijer added a comment.
This revision is now accepted and ready to land.

This direction of an IR type was taken after a discussion on the list. All 
previous comments have been addressed, and the changes here all look very 
reasonable to me. So, LGTM, but I think we need a LGTM from someone else too. 
So please wait for one more LGTM.




Comment at: llvm/include/llvm/IR/DataLayout.h:655
 return TypeSize::Fixed(16);
+  case Type::BfloatTyID:
+return TypeSize::Fixed(16);

Nit:

  case Type::HalfTyID:
  case Type::BfloatTyID:
return TypeSize::Fixed(16);



Comment at: llvm/lib/Support/APFloat.cpp:3266
 
+APInt IEEEFloat::convertBfloatAPFloatToAPInt() const {
+  assert(semantics == (const llvm::fltSemantics *)&semBfloat);

I am not real big fan of all the code duplication here in this file (just the 
constants are different). But there's enough prior art here, so good for now I 
think, and a nice opportunity for a refactoring follow-up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78190



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


[PATCH] D78401: [SveEmitter] IsInsertOp1SVALL and builtins for svqdec[bhwd] and svqinc[bhwd]

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added inline comments.



Comment at: clang/include/clang/Basic/arm_sve.td:530
+class sat_type { string U = u; string T = t; }
+def SIGNED_BYTE : sat_type<"",  "c">;
+def SIGNED_HALF : sat_type<"",  "s">;

SjoerdMeijer wrote:
> nit: just wondering if all these defs should be all capitals.
They don't and I can see how this can be confused with intrinsics. I've changed 
it!



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7684
 
+if (TypeFlags.isInsertOp1SVALL())
+  Ops.insert(&Ops[1], Builder.getInt32(31));

SjoerdMeijer wrote:
> would this be the most appropriate place to add the useful sentence from the 
> description: 
> 
> "Some ACLE builtins leave out the argument to specify the predicate
> pattern, which is expected to be expanded to an SV_ALL pattern."
> 
> because that's what 31 is, right?
Yes, good suggestion! I've added the comment.



Comment at: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecb.c:7
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3

SjoerdMeijer wrote:
> nit: used,unused -> "used/unused", or "used, unused"
I'd rather not fix this for this patch, because it would need changing for all 
other test files as well.


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

https://reviews.llvm.org/D78401



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


[PATCH] D77597: [SveEmitter] Add IsAppendSVALL and builtins for svptrue and svcnt[bhwd]

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 259555.
sdesmalen marked 2 inline comments as done.
sdesmalen added a comment.

- Added comment explaining need for expanding SV_ALL


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

https://reviews.llvm.org/D77597

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cnth.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ptrue.c

Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ptrue.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ptrue.c
@@ -0,0 +1,201 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+svbool_t test_svptrue_b8()
+{
+  // CHECK-LABEL: test_svptrue_b8
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_b8();
+}
+
+svbool_t test_svptrue_b16()
+{
+  // CHECK-LABEL: test_svptrue_b16
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv8i1(i32 31)
+  // CHECK: %[[CAST:.*]] = call  @llvm.aarch64.sve.convert.to.svbool.nxv8i1( %[[INTRINSIC]])
+  // CHECK: ret  %[[CAST]]
+  return svptrue_b16();
+}
+
+svbool_t test_svptrue_b32()
+{
+  // CHECK-LABEL: test_svptrue_b32
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv4i1(i32 31)
+  // CHECK: %[[CAST:.*]] = call  @llvm.aarch64.sve.convert.to.svbool.nxv4i1( %[[INTRINSIC]])
+  // CHECK: ret  %[[CAST]]
+  return svptrue_b32();
+}
+
+svbool_t test_svptrue_b64()
+{
+  // CHECK-LABEL: test_svptrue_b64
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv2i1(i32 31)
+  // CHECK: %[[CAST:.*]] = call  @llvm.aarch64.sve.convert.to.svbool.nxv2i1( %[[INTRINSIC]])
+  // CHECK: ret  %[[CAST]]
+  return svptrue_b64();
+}
+
+svbool_t test_svptrue_pat_b8()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 0)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_POW2);
+}
+
+svbool_t test_svptrue_pat_b8_1()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_1
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 1)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL1);
+}
+
+svbool_t test_svptrue_pat_b8_2()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_2
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 2)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL2);
+}
+
+svbool_t test_svptrue_pat_b8_3()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_3
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 3)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL3);
+}
+
+svbool_t test_svptrue_pat_b8_4()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_4
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 4)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL4);
+}
+
+svbool_t test_svptrue_pat_b8_5()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_5
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 5)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL5);
+}
+
+svbool_t test_svptrue_pat_b8_6()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_6
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 6)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL6);
+}
+
+svbool_t test_svptrue_pat_b8_7()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_7
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 7)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL7);
+}
+
+svbool_t test_svptrue_pat_b8_8()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_8
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 8)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL8);
+}
+
+svbool_t test_svptrue_pat_b8_9()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_9
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 9)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL16);
+}
+
+svbool_t test_svptrue_pat_b8_10()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_10
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 10)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL32);
+}
+
+svbool_t test_svptrue_pat_b8_11()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_11
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 11)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL64);
+}
+
+svbool_t test_svptrue_pat_b8

[PATCH] D78638: [analyzer] Consider array subscripts to be interesting lvalues

2020-04-23 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.

Yup. Yet another epic bug!




Comment at: 
clang/test/Analysis/CheckThatArraySubsciptNodeIsNotCollected.cpp:18-19
+// time to collect redundant nodes. This GC-like mechanism kicks in only when
+// the exploded graph is large enough (>1K nodes). For this reason, 'index'
+// is a global variable, and the sink point is inside of a loop.
+

I'm still curious why `index` being global actually matters here. Like, how 
does it increase the number of nodes in the graph?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78638



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


[PATCH] D78401: [SveEmitter] IsInsertOp1SVALL and builtins for svqdec[bhwd] and svqinc[bhwd]

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 259554.
sdesmalen marked 3 inline comments as done.
sdesmalen added a comment.

- Changed UNSIGNED_BYTE etc from upper-case to CamelCase.
- Added comment explaining need to expand SV_ALL


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

https://reviews.llvm.org/D78401

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdech.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qinch.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qdecb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qdecd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qdech.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qdecw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qinch.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincw.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -505,6 +505,7 @@
 Bitwidth = 16;
 ElementBitwidth = 1;
 break;
+  case 's':
   case 'a':
 Bitwidth = ElementBitwidth;
 NumVectors = 0;
Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincw.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincw.c
@@ -0,0 +1,155 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1,A2,A3,A4) A1##A2##A3##A4
+#endif
+
+#include 
+
+int32_t test_svqincw_n_s32(int32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_s32,,)(op, 0);
+}
+
+int32_t test_svqincw_n_s32_1(int32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_s32,,)(op, 17);
+}
+
+int64_t test_svqincw_n_s64(int64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_s64,,)(op, 0);
+}
+
+int64_t test_svqincw_n_s64_1(int64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_s64,,)(op, 17);
+}
+
+uint32_t test_svqincw_n_u32(uint32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_u32,,)(op, 0);
+}
+
+uint32_t test_svqincw_n_u32_1(uint32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_u32,,)(op, 17);
+}
+
+uint64_t test_svqincw_n_u64(uint64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_u64,,)(op, 0);
+}
+
+uint64_t test_svqincw_n_u64_1(uint64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_u64,,)(op, 17);
+}
+
+int32_t test_svqincw_pat_n_s32(int32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw_pat,_n_s32,,)(op, SV_POW2, 0);
+}
+
+int32_t test_svqincw_pat_n_s32_1(int32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw_pat,_n_s32,,)(op, SV_VL1, 17);
+}
+
+int64_t test_svqincw_pat_n_s64(int64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw_pat,_n_s64,,)(op, SV_VL2, 0);
+}
+
+int64_t test_svqincw_pat_n_s64_1(int64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid ran

[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-23 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

In D77809#1999050 , @xazax.hun wrote:

> Actually, sorry. I just realized that the alignof problem is introduced by 
> this patch. I'd love to see the solution committed together with this patch 
> (it could be a separate patch but preferably, they should be committed 
> together.)


I do not see that the alignof problem is introduced here. If this patch is 
ignored the alignof problem still exists. I have found the problematic code, 
for every kind of `UnaryExprOrTypeTraitExpr` the VLA size is evaluated if there 
is a VLA. It looks easy to fix, just add a few lines and tests for it. Still it 
is a not related problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D78638: [analyzer] Consider array subscripts to be interesting lvalues

2020-04-23 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko marked an inline comment as done.
vsavchenko added inline comments.



Comment at: 
clang/test/Analysis/CheckThatArraySubsciptNodeIsNotCollected.cpp:18-19
+// time to collect redundant nodes. This GC-like mechanism kicks in only when
+// the exploded graph is large enough (>1K nodes). For this reason, 'index'
+// is a global variable, and the sink point is inside of a loop.
+

NoQ wrote:
> I'm still curious why `index` being global actually matters here. Like, how 
> does it increase the number of nodes in the graph?
It does not simply increase the number of nodes, it increases it by thousands!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78638



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


[PATCH] D46472: [HIP] Support offloading by linker script

2020-04-23 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added inline comments.
Herald added a reviewer: jdoerfert.



Comment at: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp:1329
+  // Get the HIP offload tool chain.
+  auto *HIPTC = static_cast(
+  C.getSingleOffloadToolChain());

Should this be `toolchains::HipToolChain`?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D46472



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


[PATCH] D78704: [analyzer][NFC] Add unittest for FalsePositiveRefutationBRVisitor

2020-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

I like it! Nice work! I have some minor comments.




Comment at: clang/unittests/StaticAnalyzer/CheckerRegistration.h:81
+template 
+bool runCheckerOnCodeWithArgs(const std::string &Code, std::string &Diags,
+  const std::vector &Args,

Do you use this function template anywhere?



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:138
+  std::string Diags2;
+  EXPECT_TRUE(runFalsePositiveGeneratorOnCode(Code, Diags2));
+  EXPECT_EQ(Diags2, 
"test.FalsePositiveGenerator:REACHED_WITH_CONTRADICTION\n");

There is no need to have `Diags2`. You could reuse `Diags` if in 
`runFalsePositiveGeneratorOnCode` you cleared the diag param.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78704



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


[PATCH] D78563: [AIX] Port power alignment rules to clang

2020-04-23 Thread Xiangling Liao via Phabricator via cfe-commits
Xiangling_L updated this revision to Diff 259559.
Xiangling_L marked 5 inline comments as done.
Xiangling_L added a comment.

Adjust some comments style;
Add more testcases;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78563

Files:
  clang/include/clang/AST/RecordLayout.h
  clang/lib/AST/RecordLayout.cpp
  clang/lib/AST/RecordLayoutBuilder.cpp
  clang/test/Layout/aix-double-struct-member.cpp
  clang/test/Layout/aix-virtual-function-alignment.cpp

Index: clang/test/Layout/aix-virtual-function-alignment.cpp
===
--- /dev/null
+++ clang/test/Layout/aix-virtual-function-alignment.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -emit-llvm-only -triple powerpc-ibm-aix-xcoff \
+// RUN: -fdump-record-layouts -fsyntax-only %s 2>/dev/null | FileCheck \
+// RUN: --check-prefix=CHECK32 %s
+
+// RUN: %clang_cc1 -emit-llvm-only -triple powerpc64-ibm-aix-xcoff \
+// RUN: -fdump-record-layouts -fsyntax-only %s 2>/dev/null | FileCheck \
+// RUN: --check-prefix=CHECK64 %s
+
+struct A {
+  virtual void boo() {}
+};
+
+struct B {
+  bool b;
+  A a;
+};
+
+int i = sizeof(B);
+
+// CHECK32:  *** Dumping AST Record Layout
+// CHECK32-NEXT:  0 | struct A
+// CHECK32-NEXT:  0 |   (A vtable pointer)
+// CHECK32-NEXT:| [sizeof=4, dsize=4, align=4,
+// CHECK32-NEXT:|  nvsize=4, nvalign=4]
+
+// CHECK32:  *** Dumping AST Record Layout
+// CHECK32-NEXT:  0 | struct B
+// CHECK32-NEXT:  0 |   _Bool b
+// CHECK32-NEXT:  4 |   struct A a
+// CHECK32-NEXT:  4 | (A vtable pointer)
+// CHECK32-NEXT:| [sizeof=8, dsize=8, align=4,
+// CHECK32-NEXT:|  nvsize=8, nvalign=4]
+
+// CHECK64:  *** Dumping AST Record Layout
+// CHECK64-NEXT:  0 | struct A
+// CHECK64-NEXT:  0 |   (A vtable pointer)
+// CHECK64-NEXT:| [sizeof=8, dsize=8, align=8,
+// CHECK64-NEXT:|  nvsize=8, nvalign=8]
+
+// CHECK64:  *** Dumping AST Record Layout
+// CHECK64-NEXT:  0 | struct B
+// CHECK64-NEXT:  0 |   _Bool b
+// CHECK64-NEXT:  8 |   struct A a
+// CHECK64-NEXT:  8 | (A vtable pointer)
+// CHECK64-NEXT:| [sizeof=16, dsize=16, align=8,
+// CHECK64-NEXT:|  nvsize=16, nvalign=8]
Index: clang/test/Layout/aix-double-struct-member.cpp
===
--- /dev/null
+++ clang/test/Layout/aix-double-struct-member.cpp
@@ -0,0 +1,282 @@
+// RUN: %clang_cc1 -emit-llvm-only -triple powerpc-ibm-aix-xcoff \
+// RUN: -fdump-record-layouts -fsyntax-only %s 2>/dev/null | FileCheck %s
+
+// RUN: %clang_cc1 -emit-llvm-only -triple powerpc64-ibm-aix-xcoff \
+// RUN: -fdump-record-layouts -fsyntax-only %s 2>/dev/null | FileCheck %s
+
+namespace test1 {
+// Test double alignment when it is/is not the first struct member.
+struct D {
+  double d1;
+  int i1;
+};
+
+struct DoubleFirst {
+  struct D d2;
+  int i2;
+};
+
+struct IntFirst {
+  int i3;
+  struct D d3;
+};
+
+int a = sizeof(DoubleFirst);
+int b = sizeof(IntFirst);
+
+// CHECK: *** Dumping AST Record Layout
+// CHECK-NEXT: 0 | struct test1::D
+// CHECK-NEXT: 0 |   double d1
+// CHECK-NEXT: 8 |   int i1
+// CHECK-NEXT:   | [sizeof=16, dsize=16, align=8,
+// CHECK-NEXT:   |  nvsize=16, nvalign=8]
+
+// CHECK: *** Dumping AST Record Layout
+// CHECK-NEXT: 0 | struct test1::DoubleFirst
+// CHECK-NEXT: 0 |   struct test1::D d2
+// CHECK-NEXT: 0 | double d1
+// CHECK-NEXT: 8 | int i1
+// CHECK-NEXT:16 |   int i2
+// CHECK-NEXT:   | [sizeof=24, dsize=24, align=8,
+// CHECK-NEXT:   |  nvsize=24, nvalign=8]
+
+// CHECK: *** Dumping AST Record Layout
+// CHECK-NEXT: 0 | struct test1::IntFirst
+// CHECK-NEXT: 0 |   int i3
+// CHECK-NEXT: 4 |   struct test1::D d3
+// CHECK-NEXT: 4 | double d1
+// CHECK-NEXT:12 | int i1
+// CHECK-NEXT:   | [sizeof=20, dsize=20, align=4,
+// CHECK-NEXT:   |  nvsize=20, nvalign=4]
+}; // namespace test1
+
+namespace test2 {
+// Test AIX layout for zero sized bitfield followed by double.
+struct Double {
+  int : 0;
+  double d;
+};
+
+int a = sizeof(Double);
+
+// CHECK: *** Dumping AST Record Layout
+// CHECK-NEXT: 0 | struct test2::Double
+// CHECK-NEXT:   0:- |   int
+// CHECK-NEXT: 0 |   double d
+// CHECK-NEXT:   | [sizeof=8, dsize=8, align=4,
+// CHECK-NEXT:   |  nvsize=8, nvalign=4]
+}; // namespace test2
+
+namespace test3 {
+// Test the alignment of a double member in union.
+union A {
+  int *b;
+  double d;
+};
+
+struct UnionStruct {
+  union A a;
+  int i;
+};
+
+int a = sizeof(UnionStruct);
+
+// CHECK:  *** Dumping AST Record Layout
+// CHECK-NEXT:  0 | union test

[PATCH] D78286: [analyzer] Track runtime types represented by Obj-C Class objects

2020-04-23 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

Let's land this, I guess? Fantastic work!




Comment at: clang/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp:198
+  // 'self' variable of the current class method.
+  if (ReceiverSVal == Message.getSelfSVal()) {
+// In this case, we should return the type of the enclosing class

vsavchenko wrote:
> NoQ wrote:
> > NoQ wrote:
> > > vsavchenko wrote:
> > > > NoQ wrote:
> > > > > vsavchenko wrote:
> > > > > > NoQ wrote:
> > > > > > > I believe this is pretty much always the case. At least whenever 
> > > > > > > `getInstanceReceiver()` is available. Another exception seem to 
> > > > > > > be when `ReceiverSVal` is an `UnknownVal` (in this case `self` is 
> > > > > > > going to be `SymbolRegionValue` because it's never set in the 
> > > > > > > Store), but that's it. I inferred this by looking at 
> > > > > > > `ObjCMethodCall::getInitialStackFrameContents()`.
> > > > > > > 
> > > > > > > I think we should have used `getSelfSVal()` to begin with.
> > > > > > > I believe this is pretty much always the case.
> > > > > > 
> > > > > > I didn't quite get what you mean by that
> > > > > > 
> > > > > > 
> > > > > What i'm trying to say is that `C.getSVal(RecE)` and 
> > > > > `Message.getSelfSVal()` and `Message.getReceiverSVal()` are basically 
> > > > > the same `SVal`. It shouldn't be necessary to check both or check 
> > > > > whether they're the same; you must have meant to check for something 
> > > > > else, probably something purely syntactic.
> > > > > 
> > > > > 
> > > > > 
> > > > > > I inferred this by looking at 
> > > > > > ObjCMethodCall::getInitialStackFrameContents().
> > > > > 
> > > > > Wait, so it's only true for inlined methods. For non-inlined methods 
> > > > > `getSelfSVal()` will be unknown :/
> > > > Yeah, that might be a bit extraneous to do it with `SVal`s, but this 
> > > > code for sure does its job (it is definitely not a redundant check). 
> > > > `getSelfSVal()` returns receiver of the function //containing// the 
> > > > call and not the call itself. So, it does check if we the receiver of 
> > > > the message is `self`.
> > > > 
> > > > I changed it to this way of doing things because it is consistent with 
> > > > how the same thing is done in `getRuntimeDefinition`.
> > > > `getSelfSVal()` returns receiver of the function containing the call 
> > > > and not the call itself
> > > 
> > > 😱 looks broken to me.
> > Let's rename `getSelfSVal()` so that it screamed that it's the callee's 
> > self as opposed to the caller's self, and explain in a long comment why do 
> > we even care about the caller's self. I.e., that we heuristically assume 
> > that if a class method jumps into another class method on the same class 
> > object, it's going to be devirtualized to the same class. Which isn't 
> > always the case, hence !Precise.
> > 
> > 
> I don't really think that it's a good idea to mix these two worlds:
> 
>   - **world one** - interface function that allows to get an `SVal` for 
> `self` of the containing method. It does exactly this, for no specific 
> reason. I'm on board with renaming, but we need to come up with an 
> appropriate name that describes what it gives and not why.
>   - **world two** - use-case of this interface method that tries to figure 
> out the type of the receiver (for devirtualization purposes or not).
> 
> So, the comment can be only here. I agree, I can add more explanation about 
> what we are doing in this particular piece of code, but it won't make any 
> sense to add this (or similar) comment for `getSelfSVal()`.
Ideally i'd detach `getSelfSVal()` from `CallEvent` entirely. Like, it doesn't 
even depend on the call site, why would it be part of `CallEvent` to begin 
with? This additionally takes care of **world one**.

> so that it screamed that it's the callee's self as opposed to the caller's 
> self

Mmm, the opposite, of course. `getCallerSelfSVal()`?





Comment at: clang/lib/StaticAnalyzer/Core/DynamicType.cpp:147
+static bool isLive(SymbolReaper &SR, const MemRegion *MR) {
+  return SR.isLiveRegion(MR);
+}

vsavchenko wrote:
> NoQ wrote:
> > Feel free to rename `isLiveRegion` instead if it helps :)
> Unfortunately, it is named a bit differently for a reason, - compiler 
> couldn't decide which function to use `bool isLive(const MemRegion *region)` 
> or `bool isLive(const VarRegion *VR, bool includeStoreBindings = false) 
> const` for a call `isLive(VarRegion *)` (even though it's pretty obvious). 
> Splitting `isLive` for `VarRegion` into two functions doesn't seem like an 
> easy one. The only option I can see is the introduction of `isLiveImpl` (not 
> very pretty in a header file) and two functions `isLive(const VarRegion*) 
> const ` and `isLiveIncludingStoreBindings(const VarRegion *) const`.
> 
Or rename `isLive(const VarRegion *, bool includeSto

[PATCH] D70500: [WebAssembly] Enable use of wasm-opt and LTO-enabled system libraries

2020-04-23 Thread Dan Gohman via Phabricator via cfe-commits
sunfish added a comment.

In D70500#1998994 , @bernhard wrote:

> Are there plans to offer a way to disable this behavior (or have it optional 
> in the first place)?
>  We'd like to run some custom processing between wasm-ld and wasm-opt which 
> can't happen after the latter due to some of its one-way destructive 
> optimizations (i.e. memory-packing or simplify-globals passes).
>  The only way now is to tell our users to place wasm-opt somewhere where 
> clang can't find it. Or instead of using one clang super-command to manually 
> call -cc1 and wasm-ld separately which is disappointing.
>
> Also, is it even common to place wasm-opt next to the clang executable? Who 
> is this for? Is this documented?


It's for users who want smaller wasm binaries. It's not currently documented, 
though yes, it would be nice to document it.

That said, details about how LLVM lays out memory or uses globals are 
intentionally not documented. Just as we don't make any guarantees about 
exactly which optimizations we do at -O1 vs -O2, we're don't make any 
guarantees about which optimizations are done in clang vs wasm-ld vs wasm-opt. 
Clang and wasm-ld are free to do anything wasm-opt does. Could you describe 
what you want to do in more detail? It may be possible to find alternative 
approaches, or to design a feature for it with a clear and documentable scope.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70500



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


[PATCH] D78704: [analyzer][NFC] Add unittest for FalsePositiveRefutationBRVisitor

2020-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:55
+
+  bool reachedWithNoContradiction(const CallEvent &, CheckerContext &C,
+  ProgramStateRef State) const {

It this not used in the test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78704



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


[PATCH] D78289: [analyzer] Stability improvements for IteratorModeling functions

2020-04-23 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov updated this revision to Diff 259561.
ASDenysPetrov edited the summary of this revision.
ASDenysPetrov added a comment.

I decided not to add changes of what I cannot cover by tests. So I removed them.

@NoQ @baloghadamsoftware
please, review my changes.


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

https://reviews.llvm.org/D78289

Files:
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/test/Analysis/iterator-range.cpp


Index: clang/test/Analysis/iterator-range.cpp
===
--- clang/test/Analysis/iterator-range.cpp
+++ clang/test/Analysis/iterator-range.cpp
@@ -810,6 +810,19 @@
   auto j = std::prev(i, 0); // no-warning
 }
 
+// std::prev() with int* for checking Loc value argument
+namespace std {
+template 
+T prev(T, int *);
+}
+
+void prev_loc_value(const std::vector &V, int o) {
+
+  auto i = return_any_iterator(V.begin());
+  int *offset = &o;
+  auto j = std::prev(i, offset); // no-warning
+}
+
 //
 // Structure member dereference operators
 //
Index: clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
@@ -402,7 +402,7 @@
   if (!Cont)
 return;
 
-  // At least one of the iterators have recorded positions. If one of them has
+  // At least one of the iterators has recorded positions. If one of them does
   // not then create a new symbol for the offset.
   SymbolRef Sym;
   if (!LPos || !RPos) {
@@ -422,7 +422,7 @@
 RPos = getIteratorPosition(State, RVal);
   }
 
-  // We cannot make assumpotions on `UnknownVal`. Let us conjure a symbol
+  // We cannot make assumptions on `UnknownVal`. Let us conjure a symbol
   // instead.
   if (RetVal.isUnknown()) {
 auto &SymMgr = C.getSymbolManager();
@@ -532,8 +532,9 @@
 return;
 
   const auto *value = &RHS;
+  SVal val;
   if (auto loc = RHS.getAs()) {
-const auto val = State->getRawSVal(*loc);
+val = State->getRawSVal(*loc);
 value = &val;
   }
 


Index: clang/test/Analysis/iterator-range.cpp
===
--- clang/test/Analysis/iterator-range.cpp
+++ clang/test/Analysis/iterator-range.cpp
@@ -810,6 +810,19 @@
   auto j = std::prev(i, 0); // no-warning
 }
 
+// std::prev() with int* for checking Loc value argument
+namespace std {
+template 
+T prev(T, int *);
+}
+
+void prev_loc_value(const std::vector &V, int o) {
+
+  auto i = return_any_iterator(V.begin());
+  int *offset = &o;
+  auto j = std::prev(i, offset); // no-warning
+}
+
 //
 // Structure member dereference operators
 //
Index: clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
@@ -402,7 +402,7 @@
   if (!Cont)
 return;
 
-  // At least one of the iterators have recorded positions. If one of them has
+  // At least one of the iterators has recorded positions. If one of them does
   // not then create a new symbol for the offset.
   SymbolRef Sym;
   if (!LPos || !RPos) {
@@ -422,7 +422,7 @@
 RPos = getIteratorPosition(State, RVal);
   }
 
-  // We cannot make assumpotions on `UnknownVal`. Let us conjure a symbol
+  // We cannot make assumptions on `UnknownVal`. Let us conjure a symbol
   // instead.
   if (RetVal.isUnknown()) {
 auto &SymMgr = C.getSymbolManager();
@@ -532,8 +532,9 @@
 return;
 
   const auto *value = &RHS;
+  SVal val;
   if (auto loc = RHS.getAs()) {
-const auto val = State->getRawSVal(*loc);
+val = State->getRawSVal(*loc);
 value = &val;
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D78715: [clangd] Fix modernize-loop-convert "multiple diag in flight" crash.

2020-04-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: sammccall.
Herald added subscribers: usaxena95, kadircet, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

this maybe not ideal, but it is trivial and does fix the crash.

Fixes https://github.com/clangd/clangd/issues/156.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78715

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -272,6 +272,33 @@
   "use a trailing return type for this function");
 }
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(
+template  struct Foo {
+  T *begin();
+  T *end();
+};
+struct LabelInfo {
+  int a;
+  bool b;
+};
+
+void f() {
+  Foo label_info_map;
+  [[for]] (auto it = label_info_map.begin(); it != label_info_map.end(); 
++it) {
+auto S = *it;
+  }
+}
+  )cpp");
+  TestTU TU = TestTU::withCode(Main.code());
+  TU.ClangTidyChecks = "modernize-loop-convert";
+  EXPECT_THAT(
+  TU.build().getDiagnostics(),
+  UnorderedElementsAre(::testing::AllOf(
+  Diag(Main.range(), "use range-based for loop instead"),
+  DiagSource(Diag::ClangTidy), DiagName("modernize-loop-convert";
+}
+
 TEST(DiagnosticTest, ClangTidySuppressionComment) {
   Annotations Main(R"cpp(
 int main() {
Index: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
@@ -525,6 +525,9 @@
 const ValueDecl *MaybeContainer, const UsageResult &Usages,
 const DeclStmt *AliasDecl, bool AliasUseRequired, bool AliasFromForInit,
 const ForStmt *Loop, RangeDescriptor Descriptor) {
+  // getTypeInfo may emit a diagnostic, we have to call it before constructing
+  // the Diag to avoid the "multiple-diagnostic in flight" crash in clangd.
+  auto TypeWidth = Context->getTypeInfo(Descriptor.ElemType).Width;
   auto Diag = diag(Loop->getForLoc(), "use range-based for loop instead");
 
   std::string VarName;
@@ -628,7 +631,7 @@
   !Descriptor.ElemType.isNull() &&
   Descriptor.ElemType.isTriviallyCopyableType(*Context) &&
   // TypeInfo::Width is in bits.
-  Context->getTypeInfo(Descriptor.ElemType).Width <= 8 * MaxCopySize;
+  TypeWidth <= 8 * MaxCopySize;
   bool UseCopy = CanCopy && ((VarNameFromAlias && !AliasVarIsRef) ||
  (Descriptor.DerefByConstRef && IsCheapToCopy));
 


Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -272,6 +272,33 @@
   "use a trailing return type for this function");
 }
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(
+template  struct Foo {
+  T *begin();
+  T *end();
+};
+struct LabelInfo {
+  int a;
+  bool b;
+};
+
+void f() {
+  Foo label_info_map;
+  [[for]] (auto it = label_info_map.begin(); it != label_info_map.end(); ++it) {
+auto S = *it;
+  }
+}
+  )cpp");
+  TestTU TU = TestTU::withCode(Main.code());
+  TU.ClangTidyChecks = "modernize-loop-convert";
+  EXPECT_THAT(
+  TU.build().getDiagnostics(),
+  UnorderedElementsAre(::testing::AllOf(
+  Diag(Main.range(), "use range-based for loop instead"),
+  DiagSource(Diag::ClangTidy), DiagName("modernize-loop-convert";
+}
+
 TEST(DiagnosticTest, ClangTidySuppressionComment) {
   Annotations Main(R"cpp(
 int main() {
Index: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
@@ -525,6 +525,9 @@
 const ValueDecl *MaybeContainer, const UsageResult &Usages,
 const DeclStmt *AliasDecl, bool AliasUseRequired, bool AliasFromForInit,
 const ForStmt *Loop, RangeDescriptor Descriptor) {
+  // getTypeInfo may emit a diagnostic, we have to call it before constructing
+  // the Diag to avoid the "multiple-diagnostic in flight" crash in clangd.
+  auto TypeWidth = Context->getTypeInfo(Descriptor.ElemType).Width;
   auto Diag = diag(Loop->getForLoc(), "use range-based for loop instead");
 
   std::string VarName;
@@ -628,7 +631,7 @@
   !Descriptor.ElemType.isNull() &&
   Des

[PATCH] D78704: [analyzer][NFC] Add unittest for FalsePositiveRefutationBRVisitor

2020-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:65
+
+  bool reportIfCanBeZero(const CallEvent &Call, CheckerContext &C,
+ ProgramStateRef State) const {

xazax.hun wrote:
> Maybe `reportIfArgCanBeZero`?
Perhaps a generic `reportIfTrue` would be more useful. For that you must use 
another eval function instead of `evalEQ`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78704



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


[PATCH] D50078: clang-format: support aligned nested conditionals formatting

2020-04-23 Thread Francois Ferrand via Phabricator via cfe-commits
Typz added a comment.

In D50078#1998578 , @hokein wrote:

> In D50078#1998520 , @Typz wrote:
>
> > In D50078#1998398 , @dyung wrote:
> >
> > > Hi, this change that you submitted in commit 
> > > 5daa25fd7a184524759b6ad065a8bd7e95aa149a 
> > >  
> > > seems to be causing the test "Clang-Unit :: 
> > > Format/./FormatTests.exe/FormatTest.ConfigurableUseOfTab" to randomly 
> > > fail about 50% of the time on Windows.
> > >
> > > Take the most recent 5 runs of the 
> > > llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast buildbot. Builds #31973 
> > > ,
> > >  31975 
> > > 
> > >  and 31976 
> > > 
> > >  all failed because of that test failing.
> > >
> > > On my local Windows computer, if I build your commit and run the 
> > > FormatTest unit test multiple times (the same binary without changing 
> > > anything or rebuilding), that above test fails roughly 50% of the time.
> > >
> > > Can you take a look to figure out why your change might be causing this 
> > > instability?
> >
> >
> > Hi,
> >  That is very strange indeed, nothing is supposed to be random here...
> >  I will try to have a look, but I don't have a windows computer to test, 
> > and never seen this issue on linux/macos :-/
>
>
> The linux (s390x arch) buildbot is also failing, 
> http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/31811/steps/ninja%20check%201/logs/stdio.
>  I reverted it in 47ef09e4848a970c530928496b54085cfdba5a76 
>  to make 
> buildbot happy.


Unfortunately I don't have access to either an s390x or a windows machine; is 
there a way to trigger a "private" build on buildbot, to use the same 
setup/build env ?
Or some other way to quickly get the required build env?

(Otherwise, could you please check if adding initialization of 
ConditionalsLevel to 0 in  constructor of WhitespaceManager::Change class 
(WhitespaceManager.cpp:43).cpp fixes the issue ?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50078



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


[clang-tools-extra] 89cb5d5 - [clangd] Delete remapped buffers in tests

2020-04-23 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2020-04-23T16:31:35+02:00
New Revision: 89cb5d558895706e053bc3af972aa5b15aa82863

URL: 
https://github.com/llvm/llvm-project/commit/89cb5d558895706e053bc3af972aa5b15aa82863
DIFF: 
https://github.com/llvm/llvm-project/commit/89cb5d558895706e053bc3af972aa5b15aa82863.diff

LOG: [clangd] Delete remapped buffers in tests

These buffers normally get freed after being used in a CompilerInstance.
but tests don't make use of those, so we need to free them explicitly.

Added: 


Modified: 
clang-tools-extra/clangd/unittests/PreambleTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/PreambleTests.cpp 
b/clang-tools-extra/clangd/unittests/PreambleTests.cpp
index 6382285b63fc..5ff7ebc27e09 100644
--- a/clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ b/clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -91,6 +91,8 @@ TEST(PreamblePatchTest, IncludeParsing) {
 PreamblePatch::create(FileName, PI, *EmptyPreamble).apply(*CI);
 EXPECT_THAT(CI->getPreprocessorOpts().RemappedFileBuffers,
 Contains(Pair(_, HasContents(ExpectedBuffer;
+for (const auto &RB : CI->getPreprocessorOpts().RemappedFileBuffers)
+  delete RB.second;
   }
 }
 
@@ -120,6 +122,8 @@ TEST(PreamblePatchTest, ContainsNewIncludes) {
   PreamblePatch::create(FileName, PI, *FullPreamble).apply(*CI);
   EXPECT_THAT(CI->getPreprocessorOpts().RemappedFileBuffers,
   Contains(Pair(_, HasContents(Patch;
+  for (const auto &RB : CI->getPreprocessorOpts().RemappedFileBuffers)
+delete RB.second;
 }
 
 } // namespace



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


[clang] b0a1c0b - [doc] Fix broken link. NFC.

2020-04-23 Thread Xing GUO via cfe-commits

Author: Xing GUO
Date: 2020-04-23T22:47:39+08:00
New Revision: b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8

URL: 
https://github.com/llvm/llvm-project/commit/b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8
DIFF: 
https://github.com/llvm/llvm-project/commit/b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8.diff

LOG: [doc] Fix broken link. NFC.

Added: 


Modified: 
clang/docs/ClangFormat.rst

Removed: 




diff  --git a/clang/docs/ClangFormat.rst b/clang/docs/ClangFormat.rst
index 2b0d6424e0a8..51ecabe927b5 100644
--- a/clang/docs/ClangFormat.rst
+++ b/clang/docs/ClangFormat.rst
@@ -195,7 +195,7 @@ Download the latest Visual Studio extension from the `alpha 
build site
 Visual Studio Code Integration
 ==
 
-Get the latest Visual Studio Code extension from the `Visual Studio 
Marketplace 
_`. The 
default key-binding is Alt-Shift-F.
+Get the latest Visual Studio Code extension from the `Visual Studio 
Marketplace 
`_. The 
default key-binding is Alt-Shift-F.
 
 
 Script for patch reformatting



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


[clang] b0a1c0b - [doc] Fix broken link. NFC.

2020-04-23 Thread Xing GUO via cfe-commits

Author: Xing GUO
Date: 2020-04-23T22:47:39+08:00
New Revision: b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8

URL: 
https://github.com/llvm/llvm-project/commit/b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8
DIFF: 
https://github.com/llvm/llvm-project/commit/b0a1c0b72c9c61f8b0a223e08f43498abb64f5e8.diff

LOG: [doc] Fix broken link. NFC.

Added: 


Modified: 
clang/docs/ClangFormat.rst

Removed: 




diff  --git a/clang/docs/ClangFormat.rst b/clang/docs/ClangFormat.rst
index 2b0d6424e0a8..51ecabe927b5 100644
--- a/clang/docs/ClangFormat.rst
+++ b/clang/docs/ClangFormat.rst
@@ -195,7 +195,7 @@ Download the latest Visual Studio extension from the `alpha 
build site
 Visual Studio Code Integration
 ==
 
-Get the latest Visual Studio Code extension from the `Visual Studio 
Marketplace 
_`. The 
default key-binding is Alt-Shift-F.
+Get the latest Visual Studio Code extension from the `Visual Studio 
Marketplace 
`_. The 
default key-binding is Alt-Shift-F.
 
 
 Script for patch reformatting



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


Re: [clang] 2214b90 - [clangd] Make signatureHelp work with stale preambles

2020-04-23 Thread Kadir Çetinkaya via cfe-commits
Thanks Mikael, sent out an ugly fix
at 89cb5d558895706e053bc3af972aa5b15aa82863 to get sanitizer build bots
running.

Will change the testing scheme for a proper fix.

On Thu, Apr 23, 2020 at 4:53 PM Mikael Holmén 
wrote:

> Hi Kadir,
>
> I start seeing some sanitizer complaints with this commit for the
> following two testcases:
>   ./ClangdTests/PreamblePatchTest.ContainsNewIncludes
>   ./ClangdTests/PreamblePatchTest.IncludeParsing
>
> The complaints look like this:
>
> =
> ==75126==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 369 byte(s) in 4 object(s) allocated from:
> #0 0x5bbe40 in operator new(unsigned long, std::nothrow_t const&)
> /repo/uabkaka/tmp/llvm/projects/compiler-
> rt/lib/asan/asan_new_delete.cc:112
> #1 0x149a3e9 in
> llvm::WritableMemoryBuffer::getNewUninitMemBuffer(unsigned long,
> llvm::Twine const&) /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../lib/Support/MemoryBuffer.cpp:298:34
> #2 0x1498db3 in getMemBufferCopyImpl /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../lib/Support/MemoryBuffer.cpp:127:14
> #3 0x1498db3 in
> llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, llvm::Twine
> const&) /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> sanitize-asan/llvm/build-all-asan/../lib/Support/MemoryBuffer.cpp:136
> #4 0x506012e in
> clang::clangd::PreamblePatch::apply(clang::CompilerInvocation&) const
> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
> asan/llvm/build-all-asan/../../clang-tools-
> extra/clangd/Preamble.cpp:337:7
> #5 0xf910e6 in clang::clangd::(anonymous
> namespace)::PreamblePatchTest_IncludeParsing_Test::TestBody()
> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
> asan/llvm/build-all-asan/../../clang-tools-
> extra/clangd/unittests/PreambleTests.cpp:91:57
> #6 0x164e8e0 in HandleExceptionsInMethodIfSupported void> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc
> #7 0x164e8e0 in testing::Test::Run() /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:2474
> #8 0x1651fc5 in testing::TestInfo::Run() /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:2656:11
> #9 0x1653440 in testing::TestCase::Run() /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:2774:28
> #10 0x1671e64 in testing::internal::UnitTestImpl::RunAllTests()
> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
> asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:4649:43
> #11 0x1671010 in
> HandleExceptionsInMethodIfSupported bool> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc
> #12 0x1671010 in testing::UnitTest::Run() /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:4257
> #13 0x1633040 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
> #14 0x1633040 in main /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
> #15 0x7f7dfdfe6544 in __libc_start_main (/lib64/libc.so.6+0x22544)
>
> SUMMARY: AddressSanitizer: 369 byte(s) leaked in 4 allocation(s).
>
> Regards,
> Mikael
>
> On Tue, 2020-04-21 at 01:34 -0700, Kadir Cetinkaya via cfe-commits
> wrote:
> > Author: Kadir Cetinkaya
> > Date: 2020-04-21T10:27:26+02:00
> > New Revision: 2214b9076f1d3a4784820c4479e2417685e5c980
> >
> > URL:
> >
> https://github.com/llvm/llvm-project/commit/2214b9076f1d3a4784820c4479e2417685e5c980
> > DIFF:
> >
> https://github.com/llvm/llvm-project/commit/2214b9076f1d3a4784820c4479e2417685e5c980.diff
> >
> > LOG: [clangd] Make signatureHelp work with stale preambles
> >
> > Summary:
> > This is achieved by calculating newly added includes and implicitly
> > parsing them as if they were part of the main file.
> >
> > This also gets rid of the need for consistent preamble reads.
> >
> > Reviewers: sammccall
> >
> > Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, mgrang,
> > arphaman, jfb, usaxena95, cfe-commits
> >
> > Tags: #clang
> >
> > Differential Revision: https://reviews.llvm.org/D77392
> >
> > Added:
> > clang-tools-extra/clangd/unittests/PreambleTests.cpp
> >
> > Modified:
> > clang-tools-extra

[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

2020-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2822
 PathSensitiveBugReport &BR) {
   // Collect new constraints
+  addConstraints(EndPathNode, /*OnlyForNewSymbols=*/false);

Probably you wanted to use `hasContradictionUsingZ3` starting from here. (?)



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2871
+  // Overwrite the associated constraint of the Symbol.
+  Constraints = CF.remove(Constraints, Sym);
   Constraints = CF.add(Constraints, Sym, C.second);

steakhal wrote:
> How can we simplify this?
Could we change the visitation logic to start with the `EndPathNode`? I mean 
could we exercise `FalsePositiveRefutationBRVisitor` to start the visitation 
from `EndPathNode`? If that was possible then this whole patch would be way 
simpler.
In BugReporter.cpp:
```
  // Run visitors on all nodes starting from the node *before* the last one.
  // The last node is reserved for notes generated with {@code getEndPath}.
  const ExplodedNode *NextNode = ErrorNode->getFirstPred();
  while (NextNode) {
```
Why can't we have a different visitation order implemented specifically for the 
refutation visitor? (@NoQ, @xazax.hun)



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:194
+  // This assumption is false!
+  // 'y' can not be 5 if the maximal value of both x and y is 2.
+  // This bugreport must be caught by the visitor, since the 
constraints

`x and y` -> `x and n`.



Comment at: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp:197
+  // of the bugpath are UnSAT.
+  reportIfCanBeZero(y - 5);
+}

Perhaps `reportIfTrue(y > 4)` would be easier to understand here. But then 
probably you also need a rename: `ZERO_STATE_SHOULD_NOT_EXIST` -> 
`STATE_SHOULD_NOT_EXIST`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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


[PATCH] D78457: [analyzer][Z3-refutation] Fix refutation BugReporterVisitor bug and refactor

2020-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:2871
+  // Overwrite the associated constraint of the Symbol.
+  Constraints = CF.remove(Constraints, Sym);
   Constraints = CF.add(Constraints, Sym, C.second);

martong wrote:
> steakhal wrote:
> > How can we simplify this?
> Could we change the visitation logic to start with the `EndPathNode`? I mean 
> could we exercise `FalsePositiveRefutationBRVisitor` to start the visitation 
> from `EndPathNode`? If that was possible then this whole patch would be way 
> simpler.
> In BugReporter.cpp:
> ```
>   // Run visitors on all nodes starting from the node *before* the last one.
>   // The last node is reserved for notes generated with {@code getEndPath}.
>   const ExplodedNode *NextNode = ErrorNode->getFirstPred();
>   while (NextNode) {
> ```
> Why can't we have a different visitation order implemented specifically for 
> the refutation visitor? (@NoQ, @xazax.hun)
Hmm, to answer my own question, then we would visit the ErrorNode twice. So 
then perhaps we should not allow any constraints in the ErrorNodes, right? What 
if we'd split all such ErrorNodes into a PrevNode with the constraints and a 
simple ErrorNode without the constraints?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78457



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


[PATCH] D78715: [clangd] Fix modernize-loop-convert "multiple diag in flight" crash.

2020-04-23 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Ah, nice work!
Agree it's a hack (and how many more instances are lurking) but I don't know 
how better to fix it and it's been reported 3 times...




Comment at: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp:529
+  // getTypeInfo may emit a diagnostic, we have to call it before constructing
+  // the Diag to avoid the "multiple-diagnostic in flight" crash in clangd.
+  auto TypeWidth = Context->getTypeInfo(Descriptor.ElemType).Width;

I'm not sure we need to mention clangd here - I'd expect standalone clang-tidy 
to be able to hit the same condition?
At least logically I think the bug exists either way.



Comment at: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp:275
 
+TEST(DiagnosticTest, NoMultipleDiagnosticInFlight) {
+  Annotations Main(R"cpp(

Does the bug repro with clang-tidy? If so it'd be nice to make this a 
clang-tidy test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78715



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


[PATCH] D78286: [analyzer] Track runtime types represented by Obj-C Class objects

2020-04-23 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko marked 2 inline comments as done.
vsavchenko added a comment.

> Let's land this, I guess? Fantastic work!

Thanks :-)




Comment at: clang/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp:198
+  // 'self' variable of the current class method.
+  if (ReceiverSVal == Message.getSelfSVal()) {
+// In this case, we should return the type of the enclosing class

NoQ wrote:
> vsavchenko wrote:
> > NoQ wrote:
> > > NoQ wrote:
> > > > vsavchenko wrote:
> > > > > NoQ wrote:
> > > > > > vsavchenko wrote:
> > > > > > > NoQ wrote:
> > > > > > > > I believe this is pretty much always the case. At least 
> > > > > > > > whenever `getInstanceReceiver()` is available. Another 
> > > > > > > > exception seem to be when `ReceiverSVal` is an `UnknownVal` (in 
> > > > > > > > this case `self` is going to be `SymbolRegionValue` because 
> > > > > > > > it's never set in the Store), but that's it. I inferred this by 
> > > > > > > > looking at `ObjCMethodCall::getInitialStackFrameContents()`.
> > > > > > > > 
> > > > > > > > I think we should have used `getSelfSVal()` to begin with.
> > > > > > > > I believe this is pretty much always the case.
> > > > > > > 
> > > > > > > I didn't quite get what you mean by that
> > > > > > > 
> > > > > > > 
> > > > > > What i'm trying to say is that `C.getSVal(RecE)` and 
> > > > > > `Message.getSelfSVal()` and `Message.getReceiverSVal()` are 
> > > > > > basically the same `SVal`. It shouldn't be necessary to check both 
> > > > > > or check whether they're the same; you must have meant to check for 
> > > > > > something else, probably something purely syntactic.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > I inferred this by looking at 
> > > > > > > ObjCMethodCall::getInitialStackFrameContents().
> > > > > > 
> > > > > > Wait, so it's only true for inlined methods. For non-inlined 
> > > > > > methods `getSelfSVal()` will be unknown :/
> > > > > Yeah, that might be a bit extraneous to do it with `SVal`s, but this 
> > > > > code for sure does its job (it is definitely not a redundant check). 
> > > > > `getSelfSVal()` returns receiver of the function //containing// the 
> > > > > call and not the call itself. So, it does check if we the receiver of 
> > > > > the message is `self`.
> > > > > 
> > > > > I changed it to this way of doing things because it is consistent 
> > > > > with how the same thing is done in `getRuntimeDefinition`.
> > > > > `getSelfSVal()` returns receiver of the function containing the call 
> > > > > and not the call itself
> > > > 
> > > > 😱 looks broken to me.
> > > Let's rename `getSelfSVal()` so that it screamed that it's the callee's 
> > > self as opposed to the caller's self, and explain in a long comment why 
> > > do we even care about the caller's self. I.e., that we heuristically 
> > > assume that if a class method jumps into another class method on the same 
> > > class object, it's going to be devirtualized to the same class. Which 
> > > isn't always the case, hence !Precise.
> > > 
> > > 
> > I don't really think that it's a good idea to mix these two worlds:
> > 
> >   - **world one** - interface function that allows to get an `SVal` for 
> > `self` of the containing method. It does exactly this, for no specific 
> > reason. I'm on board with renaming, but we need to come up with an 
> > appropriate name that describes what it gives and not why.
> >   - **world two** - use-case of this interface method that tries to figure 
> > out the type of the receiver (for devirtualization purposes or not).
> > 
> > So, the comment can be only here. I agree, I can add more explanation about 
> > what we are doing in this particular piece of code, but it won't make any 
> > sense to add this (or similar) comment for `getSelfSVal()`.
> Ideally i'd detach `getSelfSVal()` from `CallEvent` entirely. Like, it 
> doesn't even depend on the call site, why would it be part of `CallEvent` to 
> begin with? This additionally takes care of **world one**.
> 
> > so that it screamed that it's the callee's self as opposed to the caller's 
> > self
> 
> Mmm, the opposite, of course. `getCallerSelfSVal()`?
> 
> 
Where do you think it should be? 

My vote goes to location context.



Comment at: clang/lib/StaticAnalyzer/Core/DynamicType.cpp:147
+static bool isLive(SymbolReaper &SR, const MemRegion *MR) {
+  return SR.isLiveRegion(MR);
+}

NoQ wrote:
> vsavchenko wrote:
> > NoQ wrote:
> > > Feel free to rename `isLiveRegion` instead if it helps :)
> > Unfortunately, it is named a bit differently for a reason, - compiler 
> > couldn't decide which function to use `bool isLive(const MemRegion 
> > *region)` or `bool isLive(const VarRegion *VR, bool includeStoreBindings = 
> > false) const` for a call `isLive(VarRegion *)` (even though it's pretty 
> > obvious). Splitting `isLive` for `VarRegion` into two functions doesn't 
> > seem like an easy one. The only option I can s

[PATCH] D78286: [analyzer] Track runtime types represented by Obj-C Class objects

2020-04-23 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/DynamicTypePropagation.cpp:198
+  // 'self' variable of the current class method.
+  if (ReceiverSVal == Message.getSelfSVal()) {
+// In this case, we should return the type of the enclosing class

vsavchenko wrote:
> NoQ wrote:
> > vsavchenko wrote:
> > > NoQ wrote:
> > > > NoQ wrote:
> > > > > vsavchenko wrote:
> > > > > > NoQ wrote:
> > > > > > > vsavchenko wrote:
> > > > > > > > NoQ wrote:
> > > > > > > > > I believe this is pretty much always the case. At least 
> > > > > > > > > whenever `getInstanceReceiver()` is available. Another 
> > > > > > > > > exception seem to be when `ReceiverSVal` is an `UnknownVal` 
> > > > > > > > > (in this case `self` is going to be `SymbolRegionValue` 
> > > > > > > > > because it's never set in the Store), but that's it. I 
> > > > > > > > > inferred this by looking at 
> > > > > > > > > `ObjCMethodCall::getInitialStackFrameContents()`.
> > > > > > > > > 
> > > > > > > > > I think we should have used `getSelfSVal()` to begin with.
> > > > > > > > > I believe this is pretty much always the case.
> > > > > > > > 
> > > > > > > > I didn't quite get what you mean by that
> > > > > > > > 
> > > > > > > > 
> > > > > > > What i'm trying to say is that `C.getSVal(RecE)` and 
> > > > > > > `Message.getSelfSVal()` and `Message.getReceiverSVal()` are 
> > > > > > > basically the same `SVal`. It shouldn't be necessary to check 
> > > > > > > both or check whether they're the same; you must have meant to 
> > > > > > > check for something else, probably something purely syntactic.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > I inferred this by looking at 
> > > > > > > > ObjCMethodCall::getInitialStackFrameContents().
> > > > > > > 
> > > > > > > Wait, so it's only true for inlined methods. For non-inlined 
> > > > > > > methods `getSelfSVal()` will be unknown :/
> > > > > > Yeah, that might be a bit extraneous to do it with `SVal`s, but 
> > > > > > this code for sure does its job (it is definitely not a redundant 
> > > > > > check). `getSelfSVal()` returns receiver of the function 
> > > > > > //containing// the call and not the call itself. So, it does check 
> > > > > > if we the receiver of the message is `self`.
> > > > > > 
> > > > > > I changed it to this way of doing things because it is consistent 
> > > > > > with how the same thing is done in `getRuntimeDefinition`.
> > > > > > `getSelfSVal()` returns receiver of the function containing the 
> > > > > > call and not the call itself
> > > > > 
> > > > > 😱 looks broken to me.
> > > > Let's rename `getSelfSVal()` so that it screamed that it's the callee's 
> > > > self as opposed to the caller's self, and explain in a long comment why 
> > > > do we even care about the caller's self. I.e., that we heuristically 
> > > > assume that if a class method jumps into another class method on the 
> > > > same class object, it's going to be devirtualized to the same class. 
> > > > Which isn't always the case, hence !Precise.
> > > > 
> > > > 
> > > I don't really think that it's a good idea to mix these two worlds:
> > > 
> > >   - **world one** - interface function that allows to get an `SVal` for 
> > > `self` of the containing method. It does exactly this, for no specific 
> > > reason. I'm on board with renaming, but we need to come up with an 
> > > appropriate name that describes what it gives and not why.
> > >   - **world two** - use-case of this interface method that tries to 
> > > figure out the type of the receiver (for devirtualization purposes or 
> > > not).
> > > 
> > > So, the comment can be only here. I agree, I can add more explanation 
> > > about what we are doing in this particular piece of code, but it won't 
> > > make any sense to add this (or similar) comment for `getSelfSVal()`.
> > Ideally i'd detach `getSelfSVal()` from `CallEvent` entirely. Like, it 
> > doesn't even depend on the call site, why would it be part of `CallEvent` 
> > to begin with? This additionally takes care of **world one**.
> > 
> > > so that it screamed that it's the callee's self as opposed to the 
> > > caller's self
> > 
> > Mmm, the opposite, of course. `getCallerSelfSVal()`?
> > 
> > 
> Where do you think it should be? 
> 
> My vote goes to location context.
As of now `LocationContext` is an entity so low-level that it doesn't even live 
in `libStaticAnalyzer*`, so it can't be made aware of `SVal`s.

Given that it's basically a Store lookup, i'd recommend putting it into 
`ProgramState`. I.e., `State->getSelfSVal(LCtx);`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78286



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


[PATCH] D46472: [HIP] Support offloading by linker script

2020-04-23 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 2 inline comments as done.
yaxunl added inline comments.



Comment at: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp:1329
+  // Get the HIP offload tool chain.
+  auto *HIPTC = static_cast(
+  C.getSingleOffloadToolChain());

JonChesterfield wrote:
> Should this be `toolchains::HipToolChain`?
will fix. thanks


Repository:
  rL LLVM

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

https://reviews.llvm.org/D46472



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


[PATCH] D70500: [WebAssembly] Enable use of wasm-opt and LTO-enabled system libraries

2020-04-23 Thread bernhard via Phabricator via cfe-commits
bernhard added a comment.

> It's for users who want smaller wasm binaries. It's not currently documented, 
> though yes, it would be nice to document it.

But how would a user even end up with wasm-opt in the same directory of clang 
binaries?

> Clang and wasm-ld are free to do anything wasm-opt does. Could you describe 
> what you want to do in more detail? It may be possible to find alternative 
> approaches, or to design a feature for it with a clear and documentable scope.

I'm generating additional data segments which while doing so increases the 
initial memory pages count and shifts any globals that point to __heap_base and 
global[0] (stack ptr init).

Due to memory-packing the end of data becomes ambiguous (-export=__data_end 
would mitigate that but it's nice to be compatible with any un-opt'ed wasm 
file), and due to simplify-globals with remove-unused-module-elements the 
global[0] can get copied/moved directly into the code section.
I am aware that this treads very much in undocumented assumptions, it is still 
experimental but it works. This hidden execution of wasm-opt is mostly making 
documentation on my end a bit harder.

If wasm-ld were to do these passes on its own I think there would at least be 
options passable with -Xlinker to make it not do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70500



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


[PATCH] D77062: [analyzer] Added check for unacceptable equality operation between Loc and NonLoc types

2020-04-23 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

@Szelethus, could you, please, make some suggestions about my investigation 
above?


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

https://reviews.llvm.org/D77062



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


[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-23 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 259584.
balazske added a comment.

- Separating test files, fixing alignof problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809

Files:
  clang/lib/Analysis/CFG.cpp
  clang/test/Analysis/cfg.c
  clang/test/Analysis/cfg.cpp

Index: clang/test/Analysis/cfg.cpp
===
--- clang/test/Analysis/cfg.cpp
+++ clang/test/Analysis/cfg.cpp
@@ -12,42 +12,6 @@
 // off. Feel free to add tests that test only one of the CFG flavors if you're
 // not sure how the other flavor is supposed to work in your case.
 
-// CHECK-LABEL: void checkWrap(int i)
-// CHECK: ENTRY
-// CHECK-NEXT: Succs (1): B1
-// CHECK: [B1]
-// CHECK: Succs (21): B2 B3 B4 B5 B6 B7 B8 B9
-// CHECK: B10 B11 B12 B13 B14 B15 B16 B17 B18 B19
-// CHECK: B20 B21 B0
-// CHECK: [B0 (EXIT)]
-// CHECK-NEXT: Preds (21): B2 B3 B4 B5 B6 B7 B8 B9
-// CHECK-NEXT: B10 B11 B12 B13 B14 B15 B16 B17 B18 B19
-// CHECK-NEXT: B20 B21 B1
-void checkWrap(int i) {
-  switch(i) {
-case 0: break;
-case 1: break;
-case 2: break;
-case 3: break;
-case 4: break;
-case 5: break;
-case 6: break;
-case 7: break;
-case 8: break;
-case 9: break;
-case 10: break;
-case 11: break;
-case 12: break;
-case 13: break;
-case 14: break;
-case 15: break;
-case 16: break;
-case 17: break;
-case 18: break;
-case 19: break;
-  }
-}
-
 // CHECK-LABEL: void checkDeclStmts()
 // CHECK: ENTRY
 // CHECK-NEXT: Succs (1): B1
@@ -84,24 +48,6 @@
   static_assert(1, "abc");
 }
 
-
-// CHECK-LABEL: void checkGCCAsmRValueOutput()
-// CHECK: [B2 (ENTRY)]
-// CHECK-NEXT: Succs (1): B1
-// CHECK: [B1]
-// CHECK-NEXT:   1: int arg
-// CHECK-NEXT:   2: arg
-// CHECK-NEXT:   3: (int)[B1.2] (CStyleCastExpr, NoOp, int)
-// CHECK-NEXT:   4: asm ("" : "=r" ([B1.3]));
-// CHECK-NEXT:   5: arg
-// CHECK-NEXT:   6: asm ("" : "=r" ([B1.5]));
-void checkGCCAsmRValueOutput() {
-  int arg;
-  __asm__("" : "=r"((int)arg));  // rvalue output operand
-  __asm__("" : "=r"(arg));   // lvalue output operand
-}
-
-
 // CHECK-LABEL: void F(EmptyE e)
 // CHECK: ENTRY
 // CHECK-NEXT: Succs (1): B1
@@ -136,7 +82,6 @@
   (void)__builtin_object_size(dummy(), 0);
 }
 
-
 class A {
 public:
   A() {}
@@ -355,7 +300,6 @@
   return x;
 }
 
-
 // CHECK-LABEL: void test_placement_new()
 // CHECK:  [B2 (ENTRY)]
 // CHECK-NEXT:  Succs (1): B1
@@ -547,25 +491,96 @@
 }
 } // namespace statement_expression_in_return
 
-// CHECK-LABEL: int overlap_compare(int x)
-// CHECK: [B2]
-// CHECK-NEXT:   1: 1
-// CHECK-NEXT:   2: return [B2.1];
-// CHECK-NEXT:   Preds (1): B3(Unreachable)
-// CHECK-NEXT:   Succs (1): B0
-// CHECK: [B3]
+// CHECK-LABEL: void vla_simple(int x)
+// CHECK: [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: int vla[x];
+void vla_simple(int x) {
+  int vla[x];
+}
+
+// CHECK-LABEL: void vla_typedef(int x)
+// CHECK: [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: typedef int VLA[x];
+void vla_typedef(int x) {
+  typedef int VLA[x];
+}
+
+// CHECK-LABEL: void vla_typealias(int x)
+// CHECK: [B1]
 // CHECK-NEXT:   1: x
-// CHECK-NEXT:   2: [B3.1] (ImplicitCastExpr, LValueToRValue, int)
-// CHECK-NEXT:   3: 5
-// CHECK-NEXT:   4: [B3.2] > [B3.3]
-// CHECK-NEXT:   T: if [B4.5] && [B3.4]
-// CHECK-NEXT:   Preds (1): B4
-// CHECK-NEXT:   Succs (2): B2(Unreachable) B1
-int overlap_compare(int x) {
-  if (x == -1 && x > 5)
-return 1;
-
-  return 2;
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: using VLA = int [x];
+void vla_typealias(int x) {
+  using VLA = int[x];
+}
+
+// CHECK-LABEL: void vla_typedef_multi(int x, int y)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: y
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: x
+// CHECK-NEXT:   4: [B1.3] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   5: typedef int VLA[x][y];
+void vla_typedef_multi(int x, int y) {
+  typedef int VLA[x][y];
+}
+
+// CHECK-LABEL: void vla_typedefname_multi(int x, int y)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: x
+// CHECK-NEXT:   2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   3: typedef int VLA[x];
+// CHECK-NEXT:   4: y
+// CHECK-NEXT:   5: [B1.4] (ImplicitCastExpr, LValueToRValue, int)
+// CHECK-NEXT:   6: typedef VLA VLA1[y];
+// CHECK-NEXT:   7: 3
+// CHECK-NEXT:   8: using VLA2 = VLA1 [3];
+// CHECK-NEXT:   9: 4
+// CHECK-NEXT:  10: VLA2 vla[4];
+void vla_typedefname_multi(int x, int y) {
+  typedef int VLA[x];
+  typedef VLA VLA1[y];
+  using VLA2 = VLA1[3];
+  VLA2 vla[4];
+}
+
+// CHECK-LABEL: void vla_embedded(int x)
+// CHECK:  [B1]
+// CHECK-NEXT:   1: void (*vla)(int *);
+void vla_embedded(int x) {
+  // FIXME: 'x' is not generated but should b

[PATCH] D78677: [SveEmitter] Add builtins for gather prefetches

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 259589.
sdesmalen added a comment.

- Updated the tests to use `SVE_ACLE_FUNC` for the overloaded builtins.


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

https://reviews.llvm.org/D78677

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfh.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -599,6 +599,12 @@
 Float = true;
 ElementBitwidth = 64;
 break;
+  case 'Q':
+Constant = true;
+Pointer = true;
+Void = true;
+NumVectors = 0;
+break;
   case 'S':
 Constant = true;
 Pointer = true;
Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
===
--- clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
@@ -116,3 +116,77 @@
   // CHECK: @llvm.aarch64.sve.prf.nxv4i1( %[[PG]], i8* %[[I8_BASE]], i32 0)
   return svprfw_vnum(pg, base, vnum, SV_PLDL1KEEP);
 }
+
+void test_svprfw_gather_u32base(svbool_t pg, svuint32_t bases)
+{
+  // CHECK-LABEL: test_svprfw_gather_u32base
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.scalar.offset.nxv4i32( %[[PG]],  %bases, i64 0, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather,_u32base,,)(pg, bases, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u64base(svbool_t pg, svuint64_t bases)
+{
+  // CHECK-LABEL: test_svprfw_gather_u64base
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.scalar.offset.nxv2i64( %[[PG]],  %bases, i64 0, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather,_u64base,,)(pg, bases, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_s32index(svbool_t pg, const void *base, svint32_t indices)
+{
+  // CHECK-LABEL: test_svprfw_gather_s32index
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.sxtw.index.nxv4i32( %[[PG]], i8* %base,  %indices, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather_,s32,index,)(pg, base, indices, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_s64index(svbool_t pg, const void *base, svint64_t indices)
+{
+  // CHECK-LABEL: test_svprfw_gather_s64index
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.index.nxv2i64( %[[PG]], i8* %base,  %indices, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather_,s64,index,)(pg, base, indices, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u32index(svbool_t pg, const void *base, svuint32_t indices)
+{
+  // CHECK-LABEL: test_svprfw_gather_u32index
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.uxtw.index.nxv4i32( %[[PG]], i8* %base,  %indices, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather_,u32,index,)(pg, base, indices, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u64index(svbool_t pg, const void *base, svuint64_t indices)
+{
+  // CHECK-LABEL: test_svprfw_gather_u64index
+  // CHECK: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.index.nxv2i64( %[[PG]], i8* %base,  %indices, i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather_,u64,index,)(pg, base, indices, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u32base_index(svbool_t pg, svuint32_t bases, int64_t index)
+{
+  // CHECK-LABEL: test_svprfw_gather_u32base_index
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv4i1( %pg)
+  // CHECK-DAG: %[[SHL:.*]] = shl i64 %index, 2
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.scalar.offset.nxv4i32( %[[PG]],  %bases, i64 %[[SHL]], i32 0)
+  // CHECK: ret void
+  return SVE_ACLE_FUNC(svprfw_gather,_u32base,_index,)(pg, bases, index, SV_PLDL1KEEP);
+}
+
+void test_svprfw_gather_u64base_index(svbool_t pg, svuint64_t bases, int64_t index)
+{
+  // CHECK-LABEL: test_svprfw_gather_u64base_index
+  // CHECK-DAG: %[[PG:.*]] = call  @llvm.aarch64.sve.convert.from.svbool.nxv2i1( %pg)
+  // CHECK-DAG: %[[SHL:.*]] = shl i64 %index, 2
+  // CHECK: call void @llvm.aarch64.sve.prfw.gather.scalar.offset.nxv2i64( %[[PG]],  %bases, i64 %[[SHL]], i32 0

[PATCH] D78674: [SveEmitter] Add builtins for contiguous prefetches

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 259587.
sdesmalen marked an inline comment as done.
sdesmalen added a comment.

- Don't emit bitcast+gep+bitcast when offset is 0.
- Added negative tests for _vnum cases.


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

https://reviews.llvm.org/D78674

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfh.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfh.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfw.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -537,6 +537,15 @@
 Immediate = true;
 PredicatePattern = true;
 break;
+  case 'J':
+Predicate = false;
+Float = false;
+ElementBitwidth = Bitwidth = 32;
+NumVectors = 0;
+Signed = true;
+Immediate = true;
+PrefetchOp = true;
+break;
   case 'k':
 Predicate = false;
 Signed = true;
@@ -704,6 +713,9 @@
   if (T.isPredicatePattern())
 ImmChecks.emplace_back(
 I - 1, Emitter.getEnumValueForImmCheck("ImmCheck0_31"));
+  else if (T.isPrefetchOp())
+ImmChecks.emplace_back(
+I - 1, Emitter.getEnumValueForImmCheck("ImmCheck0_13"));
 }
   }
 
@@ -1006,6 +1018,22 @@
   OS << "  SV_ALL = 31\n";
   OS << "} sv_pattern;\n\n";
 
+  OS << "typedef enum\n";
+  OS << "{\n";
+  OS << "  SV_PLDL1KEEP = 0,\n";
+  OS << "  SV_PLDL1STRM = 1,\n";
+  OS << "  SV_PLDL2KEEP = 2,\n";
+  OS << "  SV_PLDL2STRM = 3,\n";
+  OS << "  SV_PLDL3KEEP = 4,\n";
+  OS << "  SV_PLDL3STRM = 5,\n";
+  OS << "  SV_PSTL1KEEP = 8,\n";
+  OS << "  SV_PSTL1STRM = 9,\n";
+  OS << "  SV_PSTL2KEEP = 10,\n";
+  OS << "  SV_PSTL2STRM = 11,\n";
+  OS << "  SV_PSTL3KEEP = 12,\n";
+  OS << "  SV_PSTL3STRM = 13\n";
+  OS << "} sv_prfop;\n\n";
+
   OS << "/* Function attributes */\n";
   OS << "#define __aio static inline __attribute__((__always_inline__, "
 "__nodebug__, __overloadable__))\n\n";
Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfw.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfw.c
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+
+#include 
+
+void test_svprfw(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value 14 is outside the valid range [0, 13]}}
+  return svprfw(pg, base, 14);
+}
+
+void test_svprfw_1(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfw(pg, base, -1);
+}
+
+void test_svprfw_vnum(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value 14 is outside the valid range [0, 13]}}
+  return svprfw_vnum(pg, base, 0, 14);
+}
+
+void test_svprfw_vnum_1(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfw_vnum(pg, base, 0, -1);
+}
Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfh.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfh.c
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+
+#include 
+
+void test_svprfh(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value 14 is outside the valid range [0, 13]}}
+  return svprfh(pg, base, 14);
+}
+
+void test_svprfh_1(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfh(pg, base, -1);
+}
+
+void test_svprfh_vnum(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value 14 is outside the valid range [0, 13]}}
+  return svprfh_vnum(pg, base, 0, 14);
+}
+
+void test_svprfh_vnum_1(svbool_t pg, const void *base)
+{
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfh_vnum(pg, base, 0, -1);
+}
Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfd.c

[PATCH] D78573: [Clang][Sema] Capturing section type conflicts between #pragma clang section and section attributes

2020-04-23 Thread Lucas Prates via Phabricator via cfe-commits
pratlucas updated this revision to Diff 259594.
pratlucas added a comment.

Rebasing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78573

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/pragma-clang-section.c

Index: clang/test/Sema/pragma-clang-section.c
===
--- clang/test/Sema/pragma-clang-section.c
+++ clang/test/Sema/pragma-clang-section.c
@@ -22,4 +22,9 @@
 #pragma clang section bss = "myrodata.1"   // expected-error {{this causes a section type conflict with a prior #pragma section}}
 #pragma clang section text = "mybss.3" // expected-error {{this causes a section type conflict with a prior #pragma section}}
 
+#pragma clang section rodata = "myrodata.4"  // expected-note {{#pragma entered here}}
+int x __attribute__((section("myrodata.4")));// expected-error {{'x' causes a section type conflict with a prior #pragma section}}
+const int y __attribute__((section("myrodata.5"))) = 10; // expected-note {{declared here}}
+#pragma clang section data = "myrodata.5"// expected-error {{this causes a section type conflict with 'y'}}
+
 int a;
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -12746,7 +12746,7 @@
   if (GlobalStorage && var->isThisDeclarationADefinition() &&
   !inTemplateInstantiation()) {
 PragmaStack *Stack = nullptr;
-int SectionFlags = ASTContext::PSF_Implicit | ASTContext::PSF_Read;
+int SectionFlags = ASTContext::PSF_Read;
 if (var->getType().isConstQualified())
   Stack = &ConstSegStack;
 else if (!var->getInit()) {
@@ -12756,14 +12756,19 @@
   Stack = &DataSegStack;
   SectionFlags |= ASTContext::PSF_Write;
 }
-if (Stack->CurrentValue && !var->hasAttr())
+if (const SectionAttr *SA = var->getAttr()) {
+  if (SA->getSyntax() == AttributeCommonInfo::AS_Declspec)
+SectionFlags |= ASTContext::PSF_Implicit;
+  UnifySection(SA->getName(), SectionFlags, var);
+} else if (Stack->CurrentValue) {
+  SectionFlags |= ASTContext::PSF_Implicit;
+  auto SectionName = Stack->CurrentValue->getString();
   var->addAttr(SectionAttr::CreateImplicit(
-  Context, Stack->CurrentValue->getString(),
-  Stack->CurrentPragmaLocation, AttributeCommonInfo::AS_Pragma,
-  SectionAttr::Declspec_allocate));
-if (const SectionAttr *SA = var->getAttr())
-  if (UnifySection(SA->getName(), SectionFlags, var))
+  Context, SectionName, Stack->CurrentPragmaLocation,
+  AttributeCommonInfo::AS_Pragma, SectionAttr::Declspec_allocate));
+  if (UnifySection(SectionName, SectionFlags, var))
 var->dropAttr();
+}
 
 // Apply the init_seg attribute if this has an initializer.  If the
 // initializer turns out to not be dynamic, we'll end up ignoring this
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ -471,42 +471,49 @@
 bool Sema::UnifySection(StringRef SectionName,
 int SectionFlags,
 DeclaratorDecl *Decl) {
-  auto Section = Context.SectionInfos.find(SectionName);
-  if (Section == Context.SectionInfos.end()) {
+  SourceLocation PragmaLocation;
+  if (auto A = Decl->getAttr())
+if (A->isImplicit())
+  PragmaLocation = A->getLocation();
+  auto SectionIt = Context.SectionInfos.find(SectionName);
+  if (SectionIt == Context.SectionInfos.end()) {
 Context.SectionInfos[SectionName] =
-ASTContext::SectionInfo(Decl, SourceLocation(), SectionFlags);
+ASTContext::SectionInfo(Decl, PragmaLocation, SectionFlags);
 return false;
   }
   // A pre-declared section takes precedence w/o diagnostic.
-  if (Section->second.SectionFlags == SectionFlags ||
-  !(Section->second.SectionFlags & ASTContext::PSF_Implicit))
+  const auto &Section = SectionIt->second;
+  if (Section.SectionFlags == SectionFlags ||
+  ((SectionFlags & ASTContext::PSF_Implicit) &&
+   !(Section.SectionFlags & ASTContext::PSF_Implicit)))
 return false;
-  auto OtherDecl = Section->second.Decl;
-  Diag(Decl->getLocation(), diag::err_section_conflict)
-  << Decl << OtherDecl;
-  Diag(OtherDecl->getLocation(), diag::note_declared_at)
-  << OtherDecl->getName();
-  if (auto A = Decl->getAttr())
-if (A->isImplicit())
-  Diag(A->getLocation(), diag::note_pragma_entered_here);
-  if (auto A = OtherDecl->getAttr())
-if (A->isImplicit())
-  Diag(A->getLocation(), diag::note_pragma_entered_here);
+  Diag(Decl->getLocation(), diag::err_section_conflict) << Decl << Section;
+  if (Section.Dec

[PATCH] D76996: [analyzer] Improve PlacementNewChecker

2020-04-23 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/CheckPlacementNew.cpp:261
+
+  if (const VarRegion *TheVarRegion = BaseRegion->getAs()) {
+const VarDecl *TheVarDecl = TheVarRegion->getDecl();

Perhaps you could call instead `checkVarRegionAlign()`?



Comment at: clang/lib/StaticAnalyzer/Checkers/CheckPlacementNew.cpp:261
+
+  if (const VarRegion *TheVarRegion = BaseRegion->getAs()) {
+const VarDecl *TheVarDecl = TheVarRegion->getDecl();

martong wrote:
> Perhaps you could call instead `checkVarRegionAlign()`?
Also, I think `BaseRegion` can be an `ElementRegion` here as well. So, in that 
case we should call into `checkElementRegionAlign()`, shouldn't we? This draws 
a pattern that we should recursively descend down to the top most base region. 
I.e. the different `check*RegionAlign` methods should call into each other 
until we reach the top level base region.

The observation here is that the alignment of a region can be correct only if 
we can prove that its base region is aligned properly (and other requirements, 
e.g. the offset is divisible). But the base region may have another base region 
and we have to prove the alignment correctness to that as well.

I hope this makes sense, please correct me if I am wrong.



Comment at: clang/test/Analysis/placement-new.cpp:245
+
+  // ok. 2(short align) + 3*2(index '3' offset)
+  ::new (&b[3]) long;

So these tests failed after you rewrote ElementRegion processing, right?
Actually, I wonder why we thought that if x is divisible by 2 then (x+6) will 
be divisible by 8 unconditionally.It's good you have this fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76996



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


[PATCH] D78674: [SveEmitter] Add builtins for contiguous prefetches

2020-04-23 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen marked an inline comment as done.
sdesmalen added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7727
+  Value *Offset = Ops.size() > 3 ? Ops[2] : Builder.getInt32(0);
+  BasePtr = Builder.CreateGEP(MemoryTy, BasePtr, Offset);
+

efriedma wrote:
> It seems sort of silly to emit a no-op bitcast+gep+bitcast in the `Ops.size() 
> <= 3` case, but I guess it doesn't matter much.
You're right that was a bit silly. I've changed it now.



Comment at: 
clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_prfb.c:22
+  // expected-error@+1 {{argument value -1 is outside the valid range [0, 13]}}
+  return svprfb(pg, base, -1);
+}

efriedma wrote:
> Maybe worth adding a negative test for svprfb_vnum?
Yes good catch I've added them. I'm not necessarily sure we also need to add 
them for all the gather variants as well. I think just having tests where the 
position of the prefetch specifier is different should be sufficient.


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

https://reviews.llvm.org/D78674



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


[PATCH] D78572: [Clang][Sema] Capturing section type conflicts on #pragma clang section

2020-04-23 Thread Lucas Prates via Phabricator via cfe-commits
pratlucas updated this revision to Diff 259593.
pratlucas added a comment.

Rebasing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78572

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/Sema/pragma-clang-section.c


Index: clang/test/Sema/pragma-clang-section.c
===
--- clang/test/Sema/pragma-clang-section.c
+++ clang/test/Sema/pragma-clang-section.c
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -triple arm-none-eabi
-#pragma clang section bss="mybss.1" data="mydata.1" rodata="myrodata.1" 
text="mytext.1"
+#pragma clang section bss = "mybss.1" data = "mydata.1" rodata = "myrodata.1" 
text = "mytext.1" // expected-note {{#pragma entered here}} expected-note 
{{#pragma entered here}}
 #pragma clang section bss="" data="" rodata="" text=""
 #pragma clang section
 
@@ -16,4 +16,10 @@
 #pragma clang section text "text.2"   // expected-error {{expected '=' 
following '#pragma clang section text'}}
 #pragma clang section relro "relro.2"   // expected-error {{expected '=' 
following '#pragma clang section relro'}}
 #pragma clang section bss="" data="" rodata="" text="" more //expected-error 
{{expected one of [bss|data|rodata|text|relro] section kind in '#pragma clang 
section'}}
+
+#pragma clang section bss = "mybss.3" data = "mybss.3" // expected-error 
{{this causes a section type conflict with a prior #pragma section}} 
expected-note {{#pragma entered here}} expected-note {{#pragma entered here}}
+#pragma clang section rodata = "mydata.1"  // expected-error 
{{this causes a section type conflict with a prior #pragma section}}
+#pragma clang section bss = "myrodata.1"   // expected-error 
{{this causes a section type conflict with a prior #pragma section}}
+#pragma clang section text = "mybss.3" // expected-error 
{{this causes a section type conflict with a prior #pragma section}}
+
 int a;
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ -256,12 +256,15 @@
 void Sema::ActOnPragmaClangSection(SourceLocation PragmaLoc, 
PragmaClangSectionAction Action,
PragmaClangSectionKind SecKind, StringRef 
SecName) {
   PragmaClangSection *CSec;
+  int SectionFlags = ASTContext::PSF_Read;
   switch (SecKind) {
 case PragmaClangSectionKind::PCSK_BSS:
   CSec = &PragmaClangBSSSection;
+  SectionFlags |= ASTContext::PSF_Write | ASTContext::PSF_ZeroInit;
   break;
 case PragmaClangSectionKind::PCSK_Data:
   CSec = &PragmaClangDataSection;
+  SectionFlags |= ASTContext::PSF_Write;
   break;
 case PragmaClangSectionKind::PCSK_Rodata:
   CSec = &PragmaClangRodataSection;
@@ -271,6 +274,7 @@
   break;
 case PragmaClangSectionKind::PCSK_Text:
   CSec = &PragmaClangTextSection;
+  SectionFlags |= ASTContext::PSF_Execute;
   break;
 default:
   llvm_unreachable("invalid clang section kind");
@@ -281,6 +285,9 @@
 return;
   }
 
+  if (UnifySection(SecName, SectionFlags, PragmaLoc))
+return;
+
   CSec->Valid = true;
   CSec->SectionName = std::string(SecName);
   CSec->PragmaLocation = PragmaLoc;
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -1845,6 +1845,7 @@
   return;
 }
 
+SourceLocation PragmaLocation = Tok.getLocation();
 PP.Lex(Tok); // eat ['bss'|'data'|'rodata'|'text']
 if (Tok.isNot(tok::equal)) {
   PP.Diag(Tok.getLocation(), 
diag::err_pragma_clang_section_expected_equal) << SecKind;
@@ -1855,10 +1856,11 @@
 if (!PP.LexStringLiteral(Tok, SecName, "pragma clang section", false))
   return;
 
-Actions.ActOnPragmaClangSection(Tok.getLocation(),
-  (SecName.size()? Sema::PragmaClangSectionAction::PCSA_Set :
-   Sema::PragmaClangSectionAction::PCSA_Clear),
-   SecKind, SecName);
+Actions.ActOnPragmaClangSection(
+PragmaLocation,
+(SecName.size() ? Sema::PragmaClangSectionAction::PCSA_Set
+: Sema::PragmaClangSectionAction::PCSA_Clear),
+SecKind, SecName);
   }
 }
 
Index: clang/include/clang/AST/ASTContext.h
===
--- clang/include/clang/AST/ASTContext.h
+++ clang/include/clang/AST/ASTContext.h
@@ -2976,6 +2976,7 @@
 PSF_Write = 0x2,
 PSF_Execute = 0x4,
 PSF_Implicit = 0x8,
+PSF_ZeroInit = 0x10,
 PSF_Invalid = 0x8000U,
   };
 


Index: clang/test/Sema/pragma-clang-section.c
===
--- clang/test/Sema/pragma-clang-section.c
+++ clang/t

[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM with a minor nit, thank you!




Comment at: clang/lib/Analysis/CFG.cpp:2855
+ VA = FindVA(VA->getElementType().getTypePtr())) {
+  if (CFGBlock *newBlock = addStmt(VA->getSizeExpr()))
+LastBlock = newBlock;

newBlock -> NewBlock per coding standard.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D78726: [CUDA] Define __CUDACC_DEBUG__ when compiling device code in debug mode

2020-04-23 Thread Raul Tambre via Phabricator via cfe-commits
tambre created this revision.
tambre added a reviewer: tra.
Herald added subscribers: cfe-commits, yaxunl.
Herald added a project: clang.

NVCC defines __CUDACC_DEBUG__ when compiling device code in debug mode.
Let's do the same to help with compatibility between the two and possibly 
enable users to select debug-friendly code.

Implements PR45596.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78726

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/test/Driver/cuda-options.cu


Index: clang/test/Driver/cuda-options.cu
===
--- clang/test/Driver/cuda-options.cu
+++ clang/test/Driver/cuda-options.cu
@@ -183,6 +183,9 @@
 // RUN:   -c %s 2>&1 \
 // RUN: | FileCheck -check-prefixes FATBIN-COMMON,PTX-SM35,PTX-SM30 %s
 
+// Verify that -g adds __CUDACC_DEBUG__ define.
+// RUN: %clang -### -target x86_64-linux-gnu -g %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEBUG %s
 
 // ARCH-SM20: "-cc1"{{.*}}"-target-cpu" "sm_20"
 // NOARCH-SM20-NOT: "-cc1"{{.*}}"-target-cpu" "sm_20"
@@ -287,3 +290,5 @@
 // FATBIN-COMMON: "--image=profile=sm_35,file=
 // PTX-SM35: "--image=profile=compute_35,file=
 // NOPTX-SM35-NOT: "--image=profile=compute_35,file=
+
+// DEBUG: -D__CUDACC_DEBUG__
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -626,6 +626,11 @@
   if (DriverArgs.hasArg(options::OPT_nogpulib))
 return;
 
+  // NVCC defines __CUDACC_DEBUG__ for device code when compiling with debug
+  // info.
+  if (mustEmitDebugInfo(DriverArgs) == EmitSameDebugInfoAsHost)
+CC1Args.push_back("-D__CUDACC_DEBUG__");
+
   std::string LibDeviceFile = CudaInstallation.getLibDeviceFile(GpuArch);
 
   if (LibDeviceFile.empty()) {


Index: clang/test/Driver/cuda-options.cu
===
--- clang/test/Driver/cuda-options.cu
+++ clang/test/Driver/cuda-options.cu
@@ -183,6 +183,9 @@
 // RUN:   -c %s 2>&1 \
 // RUN: | FileCheck -check-prefixes FATBIN-COMMON,PTX-SM35,PTX-SM30 %s
 
+// Verify that -g adds __CUDACC_DEBUG__ define.
+// RUN: %clang -### -target x86_64-linux-gnu -g %s 2>&1 \
+// RUN: | FileCheck -check-prefix DEBUG %s
 
 // ARCH-SM20: "-cc1"{{.*}}"-target-cpu" "sm_20"
 // NOARCH-SM20-NOT: "-cc1"{{.*}}"-target-cpu" "sm_20"
@@ -287,3 +290,5 @@
 // FATBIN-COMMON: "--image=profile=sm_35,file=
 // PTX-SM35: "--image=profile=compute_35,file=
 // NOPTX-SM35-NOT: "--image=profile=compute_35,file=
+
+// DEBUG: -D__CUDACC_DEBUG__
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -626,6 +626,11 @@
   if (DriverArgs.hasArg(options::OPT_nogpulib))
 return;
 
+  // NVCC defines __CUDACC_DEBUG__ for device code when compiling with debug
+  // info.
+  if (mustEmitDebugInfo(DriverArgs) == EmitSameDebugInfoAsHost)
+CC1Args.push_back("-D__CUDACC_DEBUG__");
+
   std::string LibDeviceFile = CudaInstallation.getLibDeviceFile(GpuArch);
 
   if (LibDeviceFile.empty()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D74813: [RFC] Add hash of block contents to function block names

2020-04-23 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington added inline comments.



Comment at: clang/lib/AST/Mangle.cpp:41
+  for (ParmVarDecl *PVD : BD->parameters()) {
+Context.mangleTypeName(PVD->getType(), Out);
+  }

>>! In D74813#1996143, @alexbdv wrote:
> @dexonsmith, @erik.pilkington - how about this ? 
> 
> Z7my_mainv_block_invoke_ZTSi_ZTSj_ZTSPVK3sss
> 

That doesn't look quite right, `_ZTSi` means the typeinfo symbol for int, but 
we really should just be printing the type, `i`. I think we should add a new 
member on MangleContext (in Mangle.h) for mangling block invocation functions, 
then implement it in ItaniumMangle.cpp to call `CXXNameMangler::mangleType` for 
each parameter (the MS mangling can probably just be left as-is, I don't think 
it matters all that much for blocks).



Comment at: llvm/include/llvm/Demangle/ItaniumDemangle.h:5537
+
+  paramType->print(ParamOS);
+}

alexbdv wrote:
> erik.pilkington wrote:
> > Can you make a special BlockInvocationFunction AST node that stores the 
> > parameter types as AST nodes (rather than strings) in a NodeArray? Right 
> > now it looks like this code is leaking, since initializeOutputStream 
> > allocates a buffer that it expects the user of OutputStream to manage (the 
> > ownership is a bit awkward, but its meant to accommodate the API of 
> > `__cxa_demangle`). 
> Resolved with better memory management.
Okay, but now this is just leaking in the buffer you allocate in DescOS. There 
isn't any way for this approach to work, because you need the temporary buffer 
you're allocating to live until after the SpecialName is printed, and the AST 
nodes do not get destroyed. Can you please do what I said above, and create a 
BlockInvocationFunction node that has a NodeArray of parameters? You can look 
at e.g. `FunctionType` above for an example of this. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813



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


[PATCH] D78129: Add Marvell ThunderX3T110 support

2020-04-23 Thread Wei Zhao via Phabricator via cfe-commits
wxz2020 updated this revision to Diff 259605.
wxz2020 added a comment.

Resubmit as the previous one was rejected by test plan changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78129

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64SchedA53.td
  llvm/lib/Target/AArch64/AArch64SchedA57.td
  llvm/lib/Target/AArch64/AArch64SchedCyclone.td
  llvm/lib/Target/AArch64/AArch64SchedExynosM3.td
  llvm/lib/Target/AArch64/AArch64SchedExynosM4.td
  llvm/lib/Target/AArch64/AArch64SchedExynosM5.td
  llvm/lib/Target/AArch64/AArch64SchedFalkor.td
  llvm/lib/Target/AArch64/AArch64SchedKryo.td
  llvm/lib/Target/AArch64/AArch64SchedThunderX.td
  llvm/lib/Target/AArch64/AArch64SchedThunderX2T99.td
  llvm/lib/Target/AArch64/AArch64SchedThunderX3T110.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/test/CodeGen/AArch64/aarch64-combine-fmul-fsub.mir
  llvm/test/CodeGen/AArch64/cpus.ll
  llvm/test/CodeGen/AArch64/loop-micro-op-buffer-size-t110.ll
  llvm/test/CodeGen/AArch64/machine-combiner-madd.ll
  llvm/test/CodeGen/AArch64/preferred-function-alignment.ll
  llvm/test/CodeGen/AArch64/remat.ll

Index: llvm/test/CodeGen/AArch64/remat.ll
===
--- llvm/test/CodeGen/AArch64/remat.ll
+++ llvm/test/CodeGen/AArch64/remat.ll
@@ -19,6 +19,7 @@
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=thunderx2t99 -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=tsv110 -o - %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnuabi -mattr=+custom-cheap-as-move -o - %s | FileCheck %s
+; RUN: llc -mtriple=aarch64-linux-gnuabi -mcpu=thunderx3t110 -o - %s | FileCheck %s
 
 %X = type { i64, i64, i64 }
 declare void @f(%X*)
Index: llvm/test/CodeGen/AArch64/preferred-function-alignment.ll
===
--- llvm/test/CodeGen/AArch64/preferred-function-alignment.ll
+++ llvm/test/CodeGen/AArch64/preferred-function-alignment.ll
@@ -19,6 +19,7 @@
 ; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=thunderxt83 < %s | FileCheck --check-prefixes=ALIGN3,CHECK %s
 ; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=thunderxt88 < %s | FileCheck --check-prefixes=ALIGN3,CHECK %s
 ; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=thunderx2t99 < %s | FileCheck --check-prefixes=ALIGN3,CHECK %s
+; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=thunderx3t110 < %s | FileCheck --check-prefixes=ALIGN4,CHECK %s
 ; RUN: llc -mtriple=aarch64-unknown-linux -mcpu=exynos-m3 < %s | FileCheck --check-prefixes=ALIGN5,CHECK %s
 
 define void @test() {
Index: llvm/test/CodeGen/AArch64/machine-combiner-madd.ll
===
--- llvm/test/CodeGen/AArch64/machine-combiner-madd.ll
+++ llvm/test/CodeGen/AArch64/machine-combiner-madd.ll
@@ -6,6 +6,7 @@
 ; RUN: llc -mtriple=aarch64-linux-gnu -mcpu=exynos-m3  < %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnu -mcpu=kryo   < %s | FileCheck %s
 ; RUN: llc -mtriple=aarch64-linux-gnu -mcpu=thunderx2t99 < %s | FileCheck %s
+; RUN: llc -mtriple=aarch64-linux-gnu -mcpu=thunderx3t110 < %s | FileCheck %s
 
 ; Make sure that inst-combine fuses the multiply add in the addressing mode of
 ; the load.
Index: llvm/test/CodeGen/AArch64/loop-micro-op-buffer-size-t110.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/loop-micro-op-buffer-size-t110.ll
@@ -0,0 +1,124 @@
+; REQUIRES: asserts
+; RUN: opt -mcpu=thunderx3t110 -loop-unroll --debug-only=loop-unroll --debug-only=basicblock-utils -S -unroll-allow-partial < %s 2>&1 | FileCheck %s
+
+target triple = "aarch64-unknown-linux-gnu"
+
+; CHECK: Loop Unroll: F[foo] Loop %loop.2.header
+; CHECK: Loop Size = 19
+; CHECK: Trip Count = 512
+; CHECK: Trip Multiple = 512
+; CHECK: UNROLLING loop %loop.2.header by 4 with a breakout at trip 0
+; CHECK: Merging:
+; CHECK: Loop Unroll: F[foo] Loop %loop.header
+; CHECK:   Loop Size = 18
+; CHECK:   Trip Count = 512
+; CHECK:   Trip Multiple = 512
+; CHECK: UNROLLING loop %loop.header by 4 with a breakout at trip 0
+; CHECK: Merging:
+; CHECK: %counter = phi i32 [ 0, %entry ], [ %inc.3, %loop.inc.3 ]
+; CHECK: %val = add nuw nsw i32 %counter, 5
+; CHECK: %val1 = add nuw nsw i32 %counter, 6
+; CHECK: %val2 = add nuw nsw i32 %counter, 7
+; CHECK: %val3 = add nuw nsw i32 %counter, 8
+; CHECK: %val4 = add nuw nsw i32 %counter, 9
+; CHECK: %val5 = add nuw nsw i32 %counter, 10
+; CHECK-NOT: %val = add i32 %counter, 5
+; CHECK-NOT: %val = add i32 %counter, 6
+; CHECK-NOT: %val = add i32 %counter, 7
+; CHECK-NOT: %val = add i32 %counter, 8
+; CHECK-NOT: %val = add i32 %counter, 9
+; CHECK-NOT: %val = add i32 %counte

[PATCH] D78521: [clangd] Extend dexp to support remote index

2020-04-23 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 259604.
kbobyrev added a comment.

Implement (B) for now


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78521

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/Features.inc.in
  clang-tools-extra/clangd/index/Serialization.h
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/index/dex/dexp/CMakeLists.txt
  clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp
  clang-tools-extra/clangd/index/remote/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/Client.h
  clang-tools-extra/clangd/index/remote/Index.cpp
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/Marshalling.cpp
  clang-tools-extra/clangd/index/remote/Marshalling.h
  clang-tools-extra/clangd/index/remote/client/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/client/Client.cpp
  clang-tools-extra/clangd/index/remote/server/CMakeLists.txt
  clang-tools-extra/clangd/index/remote/server/Server.cpp

Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -8,6 +8,7 @@
 
 #include "index/Index.h"
 #include "index/Serialization.h"
+#include "index/remote/Marshalling.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/LineEditor/LineEditor.h"
@@ -23,6 +24,7 @@
 
 namespace clang {
 namespace clangd {
+namespace remote {
 namespace {
 
 static const std::string Overview = R"(
@@ -33,42 +35,78 @@
 llvm::cl::opt IndexPath(llvm::cl::desc(""),
  llvm::cl::Positional, llvm::cl::Required);
 
-llvm::cl::opt ServerAddress("server-address",
- llvm::cl::init("0.0.0.0:50051"));
+llvm::cl::opt ServerAddress(
+"server-address", llvm::cl::init("0.0.0.0:50051"),
+llvm::cl::desc("Address of the invoked server. Defaults to 0.0.0.0:50051"));
 
-std::unique_ptr openIndex(llvm::StringRef Index) {
+std::unique_ptr openIndex(llvm::StringRef Index) {
   return loadIndex(Index, /*UseIndex=*/true);
 }
 
-class RemoteIndexServer final : public remote::Index::Service {
+class RemoteIndexServer final : public SymbolIndex::Service {
 public:
-  RemoteIndexServer(std::unique_ptr Index)
+  RemoteIndexServer(std::unique_ptr Index)
   : Index(std::move(Index)) {}
 
 private:
   grpc::Status Lookup(grpc::ServerContext *Context,
-  const remote::LookupRequest *Request,
-  grpc::ServerWriter *Reply) override {
-llvm::outs() << "Lookup of symbol with ID " << Request->id() << '\n';
-LookupRequest Req;
-auto SID = SymbolID::fromStr(Request->id());
-if (!SID) {
-  llvm::outs() << llvm::toString(SID.takeError()) << "\n";
-  return grpc::Status::CANCELLED;
+  const LookupRequest *Request,
+  grpc::ServerWriter *Reply) override {
+clangd::LookupRequest Req;
+for (const auto &ID : Request->ids()) {
+  auto SID = SymbolID::fromStr(StringRef(ID));
+  if (!SID)
+return grpc::Status::CANCELLED;
+  Req.IDs.insert(*SID);
 }
-Req.IDs.insert(*SID);
-Index->lookup(Req, [&](const Symbol &Sym) {
-  remote::LookupReply NextSymbol;
-  NextSymbol.set_symbol_yaml(toYAML(Sym));
+Index->lookup(Req, [&](const clangd::Symbol &Sym) {
+  Symbol NextSymbol;
+  NextSymbol.set_yaml_serializatiton(toYAML(Sym));
   Reply->Write(NextSymbol);
 });
 return grpc::Status::OK;
   }
 
-  std::unique_ptr Index;
+  grpc::Status FuzzyFind(grpc::ServerContext *Context,
+ const FuzzyFindRequest *Request,
+ grpc::ServerWriter *Reply) override {
+const auto Req = fromProtobuf(Request);
+bool HasMore = Index->fuzzyFind(Req, [&](const clangd::Symbol &Sym) {
+  FuzzyFindReply NextMessage;
+  NextMessage.mutable_stream_result()->set_yaml_serializatiton(toYAML(Sym));
+  Reply->Write(NextMessage);
+});
+FuzzyFindReply LastMessage;
+LastMessage.set_final_result(HasMore);
+Reply->Write(LastMessage);
+return grpc::Status::OK;
+  }
+
+  grpc::Status Refs(grpc::ServerContext *Context, const RefsRequest *Request,
+grpc::ServerWriter *Reply) override {
+clangd::RefsRequest Req;
+for (const auto &ID : Request->ids()) {
+  auto SID = SymbolID::fromStr(StringRef(ID));
+  if (!SID)
+return grpc::Status::CANCELLED;
+  Req.IDs.insert(*SID);
+}
+bool HasMore = Index->refs(Req, [&](const clangd::Ref &Reference) {
+  RefsReply NextMessage;
+  NextMessage.mutable_stream_result()->set_yaml_serializatiton(
+  toYAML(Reference));
+  Reply->Write(NextMessage);
+});
+RefsReply LastMessag

[PATCH] D77592: [NFC][CodeGen] Add enum for selecting the layout of components in the vtable

2020-04-23 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 259602.
leonardchan added a comment.

Updated to reflect the changes in D72959  
which make the vtable 4-byte aligned under the `Relative` layout.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77592

Files:
  clang/include/clang/AST/VTableBuilder.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/VTableBuilder.cpp


Index: clang/lib/AST/VTableBuilder.cpp
===
--- clang/lib/AST/VTableBuilder.cpp
+++ clang/lib/AST/VTableBuilder.cpp
@@ -2221,8 +2221,9 @@
 
 VTableLayout::~VTableLayout() { }
 
-ItaniumVTableContext::ItaniumVTableContext(ASTContext &Context)
-: VTableContextBase(/*MS=*/false) {}
+ItaniumVTableContext::ItaniumVTableContext(
+ASTContext &Context, VTableComponentLayout ComponentLayout)
+: VTableContextBase(/*MS=*/false), ComponentLayout(ComponentLayout) {}
 
 ItaniumVTableContext::~ItaniumVTableContext() {}
 
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -10463,6 +10463,8 @@
 if (Target->getCXXABI().isMicrosoft())
   VTContext.reset(new MicrosoftVTableContext(*this));
 else
+  // TODO: Specify that we want to use the Relative VTableComponentLayout
+  // here once we add the option for selecting it for Fuchsia.
   VTContext.reset(new ItaniumVTableContext(*this));
   }
   return VTContext.get();
Index: clang/include/clang/AST/VTableBuilder.h
===
--- clang/include/clang/AST/VTableBuilder.h
+++ clang/include/clang/AST/VTableBuilder.h
@@ -371,7 +371,20 @@
   void computeVTableRelatedInformation(const CXXRecordDecl *RD) override;
 
 public:
-  ItaniumVTableContext(ASTContext &Context);
+  enum VTableComponentLayout {
+/// Components in the vtable are pointers to other structs/functions.
+/// Offsets are of size ptrdiff_t, making the entire vtable pointer 
aligned.
+/// This is the default layout.
+Pointer,
+
+/// Components in the vtable are relative 32-bit offsets between the vtable
+/// and other structs/functions. Offsets will be 32-bits, making the entire
+/// vtable 4-byte aligned.
+Relative,
+  };
+
+  ItaniumVTableContext(ASTContext &Context,
+   VTableComponentLayout ComponentLayout = Pointer);
   ~ItaniumVTableContext() override;
 
   const VTableLayout &getVTableLayout(const CXXRecordDecl *RD) {
@@ -402,6 +415,16 @@
   static bool classof(const VTableContextBase *VT) {
 return !VT->isMicrosoft();
   }
+
+  VTableComponentLayout getVTableComponentLayout() const {
+return ComponentLayout;
+  }
+
+  bool isPointerLayout() const { return ComponentLayout == Pointer; }
+  bool isRelativeLayout() const { return ComponentLayout == Relative; }
+
+private:
+  VTableComponentLayout ComponentLayout;
 };
 
 /// Holds information about the inheritance path to a virtual base or function


Index: clang/lib/AST/VTableBuilder.cpp
===
--- clang/lib/AST/VTableBuilder.cpp
+++ clang/lib/AST/VTableBuilder.cpp
@@ -2221,8 +2221,9 @@
 
 VTableLayout::~VTableLayout() { }
 
-ItaniumVTableContext::ItaniumVTableContext(ASTContext &Context)
-: VTableContextBase(/*MS=*/false) {}
+ItaniumVTableContext::ItaniumVTableContext(
+ASTContext &Context, VTableComponentLayout ComponentLayout)
+: VTableContextBase(/*MS=*/false), ComponentLayout(ComponentLayout) {}
 
 ItaniumVTableContext::~ItaniumVTableContext() {}
 
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -10463,6 +10463,8 @@
 if (Target->getCXXABI().isMicrosoft())
   VTContext.reset(new MicrosoftVTableContext(*this));
 else
+  // TODO: Specify that we want to use the Relative VTableComponentLayout
+  // here once we add the option for selecting it for Fuchsia.
   VTContext.reset(new ItaniumVTableContext(*this));
   }
   return VTContext.get();
Index: clang/include/clang/AST/VTableBuilder.h
===
--- clang/include/clang/AST/VTableBuilder.h
+++ clang/include/clang/AST/VTableBuilder.h
@@ -371,7 +371,20 @@
   void computeVTableRelatedInformation(const CXXRecordDecl *RD) override;
 
 public:
-  ItaniumVTableContext(ASTContext &Context);
+  enum VTableComponentLayout {
+/// Components in the vtable are pointers to other structs/functions.
+/// Offsets are of size ptrdiff_t, making the entire vtable pointer aligned.
+/// This is the default layout.
+Pointer,
+
+/// Components in the vtable are relative 32-bit offsets between the vtable
+/// and other structs/functions. Offsets 

[PATCH] D78569: [SVE][CodeGen] Lower SDIV & UDIV to SVE intrinsics

2020-04-23 Thread Kerry McLaughlin via Phabricator via cfe-commits
kmclaughlin updated this revision to Diff 259610.
kmclaughlin added a comment.

- Removed changes to handle legalisation from this patch (this will be included 
in a follow up)
- Added AArch64ISD nodes for SDIV_PRED & UDIV_PRED
- Changed LowerDIV to use the new ISD nodes rather than lowering to SVE 
intrinsics
- Update tests to use CHECK-DAG


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

https://reviews.llvm.org/D78569

Files:
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.h
  llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
  llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll

Index: llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/llvm-ir-to-intrinsic.ll
@@ -0,0 +1,45 @@
+; RUN: llc -mtriple=aarch64-linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; SDIV
+;
+
+define  @sdiv_i32( %a,  %b) {
+; CHECK-LABEL: @sdiv_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: sdiv z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+define  @sdiv_i64( %a,  %b) {
+; CHECK-LABEL: @sdiv_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: sdiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = sdiv  %a, %b
+  ret  %div
+}
+
+;
+; UDIV
+;
+
+define  @udiv_i32( %a,  %b) {
+; CHECK-LABEL: @udiv_i32
+; CHECK-DAG: ptrue p0.s
+; CHECK-DAG: udiv z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
+
+define  @udiv_i64( %a,  %b) {
+; CHECK-LABEL: @udiv_i64
+; CHECK-DAG: ptrue p0.d
+; CHECK-DAG: udiv z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT: ret
+  %div = udiv  %a, %b
+  ret  %div
+}
Index: llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
===
--- llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
+++ llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
@@ -145,6 +145,14 @@
 def AArch64lasta   :  SDNode<"AArch64ISD::LASTA", SDT_AArch64Reduce>;
 def AArch64lastb   :  SDNode<"AArch64ISD::LASTB", SDT_AArch64Reduce>;
 
+def SDT_AArch64DIV : SDTypeProfile<1, 3, [
+  SDTCisVec<0>, SDTCisVec<1>, SDTCisVec<2>, SDTCisVec<3>,
+  SDTCVecEltisVT<1,i1>, SDTCisSameAs<2,3>
+]>;
+
+def AArch64sdiv_pred  :  SDNode<"AArch64ISD::SDIV_PRED", SDT_AArch64DIV>;
+def AArch64udiv_pred  :  SDNode<"AArch64ISD::UDIV_PRED", SDT_AArch64DIV>;
+
 def SDT_AArch64ReduceWithInit : SDTypeProfile<1, 3, [SDTCisVec<1>, SDTCisVec<3>]>;
 def AArch64clasta_n   : SDNode<"AArch64ISD::CLASTA_N",   SDT_AArch64ReduceWithInit>;
 def AArch64clastb_n   : SDNode<"AArch64ISD::CLASTB_N",   SDT_AArch64ReduceWithInit>;
@@ -239,8 +247,8 @@
   def : Pat<(mul nxv2i64:$Op1, nxv2i64:$Op2),
 (MUL_ZPmZ_D (PTRUE_D 31), $Op1, $Op2)>;
 
-  defm SDIV_ZPmZ  : sve_int_bin_pred_arit_2_div<0b100, "sdiv", int_aarch64_sve_sdiv>;
-  defm UDIV_ZPmZ  : sve_int_bin_pred_arit_2_div<0b101, "udiv", int_aarch64_sve_udiv>;
+  defm SDIV_ZPmZ  : sve_int_bin_pred_arit_2_div<0b100, "sdiv",  AArch64sdiv_pred>;
+  defm UDIV_ZPmZ  : sve_int_bin_pred_arit_2_div<0b101, "udiv",  AArch64udiv_pred>;
   defm SDIVR_ZPmZ : sve_int_bin_pred_arit_2_div<0b110, "sdivr", int_aarch64_sve_sdivr>;
   defm UDIVR_ZPmZ : sve_int_bin_pred_arit_2_div<0b111, "udivr", int_aarch64_sve_udivr>;
 
Index: llvm/lib/Target/AArch64/AArch64ISelLowering.h
===
--- llvm/lib/Target/AArch64/AArch64ISelLowering.h
+++ llvm/lib/Target/AArch64/AArch64ISelLowering.h
@@ -52,6 +52,10 @@
   ADC,
   SBC, // adc, sbc instructions
 
+  // Arithmetic instructions
+  SDIV_PRED,
+  UDIV_PRED,
+
   // Arithmetic instructions which write flags.
   ADDS,
   SUBS,
@@ -781,6 +785,8 @@
   SDValue LowerVECTOR_SHUFFLE(SDValue Op, SelectionDAG &DAG) const;
   SDValue LowerSPLAT_VECTOR(SDValue Op, SelectionDAG &DAG) const;
   SDValue LowerDUPQLane(SDValue Op, SelectionDAG &DAG) const;
+  SDValue LowerDIV(SDValue Op, SelectionDAG &DAG,
+   unsigned NewOp) const;
   SDValue LowerEXTRACT_SUBVECTOR(SDValue Op, SelectionDAG &DAG) const;
   SDValue LowerVectorSRA_SRL_SHL(SDValue Op, SelectionDAG &DAG) const;
   SDValue LowerShiftLeftParts(SDValue Op, SelectionDAG &DAG) const;
Index: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
===
--- llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
+++ llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
@@ -883,8 +883,11 @@
 // splat of 0 or undef) once vector selects supported in SVE codegen. See
 // D68877 for more details.
 for (MVT VT : MVT::integer_scalable_vector_valuetypes()) {
-  if (isTypeLegal(VT))
+  if (isTypeLegal(VT)) {
 setOperationAction(ISD::SPLAT_VECTOR, VT, Custom);
+setOperationAction(ISD::SDIV, VT, Custom);
+setOperationAction(ISD::UDIV, VT, Custom);
+  }
 }
 setOperationAction(ISD::INTRINSIC_WO_CHAIN, MVT::i8, Custom);
 se

[clang] a880256 - [analyzer] Consider array subscripts to be interesting lvalues.

2020-04-23 Thread Artem Dergachev via cfe-commits

Author: Valeriy Savchenko
Date: 2020-04-23T19:52:45+03:00
New Revision: a88025672f89374bfa584e2179a557f44d86da11

URL: 
https://github.com/llvm/llvm-project/commit/a88025672f89374bfa584e2179a557f44d86da11
DIFF: 
https://github.com/llvm/llvm-project/commit/a88025672f89374bfa584e2179a557f44d86da11.diff

LOG: [analyzer] Consider array subscripts to be interesting lvalues.

Static analyzer has a mechanism of clearing redundant nodes when
analysis hits a certain threshold with a number of nodes in exploded
graph (default is 1000). It is similar to GC and aims removing nodes
not useful for analysis. Unfortunately nodes corresponding to array
subscript expressions (that actively participate in data propagation)
get removed during the cleanup. This might prevent the analyzer from
generating useful notes about where it thinks the data came from.

This fix is pretty much consistent with the way analysis works
already. Lvalue "interestingness" stands for the analyzer's
possibility of tracking values through them.

Differential Revision: https://reviews.llvm.org/D78638

Added: 
clang/test/Analysis/CheckThatArraySubsciptNodeIsNotCollected.cpp

Modified: 
clang/lib/StaticAnalyzer/Core/ExplodedGraph.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/ExplodedGraph.cpp 
b/clang/lib/StaticAnalyzer/Core/ExplodedGraph.cpp
index c4838492271c..635495e9bf60 100644
--- a/clang/lib/StaticAnalyzer/Core/ExplodedGraph.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExplodedGraph.cpp
@@ -50,9 +50,8 @@ ExplodedGraph::~ExplodedGraph() = default;
 bool ExplodedGraph::isInterestingLValueExpr(const Expr *Ex) {
   if (!Ex->isLValue())
 return false;
-  return isa(Ex) ||
- isa(Ex) ||
- isa(Ex);
+  return isa(Ex) || isa(Ex) ||
+ isa(Ex) || isa(Ex);
 }
 
 bool ExplodedGraph::shouldCollect(const ExplodedNode *node) {

diff  --git a/clang/test/Analysis/CheckThatArraySubsciptNodeIsNotCollected.cpp 
b/clang/test/Analysis/CheckThatArraySubsciptNodeIsNotCollected.cpp
new file mode 100644
index ..b1c0f339bd56
--- /dev/null
+++ b/clang/test/Analysis/CheckThatArraySubsciptNodeIsNotCollected.cpp
@@ -0,0 +1,40 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -analyzer-output=text 
-verify %s
+
+class A {
+public:
+  int method();
+};
+
+A *foo();
+void bar(A *);
+
+int index;
+
+// We want to check here that the notes about the origins of the null pointer
+// (array[index] = foo()) will get to the final report.
+//
+// The analyzer used to drop exploded nodes for array subscripts when it was
+// time to collect redundant nodes. This GC-like mechanism kicks in only when
+// the exploded graph is large enough (>1K nodes). For this reason, 'index'
+// is a global variable, and the sink point is inside of a loop.
+
+void test() {
+  A *array[42];
+  A *found;
+
+  for (index = 0; (array[index] = foo()); ++index) { // expected-note {{Loop 
condition is false. Execution continues on line 34}}
+// expected-note@-1 {{Value assigned to 'index'}}
+// expected-note@-2 {{Assigning value}}
+// expected-note@-3 {{Assuming pointer value is null}}
+if (array[0])
+  break;
+  }
+
+  do {
+found = array[index]; // expected-note {{Null pointer value stored to 
'found'}}
+
+if (found->method()) // expected-warning {{Called C++ object pointer is 
null [core.CallAndMessage]}}
+  // expected-note@-1 {{Called C++ object pointer is null}}
+  bar(found);
+  } while (--index);
+}



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


[PATCH] D78693: Make "#pragma clang attribute" support uninitialized attribute.

2020-04-23 Thread JF Bastien via Phabricator via cfe-commits
jfb accepted this revision.
jfb added inline comments.



Comment at: clang/test/Parser/pragma-attribute.cpp:190
+#pragma clang attribute pop
+#pragma clang attribute push([[clang::uninitialized]], apply_to = variable) // 
expected-error {{attribute 'uninitialized' can't be applied to 'variable'}}
+#pragma clang attribute pop

aaron.ballman wrote:
> jfb wrote:
> > Should variable work? Since it’s a superset of local it seems like maybe? 
> > But then again only local works, so ok not sure. 
> I think this is correct. Requiring an explicit `is_local` here is a 
> conservative approach. It means we can start supporting 
> `[[clang::uninitialized]]` in other contexts without breaking code that uses 
> `#pragma clang attribute` to apply it to more entities unexpectedly.
That makes sense, thanks for confirming!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78693



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


[PATCH] D78726: [CUDA] Define __CUDACC_DEBUG__ when compiling device code in debug mode

2020-04-23 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:632
+  if (mustEmitDebugInfo(DriverArgs) == EmitSameDebugInfoAsHost)
+CC1Args.push_back("-D__CUDACC_DEBUG__");
+

Built-in preprocessor macros are defined in  
clang/lib/Frontend/InitPreprocessor.cpp, so the change should ideally go there.

Also, it's not clear what exactly does the macro mean. I am not convinced that 
clang must set this macro. Clang is not 1:1 compatible with NVCC anyways, and 
I'd rather not add quirks unless they are absolutely necessary. In this case, 
it can be easily added by the user.






Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78726



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


[PATCH] D78642: [clang-format] Handle C# property accessors when parsing lines

2020-04-23 Thread Jonathan B Coe via Phabricator via cfe-commits
jbcoe marked 2 inline comments as done.
jbcoe added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1344
   addUnwrappedLine();
 FormatTok->Type = TT_FunctionLBrace;
 parseBlock(/*MustBeDeclaration=*/false);

MyDeveloperDay wrote:
> previously set and get would break based on the setting of AfterFunction 
> correct? now I assume it doesn't?
That's right. There's a bunch more work needed here and current/previous 
behaviour is undertested and incorrect. 

I'm focusing on this for the next few days so should get everything working 
well and configurable as we'd like.

MS examples are not very consistent so choice seems like the way forward: 
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#properties



Comment at: clang/unittests/Format/FormatTestCSharp.cpp:249
+   "public string Host { set; get; }");
 
   verifyFormat("[TestMethod(\"start\", HelpText = \"Starts the server "

MyDeveloperDay wrote:
> is this just a personal choice? or based on some rule that it shouldn't break?
> 
> I don't like us changing tests unless we understand otherwise we just keep 
> flip-flopping the style?
Agreed. This was oversight and merits discussion. I'll make this configurable 
in a follow-up patch.

Thanks for taking the time to review/comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78642



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


  1   2   3   >