[PATCH] D67695: [clangd] Implement getBeginning for overloaded operators.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: ilya-biryukov.
Herald added subscribers: usaxena95, kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.
hokein marked an inline comment as done.
hokein added inline comments.



Comment at: clang-tools-extra/clangd/SourceCode.cpp:256
+
 SourceLocation getBeginningOfIdentifier(const Position &Pos,
 const SourceManager &SM,

the function name doesn't match what it does now, considering a new name for 
it, `getBeginningOfIdentifierOrOverloadedOperator` seems too verbose, maybe 
just `getBeginning`?


This will fix some bugs where navigation doesn't work on cases like
`std::cout <^< "hello"`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67695

Files:
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -434,6 +434,15 @@
   auto x = m^akeX();
 }
   )cpp",
+
+  R"cpp(
+struct X {
+  X& [[operator]]++() {}
+};
+void foo(X& x) {
+  +^+x;
+}
+  )cpp",
   };
   for (const char *Test : Tests) {
 Annotations T(Test);
Index: clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
===
--- clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
+++ clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
@@ -326,6 +326,9 @@
"int foo(^);",  // non-identifier
"^int foo();",  // beginning of file (can't back up)
"int ^f0^0();", // after a digit (lexing at N-1 is wrong)
+   "void f(int abc) { ^a^b^c^++; }", // range of identifier
+   "void f(int abc) { ++^a^b^c^; }", // range of identifier
+   "void f(int abc) { ^+^+abc; }",   // range of operator
"int ^λλ^λ();", // UTF-8 handled properly when backing up
 
// identifier in macro arg
Index: clang-tools-extra/clangd/SourceCode.cpp
===
--- clang-tools-extra/clangd/SourceCode.cpp
+++ clang-tools-extra/clangd/SourceCode.cpp
@@ -237,6 +237,22 @@
   return halfOpenToRange(SM, CharSourceRange::getCharRange(TokLoc, End));
 }
 
+static bool isIdentifierOrOverloadedOperator(const Token &Tok) {
+  switch (Tok.getKind()) {
+  case tok::raw_identifier:
+return true;
+#define OVERLOADED_OPERATOR(Name, Spelling, Token, Unary, Binary, MemOnly) \
+  case tok::Token:
+#define OVERLOADED_OPERATOR_MULTI(Name, Spelling, Unary, Binary, MemOnly)
+#include "clang/Basic/OperatorKinds.def"
+return true;
+
+  default:
+break;
+  }
+  return false;
+}
+
 SourceLocation getBeginningOfIdentifier(const Position &Pos,
 const SourceManager &SM,
 const LangOptions &LangOpts) {
@@ -248,24 +264,39 @@
   }
 
   // GetBeginningOfToken(pos) is almost what we want, but does the wrong thing
-  // if the cursor is at the end of the identifier.
-  // Instead, we lex at GetBeginningOfToken(pos - 1). The cases are:
-  //  1) at the beginning of an identifier, we'll be looking at something
-  //  that isn't an identifier.
-  //  2) at the middle or end of an identifier, we get the identifier.
-  //  3) anywhere outside an identifier, we'll get some non-identifier thing.
+  // if the cursor is at the end of the target token (identifier, overloaded
+  // operators). Instead, we lex at GetBeginningOfToken(pos - 1). The cases are:
+  //  1) at the beginning of a target token, we'll be looking at something
+  //  that isn't a target token.
+  //  2) at the middle or end of a target token, we get the target token.
+  //  3) anywhere outside the target token, we'll get some non-target-token
+  //  thing.
   // We can't actually distinguish cases 1 and 3, but returning the original
   // location is correct for both!
   SourceLocation InputLoc = SM.getComposedLoc(FID, *Offset);
   if (*Offset == 0) // Case 1 or 3.
 return InputLoc;
-  SourceLocation Before = SM.getComposedLoc(FID, *Offset - 1);
 
-  Before = Lexer::GetBeginningOfToken(Before, SM, LangOpts);
   Token Tok;
+  // As we use closed range [start, end] for identifiers, we encounter tricky
+  // cases when identifiers meet with overloaded operators:
+  //   1) ++^foo; => return the start location of foo.
+  //   2) ^foo^++;  => return the start location of foo.
+  //  ~ range for foo.
+  // so if we see the original location is the beginning of the identifier, we
+  // just return the the original location, otherwise we will return the
+  // beginning loc of "++" in 1).
+  if (InputLoc.isVa

[PATCH] D67627: Clang-format: Add Whitesmiths indentation style

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67627



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

[PATCH] D67695: [clangd] Implement getBeginning for overloaded operators.

[Haojian Wu via Phabricator via cfe-commits]

hokein marked an inline comment as done.
hokein added inline comments.



Comment at: clang-tools-extra/clangd/SourceCode.cpp:256
+
 SourceLocation getBeginningOfIdentifier(const Position &Pos,
 const SourceManager &SM,

the function name doesn't match what it does now, considering a new name for 
it, `getBeginningOfIdentifierOrOverloadedOperator` seems too verbose, maybe 
just `getBeginning`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67695



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

[PATCH] D67670: [clang-format][PR41964] Fix crash with SIGFPE when TabWidth is set to 0 and line starts with tab

[Manuel Klimek via Phabricator via cfe-commits]

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

LG. That makes lots of sense now :) Thanks!


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

https://reviews.llvm.org/D67670



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

[PATCH] D67654: [clang-tidy] Fix a potential infinite loop in readability-isolate-declaration check.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

Do we have unit tests for clang-tidy? If yes, could we also add unit-tests for 
this function?

The modified function only needs a source manager and lang options, these are 
easy to mock.




Comment at: clang-tools-extra/clang-tidy/utils/LexerUtils.h:38
 template 
 SourceLocation findPreviousAnyTokenKind(SourceLocation Start,
 const SourceManager &SM,

Would `findPrevious` have the same problem on the first token of the file?
Can be hard to check without unit-tests, though.



Comment at: clang-tools-extra/clang-tidy/utils/LexerUtils.h:66
 Optional CurrentToken = Lexer::findNextToken(Start, SM, LangOpts);
-
-if (!CurrentToken)
+if (!CurrentToken || CurrentToken->is(tok::eof))
   return SourceLocation();

We seem to be missing a corner case here: what if folks are searching for 
'tok::eof'?

Currently we would return invalid location, but given the function's signature 
I'd expect it to return location of 'tok::eof' in that case.

I bet we don't run into this in practice, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67654



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

[PATCH] D67654: [clang-tidy] Fix a potential infinite loop in readability-isolate-declaration check.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

The fix itself LGTM, getting rid of an infinite loop is important.
All my comment can be addressed later...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67654



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

[PATCH] D67584: [Support] Replace function with function_ref in writeFileAtomically. NFC

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372201: [Support] Replace function with function_ref in 
writeFileAtomically. NFC (authored by ibiryukov, committed by ).
Herald added a subscriber: kristina.

Changed prior to commit:
  https://reviews.llvm.org/D67584?vs=220209&id=220620#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67584

Files:
  llvm/trunk/include/llvm/Support/FileUtilities.h
  llvm/trunk/lib/Support/FileUtilities.cpp


Index: llvm/trunk/lib/Support/FileUtilities.cpp
===
--- llvm/trunk/lib/Support/FileUtilities.cpp
+++ llvm/trunk/lib/Support/FileUtilities.cpp
@@ -296,7 +296,7 @@
 
 llvm::Error llvm::writeFileAtomically(
 StringRef TempPathModel, StringRef FinalPath,
-std::function Writer) {
+llvm::function_ref Writer) {
   SmallString<128> GeneratedUniqPath;
   int TempFD;
   if (sys::fs::createUniqueFile(TempPathModel.str(), TempFD,
Index: llvm/trunk/include/llvm/Support/FileUtilities.h
===
--- llvm/trunk/include/llvm/Support/FileUtilities.h
+++ llvm/trunk/include/llvm/Support/FileUtilities.h
@@ -14,6 +14,7 @@
 #ifndef LLVM_SUPPORT_FILEUTILITIES_H
 #define LLVM_SUPPORT_FILEUTILITIES_H
 
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/ErrorHandling.h"
@@ -107,9 +108,9 @@
   llvm::Error writeFileAtomically(StringRef TempPathModel, StringRef FinalPath,
   StringRef Buffer);
 
-  llvm::Error
-  writeFileAtomically(StringRef TempPathModel, StringRef FinalPath,
-  std::function Writer);
+  llvm::Error writeFileAtomically(
+  StringRef TempPathModel, StringRef FinalPath,
+  llvm::function_ref Writer);
 } // End llvm namespace
 
 #endif


Index: llvm/trunk/lib/Support/FileUtilities.cpp
===
--- llvm/trunk/lib/Support/FileUtilities.cpp
+++ llvm/trunk/lib/Support/FileUtilities.cpp
@@ -296,7 +296,7 @@
 
 llvm::Error llvm::writeFileAtomically(
 StringRef TempPathModel, StringRef FinalPath,
-std::function Writer) {
+llvm::function_ref Writer) {
   SmallString<128> GeneratedUniqPath;
   int TempFD;
   if (sys::fs::createUniqueFile(TempPathModel.str(), TempFD,
Index: llvm/trunk/include/llvm/Support/FileUtilities.h
===
--- llvm/trunk/include/llvm/Support/FileUtilities.h
+++ llvm/trunk/include/llvm/Support/FileUtilities.h
@@ -14,6 +14,7 @@
 #ifndef LLVM_SUPPORT_FILEUTILITIES_H
 #define LLVM_SUPPORT_FILEUTILITIES_H
 
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/ErrorHandling.h"
@@ -107,9 +108,9 @@
   llvm::Error writeFileAtomically(StringRef TempPathModel, StringRef FinalPath,
   StringRef Buffer);
 
-  llvm::Error
-  writeFileAtomically(StringRef TempPathModel, StringRef FinalPath,
-  std::function Writer);
+  llvm::Error writeFileAtomically(
+  StringRef TempPathModel, StringRef FinalPath,
+  llvm::function_ref Writer);
 } // End llvm namespace
 
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61717: Fix arm_neon.h to be clean under -fno-lax-vector-conversions.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a comment.

Many thanks! I've passed on the message, hopefully we can do something about 
this.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61717



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

[PATCH] D67584: [Support] Replace function with function_ref in writeFileAtomically. NFC

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov reopened this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

Ah, the tests fail to compile because we now have an overload where the only 
difference is `function_ref` vs `StringRef`.
This works fine with `std::function`, STL probably ensures the conversions from 
`StringRef` to `std::functtion` fail and `function_ref` will only fail at 
constructor instantiation time.

I'll keep this open for now, will see if it's feasible to make `function_ref` 
similar to `std::function` in that case.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67584



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

r372203 - [lldb] Print better diagnostics for user expressions and modules

[Raphael Isemann via cfe-commits]

Author: teemperor
Date: Wed Sep 18 01:53:35 2019
New Revision: 372203

URL: http://llvm.org/viewvc/llvm-project?rev=372203&view=rev
Log:
[lldb] Print better diagnostics for user expressions and modules

Summary:
Currently our expression evaluators only prints very basic errors that are not 
very useful when writing complex expressions.

For example, in the expression below the user made a type error, but it's not 
clear from the diagnostic what went wrong:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: invalid operands to binary expression ('int' and 'double')
```

This patch enables full Clang diagnostics in our expression evaluator. After 
this patch the diagnostics for the expression look like this:

```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: :1:54: invalid operands to binary expression ('int' 
and 'float')
printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
   ~~^~~~
```

To make this possible, we now emulate a user expression file within our 
diagnostics. This prevents that the user is exposed to
our internal wrapper code we inject.

Note that the diagnostics that refer to declarations from the debug information 
(e.g. 'note' diagnostics pointing to a called function)
will not be improved by this as they don't have any source locations associated 
with them, so caret or line printing isn't possible.
We instead just suppress these diagnostics as we already do with warnings as 
they would otherwise just be a context message
without any context (and the original diagnostic in the user expression should 
be enough to explain the issue).

Fixes rdar://24306342

Reviewers: JDevlieghere, aprantl, shafik, #lldb

Reviewed By: JDevlieghere, #lldb

Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, 
lldb-commits

Tags: #lldb

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticOptions.def
cfe/trunk/lib/Frontend/TextDiagnostic.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticOptions.def?rev=372203&r1=372202&r2=372203&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticOptions.def (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticOptions.def Wed Sep 18 01:53:35 2019
@@ -49,6 +49,7 @@ DIAGOPT(Pedantic, 1, 0) /// -ped
 DIAGOPT(PedanticErrors, 1, 0)   /// -pedantic-errors
 DIAGOPT(ShowColumn, 1, 1)   /// Show column number on diagnostics.
 DIAGOPT(ShowLocation, 1, 1) /// Show source location information.
+DIAGOPT(ShowLevel, 1, 1)/// Show diagnostic level.
 DIAGOPT(AbsolutePath, 1, 0) /// Use absolute paths.
 DIAGOPT(ShowCarets, 1, 1)   /// Show carets in diagnostics.
 DIAGOPT(ShowFixits, 1, 1)   /// Show fixit information.

Modified: cfe/trunk/lib/Frontend/TextDiagnostic.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/TextDiagnostic.cpp?rev=372203&r1=372202&r2=372203&view=diff
==
--- cfe/trunk/lib/Frontend/TextDiagnostic.cpp (original)
+++ cfe/trunk/lib/Frontend/TextDiagnostic.cpp Wed Sep 18 01:53:35 2019
@@ -683,8 +683,9 @@ void TextDiagnostic::emitDiagnosticMessa
   if (DiagOpts->ShowColors)
 OS.resetColor();
 
-  printDiagnosticLevel(OS, Level, DiagOpts->ShowColors,
-   DiagOpts->CLFallbackMode);
+  if (DiagOpts->ShowLevel)
+printDiagnosticLevel(OS, Level, DiagOpts->ShowColors,
+ DiagOpts->CLFallbackMode);
   printDiagnosticMessage(OS,
  /*IsSupplemental*/ Level == DiagnosticsEngine::Note,
  Message, OS.tell() - StartOfLocationInfo,


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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 220625.
balazske added a comment.

Rebase and update according to comments.
C++17 related changes not implemented yet (possible check for the called 
allocation function).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp
  clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-mem57-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/cert-mem57-cpp.cpp

Index: clang-tools-extra/test/clang-tidy/cert-mem57-cpp.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/cert-mem57-cpp.cpp
@@ -0,0 +1,39 @@
+// RUN: %check_clang_tidy %s cert-mem57-cpp %t
+
+namespace std {
+typedef __typeof(sizeof(int)) size_t;
+void *aligned_alloc(size_t, size_t);
+void free(void *);
+} // namespace std
+
+struct alignas(32) Vector1 {
+  char elems[32];
+};
+
+struct Vector2 {
+  char elems[32];
+};
+
+struct alignas(32) Vector3 {
+  char elems[32];
+  static void *operator new(std::size_t nbytes) noexcept(true) {
+return std::aligned_alloc(alignof(Vector3), nbytes);
+  }
+  static void operator delete(void *p) {
+std::free(p);
+  }
+};
+
+struct alignas(8) Vector4 {
+  char elems[32];
+};
+
+void f() {
+  auto *V1 = new Vector1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: allocation function returns a pointer with alignment 16 but the over-aligned type being allocated requires alignment 32 [cert-mem57-cpp]
+  auto *V2 = new Vector2;
+  auto *V3 = new Vector3;
+  auto *V4 = new Vector4;
+  auto *V1_Arr = new Vector1[2];
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: allocation function returns a pointer with alignment 16 but the over-aligned type being allocated requires alignment 32 [cert-mem57-cpp]
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -4,7 +4,6 @@
 =
 
 .. toctree::
-
abseil-duration-addition
abseil-duration-comparison
abseil-duration-conversion-cast
@@ -98,93 +97,94 @@
cert-err61-cpp (redirects to misc-throw-by-value-catch-by-reference) 
cert-fio38-c (redirects to misc-non-copyable-objects) 
cert-flp30-c
+   cert-mem57-cpp
cert-msc30-c (redirects to cert-msc50-cpp) 
cert-msc32-c (redirects to cert-msc51-cpp) 
cert-msc50-cpp
cert-msc51-cpp
cert-oop11-cpp (redirects to performance-move-constructor-init) 
cert-oop54-cpp (redirects to bugprone-unhandled-self-assignment) 
-   clang-analyzer-core.CallAndMessage
-   clang-analyzer-core.DivideZero
+   clang-analyzer-core.CallAndMessage (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
+   clang-analyzer-core.DivideZero (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
clang-analyzer-core.DynamicTypePropagation
-   clang-analyzer-core.NonNullParamChecker
-   clang-analyzer-core.NullDereference
-   clang-analyzer-core.StackAddressEscape
-   clang-analyzer-core.UndefinedBinaryOperatorResult
-   clang-analyzer-core.VLASize
-   clang-analyzer-core.uninitialized.ArraySubscript
-   clang-analyzer-core.uninitialized.Assign
-   clang-analyzer-core.uninitialized.Branch
+   clang-analyzer-core.NonNullParamChecker (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
+   clang-analyzer-core.NullDereference (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
+   clang-analyzer-core.StackAddressEscape (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
+   clang-analyzer-core.UndefinedBinaryOperatorResult (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
+   clang-analyzer-core.VLASize (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
+   clang-analyzer-core.uninitialized.ArraySubscript (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
+   clang-analyzer-core.uninitialized.Assign (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
+   clang-analyzer-core.uninitialized.Branch (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
clang-analyzer-core.uninitialized.CapturedBlockVariable
-   clang-analyzer-core.uninitialized.UndefReturn
+   clang-analyzer-core.uninitialized.UndefReturn (redirects to https://clang.llvm.org/docs/analyzer/checkers) 
clang-analyzer-cplusplus.InnerPointer
-   clang-analyzer-cplusplus.Move
-   clang-analyzer-cplusplus.NewDelete
-   clang-analyzer-cplusplus.NewDeleteLeaks
-   clang-analyzer-deadcode.DeadStores
-   clang-analyzer-nullability.NullPassedToNonnull
-   clang-analyzer-nulla

[PATCH] D67654: [clang-tidy] Fix a potential infinite loop in readability-isolate-declaration check.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 220627.
hokein marked 2 inline comments as done.
hokein added a comment.

Handle the eof corner case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67654

Files:
  clang-tools-extra/clang-tidy/utils/LexerUtils.h
  
clang-tools-extra/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp


Index: 
clang-tools-extra/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
===
--- /dev/null
+++ 
clang-tools-extra/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
@@ -0,0 +1,7 @@
+// RUN: %check_clang_tidy -expect-clang-tidy-error %s 
readability-isolate-declaration %t
+
+int main(){
+  int a, b
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: multiple declarations in a single 
statement reduces readability
+  // CHECK-MESSAGES: [[@LINE-2]]:11: error: expected ';' at end of declaration 
[clang-diagnostic-error]
+}
Index: clang-tools-extra/clang-tidy/utils/LexerUtils.h
===
--- clang-tools-extra/clang-tidy/utils/LexerUtils.h
+++ clang-tools-extra/clang-tidy/utils/LexerUtils.h
@@ -10,6 +10,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_LEXER_UTILS_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/Lexer.h"
 
 namespace clang {
@@ -70,6 +71,11 @@
 if (PotentialMatch.isOneOf(TK, TKs...))
   return PotentialMatch.getLocation();
 
+// If we reach the end of the file, and eof is not the target token, we 
stop
+// the loop, otherwise we will get infinite loop (findNextToken will return
+// eof on eof).
+if (PotentialMatch.is(tok::eof))
+  return SourceLocation();
 Start = PotentialMatch.getLastLoc();
   }
 }


Index: clang-tools-extra/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
@@ -0,0 +1,7 @@
+// RUN: %check_clang_tidy -expect-clang-tidy-error %s readability-isolate-declaration %t
+
+int main(){
+  int a, b
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: multiple declarations in a single statement reduces readability
+  // CHECK-MESSAGES: [[@LINE-2]]:11: error: expected ';' at end of declaration [clang-diagnostic-error]
+}
Index: clang-tools-extra/clang-tidy/utils/LexerUtils.h
===
--- clang-tools-extra/clang-tidy/utils/LexerUtils.h
+++ clang-tools-extra/clang-tidy/utils/LexerUtils.h
@@ -10,6 +10,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_LEXER_UTILS_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/Lexer.h"
 
 namespace clang {
@@ -70,6 +71,11 @@
 if (PotentialMatch.isOneOf(TK, TKs...))
   return PotentialMatch.getLocation();
 
+// If we reach the end of the file, and eof is not the target token, we stop
+// the loop, otherwise we will get infinite loop (findNextToken will return
+// eof on eof).
+if (PotentialMatch.is(tok::eof))
+  return SourceLocation();
 Start = PotentialMatch.getLastLoc();
   }
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67654: [clang-tidy] Fix a potential infinite loop in readability-isolate-declaration check.

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

> Do we have unit tests for clang-tidy? If yes, could we also add unit-tests 
> for this function?
>  The modified function only needs a source manager and lang options, these 
> are easy to mock.

Unfortunately, we don't have any unit tests for all these utility functions. 
The modified function is only used in the `readability-isolate-declaration` 
check.

I agree that we should add one, will file a bug.




Comment at: clang-tools-extra/clang-tidy/utils/LexerUtils.h:38
 template 
 SourceLocation findPreviousAnyTokenKind(SourceLocation Start,
 const SourceManager &SM,

ilya-biryukov wrote:
> Would `findPrevious` have the same problem on the first token of the file?
> Can be hard to check without unit-tests, though.
it depends on the caller. Calling this function directly would probably get 
into infinite loop. As this function is only used in 
`readability-isolate-declaration` check, it seems that the check adds some 
additional guard code before calling this function, it is probably safe, I 
assume. (I could not figure out a case that causes the problem).



Comment at: clang-tools-extra/clang-tidy/utils/LexerUtils.h:66
 Optional CurrentToken = Lexer::findNextToken(Start, SM, LangOpts);
-
-if (!CurrentToken)
+if (!CurrentToken || CurrentToken->is(tok::eof))
   return SourceLocation();

ilya-biryukov wrote:
> We seem to be missing a corner case here: what if folks are searching for 
> 'tok::eof'?
> 
> Currently we would return invalid location, but given the function's 
> signature I'd expect it to return location of 'tok::eof' in that case.
> 
> I bet we don't run into this in practice, though.
yeah, I thought that we shouldn't run into this corner case, I tweaked the code 
to fix this case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67654



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 220628.
balazske added a comment.

Fixed the test, fixed problems in list.rst.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp
  clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-mem57-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/cert-mem57-cpp.cpp

Index: clang-tools-extra/test/clang-tidy/cert-mem57-cpp.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/cert-mem57-cpp.cpp
@@ -0,0 +1,39 @@
+// RUN: %check_clang_tidy %s cert-mem57-cpp %t
+
+namespace std {
+typedef __typeof(sizeof(int)) size_t;
+void *aligned_alloc(size_t, size_t);
+void free(void *);
+} // namespace std
+
+struct alignas(32) Vector1 {
+  char elems[32];
+};
+
+struct Vector2 {
+  char elems[32];
+};
+
+struct alignas(32) Vector3 {
+  char elems[32];
+  static void *operator new(std::size_t nbytes) noexcept(true) {
+return std::aligned_alloc(alignof(Vector3), nbytes);
+  }
+  static void operator delete(void *p) {
+std::free(p);
+  }
+};
+
+struct alignas(8) Vector4 {
+  char elems[32];
+};
+
+void f() {
+  auto *V1 = new Vector1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: allocation function returns a pointer with alignment 16 but the over-aligned type being allocated requires alignment 32 [cert-mem57-cpp]
+  auto *V2 = new Vector2;
+  auto *V3 = new Vector3;
+  auto *V4 = new Vector4;
+  auto *V1_Arr = new Vector1[2];
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: allocation function returns a pointer with alignment 16 but the over-aligned type being allocated requires alignment 32 [cert-mem57-cpp]
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -98,6 +98,7 @@
cert-err61-cpp (redirects to misc-throw-by-value-catch-by-reference) 
cert-fio38-c (redirects to misc-non-copyable-objects) 
cert-flp30-c
+   cert-mem57-cpp
cert-msc30-c (redirects to cert-msc50-cpp) 
cert-msc32-c (redirects to cert-msc51-cpp) 
cert-msc50-cpp
Index: clang-tools-extra/docs/clang-tidy/checks/cert-mem57-cpp.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/cert-mem57-cpp.rst
@@ -0,0 +1,16 @@
+.. title:: clang-tidy - cert-mem57-cpp
+
+cert-mem57-cpp
+==
+
+This check flags uses of default ``operator new`` where the type has extended
+alignment (an alignment greater than the fundamental alignment). (The default
+``operator new`` is guaranteed to provide the correct alignmment if the
+requested alignment is less or equal to the fundamental alignment).
+Only cases are detected (by design) where the ``operator new`` is not
+user-defined and is not a placement new (the reason is that in these cases we
+assume that the user provided the correct memory allocation).
+
+This check corresponds to the CERT C++ Coding Standard rule
+`MEM57-CPP. Avoid using default operator new for over-aligned types
+`_.
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -73,6 +73,12 @@
   Finds instances where variables with static storage are initialized
   dynamically in header files.
 
+- New :doc:`cert-mem57-cpp
+  ` check.
+
+  Checks if an object of type with extended alignment is allocated by using
+  the default ``operator new``.
+
 - New :doc:`linuxkernel-must-use-errs
   ` check.
 
Index: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.h
@@ -0,0 +1,35 @@
+//===--- DefaultOperatorNewCheck.h - clang-tidy -*- C++ -*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CERT_DEFAULTOPERATORNEWCHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CERT_DEFAULTOPERATORNEWCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang {
+

[clang-tools-extra] r372206 - [clang-tidy] Fix a potential infinite loop in readability-isolate-declaration check.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Wed Sep 18 02:21:35 2019
New Revision: 372206

URL: http://llvm.org/viewvc/llvm-project?rev=372206&view=rev
Log:
[clang-tidy] Fix a potential infinite loop in readability-isolate-declaration 
check.

Reviewers: ilya-biryukov

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

Added:

clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h

Modified: clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h?rev=372206&r1=372205&r2=372206&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h (original)
+++ clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h Wed Sep 18 02:21:35 
2019
@@ -10,6 +10,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_LEXER_UTILS_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/Lexer.h"
 
 namespace clang {
@@ -70,6 +71,11 @@ SourceLocation findNextAnyTokenKind(Sour
 if (PotentialMatch.isOneOf(TK, TKs...))
   return PotentialMatch.getLocation();
 
+// If we reach the end of the file, and eof is not the target token, we 
stop
+// the loop, otherwise we will get infinite loop (findNextToken will return
+// eof on eof).
+if (PotentialMatch.is(tok::eof))
+  return SourceLocation();
 Start = PotentialMatch.getLastLoc();
   }
 }

Added: 
clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp?rev=372206&view=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
 (added)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
 Wed Sep 18 02:21:35 2019
@@ -0,0 +1,7 @@
+// RUN: %check_clang_tidy -expect-clang-tidy-error %s 
readability-isolate-declaration %t
+
+int main(){
+  int a, b
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: multiple declarations in a single 
statement reduces readability
+  // CHECK-MESSAGES: [[@LINE-2]]:11: error: expected ';' at end of declaration 
[clang-diagnostic-error]
+}


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

[PATCH] D67654: [clang-tidy] Fix a potential infinite loop in readability-isolate-declaration check.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372206: [clang-tidy] Fix a potential infinite loop in 
readability-isolate-declaration… (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67654?vs=220627&id=220629#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67654

Files:
  clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h
  
clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp


Index: clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h
===
--- clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h
+++ clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h
@@ -10,6 +10,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_LEXER_UTILS_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/Lexer.h"
 
 namespace clang {
@@ -70,6 +71,11 @@
 if (PotentialMatch.isOneOf(TK, TKs...))
   return PotentialMatch.getLocation();
 
+// If we reach the end of the file, and eof is not the target token, we 
stop
+// the loop, otherwise we will get infinite loop (findNextToken will return
+// eof on eof).
+if (PotentialMatch.is(tok::eof))
+  return SourceLocation();
 Start = PotentialMatch.getLastLoc();
   }
 }
Index: 
clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
===
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
@@ -0,0 +1,7 @@
+// RUN: %check_clang_tidy -expect-clang-tidy-error %s 
readability-isolate-declaration %t
+
+int main(){
+  int a, b
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: multiple declarations in a single 
statement reduces readability
+  // CHECK-MESSAGES: [[@LINE-2]]:11: error: expected ';' at end of declaration 
[clang-diagnostic-error]
+}


Index: clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h
===
--- clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h
+++ clang-tools-extra/trunk/clang-tidy/utils/LexerUtils.h
@@ -10,6 +10,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_UTILS_LEXER_UTILS_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/Lexer.h"
 
 namespace clang {
@@ -70,6 +71,11 @@
 if (PotentialMatch.isOneOf(TK, TKs...))
   return PotentialMatch.getLocation();
 
+// If we reach the end of the file, and eof is not the target token, we stop
+// the loop, otherwise we will get infinite loop (findNextToken will return
+// eof on eof).
+if (PotentialMatch.is(tok::eof))
+  return SourceLocation();
 Start = PotentialMatch.getLastLoc();
   }
 }
Index: clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/readability-isolate-declaration-no-infinite-loop.cpp
@@ -0,0 +1,7 @@
+// RUN: %check_clang_tidy -expect-clang-tidy-error %s readability-isolate-declaration %t
+
+int main(){
+  int a, b
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: multiple declarations in a single statement reduces readability
+  // CHECK-MESSAGES: [[@LINE-2]]:11: error: expected ';' at end of declaration [clang-diagnostic-error]
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67480: [analyzer] Add 'freopen' support to SimpleStreamChecker.

[Balázs Kéri via Phabricator via cfe-commits]

balazske abandoned this revision.
balazske added a comment.

I try to improve `StreamChecker` instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67480



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

[PATCH] D67661: [RISCV] Headers: Add Bitmanip extension Clang header files and rvintrin.h

[Scott Egerton via Phabricator via cfe-commits]

s.egerton added a comment.

I agree inline asm is a far from optimal solution but it seems like the lesser 
of two evils for now.

This sounds like a good idea, but we need to be able to guarantee that the 
backend will be able to match to the correct instruction for all optimisation 
levels before we can do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67661



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

[PATCH] D65433: [clangd] DefineInline action availability checks

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:65
+const FunctionDecl *getSelectedFunction(const SelectionTree::Node *SelNode) {
+  const ast_type_traits::DynTypedNode &AstNode = SelNode->ASTNode;
+  if (const FunctionDecl *FD = AstNode.get())

nit: maybe use `auto`?



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:78
+// function decl. Skips local symbols.
+llvm::DenseSet getNonLocalDeclRefs(const FunctionDecl *FD,
+ ParsedAST &AST) {

thinking this a bit more, the function is non-trivial, we probably want unit 
test for it.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:105
+  Opts.SystemSymbolFilter =
+  index::IndexingOptions::SystemSymbolFilterKind::None;
+

IIUC, I believe this function relies on the flag "Opts.IndexFunctionLocals"? 
could we spell it explicitly in the code even its default value `false` fits 
our use case.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:113
+// Checks the decls mentioned in Source are visible in the context of Target.
+// Achives that by performing lookups in Target's DeclContext.
+// Unfortunately these results need to be post-filtered since the AST we get is

hmm, looks like we don't use TargetContext in the implemenation at all. Is the 
comment out-of-date now?



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:141
+// same class.
+if (!SM.isBeforeInTranslationUnit(D->getLocation(),
+  Target->getLocation())) {

we are distinguishing two cases here: normal functions and the class methods. 
Could we make the code handle these two cases separately? e.g.

```
if (Class) {
   // check whether they are in the same class;
} else { // handle normal function
  // call isBeforeInTranslation
}
```



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:160
+// usually be the first declaration in current translation unit with the
+// exception of template specialization. For those we return the previous
+// declaration instead of the first one, since it will be template decl itself

function template is tricky, I may be not aware of the context, what's our plan 
for supporting it? could you give an concrete example? it seems that the 
current unit test doesn't cover it.



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:172
+
+/// Moves definition of a function to its declaration location.
+/// Before:

I believe it also works for class methods?



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:183
+/// a.h:
+///   void foo() { return ; }
+///

now we get a potential ODR violation in this example, maybe choose a different 
example?



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:224
+
+  Expected apply(const Selection &Sel) override {
+return llvm::createStringError(llvm::inconvertibleErrorCode(),

The tweak is under development, do we need to hide it until it is completed?



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:25
 #include "clang/Rewrite/Core/Rewriter.h"
+#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
 #include "clang/Tooling/Core/Replacement.h"

the header seems irrelevant to me.



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:709
+  EXPECT_UNAVAILABLE(R"cpp(
+#include "a.h"
+void bar();

The `a.h` seems to be non-existed unless you explicitly set it via 
`ExtraFiles["a.h"]`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65433



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

[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Peter Waller via Phabricator via cfe-commits]

peterwaller-arm updated this revision to Diff 220645.
peterwaller-arm marked 6 inline comments as done.
peterwaller-arm retitled this revision from "[clang][driver] Add basic 
--driver-mode=fortran support for flang" to "[clang][driver] Add basic 
--driver-mode=flang support for fortran".
peterwaller-arm added a comment.

Updated for review comments and spotted a couple of things myself.

Changes since last time:

- Removed various options which aren't yet implemented on the f18 side.
- --driver-mode=fortran is now --driver-mode=flang, which is more consistent 
with other modes.
- Added tests which show that multiple inputs (and mixed C+Fortran inputs) are 
supported by the driver.
- Updated comments.
- Removed a branch in getTool which didn't make sense.
- Updated commit message.


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

https://reviews.llvm.org/D63607

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/ToolChain.h
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Driver/ToolChains/Flang.h
  clang/lib/Driver/Types.cpp
  clang/test/Driver/flang/Inputs/one.f90
  clang/test/Driver/flang/Inputs/other.c
  clang/test/Driver/flang/Inputs/two.f90
  clang/test/Driver/flang/flang.F90
  clang/test/Driver/flang/flang.f90
  clang/test/Driver/flang/multiple-inputs-mixed.f90
  clang/test/Driver/flang/multiple-inputs.f90
  clang/test/Driver/fortran.f95
  clang/test/Driver/lit.local.cfg

Index: clang/test/Driver/lit.local.cfg
===
--- clang/test/Driver/lit.local.cfg
+++ clang/test/Driver/lit.local.cfg
@@ -1,4 +1,4 @@
-config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.f95',
+config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.F90', '.f95',
'.cu', '.rs', '.cl', '.hip']
 config.substitutions = list(config.substitutions)
 config.substitutions.insert(0,
Index: clang/test/Driver/fortran.f95
===
--- clang/test/Driver/fortran.f95
+++ clang/test/Driver/fortran.f95
@@ -1,21 +1,22 @@
-// Check that the clang driver can invoke gcc to compile Fortran.
+! Check that the clang driver can invoke gcc to compile Fortran when in
+! --driver-mode=clang. This is legacy behaviour - see also --driver-mode=fortran.
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
-// CHECK-OBJECT: gcc
-// CHECK-OBJECT: "-c"
-// CHECK-OBJECT: "-x" "f95"
-// CHECK-OBJECT-NOT: cc1as
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
+! CHECK-OBJECT: gcc
+! CHECK-OBJECT: "-c"
+! CHECK-OBJECT: "-x" "f95"
+! CHECK-OBJECT-NOT: cc1as
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-ASM %s
-// CHECK-ASM: gcc
-// CHECK-ASM: "-S"
-// CHECK-ASM: "-x" "f95"
-// CHECK-ASM-NOT: cc1
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-ASM %s
+! CHECK-ASM: gcc
+! CHECK-ASM: "-S"
+! CHECK-ASM: "-x" "f95"
+! CHECK-ASM-NOT: cc1
 
-// RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
-// CHECK-WARN: gcc
-// CHECK-WARN-NOT: "-Wall"
-// CHECK-WARN: ld
-// CHECK-WARN-NOT: "-Wall"
+! RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
+! CHECK-WARN: gcc
+! CHECK-WARN-NOT: "-Wall"
+! CHECK-WARN: ld
+! CHECK-WARN-NOT: "-Wall"
Index: clang/test/Driver/flang/multiple-inputs.f90
===
--- /dev/null
+++ clang/test/Driver/flang/multiple-inputs.f90
@@ -0,0 +1,7 @@
+! Check that flang driver can handle multiple inputs at once.
+
+! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/two.f90 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/two.f90"
Index: clang/test/Driver/flang/multiple-inputs-mixed.f90
===
--- /dev/null
+++ clang/test/Driver/flang/multiple-inputs-mixed.f90
@@ -0,0 +1,7 @@
+! Check that flang can handle mixed C and fortran inputs.
+
+! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/other.c 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
+! CHECK-SYNTAX-

[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Peter Waller via Phabricator via cfe-commits]

peterwaller-arm added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4788
+bool Driver::ShouldUseFlangCompiler(const JobAction &JA) const {
+  // Say "no" if there is not exactly one input of a type flang understands.
+  if (JA.size() != 1 ||

richard.barton.arm wrote:
> This first clause surprised me. Is this a temporary measure or do we never 
> intend to support compiling more than one fortran file at once?
This function answers the question at the scope of a single JobAction. My 
understanding is that the compiler (as with clang -cc1) will be invoked once 
per input file.

This does not prevent multiple fortran files from being compiled with a single 
driver invocation.



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:37
+  if (isa(JA)) {
+CmdArgs.push_back("-emit-obj");
+  } else if (isa(JA)) {

richard.barton.arm wrote:
> F18 does not currently support these options that control the output like 
> -emit-llvm and -emit-obj so this code doesn't do anything sensible at 
> present. Would it not make more sense to add this later on once F18 or 
> llvm/flang grows support for such options?
I've removed them.



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:44
+if (JA.getType() == types::TY_Nothing) {
+  CmdArgs.push_back("-fsyntax-only");
+} else if (JA.getType() == types::TY_LLVM_IR ||

richard.barton.arm wrote:
> Looks like the F18 option spelling for this is -fparse-only? Or maybe 
> -fdebug-semantics? I know the intention is to throw away the 'throwaway 
> driver' in F18, so perhaps you are preparing to replace this option spelling 
> in the throwaway driver with -fsyntax-only so this would highlight that 
> perhaps adding the code here before the F18 driver is ready to accept it is 
> not the right approach?
In the RFC, the intent expressed was to mimick gfortran and clang options. I am 
making a spelling choice here that I think it should be called -fsyntax-only, 
which matches those. I intend to make the `flang -fc1` side match in the near 
future.

-fdebug-* could be supported through an `-Xflang ...` option to pass debug 
flags through.



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:67
+  Args.AddAllArgs(CmdArgs, options::OPT_R_Group); // "Rpass-"" options 
passthrough.
+  Args.AddAllArgs(CmdArgs, options::OPT_gfortran_Group); // gfortran options 
passthrough.
+

richard.barton.arm wrote:
> Similarly to previous comment, do we want to be passing all gfortran options 
> through to F18 in the immediate term or even the long term? I don't think 
> there has been any agreement yet on what the options that F18 will support 
> are (although I agree that gfortran-like options would be most sensible and 
> in keeping with clang's philosophy)
I have deleted these options pass-throughs. I think you're right in general 
that we should only add options along with support for those things. The plan 
is now to add an OPT_flang_Group (or alike) later.



Comment at: clang/test/Driver/fortran.f95:1
-// Check that the clang driver can invoke gcc to compile Fortran.
+! Check that the clang driver can invoke gcc to compile Fortran.
 

richard.barton.arm wrote:
> ... when not in --driver-mode=fortran
Fixed.


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

https://reviews.llvm.org/D63607



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

[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Peter Waller via Phabricator via cfe-commits]

peterwaller-arm updated this revision to Diff 220646.
peterwaller-arm added a comment.

Updated comment for IsFlangMode.


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

https://reviews.llvm.org/D63607

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/ToolChain.h
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Driver/ToolChains/Flang.h
  clang/lib/Driver/Types.cpp
  clang/test/Driver/flang/Inputs/one.f90
  clang/test/Driver/flang/Inputs/other.c
  clang/test/Driver/flang/Inputs/two.f90
  clang/test/Driver/flang/flang.F90
  clang/test/Driver/flang/flang.f90
  clang/test/Driver/flang/multiple-inputs-mixed.f90
  clang/test/Driver/flang/multiple-inputs.f90
  clang/test/Driver/fortran.f95
  clang/test/Driver/lit.local.cfg

Index: clang/test/Driver/lit.local.cfg
===
--- clang/test/Driver/lit.local.cfg
+++ clang/test/Driver/lit.local.cfg
@@ -1,4 +1,4 @@
-config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.f95',
+config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.F90', '.f95',
'.cu', '.rs', '.cl', '.hip']
 config.substitutions = list(config.substitutions)
 config.substitutions.insert(0,
Index: clang/test/Driver/fortran.f95
===
--- clang/test/Driver/fortran.f95
+++ clang/test/Driver/fortran.f95
@@ -1,21 +1,22 @@
-// Check that the clang driver can invoke gcc to compile Fortran.
+! Check that the clang driver can invoke gcc to compile Fortran when in
+! --driver-mode=clang. This is legacy behaviour - see also --driver-mode=fortran.
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
-// CHECK-OBJECT: gcc
-// CHECK-OBJECT: "-c"
-// CHECK-OBJECT: "-x" "f95"
-// CHECK-OBJECT-NOT: cc1as
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
+! CHECK-OBJECT: gcc
+! CHECK-OBJECT: "-c"
+! CHECK-OBJECT: "-x" "f95"
+! CHECK-OBJECT-NOT: cc1as
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-ASM %s
-// CHECK-ASM: gcc
-// CHECK-ASM: "-S"
-// CHECK-ASM: "-x" "f95"
-// CHECK-ASM-NOT: cc1
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-ASM %s
+! CHECK-ASM: gcc
+! CHECK-ASM: "-S"
+! CHECK-ASM: "-x" "f95"
+! CHECK-ASM-NOT: cc1
 
-// RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
-// CHECK-WARN: gcc
-// CHECK-WARN-NOT: "-Wall"
-// CHECK-WARN: ld
-// CHECK-WARN-NOT: "-Wall"
+! RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
+! CHECK-WARN: gcc
+! CHECK-WARN-NOT: "-Wall"
+! CHECK-WARN: ld
+! CHECK-WARN-NOT: "-Wall"
Index: clang/test/Driver/flang/multiple-inputs.f90
===
--- /dev/null
+++ clang/test/Driver/flang/multiple-inputs.f90
@@ -0,0 +1,7 @@
+! Check that flang driver can handle multiple inputs at once.
+
+! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/two.f90 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/two.f90"
Index: clang/test/Driver/flang/multiple-inputs-mixed.f90
===
--- /dev/null
+++ clang/test/Driver/flang/multiple-inputs-mixed.f90
@@ -0,0 +1,7 @@
+! Check that flang can handle mixed C and fortran inputs.
+
+! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/other.c 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}clang{{[^"/]*}}" "-cc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/other.c"
Index: clang/test/Driver/flang/flang.f90
===
--- /dev/null
+++ clang/test/Driver/flang/flang.f90
@@ -0,0 +1,34 @@
+! Check that flang -fc1 is invoked when in --driver-mode=flang.
+
+! See also: flang.F90 - "an input which also requires preprocessing".
+
+! Test various output types:
+! * The default (-emit-obj)
+! * -fsyntax-only
+! * -emit-llvm
+! * -emit-llvm -S
+! * -S
+
+! Most tests use ALL-LABEL to bracket the checks with the compiler invocation and the source, which appear at the beginning and end.
+

[PATCH] D65917: [clang-tidy] Added check for the Google style guide's category method naming rule.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/google-objc-require-category-method-prefixes.rst:41
+
+.. option:: ExpectedPrefixes
+

stephanemoore wrote:
> aaron.ballman wrote:
> > stephanemoore wrote:
> > > This option seems to describe a list of class prefixes that are 
> > > whitelisted. If that is the case, perhaps `WhitelistedPrefixes` or 
> > > `WhitelistedClassPrefixes` would be a better name for the option? WDYT?
> > No, please. We should try to avoid "white" and "black" lists in favor of 
> > more descriptive terms with less social connotations. I'd be fine with 
> > `ExpectedClassPrefixes`, `AllowedPrefixes`, `KnownPrefixes`, etc.
> Makes sense. Would `ExemptClassPrefixes` work?
I think that'd be a great name.


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

https://reviews.llvm.org/D65917



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

r372217 - [AST] CommentLexer - Remove (optional) Invalid parameter from getSpelling.

[Simon Pilgrim via cfe-commits]

Author: rksimon
Date: Wed Sep 18 05:11:16 2019
New Revision: 372217

URL: http://llvm.org/viewvc/llvm-project?rev=372217&view=rev
Log:
[AST] CommentLexer - Remove (optional) Invalid parameter from getSpelling.

The static analyzer noticed that we were dereferencing it even when the default 
null value was being used. Further investigation showed that we never 
explicitly set the parameter so I've just removed it entirely.

Modified:
cfe/trunk/include/clang/AST/CommentLexer.h
cfe/trunk/lib/AST/CommentLexer.cpp

Modified: cfe/trunk/include/clang/AST/CommentLexer.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/CommentLexer.h?rev=372217&r1=372216&r2=372217&view=diff
==
--- cfe/trunk/include/clang/AST/CommentLexer.h (original)
+++ cfe/trunk/include/clang/AST/CommentLexer.h Wed Sep 18 05:11:16 2019
@@ -352,8 +352,7 @@ public:
 
   void lex(Token &T);
 
-  StringRef getSpelling(const Token &Tok, const SourceManager &SourceMgr,
-bool *Invalid = nullptr) const;
+  StringRef getSpelling(const Token &Tok, const SourceManager &SourceMgr) 
const;
 };
 
 } // end namespace comments

Modified: cfe/trunk/lib/AST/CommentLexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/CommentLexer.cpp?rev=372217&r1=372216&r2=372217&view=diff
==
--- cfe/trunk/lib/AST/CommentLexer.cpp (original)
+++ cfe/trunk/lib/AST/CommentLexer.cpp Wed Sep 18 05:11:16 2019
@@ -850,17 +850,14 @@ again:
 }
 
 StringRef Lexer::getSpelling(const Token &Tok,
- const SourceManager &SourceMgr,
- bool *Invalid) const {
+ const SourceManager &SourceMgr) const {
   SourceLocation Loc = Tok.getLocation();
   std::pair LocInfo = SourceMgr.getDecomposedLoc(Loc);
 
   bool InvalidTemp = false;
   StringRef File = SourceMgr.getBufferData(LocInfo.first, &InvalidTemp);
-  if (InvalidTemp) {
-*Invalid = true;
+  if (InvalidTemp)
 return StringRef();
-  }
 
   const char *Begin = File.data() + LocInfo.second;
   return StringRef(Begin, Tok.getLength());


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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:38
+return;
+
+  ASTContext &Context = D->getASTContext();

Would it make sense to early return here if the language dialect is >= C++17 ? 



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

What is the difference between "default" and "fundamental" alignment? Are they 
the same? Can they differ in any architecture?

https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
Here there is no wording of "default alignment" only "fundamental alignment" is 
mentioned. Based on this I'd call this as `FundamentalAligment`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

r372220 - [mips] Pass "xgot" flag as a subtarget feature

[Simon Atanasyan via cfe-commits]

Author: atanasyan
Date: Wed Sep 18 05:24:57 2019
New Revision: 372220

URL: http://llvm.org/viewvc/llvm-project?rev=372220&view=rev
Log:
[mips] Pass "xgot" flag as a subtarget feature

We need "xgot" flag in the MipsAsmParser to implement correct expansion
of some pseudo instructions in case of using 32-bit GOT (XGOT).
MipsAsmParser does not have reference to MipsSubtarget but has a
reference to "feature bit set".

Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/mips-features.c
cfe/trunk/test/Driver/mips-integrated-as.s

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp?rev=372220&r1=372219&r2=372220&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp Wed Sep 18 05:24:57 2019
@@ -267,6 +267,13 @@ void mips::getMIPSTargetFeatures(const D
   D.Diag(diag::warn_drv_unsupported_longcalls) << (ABICallsArg ? 0 : 1);
   }
 
+  if (Arg *A = Args.getLastArg(options::OPT_mxgot, options::OPT_mno_xgot)) {
+if (A->getOption().matches(options::OPT_mxgot))
+  Features.push_back("+xgot");
+else
+  Features.push_back("-xgot");
+  }
+
   mips::FloatABI FloatABI = mips::getMipsFloatABI(D, Args);
   if (FloatABI == mips::FloatABI::Soft) {
 // FIXME: Note, this is a hack. We need to pass the selected float

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=372220&r1=372219&r2=372220&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Wed Sep 18 05:24:57 2019
@@ -1675,13 +1675,6 @@ void Clang::AddMIPSTargetArgs(const ArgL
 CmdArgs.push_back("hard");
   }
 
-  if (Arg *A = Args.getLastArg(options::OPT_mxgot, options::OPT_mno_xgot)) {
-if (A->getOption().matches(options::OPT_mxgot)) {
-  CmdArgs.push_back("-mllvm");
-  CmdArgs.push_back("-mxgot");
-}
-  }
-
   if (Arg *A = Args.getLastArg(options::OPT_mldc1_sdc1,
options::OPT_mno_ldc1_sdc1)) {
 if (A->getOption().matches(options::OPT_mno_ldc1_sdc1)) {

Modified: cfe/trunk/test/Driver/mips-features.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mips-features.c?rev=372220&r1=372219&r2=372220&view=diff
==
--- cfe/trunk/test/Driver/mips-features.c (original)
+++ cfe/trunk/test/Driver/mips-features.c Wed Sep 18 05:24:57 2019
@@ -268,13 +268,13 @@
 // RUN: %clang -target mips-linux-gnu -### -c %s \
 // RUN: -mno-xgot -mxgot 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-XGOT %s
-// CHECK-XGOT: "-mllvm" "-mxgot"
+// CHECK-XGOT: "-target-feature" "+xgot"
 //
 // -mno-xgot
 // RUN: %clang -target mips-linux-gnu -### -c %s \
 // RUN: -mxgot -mno-xgot 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-NOXGOT %s
-// CHECK-NOXGOT-NOT: "-mllvm" "-mxgot"
+// CHECK-NOXGOT: "-target-feature" "-xgot"
 //
 // -mldc1-sdc1
 // RUN: %clang -target mips-linux-gnu -### -c %s \

Modified: cfe/trunk/test/Driver/mips-integrated-as.s
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mips-integrated-as.s?rev=372220&r1=372219&r2=372220&view=diff
==
--- cfe/trunk/test/Driver/mips-integrated-as.s (original)
+++ cfe/trunk/test/Driver/mips-integrated-as.s Wed Sep 18 05:24:57 2019
@@ -293,3 +293,13 @@
 // IMG-SINGLEFLOAT-EXPLICIT-FPXX: "-target-feature" "+single-float"
 // IMG-SINGLEFLOAT-EXPLICIT-FPXX: "-target-feature" "+fpxx"
 // IMG-SINGLEFLOAT-EXPLICIT-FPXX: "-target-feature" "+nooddspreg"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -mxgot -c %s 2>&1 | 
\
+// RUN:   FileCheck -check-prefix=XGOT %s
+// XGOT: -cc1as
+// XGOT: "-target-feature" "+xgot"
+
+// RUN: %clang -target mips-linux-gnu -### -fintegrated-as -mno-xgot -c %s 
2>&1 | \
+// RUN:   FileCheck -check-prefix=NOXGOT %s
+// NOXGOT: -cc1as
+// NOXGOT: "-target-feature" "-xgot"


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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

martong wrote:
> What is the difference between "default" and "fundamental" alignment? Are 
> they the same? Can they differ in any architecture?
> 
> https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> Here there is no wording of "default alignment" only "fundamental alignment" 
> is mentioned. Based on this I'd call this as `FundamentalAligment`.
> What is the difference between "default" and "fundamental" alignment? Are 
> they the same?

`fundamental alignment` of any type is the alignment of std::max_align_t. I.e. 
`alignof(std::max_align_t)`. 
See C++17 6.11.2.

On the other hand, default alignment is the value in 
`__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with `fnew-alignment`
See https://www.bfilipek.com/2019/08/newnew-align.html

These values can differ: https://wandbox.org/permlink/yIwjiNMw9KyXEQan

Thus, I think we should use the fundamental alignment here, not the default 
alignment. 
So, `getNewAlign()` does not seem right to me.
@aaron.ballman What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

martong wrote:
> martong wrote:
> > What is the difference between "default" and "fundamental" alignment? Are 
> > they the same? Can they differ in any architecture?
> > 
> > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > Here there is no wording of "default alignment" only "fundamental 
> > alignment" is mentioned. Based on this I'd call this as 
> > `FundamentalAligment`.
> > What is the difference between "default" and "fundamental" alignment? Are 
> > they the same?
> 
> `fundamental alignment` of any type is the alignment of std::max_align_t. 
> I.e. `alignof(std::max_align_t)`. 
> See C++17 6.11.2.
> 
> On the other hand, default alignment is the value in 
> `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with 
> `fnew-alignment`
> See https://www.bfilipek.com/2019/08/newnew-align.html
> 
> These values can differ: https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> 
> Thus, I think we should use the fundamental alignment here, not the default 
> alignment. 
> So, `getNewAlign()` does not seem right to me.
> @aaron.ballman What do you think?
> Thus, I think we should use the fundamental alignment here, not the default 
> alignment.

I have the exact opposite view.
If as per `getNewAlign()` the alignment would be okay, why should we not trust 
it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

lebedev.ri wrote:
> martong wrote:
> > martong wrote:
> > > What is the difference between "default" and "fundamental" alignment? Are 
> > > they the same? Can they differ in any architecture?
> > > 
> > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > Here there is no wording of "default alignment" only "fundamental 
> > > alignment" is mentioned. Based on this I'd call this as 
> > > `FundamentalAligment`.
> > > What is the difference between "default" and "fundamental" alignment? Are 
> > > they the same?
> > 
> > `fundamental alignment` of any type is the alignment of std::max_align_t. 
> > I.e. `alignof(std::max_align_t)`. 
> > See C++17 6.11.2.
> > 
> > On the other hand, default alignment is the value in 
> > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with 
> > `fnew-alignment`
> > See https://www.bfilipek.com/2019/08/newnew-align.html
> > 
> > These values can differ: https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > 
> > Thus, I think we should use the fundamental alignment here, not the default 
> > alignment. 
> > So, `getNewAlign()` does not seem right to me.
> > @aaron.ballman What do you think?
> > Thus, I think we should use the fundamental alignment here, not the default 
> > alignment.
> 
> I have the exact opposite view.
> If as per `getNewAlign()` the alignment would be okay, why should we not 
> trust it?
The comment on `getNewAlign()` is:
```
  /// Return the largest alignment for which a suitably-sized allocation with
  /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
  /// pointer.
```
I read that as saying any alignment larger than what is returned by 
`getNewAlign()` must call the over-aligned operator new variant in C++17 if 
available. So if the actual call target doesn't have an alignment specifier, 
it's probably getting the alignment wrong and would be worth diagnosing on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

[PATCH] D67661: [RISCV] Headers: Add Bitmanip extension Clang header files and rvintrin.h

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D67661#1673712 , @s.egerton wrote:

> I agree inline asm is a far from optimal solution but it seems like the 
> lesser of two evils for now.


Hm, i thought some previous patch already adds llvm ir riscv-specific 
intrinsics for those.

> This sounds like a good idea, but we need to be able to guarantee that the 
> backend will be able to match to the correct instruction for all optimisation 
> levels before we can do that.




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

https://reviews.llvm.org/D67661



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

[PATCH] D52281: [clang-tidy] Add modernize check to use std::invoke in generic code

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

The review says you abandoned it -- was that accidental?




Comment at: clang-tidy/modernize/ReplaceGenericFunctorCallCheck.cpp:72
+
+const Expr *Obj = BinOp->getLHS();
+const std::string ObjName =

boga95 wrote:
> I found an interesting behavior with source location:
> 
> ```
> const SourceManager *Source = Result.SourceManager;
> 
> const char *StartPos = Source->getCharacterData(Obj->getLocStart());
> const char *EndPos = Source->getCharacterData(Obj->getLocEnd());
> ```
> `StartPos` and `EndPos` point to the exact same location. Is this the 
> expected behavior or it is a bug?
That is expected behavior -- the source location points to the insertion point 
of the token and if there's only one token in the source range, two two 
locations will point to the same place.


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

https://reviews.llvm.org/D52281



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

aaron.ballman wrote:
> lebedev.ri wrote:
> > martong wrote:
> > > martong wrote:
> > > > What is the difference between "default" and "fundamental" alignment? 
> > > > Are they the same? Can they differ in any architecture?
> > > > 
> > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > Here there is no wording of "default alignment" only "fundamental 
> > > > alignment" is mentioned. Based on this I'd call this as 
> > > > `FundamentalAligment`.
> > > > What is the difference between "default" and "fundamental" alignment? 
> > > > Are they the same?
> > > 
> > > `fundamental alignment` of any type is the alignment of std::max_align_t. 
> > > I.e. `alignof(std::max_align_t)`. 
> > > See C++17 6.11.2.
> > > 
> > > On the other hand, default alignment is the value in 
> > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with 
> > > `fnew-alignment`
> > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > 
> > > These values can differ: https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > 
> > > Thus, I think we should use the fundamental alignment here, not the 
> > > default alignment. 
> > > So, `getNewAlign()` does not seem right to me.
> > > @aaron.ballman What do you think?
> > > Thus, I think we should use the fundamental alignment here, not the 
> > > default alignment.
> > 
> > I have the exact opposite view.
> > If as per `getNewAlign()` the alignment would be okay, why should we not 
> > trust it?
> The comment on `getNewAlign()` is:
> ```
>   /// Return the largest alignment for which a suitably-sized allocation with
>   /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
>   /// pointer.
> ```
> I read that as saying any alignment larger than what is returned by 
> `getNewAlign()` must call the over-aligned operator new variant in C++17 if 
> available. So if the actual call target doesn't have an alignment specifier, 
> it's probably getting the alignment wrong and would be worth diagnosing on.
> I have the exact opposite view.
> If as per getNewAlign() the alignment would be okay, why should we not trust 
> it?

That could lead to a false positive diagnostic if `-fnew-alignment=8` and 
`alignas(16)` , because `alignof(max_align_t)` is still 16.

See the definidion of `getNewAlign()` which will return with 8 in this case I 
suppose:
```
  unsigned getNewAlign() const {
return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
  }
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

martong wrote:
> aaron.ballman wrote:
> > lebedev.ri wrote:
> > > martong wrote:
> > > > martong wrote:
> > > > > What is the difference between "default" and "fundamental" alignment? 
> > > > > Are they the same? Can they differ in any architecture?
> > > > > 
> > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > Here there is no wording of "default alignment" only "fundamental 
> > > > > alignment" is mentioned. Based on this I'd call this as 
> > > > > `FundamentalAligment`.
> > > > > What is the difference between "default" and "fundamental" alignment? 
> > > > > Are they the same?
> > > > 
> > > > `fundamental alignment` of any type is the alignment of 
> > > > std::max_align_t. I.e. `alignof(std::max_align_t)`. 
> > > > See C++17 6.11.2.
> > > > 
> > > > On the other hand, default alignment is the value in 
> > > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with 
> > > > `fnew-alignment`
> > > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > > 
> > > > These values can differ: https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > > 
> > > > Thus, I think we should use the fundamental alignment here, not the 
> > > > default alignment. 
> > > > So, `getNewAlign()` does not seem right to me.
> > > > @aaron.ballman What do you think?
> > > > Thus, I think we should use the fundamental alignment here, not the 
> > > > default alignment.
> > > 
> > > I have the exact opposite view.
> > > If as per `getNewAlign()` the alignment would be okay, why should we not 
> > > trust it?
> > The comment on `getNewAlign()` is:
> > ```
> >   /// Return the largest alignment for which a suitably-sized allocation 
> > with
> >   /// '::operator new(size_t)' is guaranteed to produce a correctly-aligned
> >   /// pointer.
> > ```
> > I read that as saying any alignment larger than what is returned by 
> > `getNewAlign()` must call the over-aligned operator new variant in C++17 if 
> > available. So if the actual call target doesn't have an alignment 
> > specifier, it's probably getting the alignment wrong and would be worth 
> > diagnosing on.
> > I have the exact opposite view.
> > If as per getNewAlign() the alignment would be okay, why should we not 
> > trust it?
> 
> That could lead to a false positive diagnostic if `-fnew-alignment=8` and 
> `alignas(16)` , because `alignof(max_align_t)` is still 16.
> 
> See the definidion of `getNewAlign()` which will return with 8 in this case I 
> suppose:
> ```
>   unsigned getNewAlign() const {
> return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
>   }
> ```
> So if the actual call target doesn't have an alignment specifier, it's 
> probably getting the alignment wrong and would be worth diagnosing on.

I agree, but then we are implementing a checker which is different from the 
description given in cert-mem57.
So it is not a CERT checker anymore, perhaps we should rename then.
There is no mention of __STDCPP_DEFAULT_NEW_ALIGNMENT__ in 
https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
It clearly references the "fundamental alignement".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

martong wrote:
> martong wrote:
> > aaron.ballman wrote:
> > > lebedev.ri wrote:
> > > > martong wrote:
> > > > > martong wrote:
> > > > > > What is the difference between "default" and "fundamental" 
> > > > > > alignment? Are they the same? Can they differ in any architecture?
> > > > > > 
> > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > Here there is no wording of "default alignment" only "fundamental 
> > > > > > alignment" is mentioned. Based on this I'd call this as 
> > > > > > `FundamentalAligment`.
> > > > > > What is the difference between "default" and "fundamental" 
> > > > > > alignment? Are they the same?
> > > > > 
> > > > > `fundamental alignment` of any type is the alignment of 
> > > > > std::max_align_t. I.e. `alignof(std::max_align_t)`. 
> > > > > See C++17 6.11.2.
> > > > > 
> > > > > On the other hand, default alignment is the value in 
> > > > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with 
> > > > > `fnew-alignment`
> > > > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > > > 
> > > > > These values can differ: https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > > > 
> > > > > Thus, I think we should use the fundamental alignment here, not the 
> > > > > default alignment. 
> > > > > So, `getNewAlign()` does not seem right to me.
> > > > > @aaron.ballman What do you think?
> > > > > Thus, I think we should use the fundamental alignment here, not the 
> > > > > default alignment.
> > > > 
> > > > I have the exact opposite view.
> > > > If as per `getNewAlign()` the alignment would be okay, why should we 
> > > > not trust it?
> > > The comment on `getNewAlign()` is:
> > > ```
> > >   /// Return the largest alignment for which a suitably-sized allocation 
> > > with
> > >   /// '::operator new(size_t)' is guaranteed to produce a 
> > > correctly-aligned
> > >   /// pointer.
> > > ```
> > > I read that as saying any alignment larger than what is returned by 
> > > `getNewAlign()` must call the over-aligned operator new variant in C++17 
> > > if available. So if the actual call target doesn't have an alignment 
> > > specifier, it's probably getting the alignment wrong and would be worth 
> > > diagnosing on.
> > > I have the exact opposite view.
> > > If as per getNewAlign() the alignment would be okay, why should we not 
> > > trust it?
> > 
> > That could lead to a false positive diagnostic if `-fnew-alignment=8` and 
> > `alignas(16)` , because `alignof(max_align_t)` is still 16.
> > 
> > See the definidion of `getNewAlign()` which will return with 8 in this case 
> > I suppose:
> > ```
> >   unsigned getNewAlign() const {
> > return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
> >   }
> > ```
> > So if the actual call target doesn't have an alignment specifier, it's 
> > probably getting the alignment wrong and would be worth diagnosing on.
> 
> I agree, but then we are implementing a checker which is different from the 
> description given in cert-mem57.
> So it is not a CERT checker anymore, perhaps we should rename then.
> There is no mention of __STDCPP_DEFAULT_NEW_ALIGNMENT__ in 
> https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> It clearly references the "fundamental alignement".
Why do you believe that to be a false positive? That seems like exactly the 
behavior we'd want -- if the user says that their allocation function 
guarantees a particular max alignment by using `-fnew-alignment`, we should 
honor that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

aaron.ballman wrote:
> martong wrote:
> > martong wrote:
> > > aaron.ballman wrote:
> > > > lebedev.ri wrote:
> > > > > martong wrote:
> > > > > > martong wrote:
> > > > > > > What is the difference between "default" and "fundamental" 
> > > > > > > alignment? Are they the same? Can they differ in any architecture?
> > > > > > > 
> > > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > > Here there is no wording of "default alignment" only "fundamental 
> > > > > > > alignment" is mentioned. Based on this I'd call this as 
> > > > > > > `FundamentalAligment`.
> > > > > > > What is the difference between "default" and "fundamental" 
> > > > > > > alignment? Are they the same?
> > > > > > 
> > > > > > `fundamental alignment` of any type is the alignment of 
> > > > > > std::max_align_t. I.e. `alignof(std::max_align_t)`. 
> > > > > > See C++17 6.11.2.
> > > > > > 
> > > > > > On the other hand, default alignment is the value in 
> > > > > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with 
> > > > > > `fnew-alignment`
> > > > > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > > > > 
> > > > > > These values can differ: 
> > > > > > https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > > > > 
> > > > > > Thus, I think we should use the fundamental alignment here, not the 
> > > > > > default alignment. 
> > > > > > So, `getNewAlign()` does not seem right to me.
> > > > > > @aaron.ballman What do you think?
> > > > > > Thus, I think we should use the fundamental alignment here, not the 
> > > > > > default alignment.
> > > > > 
> > > > > I have the exact opposite view.
> > > > > If as per `getNewAlign()` the alignment would be okay, why should we 
> > > > > not trust it?
> > > > The comment on `getNewAlign()` is:
> > > > ```
> > > >   /// Return the largest alignment for which a suitably-sized 
> > > > allocation with
> > > >   /// '::operator new(size_t)' is guaranteed to produce a 
> > > > correctly-aligned
> > > >   /// pointer.
> > > > ```
> > > > I read that as saying any alignment larger than what is returned by 
> > > > `getNewAlign()` must call the over-aligned operator new variant in 
> > > > C++17 if available. So if the actual call target doesn't have an 
> > > > alignment specifier, it's probably getting the alignment wrong and 
> > > > would be worth diagnosing on.
> > > > I have the exact opposite view.
> > > > If as per getNewAlign() the alignment would be okay, why should we not 
> > > > trust it?
> > > 
> > > That could lead to a false positive diagnostic if `-fnew-alignment=8` and 
> > > `alignas(16)` , because `alignof(max_align_t)` is still 16.
> > > 
> > > See the definidion of `getNewAlign()` which will return with 8 in this 
> > > case I suppose:
> > > ```
> > >   unsigned getNewAlign() const {
> > > return NewAlign ? NewAlign : std::max(LongDoubleAlign, LongLongAlign);
> > >   }
> > > ```
> > > So if the actual call target doesn't have an alignment specifier, it's 
> > > probably getting the alignment wrong and would be worth diagnosing on.
> > 
> > I agree, but then we are implementing a checker which is different from the 
> > description given in cert-mem57.
> > So it is not a CERT checker anymore, perhaps we should rename then.
> > There is no mention of __STDCPP_DEFAULT_NEW_ALIGNMENT__ in 
> > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > It clearly references the "fundamental alignement".
> Why do you believe that to be a false positive? That seems like exactly the 
> behavior we'd want -- if the user says that their allocation function 
> guarantees a particular max alignment by using `-fnew-alignment`, we should 
> honor that.
> Why do you believe that to be a false positive? That seems like exactly the 
> behavior we'd want -- if the user says that their allocation function 
> guarantees a particular max alignment by using -fnew-alignment, we should 
> honor that.

Okay, giving it more thought, that makes perfect sense.
Anyway, thanks for trying to understand my concerns :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67545



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

martong wrote:
> aaron.ballman wrote:
> > martong wrote:
> > > martong wrote:
> > > > aaron.ballman wrote:
> > > > > lebedev.ri wrote:
> > > > > > martong wrote:
> > > > > > > martong wrote:
> > > > > > > > What is the difference between "default" and "fundamental" 
> > > > > > > > alignment? Are they the same? Can they differ in any 
> > > > > > > > architecture?
> > > > > > > > 
> > > > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > > > Here there is no wording of "default alignment" only 
> > > > > > > > "fundamental alignment" is mentioned. Based on this I'd call 
> > > > > > > > this as `FundamentalAligment`.
> > > > > > > > What is the difference between "default" and "fundamental" 
> > > > > > > > alignment? Are they the same?
> > > > > > > 
> > > > > > > `fundamental alignment` of any type is the alignment of 
> > > > > > > std::max_align_t. I.e. `alignof(std::max_align_t)`. 
> > > > > > > See C++17 6.11.2.
> > > > > > > 
> > > > > > > On the other hand, default alignment is the value in 
> > > > > > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with 
> > > > > > > `fnew-alignment`
> > > > > > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > > > > > 
> > > > > > > These values can differ: 
> > > > > > > https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > > > > > 
> > > > > > > Thus, I think we should use the fundamental alignment here, not 
> > > > > > > the default alignment. 
> > > > > > > So, `getNewAlign()` does not seem right to me.
> > > > > > > @aaron.ballman What do you think?
> > > > > > > Thus, I think we should use the fundamental alignment here, not 
> > > > > > > the default alignment.
> > > > > > 
> > > > > > I have the exact opposite view.
> > > > > > If as per `getNewAlign()` the alignment would be okay, why should 
> > > > > > we not trust it?
> > > > > The comment on `getNewAlign()` is:
> > > > > ```
> > > > >   /// Return the largest alignment for which a suitably-sized 
> > > > > allocation with
> > > > >   /// '::operator new(size_t)' is guaranteed to produce a 
> > > > > correctly-aligned
> > > > >   /// pointer.
> > > > > ```
> > > > > I read that as saying any alignment larger than what is returned by 
> > > > > `getNewAlign()` must call the over-aligned operator new variant in 
> > > > > C++17 if available. So if the actual call target doesn't have an 
> > > > > alignment specifier, it's probably getting the alignment wrong and 
> > > > > would be worth diagnosing on.
> > > > > I have the exact opposite view.
> > > > > If as per getNewAlign() the alignment would be okay, why should we 
> > > > > not trust it?
> > > > 
> > > > That could lead to a false positive diagnostic if `-fnew-alignment=8` 
> > > > and `alignas(16)` , because `alignof(max_align_t)` is still 16.
> > > > 
> > > > See the definidion of `getNewAlign()` which will return with 8 in this 
> > > > case I suppose:
> > > > ```
> > > >   unsigned getNewAlign() const {
> > > > return NewAlign ? NewAlign : std::max(LongDoubleAlign, 
> > > > LongLongAlign);
> > > >   }
> > > > ```
> > > > So if the actual call target doesn't have an alignment specifier, it's 
> > > > probably getting the alignment wrong and would be worth diagnosing on.
> > > 
> > > I agree, but then we are implementing a checker which is different from 
> > > the description given in cert-mem57.
> > > So it is not a CERT checker anymore, perhaps we should rename then.
> > > There is no mention of __STDCPP_DEFAULT_NEW_ALIGNMENT__ in 
> > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > It clearly references the "fundamental alignement".
> > Why do you believe that to be a false positive? That seems like exactly the 
> > behavior we'd want -- if the user says that their allocation function 
> > guarantees a particular max alignment by using `-fnew-alignment`, we should 
> > honor that.
> > Why do you believe that to be a false positive? That seems like exactly the 
> > behavior we'd want -- if the user says that their allocation function 
> > guarantees a particular max alignment by using -fnew-alignment, we should 
> > honor that.
> 
> Okay, giving it more thought, that makes perfect sense.
> Anyway, thanks for trying to understand my concerns :)
That's because the CERT rule was written to target C++14 and earlier, which did 
not have `__STDCPP_DEFAULT_NEW_ALIGNMENT__`.

We can solve this in one of two ways: don't enable the check in C++17 mode, or 
do the right thing in C++17 mode. I think we should do the right thing, which 
is to check which overload is selec

[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Kiran Chandramohan via Phabricator via cfe-commits]

kiranchandramohan added a comment.

Some minor comments about Filetypes and file extensions. Can be ignored or 
considered for a separate commit.




Comment at: clang/include/clang/Driver/Driver.h:69
+CLMode,
+FlangMode,
   } Mode;

Is the comma by choice?



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:37
+  if (isa(JA)) {
+CmdArgs.push_back("-emit-obj");
+  } else if (isa(JA)) {

peterwaller-arm wrote:
> richard.barton.arm wrote:
> > F18 does not currently support these options that control the output like 
> > -emit-llvm and -emit-obj so this code doesn't do anything sensible at 
> > present. Would it not make more sense to add this later on once F18 or 
> > llvm/flang grows support for such options?
> I've removed them.
Can it be removed from the Summary of this PR?



Comment at: clang/lib/Driver/Types.cpp:220
+
+  case TY_Fortran: case TY_PP_Fortran:
+return true;

Now that there is a 2018 standard, I am assuming that f18 and F18 are also 
valid fortran extensions. Can these be added to the File types?

Also, should the TypeInfo file be extended to handle all Fortran file types? 
./include/clang/Driver/Types.def

Also, should we capture some information about the standards from the filename 
extension?



Comment at: clang/test/Driver/lit.local.cfg:1
-config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.f95',
+config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', 
'.F90', '.f95',
'.cu', '.rs', '.cl', '.hip']

For completion .F95 also?
Should we add f03,F03,f08,F08,f18,F18. May be not now.


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

https://reviews.llvm.org/D63607



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

aaron.ballman wrote:
> martong wrote:
> > aaron.ballman wrote:
> > > martong wrote:
> > > > martong wrote:
> > > > > aaron.ballman wrote:
> > > > > > lebedev.ri wrote:
> > > > > > > martong wrote:
> > > > > > > > martong wrote:
> > > > > > > > > What is the difference between "default" and "fundamental" 
> > > > > > > > > alignment? Are they the same? Can they differ in any 
> > > > > > > > > architecture?
> > > > > > > > > 
> > > > > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > > > > Here there is no wording of "default alignment" only 
> > > > > > > > > "fundamental alignment" is mentioned. Based on this I'd call 
> > > > > > > > > this as `FundamentalAligment`.
> > > > > > > > > What is the difference between "default" and "fundamental" 
> > > > > > > > > alignment? Are they the same?
> > > > > > > > 
> > > > > > > > `fundamental alignment` of any type is the alignment of 
> > > > > > > > std::max_align_t. I.e. `alignof(std::max_align_t)`. 
> > > > > > > > See C++17 6.11.2.
> > > > > > > > 
> > > > > > > > On the other hand, default alignment is the value in 
> > > > > > > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined with 
> > > > > > > > `fnew-alignment`
> > > > > > > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > > > > > > 
> > > > > > > > These values can differ: 
> > > > > > > > https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > > > > > > 
> > > > > > > > Thus, I think we should use the fundamental alignment here, not 
> > > > > > > > the default alignment. 
> > > > > > > > So, `getNewAlign()` does not seem right to me.
> > > > > > > > @aaron.ballman What do you think?
> > > > > > > > Thus, I think we should use the fundamental alignment here, not 
> > > > > > > > the default alignment.
> > > > > > > 
> > > > > > > I have the exact opposite view.
> > > > > > > If as per `getNewAlign()` the alignment would be okay, why should 
> > > > > > > we not trust it?
> > > > > > The comment on `getNewAlign()` is:
> > > > > > ```
> > > > > >   /// Return the largest alignment for which a suitably-sized 
> > > > > > allocation with
> > > > > >   /// '::operator new(size_t)' is guaranteed to produce a 
> > > > > > correctly-aligned
> > > > > >   /// pointer.
> > > > > > ```
> > > > > > I read that as saying any alignment larger than what is returned by 
> > > > > > `getNewAlign()` must call the over-aligned operator new variant in 
> > > > > > C++17 if available. So if the actual call target doesn't have an 
> > > > > > alignment specifier, it's probably getting the alignment wrong and 
> > > > > > would be worth diagnosing on.
> > > > > > I have the exact opposite view.
> > > > > > If as per getNewAlign() the alignment would be okay, why should we 
> > > > > > not trust it?
> > > > > 
> > > > > That could lead to a false positive diagnostic if `-fnew-alignment=8` 
> > > > > and `alignas(16)` , because `alignof(max_align_t)` is still 16.
> > > > > 
> > > > > See the definidion of `getNewAlign()` which will return with 8 in 
> > > > > this case I suppose:
> > > > > ```
> > > > >   unsigned getNewAlign() const {
> > > > > return NewAlign ? NewAlign : std::max(LongDoubleAlign, 
> > > > > LongLongAlign);
> > > > >   }
> > > > > ```
> > > > > So if the actual call target doesn't have an alignment specifier, 
> > > > > it's probably getting the alignment wrong and would be worth 
> > > > > diagnosing on.
> > > > 
> > > > I agree, but then we are implementing a checker which is different from 
> > > > the description given in cert-mem57.
> > > > So it is not a CERT checker anymore, perhaps we should rename then.
> > > > There is no mention of __STDCPP_DEFAULT_NEW_ALIGNMENT__ in 
> > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > It clearly references the "fundamental alignement".
> > > Why do you believe that to be a false positive? That seems like exactly 
> > > the behavior we'd want -- if the user says that their allocation function 
> > > guarantees a particular max alignment by using `-fnew-alignment`, we 
> > > should honor that.
> > > Why do you believe that to be a false positive? That seems like exactly 
> > > the behavior we'd want -- if the user says that their allocation function 
> > > guarantees a particular max alignment by using -fnew-alignment, we should 
> > > honor that.
> > 
> > Okay, giving it more thought, that makes perfect sense.
> > Anyway, thanks for trying to understand my concerns :)
> That's because the CERT rule was written to target C++14 and earlier, which 
> did not have `__STDCPP_DEFAULT

RE: r372185 - Revert "Create UsersManual section entitled 'Controlling Floating Point"

[Keane, Erich via cfe-commits]

Ah, sorry-
It broke the sphinx build bot, and the author was home for the evening and is 
going to get to it during the day today.

From: Richard Smith 
Sent: Tuesday, September 17, 2019 8:10 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r372185 - Revert "Create UsersManual section entitled 'Controlling 
Floating Point"

On Tue, 17 Sep 2019, 15:25 Erich Keane via cfe-commits, 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Sep 17 14:27:07 2019
New Revision: 372185

URL: http://llvm.org/viewvc/llvm-project?rev=372185&view=rev
Log:
Revert "Create UsersManual section entitled 'Controlling Floating Point"

When reverting a change, please include a reason for the revert in your commit 
message.

This reverts commit a08d5a4b0ebd44dc64f41049ed4e97a3c6d31498.

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=372185&r1=372184&r2=372185&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Tue Sep 17 14:27:07 2019
@@ -1128,165 +1128,6 @@ number of cases where the compilation en
 and the precompiled header cannot be generated after headers have been
 installed.

-.. _controlling-fp-behavior:
-
-Controlling Floating Point Behavior

-
-Clang provides a number of ways to control floating point behavior. The options
-are listed below.
-
-.. option:: -ffast-math
-
-   Enable fast-math mode.  This option lets the
-   compiler make aggressive, potentially-lossy assumptions about
-   floating-point math.  These include:
-
-   * Floating-point math obeys regular algebraic rules for real numbers (e.g.
- ``+`` and ``*`` are associative, ``x/y == x * (1/y)``, and
- ``(a + b) * c == a * c + b * c``),
-   * Operands to floating-point operations are not equal to ``NaN`` and
- ``Inf``, and
-   * ``+0`` and ``-0`` are interchangeable.
-
-   ``-ffast-math`` also defines the ``__FAST_MATH__`` preprocessor
-   macro. Some math libraries recognize this macro and change their behavior.
-   With the exception of ``-ffp-contract=fast``, using any of the options
-   below to disable any of the individual optimizations in ``-ffast-math``
-   will cause ``__FAST_MATH__`` to no longer be set.
-
-  This option implies:
-
-   * ``-fno-honor-infinities``
-
-   * ``-fno-honor-nans``
-
-   * ``-fno-math-errno``
-
-   * ``-ffinite-math``
-
-   * ``-fassociative-math``
-
-   * ``-freciprocal-math``
-
-   * ``-fno-signed-zeros``
-
-   * ``-fno-trapping-math``
-
-   * ``-ffp-contract=fast``
-
-.. option:: -fdenormal-fp-math=
-
-   Select which denormal numbers the code is permitted to require.
-
-   Valid values are:
-
-   * ``ieee`` - IEEE 754 denormal numbers
-   * ``preserve-sign`` - the sign of a flushed-to-zero number is preserved in 
the sign of 0
-   * ``positive-zero`` - denormals are flushed to positive zero
-
-   Defaults to ``ieee``.
-
-.. option:: -f[no-]strict-float-cast-overflow
-
-   When a floating-point value is not representable in a destination integer
-   type, the code has undefined behavior according to the language standard.
-   By default, Clang will not guarantee any particular result in that case.
-   With the 'no-strict' option, Clang attempts to match the overflowing 
behavior
-   of the target's native float-to-int conversion instructions.
-
-.. option:: -f[no-]math-errno
-
-   Require math functions to indicate errors by setting errno.
-   The default varies by ToolChain.  ``-fno-math-errno`` allows optimizations
-   that might cause standard C math functions to not set ``errno``.
-   For example, on some systems, the math function ``sqrt`` is specified
-   as setting ``errno`` to ``EDOM`` when the input is negative. On these
-   systems, the compiler cannot normally optimize a call to ``sqrt`` to use
-   inline code (e.g. the x86 ``sqrtsd`` instruction) without additional
-   checking to ensure that ``errno`` is set appropriately.
-   ``-fno-math-errno`` permits these transformations.
-
-   On some targets, math library functions never set ``errno``, and so
-   ``-fno-math-errno`` is the default. This includes most BSD-derived
-   systems, including Darwin.
-
-.. option:: -f[no-]trapping-math
-
-   ``-fno-trapping-math`` allows optimizations that assume that
-   floating point operations cannot generate traps such as divide-by-zero,
-   overflow and underflow. Defaults to ``-ftrapping-math``.
-   Currently this option has no effect.
-
-.. option:: -ffp-contract=
-
-   Specify when the compiler is permitted to form fused floating-point
-   operations, such as fused multiply-add (FMA). Fused operations are
-   permitted to produce more precise results than performing the same
-   operations separately.
-
-   The C standard permits intermediate floating-point results within an
-   expression to be computed with more precis

r372225 - Revert r372082 "[Clang] Pragma vectorize_width() implies vectorize(enable)"

[Hans Wennborg via cfe-commits]

Author: hans
Date: Wed Sep 18 06:41:51 2019
New Revision: 372225

URL: http://llvm.org/viewvc/llvm-project?rev=372225&view=rev
Log:
Revert r372082 "[Clang] Pragma vectorize_width() implies vectorize(enable)"

This broke the Chromium build. Consider the following code:

  float ScaleSumSamples_C(const float* src, float* dst, float scale, int width) 
{
float fsum = 0.f;
int i;
  #if defined(__clang__)
  #pragma clang loop vectorize_width(4)
  #endif
for (i = 0; i < width; ++i) {
  float v = *src++;
  fsum += v * v;
  *dst++ = v * scale;
}
return fsum;
  }

Compiling at -Oz, Clang  now warns:

  $ clang++ -target x86_64 -Oz -c /tmp/a.cc
  /tmp/a.cc:1:7: warning: loop not vectorized: the optimizer was unable to
  perform the requested transformation; the transformation might be disabled or
  specified as part of an unsupported transformation ordering
  [-Wpass-failed=transform-warning]

this suggests it's not actually enabling vectorization hard enough.

At -Os it asserts instead:

  $ build.release/bin/clang++ -target x86_64 -Os -c /tmp/a.cc
  clang-10: 
/work/llvm.monorepo/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:2734: void
  llvm::InnerLoopVectorizer::emitMemRuntimeChecks(llvm::Loop*, 
llvm::BasicBlock*): Assertion `
  !BB->getParent()->hasOptSize() && "Cannot emit memory checks when optimizing 
for size"' failed.

Of course neither of these are what the developer expected from the pragma.

> Specifying the vectorization width was supposed to implicitly enable
> vectorization, except that it wasn't really doing this. It was only
> setting the vectorize.width metadata, but not vectorize.enable.
>
> This should fix PR27643.
>
> Differential Revision: https://reviews.llvm.org/D66290

Modified:
cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp
cfe/trunk/test/CodeGenCXX/pragma-loop.cpp

Modified: cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGLoopInfo.cpp?rev=372225&r1=372224&r2=372225&view=diff
==
--- cfe/trunk/lib/CodeGen/CGLoopInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGLoopInfo.cpp Wed Sep 18 06:41:51 2019
@@ -270,14 +270,6 @@ LoopInfo::createLoopVectorizeMetadata(co
 
   // Setting vectorize.width
   if (Attrs.VectorizeWidth > 0) {
-// This implies vectorize.enable = true, but only add it when it is not
-// already enabled.
-if (Attrs.VectorizeEnable != LoopAttributes::Enable)
-  Args.push_back(
-  MDNode::get(Ctx, {MDString::get(Ctx, "llvm.loop.vectorize.enable"),
-ConstantAsMetadata::get(ConstantInt::get(
-llvm::Type::getInt1Ty(Ctx), 1))}));
-
 Metadata *Vals[] = {
 MDString::get(Ctx, "llvm.loop.vectorize.width"),
 ConstantAsMetadata::get(ConstantInt::get(llvm::Type::getInt32Ty(Ctx),

Modified: cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp?rev=372225&r1=372224&r2=372225&view=diff
==
--- cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp Wed Sep 18 06:41:51 2019
@@ -58,6 +58,7 @@ void test5(int *List, int Length) {
 List[i] = i * 2;
 }
 
+
 // CHECK:  ![[LOOP0]] = distinct !{![[LOOP0]], !3}
 // CHECK-NEXT: !3 = !{!"llvm.loop.vectorize.enable", i1 true}
 
@@ -69,7 +70,7 @@ void test5(int *List, int Length) {
 
 // CHECK-NEXT: ![[LOOP3]] = distinct !{![[LOOP3]], !5, !3}
 
-// CHECK-NEXT: ![[LOOP4]] = distinct !{![[LOOP4]], !3, !10}
+// CHECK-NEXT: ![[LOOP4]] = distinct !{![[LOOP4]], !10}
 // CHECK-NEXT: !10 = !{!"llvm.loop.vectorize.width", i32 1}
 
-// CHECK-NEXT: ![[LOOP5]] = distinct !{![[LOOP5]], !3, !10}
+// CHECK-NEXT: ![[LOOP5]] = distinct !{![[LOOP5]], !10}

Modified: cfe/trunk/test/CodeGenCXX/pragma-loop.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pragma-loop.cpp?rev=372225&r1=372224&r2=372225&view=diff
==
--- cfe/trunk/test/CodeGenCXX/pragma-loop.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/pragma-loop.cpp Wed Sep 18 06:41:51 2019
@@ -158,41 +158,23 @@ void template_test(double *List, int Len
   for_template_constant_expression_test(List, Length);
 }
 
-void vec_width_1(int *List, int Length) {
-// CHECK-LABEL: @{{.*}}vec_width_1{{.*}}(
-// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_15:.*]]
-
-  #pragma clang loop vectorize(enable) vectorize_width(1)
-  for (int i = 0; i < Length; i++)
-List[i] = i * 2;
-}
-
-void width_1(int *List, int Length) {
-// CHECK-LABEL: @{{.*}}width_1{{.*}}(
-// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_16:.*]]
-
-  #pragma clang loop vectorize_width(1)
-  for (int i = 0; i < Length; i++)
-

Re: r372082 - [Clang] Pragma vectorize_width() implies vectorize(enable)

[Hans Wennborg via cfe-commits]

I've reverted this in r372225 as it broke the Chromium build. It seems
it doesn't actually manage to enable vectorization of a simple loop at
-Oz, and at -Os it asserts. See details in my commit message.

On Tue, Sep 17, 2019 at 10:41 AM Sjoerd Meijer via cfe-commits
 wrote:
>
> Author: sjoerdmeijer
> Date: Tue Sep 17 01:43:11 2019
> New Revision: 372082
>
> URL: http://llvm.org/viewvc/llvm-project?rev=372082&view=rev
> Log:
> [Clang] Pragma vectorize_width() implies vectorize(enable)
>
> Specifying the vectorization width was supposed to implicitly enable
> vectorization, except that it wasn't really doing this. It was only
> setting the vectorize.width metadata, but not vectorize.enable.
>
> This should fix PR27643.
>
> Differential Revision: https://reviews.llvm.org/D66290
>
> Modified:
> cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
> cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp
> cfe/trunk/test/CodeGenCXX/pragma-loop.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGLoopInfo.cpp?rev=372082&r1=372081&r2=372082&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGLoopInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGLoopInfo.cpp Tue Sep 17 01:43:11 2019
> @@ -270,6 +270,14 @@ LoopInfo::createLoopVectorizeMetadata(co
>
>// Setting vectorize.width
>if (Attrs.VectorizeWidth > 0) {
> +// This implies vectorize.enable = true, but only add it when it is not
> +// already enabled.
> +if (Attrs.VectorizeEnable != LoopAttributes::Enable)
> +  Args.push_back(
> +  MDNode::get(Ctx, {MDString::get(Ctx, "llvm.loop.vectorize.enable"),
> +ConstantAsMetadata::get(ConstantInt::get(
> +llvm::Type::getInt1Ty(Ctx), 1))}));
> +
>  Metadata *Vals[] = {
>  MDString::get(Ctx, "llvm.loop.vectorize.width"),
>  ConstantAsMetadata::get(ConstantInt::get(llvm::Type::getInt32Ty(Ctx),
>
> Modified: cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp?rev=372082&r1=372081&r2=372082&view=diff
> ==
> --- cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp Tue Sep 17 01:43:11 
> 2019
> @@ -58,7 +58,6 @@ void test5(int *List, int Length) {
>  List[i] = i * 2;
>  }
>
> -
>  // CHECK:  ![[LOOP0]] = distinct !{![[LOOP0]], !3}
>  // CHECK-NEXT: !3 = !{!"llvm.loop.vectorize.enable", i1 true}
>
> @@ -70,7 +69,7 @@ void test5(int *List, int Length) {
>
>  // CHECK-NEXT: ![[LOOP3]] = distinct !{![[LOOP3]], !5, !3}
>
> -// CHECK-NEXT: ![[LOOP4]] = distinct !{![[LOOP4]], !10}
> +// CHECK-NEXT: ![[LOOP4]] = distinct !{![[LOOP4]], !3, !10}
>  // CHECK-NEXT: !10 = !{!"llvm.loop.vectorize.width", i32 1}
>
> -// CHECK-NEXT: ![[LOOP5]] = distinct !{![[LOOP5]], !10}
> +// CHECK-NEXT: ![[LOOP5]] = distinct !{![[LOOP5]], !3, !10}
>
> Modified: cfe/trunk/test/CodeGenCXX/pragma-loop.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pragma-loop.cpp?rev=372082&r1=372081&r2=372082&view=diff
> ==
> --- cfe/trunk/test/CodeGenCXX/pragma-loop.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/pragma-loop.cpp Tue Sep 17 01:43:11 2019
> @@ -158,23 +158,41 @@ void template_test(double *List, int Len
>for_template_constant_expression_test(List, Length);
>  }
>
> +void vec_width_1(int *List, int Length) {
> +// CHECK-LABEL: @{{.*}}vec_width_1{{.*}}(
> +// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_15:.*]]
> +
> +  #pragma clang loop vectorize(enable) vectorize_width(1)
> +  for (int i = 0; i < Length; i++)
> +List[i] = i * 2;
> +}
> +
> +void width_1(int *List, int Length) {
> +// CHECK-LABEL: @{{.*}}width_1{{.*}}(
> +// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_16:.*]]
> +
> +  #pragma clang loop vectorize_width(1)
> +  for (int i = 0; i < Length; i++)
> +List[i] = i * 2;
> +}
> +
>  // CHECK: ![[LOOP_1]] = distinct !{![[LOOP_1]], ![[UNROLL_FULL:.*]]}
>  // CHECK: ![[UNROLL_FULL]] = !{!"llvm.loop.unroll.full"}
>
> -// CHECK: ![[LOOP_2]] = distinct !{![[LOOP_2]], ![[UNROLL_DISABLE:.*]], 
> ![[DISTRIBUTE_DISABLE:.*]], ![[WIDTH_8:.*]], ![[INTERLEAVE_4:.*]]}
> +// CHECK: ![[LOOP_2]] = distinct !{![[LOOP_2]], ![[UNROLL_DISABLE:.*]], 
> ![[DISTRIBUTE_DISABLE:.*]], ![[VECTORIZE_ENABLE:.*]], ![[WIDTH_8:.*]], 
> ![[INTERLEAVE_4:.*]]}
>  // CHECK: ![[UNROLL_DISABLE]] = !{!"llvm.loop.unroll.disable"}
>  // CHECK: ![[DISTRIBUTE_DISABLE]] = !{!"llvm.loop.distribute.enable", i1 
> false}
> +// CHECK: ![[VECTORIZE_ENABLE]] = !{!"llvm.loop.vectorize.enable", i1 true}
>  // CHECK: ![[WIDTH_8]] = !{!"llvm.loop.vectorize.width", i32 8}
>  // CHECK: ![[INTERLEAVE_4]] = !{!"llv

[PATCH] D67706: [clang][checkers] Using CallDescription in StreamChecker.

[Balázs Kéri via Phabricator via cfe-commits]

balazske created this revision.
Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp.
Herald added a project: clang.

Recognization of function names is done now with the CallDescription
class instead of using IdentifierInfo. This means function name and
argument count is compared too.
A new check for filtering not global-C-functions was added.
Test was updated.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67706

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

Index: clang/test/Analysis/stream.c
===
--- clang/test/Analysis/stream.c
+++ clang/test/Analysis/stream.c
@@ -1,6 +1,7 @@
 // RUN: %clang_analyze_cc1 -analyzer-checker=alpha.unix.Stream -analyzer-store region -verify %s
 
 typedef __typeof__(sizeof(int)) size_t;
+typedef __typeof__(sizeof(int)) fpos_t;
 typedef struct _IO_FILE FILE;
 #define SEEK_SET	0	/* Seek from beginning of file.  */
 #define SEEK_CUR	1	/* Seek from current position.  */
@@ -9,36 +10,93 @@
 extern FILE *tmpfile(void);
 extern int fclose(FILE *fp);
 extern size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);
+extern size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE *stream);
 extern int fseek (FILE *__stream, long int __off, int __whence);
 extern long int ftell (FILE *__stream);
 extern void rewind (FILE *__stream);
+extern int fgetpos(FILE *stream, fpos_t *pos);
+extern int fsetpos(FILE *stream, const fpos_t *pos);
+extern void clearerr(FILE *stream);
+extern int feof(FILE *stream);
+extern int ferror(FILE *stream);
+extern int fileno(FILE *stream);
 
-void f1(void) {
-  FILE *p = fopen("foo", "r");
-  char buf[1024];
-  fread(buf, 1, 1, p); // expected-warning {{Stream pointer might be NULL}}
-  fclose(p);
+void check_fread() {
+  FILE *fp = tmpfile();
+  fread(0, 0, 0, fp); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
 }
 
-void f2(void) {
-  FILE *p = fopen("foo", "r");
-  fseek(p, 1, SEEK_SET); // expected-warning {{Stream pointer might be NULL}}
-  fclose(p);
+void check_fwrite() {
+  FILE *fp = tmpfile();
+  fwrite(0, 0, 0, fp); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
 }
 
-void f3(void) {
-  FILE *p = fopen("foo", "r");
-  ftell(p); // expected-warning {{Stream pointer might be NULL}}
-  fclose(p);
+void check_fseek() {
+  FILE *fp = tmpfile();
+  fseek(fp, 0, 0); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
+}
+
+void check_ftell() {
+  FILE *fp = tmpfile();
+  ftell(fp); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
+}
+
+void check_rewind() {
+  FILE *fp = tmpfile();
+  rewind(fp); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
+}
+
+void check_fgetpos() {
+  FILE *fp = tmpfile();
+  fpos_t pos;
+  fgetpos(fp, &pos); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
+}
+
+void check_fsetpos() {
+  FILE *fp = tmpfile();
+  fpos_t pos;
+  fsetpos(fp, &pos); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
+}
+
+void check_clearerr() {
+  FILE *fp = tmpfile();
+  clearerr(fp); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
+}
+
+void check_feof() {
+  FILE *fp = tmpfile();
+  feof(fp); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
+}
+
+void check_ferror() {
+  FILE *fp = tmpfile();
+  ferror(fp); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
 }
 
-void f4(void) {
+void check_fileno() {
+  FILE *fp = tmpfile();
+  fileno(fp); // expected-warning {{Stream pointer might be NULL}}
+  fclose(fp);
+}
+
+void f_open(void) {
   FILE *p = fopen("foo", "r");
-  rewind(p); // expected-warning {{Stream pointer might be NULL}}
+  char buf[1024];
+  fread(buf, 1, 1, p); // expected-warning {{Stream pointer might be NULL}}
   fclose(p);
 }
 
-void f5(void) {
+void f_seek(void) {
   FILE *p = fopen("foo", "r");
   if (!p)
 return;
@@ -47,26 +105,20 @@
   fclose(p);
 }
 
-void f6(void) {
+void f_double_close(void) {
   FILE *p = fopen("foo", "r");
   fclose(p); 
   fclose(p); // expected-warning {{Try to close a file Descriptor already closed. Cause undefined behaviour}}
 }
 
-void f7(void) {
-  FILE *p = tmpfile();
-  ftell(p); // expected-warning {{Stream pointer might be NULL}}
-  fclose(p);
-}
-
-void f8(int c) {
+void f_leak(int c) {
   FILE *p = fopen("foo.c", "r");
   if(c)
 return; // expected-warning {{Opened File never closed. Potential Resource leak}}
   fclose(p);
 }
 
-FILE *f9(void) {
+FILE *f_null_checked(void) {
   FILE *p = fopen("foo.c", "r");
   if (p)
 return p; // no-warning
@@ -82,4 +134,3 @@
 void pr8081(FILE *stream, long offset, int whence) {
   fseek(stream, offset, whence);
 }
-
Index: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ cla

Re: r372082 - [Clang] Pragma vectorize_width() implies vectorize(enable)

[Sjoerd Meijer via cfe-commits]

Oopsy daisy! Sorry, and thanks for the revert. I will look into this.

From: Hans Wennborg 
Sent: 18 September 2019 14:41
To: Sjoerd Meijer 
Cc: cfe-commits 
Subject: Re: r372082 - [Clang] Pragma vectorize_width() implies 
vectorize(enable)

I've reverted this in r372225 as it broke the Chromium build. It seems
it doesn't actually manage to enable vectorization of a simple loop at
-Oz, and at -Os it asserts. See details in my commit message.

On Tue, Sep 17, 2019 at 10:41 AM Sjoerd Meijer via cfe-commits
 wrote:
>
> Author: sjoerdmeijer
> Date: Tue Sep 17 01:43:11 2019
> New Revision: 372082
>
> URL: http://llvm.org/viewvc/llvm-project?rev=372082&view=rev
> Log:
> [Clang] Pragma vectorize_width() implies vectorize(enable)
>
> Specifying the vectorization width was supposed to implicitly enable
> vectorization, except that it wasn't really doing this. It was only
> setting the vectorize.width metadata, but not vectorize.enable.
>
> This should fix PR27643.
>
> Differential Revision: https://reviews.llvm.org/D66290
>
> Modified:
> cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
> cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp
> cfe/trunk/test/CodeGenCXX/pragma-loop.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGLoopInfo.cpp?rev=372082&r1=372081&r2=372082&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGLoopInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGLoopInfo.cpp Tue Sep 17 01:43:11 2019
> @@ -270,6 +270,14 @@ LoopInfo::createLoopVectorizeMetadata(co
>
>// Setting vectorize.width
>if (Attrs.VectorizeWidth > 0) {
> +// This implies vectorize.enable = true, but only add it when it is not
> +// already enabled.
> +if (Attrs.VectorizeEnable != LoopAttributes::Enable)
> +  Args.push_back(
> +  MDNode::get(Ctx, {MDString::get(Ctx, "llvm.loop.vectorize.enable"),
> +ConstantAsMetadata::get(ConstantInt::get(
> +llvm::Type::getInt1Ty(Ctx), 1))}));
> +
>  Metadata *Vals[] = {
>  MDString::get(Ctx, "llvm.loop.vectorize.width"),
>  ConstantAsMetadata::get(ConstantInt::get(llvm::Type::getInt32Ty(Ctx),
>
> Modified: cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp?rev=372082&r1=372081&r2=372082&view=diff
> ==
> --- cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/pragma-loop-predicate.cpp Tue Sep 17 01:43:11 
> 2019
> @@ -58,7 +58,6 @@ void test5(int *List, int Length) {
>  List[i] = i * 2;
>  }
>
> -
>  // CHECK:  ![[LOOP0]] = distinct !{![[LOOP0]], !3}
>  // CHECK-NEXT: !3 = !{!"llvm.loop.vectorize.enable", i1 true}
>
> @@ -70,7 +69,7 @@ void test5(int *List, int Length) {
>
>  // CHECK-NEXT: ![[LOOP3]] = distinct !{![[LOOP3]], !5, !3}
>
> -// CHECK-NEXT: ![[LOOP4]] = distinct !{![[LOOP4]], !10}
> +// CHECK-NEXT: ![[LOOP4]] = distinct !{![[LOOP4]], !3, !10}
>  // CHECK-NEXT: !10 = !{!"llvm.loop.vectorize.width", i32 1}
>
> -// CHECK-NEXT: ![[LOOP5]] = distinct !{![[LOOP5]], !10}
> +// CHECK-NEXT: ![[LOOP5]] = distinct !{![[LOOP5]], !3, !10}
>
> Modified: cfe/trunk/test/CodeGenCXX/pragma-loop.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/pragma-loop.cpp?rev=372082&r1=372081&r2=372082&view=diff
> ==
> --- cfe/trunk/test/CodeGenCXX/pragma-loop.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/pragma-loop.cpp Tue Sep 17 01:43:11 2019
> @@ -158,23 +158,41 @@ void template_test(double *List, int Len
>for_template_constant_expression_test(List, Length);
>  }
>
> +void vec_width_1(int *List, int Length) {
> +// CHECK-LABEL: @{{.*}}vec_width_1{{.*}}(
> +// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_15:.*]]
> +
> +  #pragma clang loop vectorize(enable) vectorize_width(1)
> +  for (int i = 0; i < Length; i++)
> +List[i] = i * 2;
> +}
> +
> +void width_1(int *List, int Length) {
> +// CHECK-LABEL: @{{.*}}width_1{{.*}}(
> +// CHECK: br label {{.*}}, !llvm.loop ![[LOOP_16:.*]]
> +
> +  #pragma clang loop vectorize_width(1)
> +  for (int i = 0; i < Length; i++)
> +List[i] = i * 2;
> +}
> +
>  // CHECK: ![[LOOP_1]] = distinct !{![[LOOP_1]], ![[UNROLL_FULL:.*]]}
>  // CHECK: ![[UNROLL_FULL]] = !{!"llvm.loop.unroll.full"}
>
> -// CHECK: ![[LOOP_2]] = distinct !{![[LOOP_2]], ![[UNROLL_DISABLE:.*]], 
> ![[DISTRIBUTE_DISABLE:.*]], ![[WIDTH_8:.*]], ![[INTERLEAVE_4:.*]]}
> +// CHECK: ![[LOOP_2]] = distinct !{![[LOOP_2]], ![[UNROLL_DISABLE:.*]], 
> ![[DISTRIBUTE_DISABLE:.*]], ![[VECTORIZE_ENABLE:.*]], ![[WIDTH_8:.*]], 
> ![[INTERLEAVE_4:.*]]}
>  // CHECK: ![[UNROLL_DISABLE]] = !{!"llvm.loop.unroll.disable"

[PATCH] D67661: [RISCV] Headers: Add Bitmanip extension Clang header files and rvintrin.h

[Scott Egerton via Phabricator via cfe-commits]

s.egerton added a comment.

Sorry I misread your original comment.

These functions exist so that we can guarantee that these particular 
instructions will be emitted; the other option was LLVM IR intrinsics and Clang 
builtins, this was the other patch (https://reviews.llvm.org/D66479).

We are planning on abandoning that patch in favour of this one after the 
discussions on the patch and the mailing list.


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

https://reviews.llvm.org/D67661



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Balázs Kéri via Phabricator via cfe-commits]

balazske marked an inline comment as done.
balazske added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

aaron.ballman wrote:
> aaron.ballman wrote:
> > martong wrote:
> > > aaron.ballman wrote:
> > > > martong wrote:
> > > > > martong wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > lebedev.ri wrote:
> > > > > > > > martong wrote:
> > > > > > > > > martong wrote:
> > > > > > > > > > What is the difference between "default" and "fundamental" 
> > > > > > > > > > alignment? Are they the same? Can they differ in any 
> > > > > > > > > > architecture?
> > > > > > > > > > 
> > > > > > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > > > > > Here there is no wording of "default alignment" only 
> > > > > > > > > > "fundamental alignment" is mentioned. Based on this I'd 
> > > > > > > > > > call this as `FundamentalAligment`.
> > > > > > > > > > What is the difference between "default" and "fundamental" 
> > > > > > > > > > alignment? Are they the same?
> > > > > > > > > 
> > > > > > > > > `fundamental alignment` of any type is the alignment of 
> > > > > > > > > std::max_align_t. I.e. `alignof(std::max_align_t)`. 
> > > > > > > > > See C++17 6.11.2.
> > > > > > > > > 
> > > > > > > > > On the other hand, default alignment is the value in 
> > > > > > > > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined 
> > > > > > > > > with `fnew-alignment`
> > > > > > > > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > > > > > > > 
> > > > > > > > > These values can differ: 
> > > > > > > > > https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > > > > > > > 
> > > > > > > > > Thus, I think we should use the fundamental alignment here, 
> > > > > > > > > not the default alignment. 
> > > > > > > > > So, `getNewAlign()` does not seem right to me.
> > > > > > > > > @aaron.ballman What do you think?
> > > > > > > > > Thus, I think we should use the fundamental alignment here, 
> > > > > > > > > not the default alignment.
> > > > > > > > 
> > > > > > > > I have the exact opposite view.
> > > > > > > > If as per `getNewAlign()` the alignment would be okay, why 
> > > > > > > > should we not trust it?
> > > > > > > The comment on `getNewAlign()` is:
> > > > > > > ```
> > > > > > >   /// Return the largest alignment for which a suitably-sized 
> > > > > > > allocation with
> > > > > > >   /// '::operator new(size_t)' is guaranteed to produce a 
> > > > > > > correctly-aligned
> > > > > > >   /// pointer.
> > > > > > > ```
> > > > > > > I read that as saying any alignment larger than what is returned 
> > > > > > > by `getNewAlign()` must call the over-aligned operator new 
> > > > > > > variant in C++17 if available. So if the actual call target 
> > > > > > > doesn't have an alignment specifier, it's probably getting the 
> > > > > > > alignment wrong and would be worth diagnosing on.
> > > > > > > I have the exact opposite view.
> > > > > > > If as per getNewAlign() the alignment would be okay, why should 
> > > > > > > we not trust it?
> > > > > > 
> > > > > > That could lead to a false positive diagnostic if 
> > > > > > `-fnew-alignment=8` and `alignas(16)` , because 
> > > > > > `alignof(max_align_t)` is still 16.
> > > > > > 
> > > > > > See the definidion of `getNewAlign()` which will return with 8 in 
> > > > > > this case I suppose:
> > > > > > ```
> > > > > >   unsigned getNewAlign() const {
> > > > > > return NewAlign ? NewAlign : std::max(LongDoubleAlign, 
> > > > > > LongLongAlign);
> > > > > >   }
> > > > > > ```
> > > > > > So if the actual call target doesn't have an alignment specifier, 
> > > > > > it's probably getting the alignment wrong and would be worth 
> > > > > > diagnosing on.
> > > > > 
> > > > > I agree, but then we are implementing a checker which is different 
> > > > > from the description given in cert-mem57.
> > > > > So it is not a CERT checker anymore, perhaps we should rename then.
> > > > > There is no mention of __STDCPP_DEFAULT_NEW_ALIGNMENT__ in 
> > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > It clearly references the "fundamental alignement".
> > > > Why do you believe that to be a false positive? That seems like exactly 
> > > > the behavior we'd want -- if the user says that their allocation 
> > > > function guarantees a particular max alignment by using 
> > > > `-fnew-alignment`, we should honor that.
> > > > Why do you believe that to be a false positive? That seems like exactly 
> > > > the behavior we'd want -- if the user says that their allocation 
> > > > function guarantees a particular max alignment by using 
> > > > -fnew-alignment, we should

[PATCH] D67409: [RISCV] enable LTO support, pass some options to linker.

[Kuan Hsu Chen via Phabricator via cfe-commits]

khchen updated this revision to Diff 220668.
khchen added a comment.

Thanks @lenary, I fixed it.


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

https://reviews.llvm.org/D67409

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.h
  clang/test/Driver/gold-lto.c

Index: clang/test/Driver/gold-lto.c
===
--- clang/test/Driver/gold-lto.c
+++ clang/test/Driver/gold-lto.c
@@ -26,3 +26,21 @@
 // RUN: %clang -target i686-linux-android -### %t.o -flto 2>&1 \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-ANDROID
 // CHECK-X86-ANDROID: "-plugin" "{{.*}}{{[/\\]}}LLVMgold.{{dll|dylib|so}}"
+//
+// RUN: %clang -target riscv64-unknown-elf -### %t.o -flto 2>&1 \
+// RUN: -march=rv64imf -mabi=lp64f \
+// RUN: | FileCheck %s --check-prefix=CHECK-RISCV-BAREMETAL
+// CHECK-RISCV-BAREMETAL: "-plugin" "{{.*}}{{[/\\]}}LLVMgold.{{dll|dylib|so}}"
+// CHECK-RISCV-BAREMETAL: "-plugin-opt=-mattr=+m"
+// CHECK-RISCV-BAREMETAL: "-plugin-opt=-mattr=+f"
+// CHECK-RISCV-BAREMETAL: "-plugin-opt=-mattr=+relax"
+// CHECK-RISCV-BAREMETAL: "-plugin-opt=-target-abi=lp64f"
+//
+// RUN: %clang -target riscv64-unknown-linux-gnu -### %t.o -flto 2>&1 \
+// RUN: -march=rv64imf -mabi=lp64f \
+// RUN: | FileCheck %s --check-prefix=CHECK-RISCV-LINUX
+// CHECK-RISCV-LINUX: "-plugin" "{{.*}}{{[/\\]}}LLVMgold.{{dll|dylib|so}}"
+// CHECK-RISCV-LINUX: "-plugin-opt=-mattr=+m"
+// CHECK-RISCV-LINUX: "-plugin-opt=-mattr=+f"
+// CHECK-RISCV-LINUX: "-plugin-opt=-mattr=+relax"
+// CHECK-RISCV-LINUX: "-plugin-opt=-target-abi=lp64f"
Index: clang/lib/Driver/ToolChains/RISCVToolchain.h
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.h
+++ clang/lib/Driver/ToolChains/RISCVToolchain.h
@@ -25,6 +25,7 @@
   void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args,
  Action::OffloadKind) const override;
+  bool HasNativeLLVMSupport() const override { return true; }
   void
   AddClangSystemIncludeArgs(const llvm::opt::ArgList &DriverArgs,
 llvm::opt::ArgStringList &CC1Args) const override;
Index: clang/lib/Driver/ToolChains/RISCVToolchain.cpp
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "RISCVToolchain.h"
+#include "Arch/RISCV.h"
 #include "CommonArgs.h"
 #include "InputInfo.h"
 #include "clang/Driver/Compilation.h"
@@ -100,6 +101,12 @@
 
   std::string Linker = getToolChain().GetProgramPath(getShortName());
 
+  if (D.isUsingLTO()) {
+assert(!Inputs.empty() && "Must have at least one input.");
+AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+  D.getLTOMode() == LTOK_Thin);
+  }
+
   bool WantCRTs =
   !Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles);
 
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -125,6 +125,14 @@
 void addMultilibFlag(bool Enabled, const char *const Flag,
  Multilib::flags_list &Flags);
 
+StringRef getTargetABI(const llvm::opt::ArgList &Args,
+   const llvm::Triple &Triple);
+
+void getTargetFeatures(const ToolChain &TC, const llvm::Triple &Triple,
+   const llvm::opt::ArgList &Args,
+   llvm::opt::ArgStringList &CmdArgs, bool ForAS,
+   bool ForLTOPlugin = false);
+
 } // end namespace tools
 } // end namespace driver
 } // end namespace clang
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -11,8 +11,12 @@
 #include "Arch/ARM.h"
 #include "Arch/Mips.h"
 #include "Arch/PPC.h"
+#include "Arch/RISCV.h"
+#include "Arch/Sparc.h"
 #include "Arch/SystemZ.h"
 #include "Arch/X86.h"
+#include "AMDGPU.h"
+#include "MSP430.h"
 #include "HIP.h"
 #include "Hexagon.h"
 #include "InputInfo.h"
@@ -490,6 +494,14 @@
   if (!StatsFile.empty())
 CmdArgs.push_back(
 Args.MakeArgString(Twine("-plugin-opt=stats-file=") + StatsFile));
+
+  getTargetFeatures(ToolChain, ToolChain.getTriple(), Args, CmdArgs,
+/* ForAS= */ false, /* ForLTOPlugin= */ true);
+
+  StringRef ABIName = tools::getTargetABI(Args, ToolChain.getTriple());
+  if (!ABIName.empty())
+CmdArgs.push

r372229 - Recommit -r372180

[Erich Keane via cfe-commits]

Author: erichkeane
Date: Wed Sep 18 08:09:49 2019
New Revision: 372229

URL: http://llvm.org/viewvc/llvm-project?rev=372229&view=rev
Log:
Recommit -r372180

Commit message below, original caused the sphinx build bot to fail, this
one should fix it.

Create UsersManual section entitled 'Controlling Floating Point
Behavior'

Create a new section for documenting the floating point options. Move
all the floating point options into this section, and add new entries
for the floating point options that exist but weren't previously
described in the UsersManual.

Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D67517

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=372229&r1=372228&r2=372229&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Wed Sep 18 08:09:49 2019
@@ -1128,6 +1128,185 @@ number of cases where the compilation en
 and the precompiled header cannot be generated after headers have been
 installed.
 
+.. _controlling-fp-behavior:
+
+Controlling Floating Point Behavior
+---
+
+Clang provides a number of ways to control floating point behavior. The options
+are listed below.
+
+.. option:: -ffast-math
+
+   Enable fast-math mode.  This option lets the
+   compiler make aggressive, potentially-lossy assumptions about
+   floating-point math.  These include:
+
+   * Floating-point math obeys regular algebraic rules for real numbers (e.g.
+ ``+`` and ``*`` are associative, ``x/y == x * (1/y)``, and
+ ``(a + b) * c == a * c + b * c``),
+   * Operands to floating-point operations are not equal to ``NaN`` and
+ ``Inf``, and
+   * ``+0`` and ``-0`` are interchangeable.
+
+   ``-ffast-math`` also defines the ``__FAST_MATH__`` preprocessor
+   macro. Some math libraries recognize this macro and change their behavior.
+   With the exception of ``-ffp-contract=fast``, using any of the options
+   below to disable any of the individual optimizations in ``-ffast-math``
+   will cause ``__FAST_MATH__`` to no longer be set.
+
+  This option implies:
+
+   * ``-fno-honor-infinities``
+
+   * ``-fno-honor-nans``
+
+   * ``-fno-math-errno``
+
+   * ``-ffinite-math``
+
+   * ``-fassociative-math``
+
+   * ``-freciprocal-math``
+
+   * ``-fno-signed-zeros``
+
+   * ``-fno-trapping-math``
+
+   * ``-ffp-contract=fast``
+
+.. option:: -fdenormal-fp-math=
+
+   Select which denormal numbers the code is permitted to require.
+
+   Valid values are: 
+
+   * ``ieee`` - IEEE 754 denormal numbers
+   * ``preserve-sign`` - the sign of a flushed-to-zero number is preserved in 
the sign of 0
+   * ``positive-zero`` - denormals are flushed to positive zero
+
+   Defaults to ``ieee``.
+
+.. _opt_fstrict-float-cast-overflow:
+
+**-f[no-]strict-float-cast-overflow**
+
+   When a floating-point value is not representable in a destination integer 
+   type, the code has undefined behavior according to the language standard.
+   By default, Clang will not guarantee any particular result in that case.
+   With the 'no-strict' option, Clang attempts to match the overflowing 
behavior
+   of the target's native float-to-int conversion instructions.
+
+.. _opt_fmath-errno:
+
+**-f[no-]math-errno**
+
+   Require math functions to indicate errors by setting errno.
+   The default varies by ToolChain.  ``-fno-math-errno`` allows optimizations
+   that might cause standard C math functions to not set ``errno``.
+   For example, on some systems, the math function ``sqrt`` is specified
+   as setting ``errno`` to ``EDOM`` when the input is negative. On these
+   systems, the compiler cannot normally optimize a call to ``sqrt`` to use
+   inline code (e.g. the x86 ``sqrtsd`` instruction) without additional
+   checking to ensure that ``errno`` is set appropriately.
+   ``-fno-math-errno`` permits these transformations.
+
+   On some targets, math library functions never set ``errno``, and so
+   ``-fno-math-errno`` is the default. This includes most BSD-derived
+   systems, including Darwin.
+
+.. _opt_ftrapping-math:
+
+**-f[no-]trapping-math**
+
+   ``-fno-trapping-math`` allows optimizations that assume that
+   floating point operations cannot generate traps such as divide-by-zero,
+   overflow and underflow. Defaults to ``-ftrapping-math``.
+   Currently this option has no effect.
+
+.. option:: -ffp-contract=
+
+   Specify when the compiler is permitted to form fused floating-point
+   operations, such as fused multiply-add (FMA). Fused operations are
+   permitted to produce more precise results than performing the same
+   operations separately.
+
+   The C standard permits intermediate floating-point results within an
+   expression to be computed with more precision than their type would
+   normally allow. This permits operation fusing, and Clang t

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

@Meinersbur any feedback on this update?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61446



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

[PATCH] D67661: [RISCV] Headers: Add Bitmanip extension Clang header files and rvintrin.h

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D67661#1673993 , @lebedev.ri wrote:

> In D67661#1673918 , @s.egerton wrote:
>
> > Sorry I misread your original comment.
>
>
> (which one?)
>
> > These functions exist so that we can guarantee that these particular 
> > instructions will be emitted;
>
> Sure, that makes sense.
>
> > the other option was LLVM IR intrinsics and Clang builtins, this was the 
> > other patch (https://reviews.llvm.org/D66479).
> >  We are planning on abandoning that patch in favour of this one after the 
> > discussions on the patch and the mailing list.
>
> I sure did comment that both of these approaches (emitting inline asm, or 
> having arch-specific intrinsics)
>  are worse than emitting plain IR (as there is no 'real' incentive to enhance 
> backend pattern-matching),
>  but arch-specific intrinsics are certainly better than inline asm.
>  Sorry if that thought got convoluted.


Err, my main point against arch-specific intrinsics was about NOT producing 
them in middle-end,
since nothing will know about them, and thus the IR would become more opaque if 
you produce them in middle-end.


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

https://reviews.llvm.org/D67661



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

[PATCH] D62686: [RISCV] Add support for save/restore of callee-saved registers via libcalls

[Lewis Revill via Phabricator via cfe-commits]

lewis-revill updated this revision to Diff 220677.
lewis-revill added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Replace internal -mllvm option with target feature enabled through the clang 
frontend using -msave-restore.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62686

Files:
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-features.c
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVFrameLowering.cpp
  llvm/lib/Target/RISCV/RISCVFrameLowering.h
  llvm/lib/Target/RISCV/RISCVMachineFunctionInfo.h
  llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp
  llvm/lib/Target/RISCV/RISCVRegisterInfo.h
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/saverestore.ll

Index: llvm/test/CodeGen/RISCV/saverestore.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/saverestore.ll
@@ -0,0 +1,640 @@
+; RUN: llc -mtriple=riscv32 < %s | FileCheck %s -check-prefix=RV32I
+; RUN: llc -mtriple=riscv64 < %s | FileCheck %s -check-prefix=RV64I
+; RUN: llc -mtriple=riscv32 -mattr=+save-restore < %s | FileCheck %s -check-prefix=RV32I-SR
+; RUN: llc -mtriple=riscv64 -mattr=+save-restore < %s | FileCheck %s -check-prefix=RV64I-SR
+; RUN: llc -mtriple=riscv32 -mattr=+f,+save-restore -target-abi=ilp32f < %s | FileCheck %s -check-prefix=RV32I-FP-SR
+; RUN: llc -mtriple=riscv64 -mattr=+f,+d,+save-restore -target-abi=lp64d < %s | FileCheck %s -check-prefix=RV64I-FP-SR
+
+; Check that the correct save/restore libcalls are generated.
+
+@var0 = global [18 x i32] zeroinitializer
+@var1 = global [24 x i32] zeroinitializer
+@var2 = global [30 x i32] zeroinitializer
+
+define void @callee_saved0() nounwind {
+; RV32I-LABEL: callee_saved0:
+; RV32I: addi sp, sp, -32
+; RV32I-NEXT:sw s0, 28(sp)
+; RV32I-NEXT:sw s1, 24(sp)
+; RV32I-NEXT:sw s2, 20(sp)
+; RV32I-NEXT:sw s3, 16(sp)
+; RV32I-NEXT:sw s4, 12(sp)
+; RV32I: lw s4, 12(sp)
+; RV32I-NEXT:lw s3, 16(sp)
+; RV32I-NEXT:lw s2, 20(sp)
+; RV32I-NEXT:lw s1, 24(sp)
+; RV32I-NEXT:lw s0, 28(sp)
+; RV32I-NEXT:addi sp, sp, 32
+; RV32I-NEXT:ret
+;
+; RV64I-LABEL: callee_saved0:
+; RV64I: addi sp, sp, -48
+; RV64I-NEXT:sd s0, 40(sp)
+; RV64I-NEXT:sd s1, 32(sp)
+; RV64I-NEXT:sd s2, 24(sp)
+; RV64I-NEXT:sd s3, 16(sp)
+; RV64I: ld s4, 8(sp)
+; RV64I-NEXT:ld s3, 16(sp)
+; RV64I-NEXT:ld s2, 24(sp)
+; RV64I-NEXT:ld s1, 32(sp)
+; RV64I-NEXT:ld s0, 40(sp)
+; RV64I-NEXT:addi sp, sp, 48
+; RV64I-NEXT:ret
+;
+; RV32I-SR-LABEL: callee_saved0:
+; RV32I-SR: call t0, __riscv_save_5
+; RV32I-SR: tail __riscv_restore_5
+;
+; RV64I-SR-LABEL: callee_saved0:
+; RV64I-SR: call t0, __riscv_save_5
+; RV64I-SR: tail __riscv_restore_5
+;
+; RV32I-FP-SR-LABEL: callee_saved0:
+; RV32I-FP-SR: call t0, __riscv_save_5
+; RV32I-FP-SR: tail __riscv_restore_5
+;
+; RV64I-FP-SR-LABEL: callee_saved0:
+; RV64I-FP-SR: call t0, __riscv_save_5
+; RV64I-FP-SR: tail __riscv_restore_5
+  %val = load [18 x i32], [18 x i32]* @var0
+  store volatile [18 x i32] %val, [18 x i32]* @var0
+  ret void
+}
+
+define void @callee_saved1() nounwind {
+; RV32I-LABEL: callee_saved1:
+; RV32I: addi sp, sp, -48
+; RV32I-NEXT:sw s0, 44(sp)
+; RV32I-NEXT:sw s1, 40(sp)
+; RV32I-NEXT:sw s2, 36(sp)
+; RV32I-NEXT:sw s3, 32(sp)
+; RV32I-NEXT:sw s4, 28(sp)
+; RV32I-NEXT:sw s5, 24(sp)
+; RV32I-NEXT:sw s6, 20(sp)
+; RV32I-NEXT:sw s7, 16(sp)
+; RV32I-NEXT:sw s8, 12(sp)
+; RV32I-NEXT:sw s9, 8(sp)
+; RV32I-NEXT:sw s10, 4(sp)
+; RV32I: lw s10, 4(sp)
+; RV32I-NEXT:lw s9, 8(sp)
+; RV32I-NEXT:lw s8, 12(sp)
+; RV32I-NEXT:lw s7, 16(sp)
+; RV32I-NEXT:lw s6, 20(sp)
+; RV32I-NEXT:lw s5, 24(sp)
+; RV32I-NEXT:lw s4, 28(sp)
+; RV32I-NEXT:lw s3, 32(sp)
+; RV32I-NEXT:lw s2, 36(sp)
+; RV32I-NEXT:lw s1, 40(sp)
+; RV32I-NEXT:lw s0, 44(sp)
+; RV32I-NEXT:addi sp, sp, 48
+; RV32I-NEXT:ret
+;
+; RV64I-LABEL: callee_saved1:
+; RV64I: addi sp, sp, -96
+; RV64I-NEXT:sd s0, 88(sp)
+; RV64I-NEXT:sd s1, 80(sp)
+; RV64I-NEXT:sd s2, 72(sp)
+; RV64I-NEXT:sd s3, 64(sp)
+; RV64I-NEXT:sd s4, 56(sp)
+; RV64I-NEXT:sd s5, 48(sp)
+; RV64I-NEXT:sd s6, 40(sp)
+; RV64I-NEXT:sd s7, 32(sp)
+; RV64I-NEXT:sd s8, 24(sp)
+; RV64I-NEXT:sd s9, 16(sp)
+; RV64I-NEXT:sd s10, 8(sp)
+; RV64I: ld s10, 8(sp)
+; RV64I-NEXT:ld s9, 16(sp)
+; RV64I-NEXT:ld s8, 24(sp)
+; RV64I-NEXT:ld s7, 32(sp)
+; RV64I-NEXT:ld s6, 40(sp)
+; RV64I-NEXT:ld s5, 48(sp)
+; RV64I-NEXT:ld s4, 56(sp)
+; RV64I-NEXT:ld s3, 64(sp)
+; RV64I-NEXT:ld s2, 72(sp)
+; RV64I-NEXT:ld s1, 80(sp)
+; RV64I-NEXT:ld s0, 88(sp)
+; RV64I-NEXT:addi sp, sp, 96
+; RV6

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

balazske wrote:
> aaron.ballman wrote:
> > aaron.ballman wrote:
> > > martong wrote:
> > > > aaron.ballman wrote:
> > > > > martong wrote:
> > > > > > martong wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > lebedev.ri wrote:
> > > > > > > > > martong wrote:
> > > > > > > > > > martong wrote:
> > > > > > > > > > > What is the difference between "default" and 
> > > > > > > > > > > "fundamental" alignment? Are they the same? Can they 
> > > > > > > > > > > differ in any architecture?
> > > > > > > > > > > 
> > > > > > > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > > > > > > Here there is no wording of "default alignment" only 
> > > > > > > > > > > "fundamental alignment" is mentioned. Based on this I'd 
> > > > > > > > > > > call this as `FundamentalAligment`.
> > > > > > > > > > > What is the difference between "default" and 
> > > > > > > > > > > "fundamental" alignment? Are they the same?
> > > > > > > > > > 
> > > > > > > > > > `fundamental alignment` of any type is the alignment of 
> > > > > > > > > > std::max_align_t. I.e. `alignof(std::max_align_t)`. 
> > > > > > > > > > See C++17 6.11.2.
> > > > > > > > > > 
> > > > > > > > > > On the other hand, default alignment is the value in 
> > > > > > > > > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be predefined 
> > > > > > > > > > with `fnew-alignment`
> > > > > > > > > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > > > > > > > > 
> > > > > > > > > > These values can differ: 
> > > > > > > > > > https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > > > > > > > > 
> > > > > > > > > > Thus, I think we should use the fundamental alignment here, 
> > > > > > > > > > not the default alignment. 
> > > > > > > > > > So, `getNewAlign()` does not seem right to me.
> > > > > > > > > > @aaron.ballman What do you think?
> > > > > > > > > > Thus, I think we should use the fundamental alignment here, 
> > > > > > > > > > not the default alignment.
> > > > > > > > > 
> > > > > > > > > I have the exact opposite view.
> > > > > > > > > If as per `getNewAlign()` the alignment would be okay, why 
> > > > > > > > > should we not trust it?
> > > > > > > > The comment on `getNewAlign()` is:
> > > > > > > > ```
> > > > > > > >   /// Return the largest alignment for which a suitably-sized 
> > > > > > > > allocation with
> > > > > > > >   /// '::operator new(size_t)' is guaranteed to produce a 
> > > > > > > > correctly-aligned
> > > > > > > >   /// pointer.
> > > > > > > > ```
> > > > > > > > I read that as saying any alignment larger than what is 
> > > > > > > > returned by `getNewAlign()` must call the over-aligned operator 
> > > > > > > > new variant in C++17 if available. So if the actual call target 
> > > > > > > > doesn't have an alignment specifier, it's probably getting the 
> > > > > > > > alignment wrong and would be worth diagnosing on.
> > > > > > > > I have the exact opposite view.
> > > > > > > > If as per getNewAlign() the alignment would be okay, why should 
> > > > > > > > we not trust it?
> > > > > > > 
> > > > > > > That could lead to a false positive diagnostic if 
> > > > > > > `-fnew-alignment=8` and `alignas(16)` , because 
> > > > > > > `alignof(max_align_t)` is still 16.
> > > > > > > 
> > > > > > > See the definidion of `getNewAlign()` which will return with 8 in 
> > > > > > > this case I suppose:
> > > > > > > ```
> > > > > > >   unsigned getNewAlign() const {
> > > > > > > return NewAlign ? NewAlign : std::max(LongDoubleAlign, 
> > > > > > > LongLongAlign);
> > > > > > >   }
> > > > > > > ```
> > > > > > > So if the actual call target doesn't have an alignment specifier, 
> > > > > > > it's probably getting the alignment wrong and would be worth 
> > > > > > > diagnosing on.
> > > > > > 
> > > > > > I agree, but then we are implementing a checker which is different 
> > > > > > from the description given in cert-mem57.
> > > > > > So it is not a CERT checker anymore, perhaps we should rename then.
> > > > > > There is no mention of __STDCPP_DEFAULT_NEW_ALIGNMENT__ in 
> > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > It clearly references the "fundamental alignement".
> > > > > Why do you believe that to be a false positive? That seems like 
> > > > > exactly the behavior we'd want -- if the user says that their 
> > > > > allocation function guarantees a particular max alignment by using 
> > > > > `-fnew-alignment`, we should honor that.
> > > > > Why do you believe that to be a false positive? That seems like 
> > > > > exactly the behavio

[PATCH] D67661: [RISCV] Headers: Add Bitmanip extension Clang header files and rvintrin.h

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D67661#1673918 , @s.egerton wrote:

> Sorry I misread your original comment.


(which one?)

> These functions exist so that we can guarantee that these particular 
> instructions will be emitted;

Sure, that makes sense.

> the other option was LLVM IR intrinsics and Clang builtins, this was the 
> other patch (https://reviews.llvm.org/D66479).
>  We are planning on abandoning that patch in favour of this one after the 
> discussions on the patch and the mailing list.

I sure did comment that both of these approaches (emitting inline asm, or 
having arch-specific intrinsics)
are worse than emitting plain IR (as there is no 'real' incentive to enhance 
backend pattern-matching),
but arch-specific intrinsics are certainly better than inline asm.
Sorry if that thought got convoluted.


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

https://reviews.llvm.org/D67661



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

[PATCH] D67545: [clang-tidy] Added DefaultOperatorNewCheck.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri marked an inline comment as done.
lebedev.ri added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/DefaultOperatorNewCheck.cpp:51
+  // The alignment used by default 'operator new' (in bits).
+  const unsigned DefaultAlignment = Context.getTargetInfo().getNewAlign();
+

aaron.ballman wrote:
> balazske wrote:
> > aaron.ballman wrote:
> > > aaron.ballman wrote:
> > > > martong wrote:
> > > > > aaron.ballman wrote:
> > > > > > martong wrote:
> > > > > > > martong wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > lebedev.ri wrote:
> > > > > > > > > > martong wrote:
> > > > > > > > > > > martong wrote:
> > > > > > > > > > > > What is the difference between "default" and 
> > > > > > > > > > > > "fundamental" alignment? Are they the same? Can they 
> > > > > > > > > > > > differ in any architecture?
> > > > > > > > > > > > 
> > > > > > > > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > > > > > > > Here there is no wording of "default alignment" only 
> > > > > > > > > > > > "fundamental alignment" is mentioned. Based on this I'd 
> > > > > > > > > > > > call this as `FundamentalAligment`.
> > > > > > > > > > > > What is the difference between "default" and 
> > > > > > > > > > > > "fundamental" alignment? Are they the same?
> > > > > > > > > > > 
> > > > > > > > > > > `fundamental alignment` of any type is the alignment of 
> > > > > > > > > > > std::max_align_t. I.e. `alignof(std::max_align_t)`. 
> > > > > > > > > > > See C++17 6.11.2.
> > > > > > > > > > > 
> > > > > > > > > > > On the other hand, default alignment is the value in 
> > > > > > > > > > > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` which may be 
> > > > > > > > > > > predefined with `fnew-alignment`
> > > > > > > > > > > See https://www.bfilipek.com/2019/08/newnew-align.html
> > > > > > > > > > > 
> > > > > > > > > > > These values can differ: 
> > > > > > > > > > > https://wandbox.org/permlink/yIwjiNMw9KyXEQan
> > > > > > > > > > > 
> > > > > > > > > > > Thus, I think we should use the fundamental alignment 
> > > > > > > > > > > here, not the default alignment. 
> > > > > > > > > > > So, `getNewAlign()` does not seem right to me.
> > > > > > > > > > > @aaron.ballman What do you think?
> > > > > > > > > > > Thus, I think we should use the fundamental alignment 
> > > > > > > > > > > here, not the default alignment.
> > > > > > > > > > 
> > > > > > > > > > I have the exact opposite view.
> > > > > > > > > > If as per `getNewAlign()` the alignment would be okay, why 
> > > > > > > > > > should we not trust it?
> > > > > > > > > The comment on `getNewAlign()` is:
> > > > > > > > > ```
> > > > > > > > >   /// Return the largest alignment for which a suitably-sized 
> > > > > > > > > allocation with
> > > > > > > > >   /// '::operator new(size_t)' is guaranteed to produce a 
> > > > > > > > > correctly-aligned
> > > > > > > > >   /// pointer.
> > > > > > > > > ```
> > > > > > > > > I read that as saying any alignment larger than what is 
> > > > > > > > > returned by `getNewAlign()` must call the over-aligned 
> > > > > > > > > operator new variant in C++17 if available. So if the actual 
> > > > > > > > > call target doesn't have an alignment specifier, it's 
> > > > > > > > > probably getting the alignment wrong and would be worth 
> > > > > > > > > diagnosing on.
> > > > > > > > > I have the exact opposite view.
> > > > > > > > > If as per getNewAlign() the alignment would be okay, why 
> > > > > > > > > should we not trust it?
> > > > > > > > 
> > > > > > > > That could lead to a false positive diagnostic if 
> > > > > > > > `-fnew-alignment=8` and `alignas(16)` , because 
> > > > > > > > `alignof(max_align_t)` is still 16.
> > > > > > > > 
> > > > > > > > See the definidion of `getNewAlign()` which will return with 8 
> > > > > > > > in this case I suppose:
> > > > > > > > ```
> > > > > > > >   unsigned getNewAlign() const {
> > > > > > > > return NewAlign ? NewAlign : std::max(LongDoubleAlign, 
> > > > > > > > LongLongAlign);
> > > > > > > >   }
> > > > > > > > ```
> > > > > > > > So if the actual call target doesn't have an alignment 
> > > > > > > > specifier, it's probably getting the alignment wrong and would 
> > > > > > > > be worth diagnosing on.
> > > > > > > 
> > > > > > > I agree, but then we are implementing a checker which is 
> > > > > > > different from the description given in cert-mem57.
> > > > > > > So it is not a CERT checker anymore, perhaps we should rename 
> > > > > > > then.
> > > > > > > There is no mention of __STDCPP_DEFAULT_NEW_ALIGNMENT__ in 
> > > > > > > https://wiki.sei.cmu.edu/confluence/display/cplusplus/MEM57-CPP.+Avoid+using+default+operator+new+for+over-aligned+types
> > > > > > > It clearly references the "fundamental alignement".
> > > > > > Why do you believe that to be a false positive? That seems like 
> > > > > > exactly the behavior we'd wan

[PATCH] D66795: [Mips] Use appropriate private label prefix based on Mips ABI

[Mirko Brkusanin via Phabricator via cfe-commits]

mbrkusanin updated this revision to Diff 220675.
mbrkusanin added a comment.
Herald added subscribers: lldb-commits, cfe-commits, seiya, lenary, rupprecht, 
jrtc27, hiraditya.
Herald added projects: clang, LLDB.

- MCTargetOptions is now always passed to MCAsmInfo (or rather 
createMCAsmInfo). In places where we it wasn't available before we simply pass 
empty MCTargetOptions.
- Patch is now for monorepo. Besides LLVM there are now changes to Clang and 
LLDB. I needed to use monorepo to test if everything builds correctly. If this 
is accepted I will split it into separate patches if needed.
- Also it might be best to split this into two changes. First one that adds 
MCTargetOptions to MCAsmInfo and second one that fixes prefix for Mips which is 
what I set out to solve.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66795

Files:
  clang/lib/Parse/ParseStmtAsm.cpp
  clang/tools/driver/cc1as_main.cpp
  lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp
  lldb/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
  lldb/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
  llvm/include/llvm/Support/TargetRegistry.h
  llvm/lib/CodeGen/LLVMTargetMachine.cpp
  llvm/lib/MC/MCDisassembler/Disassembler.cpp
  llvm/lib/Object/ModuleSymbolTable.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64MCTargetDesc.cpp
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUMCAsmInfo.cpp
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUMCAsmInfo.h
  llvm/lib/Target/ARC/MCTargetDesc/ARCMCTargetDesc.cpp
  llvm/lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp
  llvm/lib/Target/AVR/MCTargetDesc/AVRMCAsmInfo.cpp
  llvm/lib/Target/AVR/MCTargetDesc/AVRMCAsmInfo.h
  llvm/lib/Target/BPF/MCTargetDesc/BPFMCAsmInfo.h
  llvm/lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp
  llvm/lib/Target/Lanai/MCTargetDesc/LanaiMCAsmInfo.cpp
  llvm/lib/Target/Lanai/MCTargetDesc/LanaiMCAsmInfo.h
  llvm/lib/Target/MSP430/MCTargetDesc/MSP430MCAsmInfo.cpp
  llvm/lib/Target/MSP430/MCTargetDesc/MSP430MCAsmInfo.h
  llvm/lib/Target/Mips/MCTargetDesc/MipsMCAsmInfo.cpp
  llvm/lib/Target/Mips/MCTargetDesc/MipsMCAsmInfo.h
  llvm/lib/Target/Mips/MCTargetDesc/MipsMCTargetDesc.cpp
  llvm/lib/Target/NVPTX/MCTargetDesc/NVPTXMCAsmInfo.cpp
  llvm/lib/Target/NVPTX/MCTargetDesc/NVPTXMCAsmInfo.h
  llvm/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVMCTargetDesc.cpp
  llvm/lib/Target/Sparc/MCTargetDesc/SparcMCTargetDesc.cpp
  llvm/lib/Target/SystemZ/MCTargetDesc/SystemZMCTargetDesc.cpp
  llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCAsmInfo.cpp
  llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCAsmInfo.h
  llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.cpp
  llvm/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp
  llvm/lib/Target/XCore/MCTargetDesc/XCoreMCTargetDesc.cpp
  llvm/test/CodeGen/Mips/compactbranches/no-beqzc-bnezc.ll
  llvm/test/MC/Mips/macro-li.d.s
  llvm/test/MC/Mips/macro-li.s.s
  llvm/test/MC/Mips/private-prefix.s
  llvm/tools/dsymutil/DwarfStreamer.cpp
  llvm/tools/llvm-cfi-verify/lib/FileAnalysis.cpp
  llvm/tools/llvm-dwp/llvm-dwp.cpp
  llvm/tools/llvm-exegesis/lib/Analysis.cpp
  llvm/tools/llvm-jitlink/llvm-jitlink.cpp
  llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp
  llvm/tools/llvm-mc/Disassembler.cpp
  llvm/tools/llvm-mc/Disassembler.h
  llvm/tools/llvm-mc/llvm-mc.cpp
  llvm/tools/llvm-mca/llvm-mca.cpp
  llvm/tools/llvm-objdump/MachODump.cpp
  llvm/tools/llvm-objdump/llvm-objdump.cpp
  llvm/tools/llvm-rtdyld/llvm-rtdyld.cpp
  llvm/tools/sancov/sancov.cpp
  llvm/unittests/DebugInfo/DWARF/DwarfGenerator.cpp
  llvm/unittests/ExecutionEngine/JITLink/JITLinkTestCommon.cpp
  llvm/unittests/MC/DwarfLineTables.cpp
  llvm/unittests/MC/MCInstPrinter.cpp

Index: llvm/unittests/MC/MCInstPrinter.cpp
===
--- llvm/unittests/MC/MCInstPrinter.cpp
+++ llvm/unittests/MC/MCInstPrinter.cpp
@@ -9,6 +9,7 @@
 #include "llvm/MC/MCInstPrinter.h"
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/MC/MCInstrInfo.h"
+#include "llvm/MC/MCTargetOptions.h"
 #include "llvm/Support/TargetRegistry.h"
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Target/TargetMachine.h"
@@ -40,7 +41,8 @@
   return;
 
 MRI.reset(TheTarget->createMCRegInfo(TripleName));
-MAI.reset(TheTarget->createMCAsmInfo(*MRI, TripleName));
+MCTargetOptions MCOptions;
+MAI.reset(TheTarget->createMCAsmInfo(*MRI, TripleName, MCOptions));
 MII.reset(TheTarget->createMCInstrInfo());
 Printer.reset(TheTarget->createMCInstPrinter(
 Triple(TripleName), MAI->getAssemblerDialect(), *MAI, *MII, *MRI));
Index: llvm/unittests/MC/DwarfLineTables.cpp
===
--- llvm/unittests/MC/DwarfLineTables.cpp
+++ llvm/unittests/MC/DwarfLineTables.cpp
@@ -12,6 +12,7 @@
 #include "llvm/MC/MC

[PATCH] D66795: [Mips] Use appropriate private label prefix based on Mips ABI

[Mirko Brkusanin via Phabricator via cfe-commits]

mbrkusanin added a comment.

In D66795#1650305 , @atanasyan wrote:

> But take a look at `LLVMCreateDisasmCPUFeatures` function from 
> `Disassembler.cpp`. If we cannot retrieve `MCTargetOptions` right in this 
> function, we will have to change "LLVM-C" interface 
> `LLVMCreateDisasmCPUFeatures` function.


As far as I can tell there is currently no way to specify ABI from C interface. 
So I just made empty `MCTargetOptions`. Same with other cases where it was 
needed. Some places like `llvm-mca.cpp` had required options available so there 
we could initialize `MCTargetOptions`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66795



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

[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Peter Waller via Phabricator via cfe-commits]

peterwaller-arm updated this revision to Diff 220681.
peterwaller-arm marked 6 inline comments as done.
peterwaller-arm added a comment.

- Fixed spurious comma
- Fixed incorrect comment and changed comment wrapping.


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

https://reviews.llvm.org/D63607

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/ToolChain.h
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Driver/ToolChains/Flang.h
  clang/lib/Driver/Types.cpp
  clang/test/Driver/flang/Inputs/one.f90
  clang/test/Driver/flang/Inputs/other.c
  clang/test/Driver/flang/Inputs/two.f90
  clang/test/Driver/flang/flang.F90
  clang/test/Driver/flang/flang.f90
  clang/test/Driver/flang/multiple-inputs-mixed.f90
  clang/test/Driver/flang/multiple-inputs.f90
  clang/test/Driver/fortran.f95
  clang/test/Driver/lit.local.cfg

Index: clang/test/Driver/lit.local.cfg
===
--- clang/test/Driver/lit.local.cfg
+++ clang/test/Driver/lit.local.cfg
@@ -1,4 +1,4 @@
-config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.f95',
+config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.F90', '.f95',
'.cu', '.rs', '.cl', '.hip']
 config.substitutions = list(config.substitutions)
 config.substitutions.insert(0,
Index: clang/test/Driver/fortran.f95
===
--- clang/test/Driver/fortran.f95
+++ clang/test/Driver/fortran.f95
@@ -1,21 +1,22 @@
-// Check that the clang driver can invoke gcc to compile Fortran.
+! Check that the clang driver can invoke gcc to compile Fortran when in
+! --driver-mode=clang. This is legacy behaviour - see also --driver-mode=fortran.
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
-// CHECK-OBJECT: gcc
-// CHECK-OBJECT: "-c"
-// CHECK-OBJECT: "-x" "f95"
-// CHECK-OBJECT-NOT: cc1as
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
+! CHECK-OBJECT: gcc
+! CHECK-OBJECT: "-c"
+! CHECK-OBJECT: "-x" "f95"
+! CHECK-OBJECT-NOT: cc1as
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-ASM %s
-// CHECK-ASM: gcc
-// CHECK-ASM: "-S"
-// CHECK-ASM: "-x" "f95"
-// CHECK-ASM-NOT: cc1
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-ASM %s
+! CHECK-ASM: gcc
+! CHECK-ASM: "-S"
+! CHECK-ASM: "-x" "f95"
+! CHECK-ASM-NOT: cc1
 
-// RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
-// CHECK-WARN: gcc
-// CHECK-WARN-NOT: "-Wall"
-// CHECK-WARN: ld
-// CHECK-WARN-NOT: "-Wall"
+! RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
+! CHECK-WARN: gcc
+! CHECK-WARN-NOT: "-Wall"
+! CHECK-WARN: ld
+! CHECK-WARN-NOT: "-Wall"
Index: clang/test/Driver/flang/multiple-inputs.f90
===
--- /dev/null
+++ clang/test/Driver/flang/multiple-inputs.f90
@@ -0,0 +1,7 @@
+! Check that flang driver can handle multiple inputs at once.
+
+! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/two.f90 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/two.f90"
Index: clang/test/Driver/flang/multiple-inputs-mixed.f90
===
--- /dev/null
+++ clang/test/Driver/flang/multiple-inputs-mixed.f90
@@ -0,0 +1,7 @@
+! Check that flang can handle mixed C and fortran inputs.
+
+! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/other.c 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}clang{{[^"/]*}}" "-cc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/other.c"
Index: clang/test/Driver/flang/flang.f90
===
--- /dev/null
+++ clang/test/Driver/flang/flang.f90
@@ -0,0 +1,31 @@
+! Check that flang -fc1 is invoked when in --driver-mode=flang.
+
+! See also: flang.F90 - "an input which also requires preprocessing".
+
+! Test output types:
+! * -E
+! * -fsyntax-only
+
+! Most tests use ALL-LABEL to bracket the checks with the compiler invocation
+! and the source, which appear 

[PATCH] D67713: [OpenCL] Add image query builtin functions

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh created this revision.
svenvh added a reviewer: Anastasia.
Herald added subscribers: cfe-commits, kristina, yaxunl.
Herald added a reviewer: rengolin.
Herald added a project: clang.

Add the image query builtin functions from the OpenCL C specification.

Patch by Pierre Gondois and Sven van Haastregt.


Repository:
  rC Clang

https://reviews.llvm.org/D67713

Files:
  clang/lib/Sema/OpenCLBuiltins.td
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -71,6 +71,8 @@
   resf = read_imagef(image_read_only_image2d, i2);
   res = read_imageh(image_read_only_image2d, i2);
   res = read_imageh(image_read_only_image2d, sampler, i2);
+
+  int imgWidth = get_image_width(image_read_only_image2d);
 }
 
 #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
@@ -79,6 +81,8 @@
   int4 i4;
 
   write_imageh(image_read_write_image3d, i4, h4);
+
+  int imgDepth = get_image_depth(image_read_write_image3d);
 }
 #endif // __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 
Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -593,6 +593,31 @@
   def : Builtin<"write_imagef", [Void, ImageType, 
VectorType, Float]>;
 }
 
+// --- Table 25: Image Query Functions ---
+foreach aQual = ["RO", "WO", "RW"] in {
+  foreach imgTy = [Image1d, Image1dBuffer, Image2d, Image3d,
+   Image1dArray, Image2dArray, Image2dDepth,
+   Image2dArrayDepth] in {
+foreach name = ["get_image_width", "get_image_channel_data_type",
+"get_image_channel_order"] in {
+  def : Builtin]>;
+}
+  }
+  foreach imgTy = [Image2d, Image3d, Image2dArray, Image2dDepth,
+   Image2dArrayDepth] in {
+def : Builtin<"get_image_height", [Int, ImageType]>;
+  }
+  def : Builtin<"get_image_depth", [Int, ImageType]>;
+  foreach imgTy = [Image2d, Image2dArray, Image2dDepth,
+   Image2dArrayDepth] in {
+def : Builtin<"get_image_dim", [VectorType, ImageType]>;
+  }
+  def : Builtin<"get_image_dim", [VectorType, ImageType]>;
+  foreach imgTy = [Image1dArray, Image2dArray, Image2dArrayDepth] in {
+def : Builtin<"get_image_array_size", [Size, ImageType]>;
+  }
+}
+
 // OpenCL extension v2.0 s5.1.9: Built-in Image Read Functions
 // --- Table 8 ---
 foreach aQual = ["RO"] in {


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -71,6 +71,8 @@
   resf = read_imagef(image_read_only_image2d, i2);
   res = read_imageh(image_read_only_image2d, i2);
   res = read_imageh(image_read_only_image2d, sampler, i2);
+
+  int imgWidth = get_image_width(image_read_only_image2d);
 }
 
 #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
@@ -79,6 +81,8 @@
   int4 i4;
 
   write_imageh(image_read_write_image3d, i4, h4);
+
+  int imgDepth = get_image_depth(image_read_write_image3d);
 }
 #endif // __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 
Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -593,6 +593,31 @@
   def : Builtin<"write_imagef", [Void, ImageType, VectorType, Float]>;
 }
 
+// --- Table 25: Image Query Functions ---
+foreach aQual = ["RO", "WO", "RW"] in {
+  foreach imgTy = [Image1d, Image1dBuffer, Image2d, Image3d,
+   Image1dArray, Image2dArray, Image2dDepth,
+   Image2dArrayDepth] in {
+foreach name = ["get_image_width", "get_image_channel_data_type",
+"get_image_channel_order"] in {
+  def : Builtin]>;
+}
+  }
+  foreach imgTy = [Image2d, Image3d, Image2dArray, Image2dDepth,
+   Image2dArrayDepth] in {
+def : Builtin<"get_image_height", [Int, ImageType]>;
+  }
+  def : Builtin<"get_image_depth", [Int, ImageType]>;
+  foreach imgTy = [Image2d, Image2dArray, Image2dDepth,
+   Image2dArrayDepth] in {
+def : Builtin<"get_image_dim", [VectorType, ImageType]>;
+  }
+  def : Builtin<"get_image_dim", [VectorType, ImageType]>;
+  foreach imgTy = [Image1dArray, Image2dArray, Image2dArrayDepth] in {
+def : Builtin<"get_image_array_size", [Size, ImageType]>;
+  }
+}
+
 // OpenCL extension v2.0 s5.1.9: Built-in Image Read Functions
 // --- Table 8 ---
 foreach aQual = ["RO"] in {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67654: [clang-tidy] Fix a potential infinite loop in readability-isolate-declaration check.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov marked an inline comment as done.
ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clang-tidy/utils/LexerUtils.h:38
 template 
 SourceLocation findPreviousAnyTokenKind(SourceLocation Start,
 const SourceManager &SM,

hokein wrote:
> ilya-biryukov wrote:
> > Would `findPrevious` have the same problem on the first token of the file?
> > Can be hard to check without unit-tests, though.
> it depends on the caller. Calling this function directly would probably get 
> into infinite loop. As this function is only used in 
> `readability-isolate-declaration` check, it seems that the check adds some 
> additional guard code before calling this function, it is probably safe, I 
> assume. (I could not figure out a case that causes the problem).
Fair point, but putting an assertion or fixing the function would be good too.
But we really need unit tests to properly ensure the invariants.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67654



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

[PATCH] D67714: [OpenCL] Add -Wconversion to fdeclare-opencl-builtins test

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh created this revision.
svenvh added a reviewer: Anastasia.
Herald added subscribers: cfe-commits, kristina, yaxunl.
Herald added a reviewer: rengolin.
Herald added a project: clang.

Add the -Wconversion -Werror options to check no unexpected conversion
is done.

Patch by Pierre Gondois and Sven van Haastregt.


Repository:
  rC Clang

https://reviews.llvm.org/D67714

Files:
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -1,9 +1,9 @@
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only -cl-std=CL 
-fdeclare-opencl-builtins -DNO_HEADER
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only -cl-std=CL 
-fdeclare-opencl-builtins -finclude-default-header
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only 
-cl-std=CL1.2 -fdeclare-opencl-builtins -DNO_HEADER
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only 
-cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only 
-cl-std=CL2.0 -fdeclare-opencl-builtins -DNO_HEADER
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only 
-cl-std=CL2.0 -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror 
-fsyntax-only -cl-std=CL -fdeclare-opencl-builtins -DNO_HEADER
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror 
-fsyntax-only -cl-std=CL -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror 
-fsyntax-only -cl-std=CL1.2 -fdeclare-opencl-builtins -DNO_HEADER
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror 
-fsyntax-only -cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror 
-fsyntax-only -cl-std=CL2.0 -fdeclare-opencl-builtins -DNO_HEADER
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror 
-fsyntax-only -cl-std=CL2.0 -fdeclare-opencl-builtins -finclude-default-header
 
 #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 // expected-no-diagnostics
@@ -99,6 +99,7 @@
   out[0] = get_sub_group_size();
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
 // expected-error@-2{{implicit declaration of function 'get_sub_group_size' is 
invalid in OpenCL}}
+// expected-error@-3{{implicit conversion changes signedness: 'int' to 'uint' 
(aka 'unsigned int')}}
 #endif
 }
 


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -1,9 +1,9 @@
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only -cl-std=CL -fdeclare-opencl-builtins -DNO_HEADER
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only -cl-std=CL -fdeclare-opencl-builtins -finclude-default-header
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only -cl-std=CL1.2 -fdeclare-opencl-builtins -DNO_HEADER
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only -cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only -cl-std=CL2.0 -fdeclare-opencl-builtins -DNO_HEADER
-// RUN: %clang_cc1 %s -triple spir -verify -pedantic -fsyntax-only -cl-std=CL2.0 -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror -fsyntax-only -cl-std=CL -fdeclare-opencl-builtins -DNO_HEADER
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror -fsyntax-only -cl-std=CL -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror -fsyntax-only -cl-std=CL1.2 -fdeclare-opencl-builtins -DNO_HEADER
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror -fsyntax-only -cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror -fsyntax-only -cl-std=CL2.0 -fdeclare-opencl-builtins -DNO_HEADER
+// RUN: %clang_cc1 %s -triple spir -verify -pedantic -Wconversion -Werror -fsyntax-only -cl-std=CL2.0 -fdeclare-opencl-builtins -finclude-default-header
 
 #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 // expected-no-diagnostics
@@ -99,6 +99,7 @@
   out[0] = get_sub_group_size();
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
 // expected-error@-2{{implicit declaration of function 'get_sub_group_size' is invalid in OpenCL}}
+// expected-error@-3{{implicit conversion changes signedness: 'int' to 'uint' (aka 'unsigned int')}}
 #endif
 }
 
__

[PATCH] D62394: [ARM][CMSE] Add CMSE header & builtins

[Pablo Barrio via Phabricator via cfe-commits]

pbarrio added a comment.

Hi, CMSE upstreaming is indeed one of our priorities. So yes, we are very 
interested in your feedback. And no, CMSE upstreaming is not abandoned, just 
going a bit slow ATM :( but any help reviewing is much appreciated! :)

@chill would it make sense to start upstream other self-contained pieces of 
codegen before this patch?


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

https://reviews.llvm.org/D62394



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

[PATCH] D67508: [RISCV] support mutilib in baremetal environment

[Kuan Hsu Chen via Phabricator via cfe-commits]

khchen updated this revision to Diff 220686.
khchen marked an inline comment as done.

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

https://reviews.llvm.org/D67508

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32i/ilp32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32i/ilp32/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32iac/ilp32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32iac/ilp32/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32im/ilp32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32im/ilp32/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32imac/ilp32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32imac/ilp32/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32imafc/ilp32f/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32imafc/ilp32f/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imac/lp64/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imac/lp64/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imafdc/lp64d/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imafdc/lp64d/crtend.o
  clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/bin/ld
  clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32i/ilp32/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32iac/ilp32/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32im/ilp32/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32imac/ilp32/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32imafc/ilp32f/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv64imac/lp64/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv64imafdc/lp64d/crt0.o
  clang/test/Driver/riscv32-toolchain.c
  clang/test/Driver/riscv64-toolchain.c

Index: clang/test/Driver/riscv64-toolchain.c
===
--- clang/test/Driver/riscv64-toolchain.c
+++ clang/test/Driver/riscv64-toolchain.c
@@ -14,8 +14,8 @@
 // C-RV64-BAREMETAL-LP64: "--sysroot={{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf"
 // C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib{{/|}}crt0.o"
 // C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtbegin.o"
-// C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
 // C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
+// C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
 // C-RV64-BAREMETAL-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
 // C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtend.o"
 
@@ -29,8 +29,8 @@
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../bin{{/|}}riscv64-unknown-elf-ld"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../riscv64-unknown-elf/lib{{/|}}crt0.o"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtbegin.o"
-// C-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../riscv64-unknown-elf{{/|}}lib"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
+// C-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../riscv64-unknown-elf{{/|}}lib"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtend.o"

[PATCH] D67508: [RISCV] support mutilib in baremetal environment

[Kuan Hsu Chen via Phabricator via cfe-commits]

khchen updated this revision to Diff 220687.

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

https://reviews.llvm.org/D67508

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32i/ilp32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32i/ilp32/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32iac/ilp32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32iac/ilp32/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32im/ilp32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32im/ilp32/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32imac/ilp32/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32imac/ilp32/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32imafc/ilp32f/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv32imafc/ilp32f/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imac/lp64/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imac/lp64/crtend.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imafdc/lp64d/crtbegin.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/lib/gcc/riscv64-unknown-elf/8.2.0/rv64imafdc/lp64d/crtend.o
  clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/bin/ld
  clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32i/ilp32/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32iac/ilp32/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32im/ilp32/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32imac/ilp32/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv32imafc/ilp32f/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv64imac/lp64/crt0.o
  
clang/test/Driver/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/lib/rv64imafdc/lp64d/crt0.o
  clang/test/Driver/riscv32-toolchain.c
  clang/test/Driver/riscv64-toolchain.c

Index: clang/test/Driver/riscv64-toolchain.c
===
--- clang/test/Driver/riscv64-toolchain.c
+++ clang/test/Driver/riscv64-toolchain.c
@@ -14,8 +14,8 @@
 // C-RV64-BAREMETAL-LP64: "--sysroot={{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf"
 // C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib{{/|}}crt0.o"
 // C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtbegin.o"
-// C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
 // C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
+// C-RV64-BAREMETAL-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
 // C-RV64-BAREMETAL-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
 // C-RV64-BAREMETAL-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtend.o"
 
@@ -29,8 +29,8 @@
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../bin{{/|}}riscv64-unknown-elf-ld"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../riscv64-unknown-elf/lib{{/|}}crt0.o"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtbegin.o"
-// C-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../riscv64-unknown-elf{{/|}}lib"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1"
+// C-RV64-BAREMETAL-NOSYSROOT-LP64: "-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1/../../../../riscv64-unknown-elf{{/|}}lib"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "--start-group" "-lc" "-lgloss" "--end-group" "-lgcc"
 // C-RV64-BAREMETAL-NOSYSROOT-LP64: "{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtend.o"
 
@@ -46,8 +46,8 @@
 // CXX-RV64-BAREMETA

[PATCH] D67508: [RISCV] support mutilib in baremetal environment

[Kuan Hsu Chen via Phabricator via cfe-commits]

khchen marked 3 inline comments as done.
khchen added inline comments.



Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:1548
+{M.gccSuffix(),
+ "/../../../../riscv64-unknown-elf/lib" + M.gccSuffix()});
+  });

kito-cheng wrote:
> It could be "riscv32-unknown-elf" other than "riscv64-unknown-elf".
fixed



Comment at: clang/lib/Driver/ToolChains/RISCVToolchain.cpp:129
+  }
+
   std::string Linker = getToolChain().GetProgramPath(getShortName());

kito-cheng wrote:
> This change seems like unrelated to multi-lib, could you split this change 
> into new patch and add a test for that?
Enabling multi-lib uses 
/Inputs/multilib_riscv_elf_sdk/riscv64-unknown-elf/bin/ld so we need to specify 
the emulation format.



Comment at: clang/lib/Driver/ToolChains/RISCVToolchain.cpp:132
 
   if (D.isUsingLTO()) {
 assert(!Inputs.empty() && "Must have at least one input.");

kito-cheng wrote:
> This part will conflict when apply patch, you might generate patch with 
> https://reviews.llvm.org/D67409, could you rebase the patch with current 
> trunk?
fixed


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

https://reviews.llvm.org/D67508



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

[libunwind] r372233 - unwind: remove a could of extraneous `else` (NFC)

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Wed Sep 18 09:15:56 2019
New Revision: 372233

URL: http://llvm.org/viewvc/llvm-project?rev=372233&view=rev
Log:
unwind: remove a could of extraneous `else` (NFC)

Simplify `if return else return` by removing the unnecessary `else`.

Modified:
libunwind/trunk/src/libunwind.cpp

Modified: libunwind/trunk/src/libunwind.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/libunwind.cpp?rev=372233&r1=372232&r2=372233&view=diff
==
--- libunwind/trunk/src/libunwind.cpp (original)
+++ libunwind/trunk/src/libunwind.cpp Wed Sep 18 09:15:56 2019
@@ -171,8 +171,7 @@ _LIBUNWIND_HIDDEN int __unw_get_proc_inf
   co->getInfo(info);
   if (info->end_ip == 0)
 return UNW_ENOINFO;
-  else
-return UNW_ESUCCESS;
+  return UNW_ESUCCESS;
 }
 _LIBUNWIND_WEAK_ALIAS(__unw_get_proc_info, unw_get_proc_info)
 
@@ -194,8 +193,7 @@ _LIBUNWIND_HIDDEN int __unw_get_proc_nam
   AbstractUnwindCursor *co = (AbstractUnwindCursor *)cursor;
   if (co->getFunctionName(buf, bufLen, offset))
 return UNW_ESUCCESS;
-  else
-return UNW_EUNSPEC;
+  return UNW_EUNSPEC;
 }
 _LIBUNWIND_WEAK_ALIAS(__unw_get_proc_name, unw_get_proc_name)
 


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

r372235 - [OPENMP5.0]Allow multiple context selectors in the context selector

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Wed Sep 18 09:24:31 2019
New Revision: 372235

URL: http://llvm.org/viewvc/llvm-project?rev=372235&view=rev
Log:
[OPENMP5.0]Allow multiple context selectors in the context selector
sets.

According to OpenMP 5.0, context selector set might include several
context selectors, separated with commas. Patch fixes this problem.

Modified:
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseOpenMP.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/test/OpenMP/declare_variant_ast_print.c
cfe/trunk/test/OpenMP/declare_variant_ast_print.cpp
cfe/trunk/test/OpenMP/declare_variant_messages.c
cfe/trunk/test/OpenMP/declare_variant_messages.cpp

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=372235&r1=372234&r2=372235&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Wed Sep 18 09:24:31 2019
@@ -2834,10 +2834,15 @@ private:
   DeclGroupPtrTy ParseOMPDeclareSimdClauses(DeclGroupPtrTy Ptr,
 CachedTokens &Toks,
 SourceLocation Loc);
+  /// Parses OpenMP context selectors and calls \p Callback for each
+  /// successfully parsed context selector.
+  bool
+  parseOpenMPContextSelectors(SourceLocation Loc,
+  llvm::function_ref Callback);
+
   /// Parse clauses for '#pragma omp declare variant'.
-  DeclGroupPtrTy ParseOMPDeclareVariantClauses(DeclGroupPtrTy Ptr,
-   CachedTokens &Toks,
-   SourceLocation Loc);
+  void ParseOMPDeclareVariantClauses(DeclGroupPtrTy Ptr, CachedTokens &Toks,
+ SourceLocation Loc);
   /// Parse clauses for '#pragma omp declare target'.
   DeclGroupPtrTy ParseOMPDeclareTargetClauses();
   /// Parse '#pragma omp end declare target'.

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=372235&r1=372234&r2=372235&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Wed Sep 18 09:24:31 2019
@@ -9529,15 +9529,26 @@ public:
   ArrayRef Alignments, ArrayRef Linears,
   ArrayRef LinModifiers, ArrayRef Steps, SourceRange SR);
 
+  /// Checks '\#pragma omp declare variant' variant function and original
+  /// functions after parsing of the associated method/function.
+  /// \param DG Function declaration to which declare variant directive is
+  /// applied to.
+  /// \param VariantRef Expression that references the variant function, which
+  /// must be used instead of the original one, specified in \p DG.
+  /// \returns None, if the function/variant function are not compatible with
+  /// the pragma,pair of original function/variant ref expression otherwise.
+  Optional>
+  checkOpenMPDeclareVariantFunction(DeclGroupPtrTy DG, Expr *VariantRef,
+SourceRange SR);
+
   /// Called on well-formed '\#pragma omp declare variant' after parsing of
   /// the associated method/function.
-  /// \param DG Function declaration to which declare variant directive is
+  /// \param FD Function declaration to which declare variant directive is
   /// applied to.
   /// \param VariantRef Expression that references the variant function, which
   /// must be used instead of the original one, specified in \p DG.
-  DeclGroupPtrTy ActOnOpenMPDeclareVariantDirective(DeclGroupPtrTy DG,
-Expr *VariantRef,
-SourceRange SR);
+  void ActOnOpenMPDeclareVariantDirective(FunctionDecl *FD, Expr *VariantRef,
+  SourceRange SR);
 
   OMPClause *ActOnOpenMPSingleExprClause(OpenMPClauseKind Kind,
  Expr *Expr,

Modified: cfe/trunk/lib/Parse/ParseOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseOpenMP.cpp?rev=372235&r1=372234&r2=372235&view=diff
==
--- cfe/trunk/lib/Parse/ParseOpenMP.cpp (original)
+++ cfe/trunk/lib/Parse/ParseOpenMP.cpp Wed Sep 18 09:24:31 2019
@@ -788,65 +788,53 @@ Parser::ParseOMPDeclareSimdClauses(Parse
 
 /// Parses clauses for 'declare variant' directive.
 /// clause:
-/// 'match' '('
 ///  '=' '{'  '}'
-/// ')'
-static bool parseDeclareVariantClause(Parser &P) {
-  Token Tok = P.getCurToken();
-  // Parse 'match'.
-  if (!Tok.is(tok::identifier) ||
-  P.getPreprocessor().getSpelling(Tok).

[PATCH] D67718: [clang-format][PR41899] PointerAlignment: Left leads to useless space in lambda intializer expression

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: klimek, owenpan, krasimir, timwoj.
MyDeveloperDay added a project: clang-tools-extra.
Herald added a project: clang.

https://bugs.llvm.org/show_bug.cgi?id=41899

  auto lambda = [&a = a]() { a = 2; };

is formatted as

  auto lambda = [& a = a]() { a = 2; };

With an extra space if PointerAlignment is set to Left

> The space "& a" looks strange when there is no type in the lambda's 
> intializer expression. This can be worked around with by setting 
> "PointerAlignment: Right", but ideally "PointerAlignment: Left" would not add 
> a space in this case.


Repository:
  rC Clang

https://reviews.llvm.org/D67718

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14001,6 +14001,15 @@
   verifyFormat("STACK_OF(int*)* a;", Macros);
 }
 
+TEST_F(FormatTest, AmbersandInLamda) {
+  // Test case reported in https://bugs.llvm.org/show_bug.cgi?id=41899
+  FormatStyle AlignStyle = getLLVMStyle();
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Right;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2580,7 +2580,8 @@
 (Style.PointerAlignment != FormatStyle::PAS_Right &&
  !Line.IsMultiVariableDeclStmt) &&
 Left.Previous &&
-!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon));
+!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon,
+tok::l_square));
   if (Right.is(tok::star) && Left.is(tok::l_paren))
 return false;
   const auto SpaceRequiredForArrayInitializerLSquare =


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14001,6 +14001,15 @@
   verifyFormat("STACK_OF(int*)* a;", Macros);
 }
 
+TEST_F(FormatTest, AmbersandInLamda) {
+  // Test case reported in https://bugs.llvm.org/show_bug.cgi?id=41899
+  FormatStyle AlignStyle = getLLVMStyle();
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Right;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2580,7 +2580,8 @@
 (Style.PointerAlignment != FormatStyle::PAS_Right &&
  !Line.IsMultiVariableDeclStmt) &&
 Left.Previous &&
-!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon));
+!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon,
+tok::l_square));
   if (Right.is(tok::star) && Left.is(tok::l_paren))
 return false;
   const auto SpaceRequiredForArrayInitializerLSquare =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67719: [clang] [Basic] Enable __has_feature(leak_sanitizer)

[Michał Górny via Phabricator via cfe-commits]

mgorny created this revision.
mgorny added reviewers: krytarowski, eugenis, leonardchan, vitalybuka, phosek.

Add a 'leak_sanitizer' feature akin to existing '*_sanitizer' features
to let programmers switch code paths accounting for leak sanitizers
being enabled.


https://reviews.llvm.org/D67719

Files:
  clang/include/clang/Basic/Features.def


Index: clang/include/clang/Basic/Features.def
===
--- clang/include/clang/Basic/Features.def
+++ clang/include/clang/Basic/Features.def
@@ -39,6 +39,8 @@
 FEATURE(address_sanitizer,
 LangOpts.Sanitize.hasOneOf(SanitizerKind::Address |
SanitizerKind::KernelAddress))
+FEATURE(leak_sanitizer,
+LangOpts.Sanitize.has(SanitizerKind::Leak))
 FEATURE(hwaddress_sanitizer,
 LangOpts.Sanitize.hasOneOf(SanitizerKind::HWAddress |
SanitizerKind::KernelHWAddress))


Index: clang/include/clang/Basic/Features.def
===
--- clang/include/clang/Basic/Features.def
+++ clang/include/clang/Basic/Features.def
@@ -39,6 +39,8 @@
 FEATURE(address_sanitizer,
 LangOpts.Sanitize.hasOneOf(SanitizerKind::Address |
SanitizerKind::KernelAddress))
+FEATURE(leak_sanitizer,
+LangOpts.Sanitize.has(SanitizerKind::Leak))
 FEATURE(hwaddress_sanitizer,
 LangOpts.Sanitize.hasOneOf(SanitizerKind::HWAddress |
SanitizerKind::KernelHWAddress))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67718: [clang-format][PR41899] PointerAlignment: Left leads to useless space in lambda intializer expression

[Manuel Klimek via Phabricator via cfe-commits]

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

LG


Repository:
  rC Clang

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

https://reviews.llvm.org/D67718



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

[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Richard Barton via Phabricator via cfe-commits]

richard.barton.arm added a comment.

Thanks for the updates. I think this is now looking good and matches the RFC 
already posted.

One thought that occurs to me when reviewing this. I think we will assume that 
F18 /flang when it lands in the LLVM project will 
be an optional thing to build and will be an opt-in project at the start that 
is off by default. What happens when clang --driver-mode=flang is called and 
flang has not been built? And where would we put a test for that behaviour? If 
flang were not to be built, should --driver-mode=flang be 
unsupported/unrecognised and emit an error message?

Might not be something we need to address with this patch, but have you 
considered this?




Comment at: clang/include/clang/Driver/Driver.h:186
+  /// Other modes fall back to calling gcc which in turn calls gfortran.
+  bool IsFlangMode() const { return Mode == FlangMode; }
+

Need to update the cover letter for the patch then as it still talks about 
'fortran mode' rather than 'flang mode'.



Comment at: clang/lib/Driver/Driver.cpp:4788
+bool Driver::ShouldUseFlangCompiler(const JobAction &JA) const {
+  // Say "no" if there is not exactly one input of a type flang understands.
+  if (JA.size() != 1 ||

peterwaller-arm wrote:
> richard.barton.arm wrote:
> > This first clause surprised me. Is this a temporary measure or do we never 
> > intend to support compiling more than one fortran file at once?
> This function answers the question at the scope of a single JobAction. My 
> understanding is that the compiler (as with clang -cc1) will be invoked once 
> per input file.
> 
> This does not prevent multiple fortran files from being compiled with a 
> single driver invocation.
Righto - thanks for the explanation.



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:44
+if (JA.getType() == types::TY_Nothing) {
+  CmdArgs.push_back("-fsyntax-only");
+} else if (JA.getType() == types::TY_LLVM_IR ||

peterwaller-arm wrote:
> richard.barton.arm wrote:
> > Looks like the F18 option spelling for this is -fparse-only? Or maybe 
> > -fdebug-semantics? I know the intention is to throw away the 'throwaway 
> > driver' in F18, so perhaps you are preparing to replace this option 
> > spelling in the throwaway driver with -fsyntax-only so this would highlight 
> > that perhaps adding the code here before the F18 driver is ready to accept 
> > it is not the right approach?
> In the RFC, the intent expressed was to mimick gfortran and clang options. I 
> am making a spelling choice here that I think it should be called 
> -fsyntax-only, which matches those. I intend to make the `flang -fc1` side 
> match in the near future.
> 
> -fdebug-* could be supported through an `-Xflang ...` option to pass debug 
> flags through.
OK - happy with this approach. So -fsyntax-only and -emit-ast will be the new 
names for f18's -fdebug-semantics and -fdebug-dump-parse-tree I guess.



Comment at: clang/lib/Driver/Types.cpp:220
+
+  case TY_Fortran: case TY_PP_Fortran:
+return true;

kiranchandramohan wrote:
> Now that there is a 2018 standard, I am assuming that f18 and F18 are also 
> valid fortran extensions. Can these be added to the File types?
> 
> Also, should the TypeInfo file be extended to handle all Fortran file types? 
> ./include/clang/Driver/Types.def
> 
> Also, should we capture some information about the standards from the 
> filename extension?
Agree with those first two, but that last one is surely a new feature that 
needs adding when such a feature is enabled in the rest of F18. 

We'd need to think that through carefully too. Classic flang never supported 
such an option and GCC's `-std` option from C/C++ does not work for Fortran. 
Also, would that go in the driver or in flang -fc1?

I suggest holding fire on this until we are ready to do it properly.



Comment at: clang/test/Driver/fortran.f95:2
+! Check that the clang driver can invoke gcc to compile Fortran when in
+! --driver-mode=clang. This is legacy behaviour - see also 
--driver-mode=fortran.
 

Need to change "see also --drver-mode=fortran" to "--driver-mode=flang" here.


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

https://reviews.llvm.org/D63607



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

[PATCH] D67720: [clangd] Add semantic selection to ClangdLSPServer.

[UTKARSH SAXENA via Phabricator via cfe-commits]

usaxena95 created this revision.
usaxena95 added a reviewer: hokein.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

This adds semantic selection to the LSP Server.
Adds support for serialization of input request and the output reply.
Also adds regression tests for the feature.

Currently we do not support multi cursor.The LSP Server only accepts single 
position in the request as opposed to many position in the spec.

Spec:
https://github.com/microsoft/language-server-protocol/blob/dbaeumer/3.15/specification.md#textDocument_selectionRange


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67720

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/selection-range.test

Index: clang-tools-extra/clangd/test/selection-range.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/selection-range.test
@@ -0,0 +1,74 @@
+# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"void func() {\n int var1;\n int var2 = var1;\n}"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"textDocument/selectionRange","params":{"textDocument":{"uri":"test:///main.cpp"},"positions":[{"line":2,"character":14}]}}
+#  CHECK:  "id": 1
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": [
+# CHECK-NEXT:{
+# CHECK-NEXT:  "parent": {
+# CHECK-NEXT:"parent": {
+# CHECK-NEXT:  "parent": {
+# CHECK-NEXT:"parent": {
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 1,
+# CHECK-NEXT:  "line": 3
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 0,
+# CHECK-NEXT:  "line": 0
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 1,
+# CHECK-NEXT:"line": 3
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 12,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 17,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 1,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 16,
+# CHECK-NEXT:"line": 2
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 1,
+# CHECK-NEXT:"line": 2
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 16,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 12,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  ]
+---
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1222,6 +1222,24 @@
 };
 llvm::json::Value toJSON(const SemanticHighlightingParams &Highlighting);
 
+struct SelectionRangeParams {
+  /// The text document.
+  TextDocumentIdentifier textDocument;
+
+  /// The positions inside the text document.
+  std::vector positions;
+};
+bool fromJSON(const llvm::json::Value &, SelectionRangeParams &);
+
+struct SelectionRange {
+  // The semantic ranges for a position.
+  // Any range must contain all the previous ranges. ranges.front() must be the
+  // inner most range. ranges.back() must be the outermost range.
+  std::vector ranges;
+};
+llvm::json::Value toJSON(const SelectionRange &);
+llvm::raw_ostream &operator<<(llvm::raw_ostream &, const SelectionRange &);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/Protocol.cpp
=

r372237 - [c++20] P1331R2: Allow transient use of uninitialized objects in

[Richard Smith via cfe-commits]

Author: rsmith
Date: Wed Sep 18 10:37:44 2019
New Revision: 372237

URL: http://llvm.org/viewvc/llvm-project?rev=372237&view=rev
Log:
[c++20] P1331R2: Allow transient use of uninitialized objects in
constant evaluation.

Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/lib/AST/Interp/State.h
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p3.cpp
cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p4.cpp
cfe/trunk/test/CXX/drs/dr14xx.cpp
cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp
cfe/trunk/test/SemaCXX/constant-expression-cxx1y.cpp
cfe/trunk/test/SemaCXX/constant-expression-cxx2a.cpp
cfe/trunk/www/cxx_status.html

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=372237&r1=372236&r2=372237&view=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Wed Sep 18 10:37:44 2019
@@ -1352,7 +1352,8 @@ public:
   /// would be constexpr.
   bool defaultedDefaultConstructorIsConstexpr() const {
 return data().DefaultedDefaultConstructorIsConstexpr &&
-   (!isUnion() || hasInClassInitializer() || !hasVariantMembers());
+   (!isUnion() || hasInClassInitializer() || !hasVariantMembers() ||
+getASTContext().getLangOpts().CPlusPlus2a);
   }
 
   /// Determine whether this class has a constexpr default constructor.

Modified: cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td?rev=372237&r1=372236&r2=372237&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td Wed Sep 18 10:37:44 2019
@@ -37,7 +37,7 @@ def note_constexpr_virtual_call : Note<
 def note_constexpr_pure_virtual_call : Note<
   "pure virtual function %q0 called">;
 def note_constexpr_polymorphic_unknown_dynamic_type : Note<
-  "%select{virtual function called on|dynamic_cast applied to|"
+  "%select{|virtual function called on|dynamic_cast applied to|"
   "typeid applied to}0 object '%1' whose dynamic type is not constant">;
 def note_constexpr_dynamic_cast_to_reference_failed : Note<
   "reference dynamic_cast failed: %select{"
@@ -113,12 +113,12 @@ def note_constexpr_this : Note<
   "%select{|implicit }0use of 'this' pointer is only allowed within the "
   "evaluation of a call to a 'constexpr' member function">;
 def note_constexpr_lifetime_ended : Note<
-  "%select{read of|assignment to|increment of|decrement of|member call on|"
-  "dynamic_cast of|typeid applied to}0 "
+  "%select{read of|read of|assignment to|increment of|decrement of|"
+  "member call on|dynamic_cast of|typeid applied to}0 "
   "%select{temporary|variable}1 whose lifetime has ended">;
 def note_constexpr_access_uninit : Note<
-  "%select{read of|assignment to|increment of|decrement of|member call on|"
-  "dynamic_cast of|typeid applied to}0 "
+  "%select{read of|read of|assignment to|increment of|decrement of|"
+  "member call on|dynamic_cast of|typeid applied to}0 "
   "%select{object outside its lifetime|uninitialized object}1 "
   "is not allowed in a constant expression">;
 def note_constexpr_use_uninit_reference : Note<
@@ -128,10 +128,12 @@ def note_constexpr_modify_const_type : N
   "modification of object of const-qualified type %0 is not allowed "
   "in a constant expression">;
 def note_constexpr_access_volatile_type : Note<
-  "%select{read of|assignment to|increment of|decrement of||}0 "
+  "%select{read of|read of|assignment to|increment of|decrement of|"
+  "|}0 "
   "volatile-qualified type %1 is not allowed in a constant expression">;
 def note_constexpr_access_volatile_obj : Note<
-  "%select{read of|assignment to|increment of|decrement of||}0 "
+  "%select{read of|read of|assignment to|increment of|decrement of|"
+  "|}0 "
   "volatile %select{temporary|object %2|member %2}1 is not allowed in "
   "a constant expression">;
 def note_constexpr_volatile_here : Note<
@@ -145,31 +147,33 @@ def note_constexpr_ltor_non_constexpr :
 def note_constexpr_ltor_incomplete_type : Note<
   "read of incomplete type %0 is not allowed in a constant expression">;
 def note_constexpr_access_null : Note<
-  "%select{read of|assignment to|increment of|decrement of|member call on|"
-  "dynamic_cast of|typeid applied to}0 "
+  "%select{read of|read of|assignment to|increment of|decrement of|"
+  "member call on|dynamic_cast of|typeid applied to}0 "
   "dereferenced null pointer is not allowed in a constant expression">;
 def not

[PATCH] D67567: [clang-tidy] New check to warn when storing dispatch_once_t in non-static, non-global storage

[Dmitri Gribenko via Phabricator via cfe-commits]

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

FWIW, I like this approach better than the one in Static Analyzer because it 
warns on the variable declaration -- that's where the root of the issue is, not 
at the call to `dispatch_once()`. Like, what can you in principle do with a 
local `dispatch_once_t`? not much -- therefore produce a warning right there.




Comment at: 
clang-tools-extra/docs/clang-tidy/checks/darwin-dispatch-once-nonstatic.rst:10
+
+It is a common paradigm to have functions initialize internal static or global
+data once when the function runs, but programmers have been known to miss the

s/paradigm/pattern/


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

https://reviews.llvm.org/D67567



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

[PATCH] D67720: [clangd] Add semantic selection to ClangdLSPServer.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

A drive-by comment...




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1135
+ Params.positions.size());
+Reply(llvm::make_error("failed to decode request",
+ ErrorCode::InvalidRequest));

This should be `return Reply(...)`, right?
Especially bad if `positions` is empty as we attempt to read the first element 
right away.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67720



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

[PATCH] D67720: [clangd] Add semantic selection to ClangdLSPServer.

[UTKARSH SAXENA via Phabricator via cfe-commits]

usaxena95 updated this revision to Diff 220703.
usaxena95 added a comment.

Fixed error message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67720

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/selection-range.test

Index: clang-tools-extra/clangd/test/selection-range.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/selection-range.test
@@ -0,0 +1,74 @@
+# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"void func() {\n int var1;\n int var2 = var1;\n}"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"textDocument/selectionRange","params":{"textDocument":{"uri":"test:///main.cpp"},"positions":[{"line":2,"character":14}]}}
+#  CHECK:  "id": 1
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": [
+# CHECK-NEXT:{
+# CHECK-NEXT:  "parent": {
+# CHECK-NEXT:"parent": {
+# CHECK-NEXT:  "parent": {
+# CHECK-NEXT:"parent": {
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 1,
+# CHECK-NEXT:  "line": 3
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 0,
+# CHECK-NEXT:  "line": 0
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 1,
+# CHECK-NEXT:"line": 3
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 12,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 17,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 1,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 16,
+# CHECK-NEXT:"line": 2
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 1,
+# CHECK-NEXT:"line": 2
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 16,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 12,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  ]
+---
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1222,6 +1222,24 @@
 };
 llvm::json::Value toJSON(const SemanticHighlightingParams &Highlighting);
 
+struct SelectionRangeParams {
+  /// The text document.
+  TextDocumentIdentifier textDocument;
+
+  /// The positions inside the text document.
+  std::vector positions;
+};
+bool fromJSON(const llvm::json::Value &, SelectionRangeParams &);
+
+struct SelectionRange {
+  // The semantic ranges for a position. Any range must contain all the previous
+  // ranges. ranges.front() must be the inner most range. ranges.back() must be
+  // the outermost range.
+  std::vector ranges;
+};
+llvm::json::Value toJSON(const SelectionRange &);
+llvm::raw_ostream &operator<<(llvm::raw_ostream &, const SelectionRange &);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/Protocol.cpp
===
--- clang-tools-extra/clangd/Protocol.cpp
+++ clang-tools-extra/clangd/Protocol.cpp
@@ -15,6 +15,7 @@
 #include "URI.h"
 #include "clang/Basic/LLVM.h"
 #include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
@@ -1073,5 +1074,27 @@
   };
 }
 
+bool fromJSON(const llvm::json::Value &Params, SelectionRangeParams &P) {
+  llv

[PATCH] D67723: [CodeView] Add option to disable inline line tables.

[Amy Huang via Phabricator via cfe-commits]

akhuang created this revision.
akhuang added a reviewer: rnk.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya.
Herald added projects: clang, LLVM.

This adds a clang option to disable inline line tables. When it is used,
the inliner uses the call site as the location of the inlined function instead 
of
marking it as an inline location with the function location.

See https://bugs.llvm.org/show_bug.cgi?id=42344


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67723

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/debug-info-no-inline-line-tables.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/Transforms/Utils/InlineFunction.cpp

Index: llvm/lib/Transforms/Utils/InlineFunction.cpp
===
--- llvm/lib/Transforms/Utils/InlineFunction.cpp
+++ llvm/lib/Transforms/Utils/InlineFunction.cpp
@@ -1417,6 +1417,13 @@
   }
 
   if (DebugLoc DL = BI->getDebugLoc()) {
+// If we are not generating inline line tables, set the debug location
+// of the inlined code to be the call site.
+if (Fn->hasFnAttribute("no-inline-line-tables")) {
+  BI->setDebugLoc(InlinedAtNode);
+  continue;
+}
+
 DebugLoc IDL =
 inlineDebugLoc(DL, InlinedAtNode, BI->getContext(), IANodes);
 BI->setDebugLoc(IDL);
Index: llvm/include/llvm/IR/Attributes.td
===
--- llvm/include/llvm/IR/Attributes.td
+++ llvm/include/llvm/IR/Attributes.td
@@ -220,6 +220,7 @@
 def NoNansFPMath : StrBoolAttr<"no-nans-fp-math">;
 def UnsafeFPMath : StrBoolAttr<"unsafe-fp-math">;
 def NoJumpTables : StrBoolAttr<"no-jump-tables">;
+def NoInlineLineTables : StrBoolAttr<"no-inline-line-tables">;
 def ProfileSampleAccurate : StrBoolAttr<"profile-sample-accurate">;
 
 class CompatRule {
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -1433,6 +1433,10 @@
 ``naked``
 This attribute disables prologue / epilogue emission for the
 function. This can have very system-specific consequences.
+``no-inline-line-tables``
+When this attribute is set to true, inline line tables are not generated
+for this function if it is inlined and the location of the inlined code
+becomes the call site.
 ``no-jump-tables``
 When this attribute is set to true, the jump tables and lookup tables that
 can be generated from a switch case lowering are disabled.
Index: clang/test/CodeGen/debug-info-no-inline-line-tables.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-no-inline-line-tables.c
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -gcodeview -debug-info-kind=limited \
+// RUN:   -gno-inline-line-tables -emit-llvm -o - %s | FileCheck %s
+// Check that clang doesn't emit the location of the inlined function in the
+// debug info.
+
+int x;
+__attribute((always_inline)) void f() {
+  x += 1;
+}
+int main() {
+  f();
+  x += 2;
+  return x;
+}
+
+// CHECK-LABEL: define dso_local i32 @main()
+// CHECK: %{{.+}} = load i32, i32* @x, align 4, !dbg [[DbgLoc:![0-9]+]]
+// CHECK: [[DbgLoc]] = distinct !DILocation(
+// CHECK-SAME: line: 11,
+// CHECK-NOT:  inlinedAt:
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -800,6 +800,7 @@
   Opts.RecordCommandLine = Args.getLastArgValue(OPT_record_command_line);
   Opts.MergeAllConstants = Args.hasArg(OPT_fmerge_all_constants);
   Opts.NoCommon = Args.hasArg(OPT_fno_common);
+  Opts.NoInlineLineTables = Args.hasArg(OPT_gno_inline_line_tables);
   Opts.NoImplicitFloat = Args.hasArg(OPT_no_implicit_float);
   Opts.OptimizeSize = getOptimizationLevelSize(Args);
   Opts.SimplifyLibCalls = !(Args.hasArg(OPT_fno_builtin) ||
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3374,6 +3374,12 @@
  options::OPT_gno_codeview_ghash, false)) {
   CmdArgs.push_back("-gcodeview-ghash");
 }
+
+// Omit inline line tables if requested.
+if (!Args.hasFlag(options::OPT_ginline_line_tables,
+  options::OPT_gno_inline_line_tables, false)) {
+  CmdArgs.push_back("-gno-inline-line-tables");
+}
   }
 
   // Adjust the debug info kind for the given toolchain.
Index: clang/lib/CodeGen/CodeGenFunction.cpp

[PATCH] D66795: [Mips] Use appropriate private label prefix based on Mips ABI

[Alexander Richardson via Phabricator via cfe-commits]

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

Looks good to me but I guess someone else should give the final approval.




Comment at: llvm/lib/Target/Mips/MCTargetDesc/MipsMCAsmInfo.cpp:25
 
   if (TheTriple.isMIPS64() && TheTriple.getEnvironment() != Triple::GNUABIN32)
 CodePointerSize = CalleeSaveStackSlotSize = 8;

Unrelated to this diff, but I guess this Triple environment check should be 
moved down and use `ABI.isN32()`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66795



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

[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

> One thought that occurs to me when reviewing this. I think we will assume 
> that F18 /flang when it lands in the LLVM 
> project will be an optional thing to build and will be an opt-in project at 
> the start that is off by default. What happens when clang --driver-mode=flang 
> is called and flang has not been built? And where would we put a test for 
> that behaviour? If flang were not to be built, should --driver-mode=flang be 
> unsupported/unrecognised and emit an error message?

The Clang tests should not actually run flang regardless - they should just 
test the command line that should be run. An error might be emitted if "flang" 
isn't found in the relevant search paths, however, that makes sense to me 
(although we might override this for the purpose of the tests?).


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

https://reviews.llvm.org/D63607



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

[PATCH] D67031: [Clang][Bundler] Error reporting improvements

[Sergey Dmitriev via Phabricator via cfe-commits]

sdmitriev added a comment.

Ping.


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

https://reviews.llvm.org/D67031



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

[PATCH] D67720: [clangd] Add semantic selection to ClangdLSPServer.

[UTKARSH SAXENA via Phabricator via cfe-commits]

usaxena95 updated this revision to Diff 220710.
usaxena95 marked 2 inline comments as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67720

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/selection-range.test

Index: clang-tools-extra/clangd/test/selection-range.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/selection-range.test
@@ -0,0 +1,74 @@
+# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"void func() {\n int var1;\n int var2 = var1;\n}"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"textDocument/selectionRange","params":{"textDocument":{"uri":"test:///main.cpp"},"positions":[{"line":2,"character":14}]}}
+#  CHECK:  "id": 1
+# CHECK-NEXT:  "jsonrpc": "2.0",
+# CHECK-NEXT:  "result": [
+# CHECK-NEXT:{
+# CHECK-NEXT:  "parent": {
+# CHECK-NEXT:"parent": {
+# CHECK-NEXT:  "parent": {
+# CHECK-NEXT:"parent": {
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 1,
+# CHECK-NEXT:  "line": 3
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 0,
+# CHECK-NEXT:  "line": 0
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 1,
+# CHECK-NEXT:"line": 3
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 12,
+# CHECK-NEXT:"line": 0
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 17,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 1,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:},
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": 16,
+# CHECK-NEXT:"line": 2
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": 1,
+# CHECK-NEXT:"line": 2
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  },
+# CHECK-NEXT:  "range": {
+# CHECK-NEXT:"end": {
+# CHECK-NEXT:  "character": 16,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:},
+# CHECK-NEXT:"start": {
+# CHECK-NEXT:  "character": 12,
+# CHECK-NEXT:  "line": 2
+# CHECK-NEXT:}
+# CHECK-NEXT:  }
+# CHECK-NEXT:}
+# CHECK-NEXT:  ]
+---
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1222,6 +1222,24 @@
 };
 llvm::json::Value toJSON(const SemanticHighlightingParams &Highlighting);
 
+struct SelectionRangeParams {
+  /// The text document.
+  TextDocumentIdentifier textDocument;
+
+  /// The positions inside the text document.
+  std::vector positions;
+};
+bool fromJSON(const llvm::json::Value &, SelectionRangeParams &);
+
+struct SelectionRange {
+  // The semantic ranges for a position. Any range must contain all the previous
+  // ranges. ranges.front() must be the inner most range. ranges.back() must be
+  // the outermost range.
+  std::vector ranges;
+};
+llvm::json::Value toJSON(const SelectionRange &);
+llvm::raw_ostream &operator<<(llvm::raw_ostream &, const SelectionRange &);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/Protocol.cpp
===
--- clang-tools-extra/clangd/Protocol.cpp
+++ clang-tools-extra/clangd/Protocol.cpp
@@ -15,6 +15,7 @@
 #include "URI.h"
 #include "clang/Basic/LLVM.h"
 #include "llvm/ADT/Hashing.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/ErrorHandling.h"
@@ -1073,5 +1074,27 @@
   };
 }
 
+bool fromJSON(const llvm::json::Value

[PATCH] D66856: [Sema] Suppress -Wformat diagnostics for bool types when printed using %hhd

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington added a comment.

Ping!


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

https://reviews.llvm.org/D66856



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

[PATCH] D67720: [clangd] Add semantic selection to ClangdLSPServer.

[UTKARSH SAXENA via Phabricator via cfe-commits]

usaxena95 added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1135
+ Params.positions.size());
+Reply(llvm::make_error("failed to decode request",
+ ErrorCode::InvalidRequest));

ilya-biryukov wrote:
> This should be `return Reply(...)`, right?
> Especially bad if `positions` is empty as we attempt to read the first 
> element right away.
Aah. Yeah. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67720



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

[PATCH] D67723: [CodeView] Add option to disable inline line tables.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

+ other debug info people




Comment at: llvm/docs/LangRef.rst:1436
 function. This can have very system-specific consequences.
+``no-inline-line-tables``
+When this attribute is set to true, inline line tables are not generated

This is a string attribute, so it should have quotes around it.



Comment at: llvm/lib/Transforms/Utils/InlineFunction.cpp:1422
+// of the inlined code to be the call site.
+if (Fn->hasFnAttribute("no-inline-line-tables")) {
+  BI->setDebugLoc(InlinedAtNode);

Let's check `hasFnAttribute` out of the loop so we aren't doing string hash 
lookups in a loop.



Comment at: llvm/lib/Transforms/Utils/InlineFunction.cpp:1433-1446
   if (CalleeHasDebugInfo)
 continue;
 
   // If the inlined instruction has no line number, make it look as if it
   // originates from the call location. This is important for
   // ((__always_inline__, __nodebug__)) functions which must use caller
   // location for all instructions in their function body.

Let's actually try to reuse this `!CalleeHasDebugInfo` code path when this 
function attribute is present. They should do the same thing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67723



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

[PATCH] D66856: [Sema] Suppress -Wformat diagnostics for bool types when printed using %hhd

[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, thank you for this!


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

https://reviews.llvm.org/D66856



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

r372246 - [clang-format][PR41964] Fix crash with SIGFPE when TabWidth is set to 0 and line starts with tab

[Paul Hoad via cfe-commits]

Author: paulhoad
Date: Wed Sep 18 11:57:09 2019
New Revision: 372246

URL: http://llvm.org/viewvc/llvm-project?rev=372246&view=rev
Log:
[clang-format][PR41964] Fix crash with SIGFPE when TabWidth is set to 0 and 
line starts with tab

Summary:
clang-format 8.0 crashes with SIGFPE (floating point exception) when formatting 
following file:
app.cpp:
void a() {
//line starts with '\t'
}

$ clang-format -style='{TabWidth: 0}' app.cpp

Reviewers: owenpan, klimek, russellmcc, timwoj

Reviewed By: klimek

Subscribers: cfe-commits

Tags: #clang-tools-extra, #clang

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

Modified:
cfe/trunk/lib/Format/Encoding.h
cfe/trunk/lib/Format/FormatTokenLexer.cpp
cfe/trunk/lib/Format/WhitespaceManager.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/Encoding.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Encoding.h?rev=372246&r1=372245&r2=372246&view=diff
==
--- cfe/trunk/lib/Format/Encoding.h (original)
+++ cfe/trunk/lib/Format/Encoding.h Wed Sep 18 11:57:09 2019
@@ -67,7 +67,8 @@ inline unsigned columnWidthWithTabs(Stri
 if (TabPos == StringRef::npos)
   return TotalWidth + columnWidth(Tail, Encoding);
 TotalWidth += columnWidth(Tail.substr(0, TabPos), Encoding);
-TotalWidth += TabWidth - (TotalWidth + StartColumn) % TabWidth;
+if (TabWidth)
+  TotalWidth += TabWidth - (TotalWidth + StartColumn) % TabWidth;
 Tail = Tail.substr(TabPos + 1);
   }
 }

Modified: cfe/trunk/lib/Format/FormatTokenLexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/FormatTokenLexer.cpp?rev=372246&r1=372245&r2=372246&view=diff
==
--- cfe/trunk/lib/Format/FormatTokenLexer.cpp (original)
+++ cfe/trunk/lib/Format/FormatTokenLexer.cpp Wed Sep 18 11:57:09 2019
@@ -657,7 +657,8 @@ FormatToken *FormatTokenLexer::getNextTo
 ++Column;
 break;
   case '\t':
-Column += Style.TabWidth - Column % Style.TabWidth;
+Column +=
+Style.TabWidth - (Style.TabWidth ? Column % Style.TabWidth : 0);
 break;
   case '\\':
 if (i + 1 == e || (Text[i + 1] != '\r' && Text[i + 1] != '\n'))

Modified: cfe/trunk/lib/Format/WhitespaceManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/WhitespaceManager.cpp?rev=372246&r1=372245&r2=372246&view=diff
==
--- cfe/trunk/lib/Format/WhitespaceManager.cpp (original)
+++ cfe/trunk/lib/Format/WhitespaceManager.cpp Wed Sep 18 11:57:09 2019
@@ -815,19 +815,24 @@ void WhitespaceManager::appendIndentText
 Text.append(Spaces, ' ');
 break;
   case FormatStyle::UT_Always: {
-unsigned FirstTabWidth =
-Style.TabWidth - WhitespaceStartColumn % Style.TabWidth;
-// Insert only spaces when we want to end up before the next tab.
-if (Spaces < FirstTabWidth || Spaces == 1) {
+if (Style.TabWidth) {
+  unsigned FirstTabWidth =
+  Style.TabWidth - WhitespaceStartColumn % Style.TabWidth;
+
+  // Insert only spaces when we want to end up before the next tab.
+  if (Spaces < FirstTabWidth || Spaces == 1) {
+Text.append(Spaces, ' ');
+break;
+  }
+  // Align to the next tab.
+  Spaces -= FirstTabWidth;
+  Text.append("\t");
+
+  Text.append(Spaces / Style.TabWidth, '\t');
+  Text.append(Spaces % Style.TabWidth, ' ');
+} else if (Spaces == 1) {
   Text.append(Spaces, ' ');
-  break;
 }
-// Align to the next tab.
-Spaces -= FirstTabWidth;
-Text.append("\t");
-
-Text.append(Spaces / Style.TabWidth, '\t');
-Text.append(Spaces % Style.TabWidth, ' ');
 break;
   }
   case FormatStyle::UT_ForIndentation:
@@ -837,14 +842,16 @@ void WhitespaceManager::appendIndentText
   // the first one.
   if (Indentation > Spaces)
 Indentation = Spaces;
-  unsigned Tabs = Indentation / Style.TabWidth;
-  Text.append(Tabs, '\t');
-  Spaces -= Tabs * Style.TabWidth;
+  if (Style.TabWidth) {
+unsigned Tabs = Indentation / Style.TabWidth;
+Text.append(Tabs, '\t');
+Spaces -= Tabs * Style.TabWidth;
+  }
 }
 Text.append(Spaces, ' ');
 break;
   case FormatStyle::UT_ForContinuationAndIndentation:
-if (WhitespaceStartColumn == 0) {
+if (WhitespaceStartColumn == 0 && Style.TabWidth) {
   unsigned Tabs = Spaces / Style.TabWidth;
   Text.append(Tabs, '\t');
   Spaces -= Tabs * Style.TabWidth;

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=372246&r1=372245&r2=372246&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (origi

[PATCH] D67670: [clang-format][PR41964] Fix crash with SIGFPE when TabWidth is set to 0 and line starts with tab

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372246: [clang-format][PR41964] Fix crash with SIGFPE when 
TabWidth is set to 0 and… (authored by paulhoad, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67670?vs=220571&id=220718#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67670

Files:
  cfe/trunk/lib/Format/Encoding.h
  cfe/trunk/lib/Format/FormatTokenLexer.cpp
  cfe/trunk/lib/Format/WhitespaceManager.cpp
  cfe/trunk/unittests/Format/FormatTest.cpp

Index: cfe/trunk/lib/Format/Encoding.h
===
--- cfe/trunk/lib/Format/Encoding.h
+++ cfe/trunk/lib/Format/Encoding.h
@@ -67,7 +67,8 @@
 if (TabPos == StringRef::npos)
   return TotalWidth + columnWidth(Tail, Encoding);
 TotalWidth += columnWidth(Tail.substr(0, TabPos), Encoding);
-TotalWidth += TabWidth - (TotalWidth + StartColumn) % TabWidth;
+if (TabWidth)
+  TotalWidth += TabWidth - (TotalWidth + StartColumn) % TabWidth;
 Tail = Tail.substr(TabPos + 1);
   }
 }
Index: cfe/trunk/lib/Format/FormatTokenLexer.cpp
===
--- cfe/trunk/lib/Format/FormatTokenLexer.cpp
+++ cfe/trunk/lib/Format/FormatTokenLexer.cpp
@@ -657,7 +657,8 @@
 ++Column;
 break;
   case '\t':
-Column += Style.TabWidth - Column % Style.TabWidth;
+Column +=
+Style.TabWidth - (Style.TabWidth ? Column % Style.TabWidth : 0);
 break;
   case '\\':
 if (i + 1 == e || (Text[i + 1] != '\r' && Text[i + 1] != '\n'))
Index: cfe/trunk/lib/Format/WhitespaceManager.cpp
===
--- cfe/trunk/lib/Format/WhitespaceManager.cpp
+++ cfe/trunk/lib/Format/WhitespaceManager.cpp
@@ -815,19 +815,24 @@
 Text.append(Spaces, ' ');
 break;
   case FormatStyle::UT_Always: {
-unsigned FirstTabWidth =
-Style.TabWidth - WhitespaceStartColumn % Style.TabWidth;
-// Insert only spaces when we want to end up before the next tab.
-if (Spaces < FirstTabWidth || Spaces == 1) {
+if (Style.TabWidth) {
+  unsigned FirstTabWidth =
+  Style.TabWidth - WhitespaceStartColumn % Style.TabWidth;
+
+  // Insert only spaces when we want to end up before the next tab.
+  if (Spaces < FirstTabWidth || Spaces == 1) {
+Text.append(Spaces, ' ');
+break;
+  }
+  // Align to the next tab.
+  Spaces -= FirstTabWidth;
+  Text.append("\t");
+
+  Text.append(Spaces / Style.TabWidth, '\t');
+  Text.append(Spaces % Style.TabWidth, ' ');
+} else if (Spaces == 1) {
   Text.append(Spaces, ' ');
-  break;
 }
-// Align to the next tab.
-Spaces -= FirstTabWidth;
-Text.append("\t");
-
-Text.append(Spaces / Style.TabWidth, '\t');
-Text.append(Spaces % Style.TabWidth, ' ');
 break;
   }
   case FormatStyle::UT_ForIndentation:
@@ -837,14 +842,16 @@
   // the first one.
   if (Indentation > Spaces)
 Indentation = Spaces;
-  unsigned Tabs = Indentation / Style.TabWidth;
-  Text.append(Tabs, '\t');
-  Spaces -= Tabs * Style.TabWidth;
+  if (Style.TabWidth) {
+unsigned Tabs = Indentation / Style.TabWidth;
+Text.append(Tabs, '\t');
+Spaces -= Tabs * Style.TabWidth;
+  }
 }
 Text.append(Spaces, ' ');
 break;
   case FormatStyle::UT_ForContinuationAndIndentation:
-if (WhitespaceStartColumn == 0) {
+if (WhitespaceStartColumn == 0 && Style.TabWidth) {
   unsigned Tabs = Spaces / Style.TabWidth;
   Text.append(Tabs, '\t');
   Spaces -= Tabs * Style.TabWidth;
Index: cfe/trunk/unittests/Format/FormatTest.cpp
===
--- cfe/trunk/unittests/Format/FormatTest.cpp
+++ cfe/trunk/unittests/Format/FormatTest.cpp
@@ -9877,6 +9877,79 @@
Tab);
 }
 
+TEST_F(FormatTest, ZeroTabWidth) {
+  FormatStyle Tab = getLLVMStyleWithColumns(42);
+  Tab.IndentWidth = 8;
+  Tab.UseTab = FormatStyle::UT_Never;
+  Tab.TabWidth = 0;
+  EXPECT_EQ("void a(){\n"
+"// line starts with '\t'\n"
+"};",
+format("void a(){\n"
+   "\t// line starts with '\t'\n"
+   "};",
+   Tab));
+
+  EXPECT_EQ("void a(){\n"
+"// line starts with '\t'\n"
+"};",
+format("void a(){\n"
+   "\t\t// line starts with '\t'\n"
+   "};",
+   Tab));
+
+  Tab.UseTab = FormatStyle::UT_ForIndentation;
+  EXPECT_EQ("void a(){\n"
+"// line starts with '\t'\n"
+"};",
+format("void a(){\n"
+   "\t// line starts with '\t'\n"
+ 

r372247 - [Sema] Suppress -Wformat diagnostics for bool types when printed using %hhd

[Erik Pilkington via cfe-commits]

Author: epilk
Date: Wed Sep 18 12:05:14 2019
New Revision: 372247

URL: http://llvm.org/viewvc/llvm-project?rev=372247&view=rev
Log:
[Sema] Suppress -Wformat diagnostics for bool types when printed using %hhd

Also, add a diagnostic under -Wformat for printing a boolean value as a
character.

rdar://54579473

Differential revision: https://reviews.llvm.org/D66856

Added:
cfe/trunk/test/Sema/format-bool.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/AST/FormatString.cpp
cfe/trunk/lib/Sema/SemaChecking.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=372247&r1=372246&r2=372247&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Sep 18 12:05:14 
2019
@@ -8145,6 +8145,9 @@ def warn_printf_invalid_objc_flag: Warni
 def warn_scanf_scanlist_incomplete : Warning<
   "no closing ']' for '%%[' in scanf format string">,
   InGroup;
+def warn_format_bool_as_character : Warning<
+  "using '%0' format specifier, but argument has boolean value">,
+  InGroup;
 def note_format_string_defined : Note<"format string is defined here">;
 def note_format_fix_specifier : Note<"did you mean to use '%0'?">;
 def note_printf_c_str: Note<"did you mean to call the %0 method?">;

Modified: cfe/trunk/lib/AST/FormatString.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/FormatString.cpp?rev=372247&r1=372246&r2=372247&view=diff
==
--- cfe/trunk/lib/AST/FormatString.cpp (original)
+++ cfe/trunk/lib/AST/FormatString.cpp Wed Sep 18 12:05:14 2019
@@ -359,6 +359,7 @@ ArgType::matchesType(ASTContext &C, Qual
   case BuiltinType::SChar:
   case BuiltinType::UChar:
   case BuiltinType::Char_U:
+  case BuiltinType::Bool:
 return Match;
 }
   return NoMatch;
@@ -386,6 +387,7 @@ ArgType::matchesType(ASTContext &C, Qual
   case BuiltinType::SChar:
   case BuiltinType::Char_U:
   case BuiltinType::UChar:
+  case BuiltinType::Bool:
 if (T == C.UnsignedShortTy || T == C.ShortTy)
   return NoMatchPedantic;
 return T == C.UnsignedCharTy || T == C.SignedCharTy ? Match

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=372247&r1=372246&r2=372247&view=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Wed Sep 18 12:05:14 2019
@@ -8109,6 +8109,22 @@ CheckPrintfHandler::checkFormatExpr(cons
 ExprTy = TET->getUnderlyingExpr()->getType();
   }
 
+  // Diagnose attempts to print a boolean value as a character. Unlike other
+  // -Wformat diagnostics, this is fine from a type perspective, but it still
+  // doesn't make sense.
+  if (FS.getConversionSpecifier().getKind() == ConversionSpecifier::cArg &&
+  E->isKnownToHaveBooleanValue()) {
+const CharSourceRange &CSR =
+getSpecifierRange(StartSpecifier, SpecifierLen);
+SmallString<4> FSString;
+llvm::raw_svector_ostream os(FSString);
+FS.toString(os);
+EmitFormatDiagnostic(S.PDiag(diag::warn_format_bool_as_character)
+ << FSString,
+ E->getExprLoc(), false, CSR);
+return true;
+  }
+
   const analyze_printf::ArgType::MatchKind Match =
   AT.matchesType(S.Context, ExprTy);
   bool Pedantic = Match == analyze_printf::ArgType::NoMatchPedantic;

Added: cfe/trunk/test/Sema/format-bool.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/format-bool.c?rev=372247&view=auto
==
--- cfe/trunk/test/Sema/format-bool.c (added)
+++ cfe/trunk/test/Sema/format-bool.c Wed Sep 18 12:05:14 2019
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -xc %s -verify -DBOOL=_Bool
+// RUN: %clang_cc1 -xc++ %s -verify -DBOOL=bool
+// RUN: %clang_cc1 -xobjective-c %s -verify -DBOOL=_Bool
+// RUN: %clang_cc1 -xc %s -verify -DBOOL=_Bool -Wformat-pedantic -DPEDANTIC
+// RUN: %clang_cc1 -xc++ %s -verify -DBOOL=bool -Wformat-pedantic -DPEDANTIC
+
+__attribute__((format(__printf__, 1, 2)))
+int p(const char *fmt, ...);
+
+BOOL b;
+
+#ifdef __OBJC__
+@interface NSString
++(NSString *)stringWithFormat:(NSString *)fmt, ...
+__attribute__((format(__NSString__, 1, 2)));
+@end
+
+#define YES __objc_yes
+#define NO __objc_no
+#endif
+
+int main() {
+  p("%d", b);
+  p("%hd", b);
+#ifdef PEDANTIC
+  // expected-warning@-2 {{format specifies type 'short' but the argument has 
type}}
+#endif
+  p("%hhd", b);
+  p("%u", b);
+  p("%hu", b);
+#ifdef PEDANTIC

[PATCH] D63508: make -frewrite-includes also rewrite conditions in #if/#elif

[Luboš Luňák via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372248: make -frewrite-includes also rewrite conditions in 
#if/#elif (authored by llunak, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63508?vs=220378&id=220722#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63508

Files:
  cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
  cfe/trunk/test/Frontend/rewrite-includes-conditions.c
  cfe/trunk/test/Frontend/rewrite-includes.c
  cfe/trunk/test/Modules/preprocess-module.cpp

Index: cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
===
--- cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
+++ cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
@@ -49,6 +49,8 @@
   std::map ModuleIncludes;
   /// Tracks where inclusions that enter modules (in a module build) are found.
   std::map ModuleEntryIncludes;
+  /// Tracks where #if and #elif directives get evaluated and whether to true.
+  std::map IfConditions;
   /// Used transitively for building up the FileIncludes mapping over the
   /// various \c PPCallbacks callbacks.
   SourceLocation LastInclusionLocation;
@@ -78,6 +80,10 @@
   StringRef SearchPath, StringRef RelativePath,
   const Module *Imported,
   SrcMgr::CharacteristicKind FileType) override;
+  void If(SourceLocation Loc, SourceRange ConditionRange,
+  ConditionValueKind ConditionValue) override;
+  void Elif(SourceLocation Loc, SourceRange ConditionRange,
+ConditionValueKind ConditionValue, SourceLocation IfLoc) override;
   void WriteLineInfo(StringRef Filename, int Line,
  SrcMgr::CharacteristicKind FileType,
  StringRef Extra = StringRef());
@@ -89,12 +95,10 @@
   void CommentOutDirective(Lexer &DirectivesLex, const Token &StartToken,
const MemoryBuffer &FromFile, StringRef EOL,
unsigned &NextToWrite, int &Lines);
-  bool HandleHasInclude(FileID FileId, Lexer &RawLex,
-const DirectoryLookup *Lookup, Token &Tok,
-bool &FileExists);
   const IncludedFile *FindIncludeAtLocation(SourceLocation Loc) const;
   const Module *FindModuleAtLocation(SourceLocation Loc) const;
   const Module *FindEnteredModule(SourceLocation Loc) const;
+  bool IsIfAtLocationTrue(SourceLocation Loc) const;
   StringRef NextIdentifierName(Lexer &RawLex, Token &RawToken);
 };
 
@@ -203,6 +207,23 @@
 LastInclusionLocation = HashLoc;
 }
 
+void InclusionRewriter::If(SourceLocation Loc, SourceRange ConditionRange,
+   ConditionValueKind ConditionValue) {
+  auto P = IfConditions.insert(
+  std::make_pair(Loc.getRawEncoding(), ConditionValue == CVK_True));
+  (void)P;
+  assert(P.second && "Unexpected revisitation of the same if directive");
+}
+
+void InclusionRewriter::Elif(SourceLocation Loc, SourceRange ConditionRange,
+ ConditionValueKind ConditionValue,
+ SourceLocation IfLoc) {
+  auto P = IfConditions.insert(
+  std::make_pair(Loc.getRawEncoding(), ConditionValue == CVK_True));
+  (void)P;
+  assert(P.second && "Unexpected revisitation of the same elif directive");
+}
+
 /// Simple lookup for a SourceLocation (specifically one denoting the hash in
 /// an inclusion directive) in the map of inclusion information, FileChanges.
 const InclusionRewriter::IncludedFile *
@@ -233,6 +254,13 @@
   return nullptr;
 }
 
+bool InclusionRewriter::IsIfAtLocationTrue(SourceLocation Loc) const {
+  const auto I = IfConditions.find(Loc.getRawEncoding());
+  if (I != IfConditions.end())
+return I->second;
+  return false;
+}
+
 /// Detect the likely line ending style of \p FromFile by examining the first
 /// newline found within it.
 static StringRef DetectEOL(const MemoryBuffer &FromFile) {
@@ -346,80 +374,6 @@
   return StringRef();
 }
 
-// Expand __has_include and __has_include_next if possible. If there's no
-// definitive answer return false.
-bool InclusionRewriter::HandleHasInclude(
-FileID FileId, Lexer &RawLex, const DirectoryLookup *Lookup, Token &Tok,
-bool &FileExists) {
-  // Lex the opening paren.
-  RawLex.LexFromRawLexer(Tok);
-  if (Tok.isNot(tok::l_paren))
-return false;
-
-  RawLex.LexFromRawLexer(Tok);
-
-  SmallString<128> FilenameBuffer;
-  StringRef Filename;
-  // Since the raw lexer doesn't give us angle_literals we have to parse them
-  // ourselves.
-  // FIXME: What to do if the file name is a macro?
-  if (Tok.is(tok::less)) {
-RawLex.LexFromRawLexer(Tok);
-
-FilenameBuffer += '<';
-do {
-  if (Tok.is(tok::eod)) // Sanity check.
-return false;
-
-  if (Tok.is(tok::raw

[PATCH] D66856: [Sema] Suppress -Wformat diagnostics for bool types when printed using %hhd

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372247: [Sema] Suppress -Wformat diagnostics for bool types 
when printed using %hhd (authored by epilk, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66856?vs=219815&id=220721#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66856

Files:
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/lib/AST/FormatString.cpp
  cfe/trunk/lib/Sema/SemaChecking.cpp
  cfe/trunk/test/Sema/format-bool.c

Index: cfe/trunk/test/Sema/format-bool.c
===
--- cfe/trunk/test/Sema/format-bool.c
+++ cfe/trunk/test/Sema/format-bool.c
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -xc %s -verify -DBOOL=_Bool
+// RUN: %clang_cc1 -xc++ %s -verify -DBOOL=bool
+// RUN: %clang_cc1 -xobjective-c %s -verify -DBOOL=_Bool
+// RUN: %clang_cc1 -xc %s -verify -DBOOL=_Bool -Wformat-pedantic -DPEDANTIC
+// RUN: %clang_cc1 -xc++ %s -verify -DBOOL=bool -Wformat-pedantic -DPEDANTIC
+
+__attribute__((format(__printf__, 1, 2)))
+int p(const char *fmt, ...);
+
+BOOL b;
+
+#ifdef __OBJC__
+@interface NSString
++(NSString *)stringWithFormat:(NSString *)fmt, ...
+__attribute__((format(__NSString__, 1, 2)));
+@end
+
+#define YES __objc_yes
+#define NO __objc_no
+#endif
+
+int main() {
+  p("%d", b);
+  p("%hd", b);
+#ifdef PEDANTIC
+  // expected-warning@-2 {{format specifies type 'short' but the argument has type}}
+#endif
+  p("%hhd", b);
+  p("%u", b);
+  p("%hu", b);
+#ifdef PEDANTIC
+  // expected-warning@-2 {{format specifies type 'unsigned short' but the argument has type}}
+#endif
+  p("%hhu", b);
+  p("%c", b); // expected-warning {{using '%c' format specifier, but argument has boolean value}}
+  p("%lc", b); // expected-warning {{using '%lc' format specifier, but argument has boolean value}}
+  p("%c", 1 == 1); // expected-warning {{using '%c' format specifier, but argument has boolean value}}
+  p("%f", b); // expected-warning{{format specifies type 'double' but the argument has type}}
+  p("%ld", b); // expected-warning{{format specifies type 'long' but the argument has type}}
+  p("%lld", b); // expected-warning{{format specifies type 'long long' but the argument has type}}
+
+#ifdef __OBJC__
+  [NSString stringWithFormat: @"%c", 0]; // probably fine?
+  [NSString stringWithFormat: @"%c", NO]; // expected-warning {{using '%c' format specifier, but argument has boolean value}}
+#endif
+}
Index: cfe/trunk/lib/AST/FormatString.cpp
===
--- cfe/trunk/lib/AST/FormatString.cpp
+++ cfe/trunk/lib/AST/FormatString.cpp
@@ -359,6 +359,7 @@
   case BuiltinType::SChar:
   case BuiltinType::UChar:
   case BuiltinType::Char_U:
+  case BuiltinType::Bool:
 return Match;
 }
   return NoMatch;
@@ -386,6 +387,7 @@
   case BuiltinType::SChar:
   case BuiltinType::Char_U:
   case BuiltinType::UChar:
+  case BuiltinType::Bool:
 if (T == C.UnsignedShortTy || T == C.ShortTy)
   return NoMatchPedantic;
 return T == C.UnsignedCharTy || T == C.SignedCharTy ? Match
Index: cfe/trunk/lib/Sema/SemaChecking.cpp
===
--- cfe/trunk/lib/Sema/SemaChecking.cpp
+++ cfe/trunk/lib/Sema/SemaChecking.cpp
@@ -8109,6 +8109,22 @@
 ExprTy = TET->getUnderlyingExpr()->getType();
   }
 
+  // Diagnose attempts to print a boolean value as a character. Unlike other
+  // -Wformat diagnostics, this is fine from a type perspective, but it still
+  // doesn't make sense.
+  if (FS.getConversionSpecifier().getKind() == ConversionSpecifier::cArg &&
+  E->isKnownToHaveBooleanValue()) {
+const CharSourceRange &CSR =
+getSpecifierRange(StartSpecifier, SpecifierLen);
+SmallString<4> FSString;
+llvm::raw_svector_ostream os(FSString);
+FS.toString(os);
+EmitFormatDiagnostic(S.PDiag(diag::warn_format_bool_as_character)
+ << FSString,
+ E->getExprLoc(), false, CSR);
+return true;
+  }
+
   const analyze_printf::ArgType::MatchKind Match =
   AT.matchesType(S.Context, ExprTy);
   bool Pedantic = Match == analyze_printf::ArgType::NoMatchPedantic;
Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8145,6 +8145,9 @@
 def warn_scanf_scanlist_incomplete : Warning<
   "no closing ']' for '%%[' in scanf format string">,
   InGroup;
+def warn_format_bool_as_character : Warning<
+  "using '%0' format specifier, but argument has boolean value">,
+  InGroup;
 def n

r372248 - make -frewrite-includes also rewrite conditions in #if/#elif

[Lubos Lunak via cfe-commits]

Author: llunak
Date: Wed Sep 18 12:09:41 2019
New Revision: 372248

URL: http://llvm.org/viewvc/llvm-project?rev=372248&view=rev
Log:
make -frewrite-includes also rewrite conditions in #if/#elif

Those conditions may use __has_include, which needs to be rewritten.
The existing code has already tried to rewrite just __has_include,
but it didn't work with macro expansion, so e.g. Qt's
"#define QT_HAS_INCLUDE(x) __has_include(x)" didn't get handled
properly. Since the preprocessor run knows what each condition evaluates
to, just rewrite the entire condition. This of course requires that
the -frewrite-include pass has the same setup as the following
compilation, but that has always been the requirement.

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

Added:
cfe/trunk/test/Frontend/rewrite-includes-conditions.c
Modified:
cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
cfe/trunk/test/Frontend/rewrite-includes.c
cfe/trunk/test/Modules/preprocess-module.cpp

Modified: cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp?rev=372248&r1=372247&r2=372248&view=diff
==
--- cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp Wed Sep 18 12:09:41 
2019
@@ -49,6 +49,8 @@ class InclusionRewriter : public PPCallb
   std::map ModuleIncludes;
   /// Tracks where inclusions that enter modules (in a module build) are found.
   std::map ModuleEntryIncludes;
+  /// Tracks where #if and #elif directives get evaluated and whether to true.
+  std::map IfConditions;
   /// Used transitively for building up the FileIncludes mapping over the
   /// various \c PPCallbacks callbacks.
   SourceLocation LastInclusionLocation;
@@ -78,6 +80,10 @@ private:
   StringRef SearchPath, StringRef RelativePath,
   const Module *Imported,
   SrcMgr::CharacteristicKind FileType) override;
+  void If(SourceLocation Loc, SourceRange ConditionRange,
+  ConditionValueKind ConditionValue) override;
+  void Elif(SourceLocation Loc, SourceRange ConditionRange,
+ConditionValueKind ConditionValue, SourceLocation IfLoc) override;
   void WriteLineInfo(StringRef Filename, int Line,
  SrcMgr::CharacteristicKind FileType,
  StringRef Extra = StringRef());
@@ -89,12 +95,10 @@ private:
   void CommentOutDirective(Lexer &DirectivesLex, const Token &StartToken,
const MemoryBuffer &FromFile, StringRef EOL,
unsigned &NextToWrite, int &Lines);
-  bool HandleHasInclude(FileID FileId, Lexer &RawLex,
-const DirectoryLookup *Lookup, Token &Tok,
-bool &FileExists);
   const IncludedFile *FindIncludeAtLocation(SourceLocation Loc) const;
   const Module *FindModuleAtLocation(SourceLocation Loc) const;
   const Module *FindEnteredModule(SourceLocation Loc) const;
+  bool IsIfAtLocationTrue(SourceLocation Loc) const;
   StringRef NextIdentifierName(Lexer &RawLex, Token &RawToken);
 };
 
@@ -203,6 +207,23 @@ void InclusionRewriter::InclusionDirecti
 LastInclusionLocation = HashLoc;
 }
 
+void InclusionRewriter::If(SourceLocation Loc, SourceRange ConditionRange,
+   ConditionValueKind ConditionValue) {
+  auto P = IfConditions.insert(
+  std::make_pair(Loc.getRawEncoding(), ConditionValue == CVK_True));
+  (void)P;
+  assert(P.second && "Unexpected revisitation of the same if directive");
+}
+
+void InclusionRewriter::Elif(SourceLocation Loc, SourceRange ConditionRange,
+ ConditionValueKind ConditionValue,
+ SourceLocation IfLoc) {
+  auto P = IfConditions.insert(
+  std::make_pair(Loc.getRawEncoding(), ConditionValue == CVK_True));
+  (void)P;
+  assert(P.second && "Unexpected revisitation of the same elif directive");
+}
+
 /// Simple lookup for a SourceLocation (specifically one denoting the hash in
 /// an inclusion directive) in the map of inclusion information, FileChanges.
 const InclusionRewriter::IncludedFile *
@@ -233,6 +254,13 @@ InclusionRewriter::FindEnteredModule(Sou
   return nullptr;
 }
 
+bool InclusionRewriter::IsIfAtLocationTrue(SourceLocation Loc) const {
+  const auto I = IfConditions.find(Loc.getRawEncoding());
+  if (I != IfConditions.end())
+return I->second;
+  return false;
+}
+
 /// Detect the likely line ending style of \p FromFile by examining the first
 /// newline found within it.
 static StringRef DetectEOL(const MemoryBuffer &FromFile) {
@@ -346,80 +374,6 @@ StringRef InclusionRewriter::NextIdentif
   return StringRef();
 }
 
-// Expand __has_include and __has_include_next if possible. If there's no
-// definitive answer return false.
-bool InclusionRewriter::H

r372249 - [clang-format][PR41899] PointerAlignment: Left leads to useless space in lambda intializer expression

[Paul Hoad via cfe-commits]

Author: paulhoad
Date: Wed Sep 18 12:11:40 2019
New Revision: 372249

URL: http://llvm.org/viewvc/llvm-project?rev=372249&view=rev
Log:
[clang-format][PR41899] PointerAlignment: Left leads to useless space in lambda 
intializer expression

Summary:
https://bugs.llvm.org/show_bug.cgi?id=41899

```auto lambda = [&a = a]() { a = 2; };```

is formatted as

```auto lambda = [& a = a]() { a = 2; };```

With an extra space if PointerAlignment is set to Left

> The space "& a" looks strange when there is no type in the lambda's 
> intializer expression. This can be worked around with by setting 
> "PointerAlignment: Right", but ideally "PointerAlignment: Left" would not add 
> a space in this case.

Reviewers: klimek, owenpan, krasimir, timwoj

Reviewed By: klimek

Subscribers: cfe-commits

Tags: #clang-tools-extra, #clang

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

Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=372249&r1=372248&r2=372249&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Wed Sep 18 12:11:40 2019
@@ -2580,7 +2580,8 @@ bool TokenAnnotator::spaceRequiredBetwee
 (Style.PointerAlignment != FormatStyle::PAS_Right &&
  !Line.IsMultiVariableDeclStmt) &&
 Left.Previous &&
-!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon));
+!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon,
+tok::l_square));
   if (Right.is(tok::star) && Left.is(tok::l_paren))
 return false;
   const auto SpaceRequiredForArrayInitializerLSquare =

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=372249&r1=372248&r2=372249&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Wed Sep 18 12:11:40 2019
@@ -14074,6 +14074,15 @@ TEST_F(FormatTest, TypenameMacros) {
   verifyFormat("STACK_OF(int*)* a;", Macros);
 }
 
+TEST_F(FormatTest, AmbersandInLamda) {
+  // Test case reported in https://bugs.llvm.org/show_bug.cgi?id=41899
+  FormatStyle AlignStyle = getLLVMStyle();
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Right;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang


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

r372250 - actually also compile output in tests for -frewrite-includes

[Lubos Lunak via cfe-commits]

Author: llunak
Date: Wed Sep 18 12:12:14 2019
New Revision: 372250

URL: http://llvm.org/viewvc/llvm-project?rev=372250&view=rev
Log:
actually also compile output in tests for -frewrite-includes

Checking that the created output matches something is nice, but
this should also check whether the output makes sense.

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

Modified:
cfe/trunk/test/Frontend/Inputs/NextIncludes/rewrite-includes9.h
cfe/trunk/test/Frontend/Inputs/rewrite-includes1.h
cfe/trunk/test/Frontend/Inputs/rewrite-includes2.h
cfe/trunk/test/Frontend/Inputs/rewrite-includes3.h
cfe/trunk/test/Frontend/Inputs/rewrite-includes4.h
cfe/trunk/test/Frontend/Inputs/rewrite-includes5.h
cfe/trunk/test/Frontend/Inputs/rewrite-includes6.h
cfe/trunk/test/Frontend/Inputs/rewrite-includes7.h
cfe/trunk/test/Frontend/rewrite-includes-cli-include.c
cfe/trunk/test/Frontend/rewrite-includes-conditions.c
cfe/trunk/test/Frontend/rewrite-includes.c

Modified: cfe/trunk/test/Frontend/Inputs/NextIncludes/rewrite-includes9.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/NextIncludes/rewrite-includes9.h?rev=372250&r1=372249&r2=372250&view=diff
==
--- cfe/trunk/test/Frontend/Inputs/NextIncludes/rewrite-includes9.h (original)
+++ cfe/trunk/test/Frontend/Inputs/NextIncludes/rewrite-includes9.h Wed Sep 18 
12:12:14 2019
@@ -1 +1 @@
-included_line9
+int included_line9;

Modified: cfe/trunk/test/Frontend/Inputs/rewrite-includes1.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes1.h?rev=372250&r1=372249&r2=372250&view=diff
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes1.h (original)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes1.h Wed Sep 18 12:12:14 2019
@@ -1,3 +1,3 @@
 #pragma clang system_header
-included_line1
+int included_line1;
 #include "rewrite-includes2.h"

Modified: cfe/trunk/test/Frontend/Inputs/rewrite-includes2.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes2.h?rev=372250&r1=372249&r2=372250&view=diff
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes2.h (original)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes2.h Wed Sep 18 12:12:14 2019
@@ -1 +1 @@
-included_line2
+int included_line2;

Modified: cfe/trunk/test/Frontend/Inputs/rewrite-includes3.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes3.h?rev=372250&r1=372249&r2=372250&view=diff
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes3.h (original)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes3.h Wed Sep 18 12:12:14 2019
@@ -1 +1 @@
-included_line3
+unsigned int included_line3 = -10;

Modified: cfe/trunk/test/Frontend/Inputs/rewrite-includes4.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes4.h?rev=372250&r1=372249&r2=372250&view=diff
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes4.h (original)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes4.h Wed Sep 18 12:12:14 2019
@@ -1 +1 @@
-included_line4
+int included_line4;

Modified: cfe/trunk/test/Frontend/Inputs/rewrite-includes5.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes5.h?rev=372250&r1=372249&r2=372250&view=diff
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes5.h (original)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes5.h Wed Sep 18 12:12:14 2019
@@ -1 +1 @@
-included_line5
+int included_line5;

Modified: cfe/trunk/test/Frontend/Inputs/rewrite-includes6.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes6.h?rev=372250&r1=372249&r2=372250&view=diff
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes6.h (original)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes6.h Wed Sep 18 12:12:14 2019
@@ -1,2 +1,2 @@
 #pragma once
-included_line6
+int included_line6;

Modified: cfe/trunk/test/Frontend/Inputs/rewrite-includes7.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes7.h?rev=372250&r1=372249&r2=372250&view=diff
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes7.h (original)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes7.h Wed Sep 18 12:12:14 2019
@@ -1,4 +1,4 @@
 #ifndef REWRITE_INCLUDES_7
 #define REWRITE_INCLUDES_7
-included_line7
+int included_line7;
 #endif

Modified: cfe/trunk/

[PATCH] D67723: [CodeView] Add option to disable inline line tables.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added subscribers: JDevlieghere, aprantl.
dblaikie added a comment.

As per the bug - I'm not super inclined towards a function attribute here (& 
even if it's going to be an inliner rather than debug info generation/backend 
thing (which I'm more on the fence about - think I'm happy with either 
direction there, really) - I'd still be inclined towards it living in the 
DICompileUnit with other debug info things, rather than a function attribute). 
But happy to hear what other folks (especially the usual debug info cabal - 
@aprantl @probinson @JDevlieghere etc) think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67723



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

[PATCH] D67647: [Consumed] Refactor handleCall to take function argument list. NFC.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D67647#1673363 , @comex wrote:

> Ugh, it looks like `getArgs()` is a massive strict aliasing violation.  And 
> it's used in enough different places in Clang that fixing the violation may 
> require extensive refactoring... I've reported the issue as 
> https://bugs.llvm.org/show_bug.cgi?id=43344, but I don't really want to fix 
> it :)
>
> However, I can at least update this patch to avoid using getArgs().


Yeah, existing technical debt - I don't think your situation is making that any 
worse or better, so no worries about it.


Repository:
  rC Clang

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

https://reviews.llvm.org/D67647



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

[PATCH] D67718: [clang-format][PR41899] PointerAlignment: Left leads to useless space in lambda intializer expression

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372249: [clang-format][PR41899] PointerAlignment: Left leads 
to useless space in lambda… (authored by paulhoad, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67718?vs=220695&id=220724#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67718

Files:
  cfe/trunk/lib/Format/TokenAnnotator.cpp
  cfe/trunk/unittests/Format/FormatTest.cpp


Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -2580,7 +2580,8 @@
 (Style.PointerAlignment != FormatStyle::PAS_Right &&
  !Line.IsMultiVariableDeclStmt) &&
 Left.Previous &&
-!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon));
+!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon,
+tok::l_square));
   if (Right.is(tok::star) && Left.is(tok::l_paren))
 return false;
   const auto SpaceRequiredForArrayInitializerLSquare =
Index: cfe/trunk/unittests/Format/FormatTest.cpp
===
--- cfe/trunk/unittests/Format/FormatTest.cpp
+++ cfe/trunk/unittests/Format/FormatTest.cpp
@@ -14074,6 +14074,15 @@
   verifyFormat("STACK_OF(int*)* a;", Macros);
 }
 
+TEST_F(FormatTest, AmbersandInLamda) {
+  // Test case reported in https://bugs.llvm.org/show_bug.cgi?id=41899
+  FormatStyle AlignStyle = getLLVMStyle();
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Right;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang


Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -2580,7 +2580,8 @@
 (Style.PointerAlignment != FormatStyle::PAS_Right &&
  !Line.IsMultiVariableDeclStmt) &&
 Left.Previous &&
-!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon));
+!Left.Previous->isOneOf(tok::l_paren, tok::coloncolon,
+tok::l_square));
   if (Right.is(tok::star) && Left.is(tok::l_paren))
 return false;
   const auto SpaceRequiredForArrayInitializerLSquare =
Index: cfe/trunk/unittests/Format/FormatTest.cpp
===
--- cfe/trunk/unittests/Format/FormatTest.cpp
+++ cfe/trunk/unittests/Format/FormatTest.cpp
@@ -14074,6 +14074,15 @@
   verifyFormat("STACK_OF(int*)* a;", Macros);
 }
 
+TEST_F(FormatTest, AmbersandInLamda) {
+  // Test case reported in https://bugs.llvm.org/show_bug.cgi?id=41899
+  FormatStyle AlignStyle = getLLVMStyle();
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+  AlignStyle.PointerAlignment = FormatStyle::PAS_Right;
+  verifyFormat("auto lambda = [&a = a]() { a = 2; };", AlignStyle);
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63979: actually also compile output in tests for -frewrite-includes

[Luboš Luňák via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL372250: actually also compile output in tests for 
-frewrite-includes (authored by llunak, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63979?vs=207226&id=220725#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63979

Files:
  cfe/trunk/test/Frontend/Inputs/NextIncludes/rewrite-includes9.h
  cfe/trunk/test/Frontend/Inputs/rewrite-includes1.h
  cfe/trunk/test/Frontend/Inputs/rewrite-includes2.h
  cfe/trunk/test/Frontend/Inputs/rewrite-includes3.h
  cfe/trunk/test/Frontend/Inputs/rewrite-includes4.h
  cfe/trunk/test/Frontend/Inputs/rewrite-includes5.h
  cfe/trunk/test/Frontend/Inputs/rewrite-includes6.h
  cfe/trunk/test/Frontend/Inputs/rewrite-includes7.h
  cfe/trunk/test/Frontend/rewrite-includes-cli-include.c
  cfe/trunk/test/Frontend/rewrite-includes-conditions.c
  cfe/trunk/test/Frontend/rewrite-includes.c

Index: cfe/trunk/test/Frontend/rewrite-includes.c
===
--- cfe/trunk/test/Frontend/rewrite-includes.c
+++ cfe/trunk/test/Frontend/rewrite-includes.c
@@ -1,8 +1,9 @@
-// RUN: not %clang_cc1 -verify -E -frewrite-includes -DFIRST -I %S/Inputs -I %S/Inputs/NextIncludes %s -o - | FileCheck -strict-whitespace %s
-// RUN: not %clang_cc1 -verify -E -frewrite-includes -P -DFIRST -I %S/Inputs -I %S/Inputs/NextIncludes %s -o - | FileCheck -check-prefix=CHECKNL -strict-whitespace %s
+// RUN: %clang_cc1 -E -frewrite-includes -DFIRST -I %S/Inputs -I %S/Inputs/NextIncludes %s -o - | FileCheck -strict-whitespace %s
+// RUN: %clang_cc1 -E -frewrite-includes -P -DFIRST -I %S/Inputs -I %S/Inputs/NextIncludes %s -o - | FileCheck -check-prefix=CHECKNL -strict-whitespace %s
+// RUN: %clang_cc1 -E -frewrite-includes -DFIRST -I %S/Inputs -I %S/Inputs/NextIncludes %s -o - | %clang_cc1 -Wall -Wextra -Wconversion -DFIRST -x c -fsyntax-only 2>&1 | FileCheck -check-prefix=COMPILE --implicit-check-not warning: %s
 // STARTCOMPARE
 #define A(a,b) a ## b
-A(1,2)
+A(in,t) a;
 #include "rewrite-includes1.h"
 #ifdef FIRST
 #define HEADER "rewrite-includes3.h"
@@ -21,94 +22,95 @@
 #include "rewrite-includes7.h"
 #include "rewrite-includes8.h"
 #include "rewrite-includes9.h"
+static int unused;
 // ENDCOMPARE
 // CHECK: {{^}}# 1 "{{.*}}rewrite-includes.c"{{$}}
 // CHECK: {{^}}// STARTCOMPARE{{$}}
 // CHECK-NEXT: {{^}}#define A(a,b) a ## b{{$}}
-// CHECK-NEXT: {{^}}A(1,2){{$}}
+// CHECK-NEXT: {{^}}A(in,t) a;{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include "rewrite-includes1.h"{{$}}
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
-// CHECK-NEXT: {{^}}# 6 "{{.*}}rewrite-includes.c"{{$}}
+// CHECK-NEXT: {{^}}# 7 "{{.*}}rewrite-includes.c"{{$}}
 // CHECK-NEXT: {{^}}# 1 "{{.*[/\\]Inputs(/|)}}rewrite-includes1.h" 1{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#pragma clang system_header{{$}}
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}# 2 "{{.*[/\\]Inputs(/|)}}rewrite-includes1.h" 3{{$}}
-// CHECK-NEXT: {{^}}included_line1{{$}}
+// CHECK-NEXT: {{^}}int included_line1;{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include "rewrite-includes2.h"{{$}}
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}# 3 "{{.*[/\\]Inputs(/|)}}rewrite-includes1.h" 3{{$}}
 // CHECK-NEXT: {{^}}# 1 "{{.*[/\\]Inputs(/|)}}rewrite-includes2.h" 1 3{{$}}
-// CHECK-NEXT: {{^}}included_line2{{$}}
+// CHECK-NEXT: {{^}}int included_line2;{{$}}
 // CHECK-NEXT: {{^}}# 4 "{{.*[/\\]Inputs(/|)}}rewrite-includes1.h" 2 3{{$}}
-// CHECK-NEXT: {{^}}# 7 "{{.*}}rewrite-includes.c" 2{{$}}
+// CHECK-NEXT: {{^}}# 8 "{{.*}}rewrite-includes.c" 2{{$}}
 // CHECK-NEXT: {{^}}#ifdef FIRST{{$}}
 // CHECK-NEXT: {{^}}#define HEADER "rewrite-includes3.h"{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include HEADER{{$}}
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
-// CHECK-NEXT: {{^}}# 9 "{{.*}}rewrite-includes.c"{{$}}
+// CHECK-NEXT: {{^}}# 10 "{{.*}}rewrite-includes.c"{{$}}
 // CHECK-NEXT: {{^}}# 1 "{{.*[/\\]Inputs(/|)}}rewrite-includes3.h" 1{{$}}
-// CHECK-NEXT: {{^}}included_line3{{$}}
-// CHECK-NEXT: {{^}}# 10 "{{.*}}rewrite-includes.c" 2{{$}}
+// CHECK-NEXT: {{^}}unsigned int included_line3 = -10;{{$}}
+// CHECK-NEXT: {{^}}# 11 "{{.*}}rewrite-includes.c" 2{{$}}
 // CHECK-NEXT: {{^}}#else{{$}}
-// CHECK-NEXT: {{^}}# 11 "{{.*}}rewrite-includes.c"{{$}}
+// CHECK-NEXT: {{^}}# 12 "{{.*}}rewrite-includes.c"{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expa

r372252 - [OPENMP]Fix for PR43349: Crash for privatized loop bound.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Wed Sep 18 12:24:07 2019
New Revision: 372252

URL: http://llvm.org/viewvc/llvm-project?rev=372252&view=rev
Log:
[OPENMP]Fix for PR43349: Crash for privatized loop bound.

If the variable, used in the loop boundaries, is not captured in the
construct, this variable must be considered as undefined if it was
privatized.

Modified:
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/test/OpenMP/parallel_for_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp?rev=372252&r1=372251&r2=372252&view=diff
==
--- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Wed Sep 18 12:24:07 2019
@@ -120,11 +120,27 @@ public:
 class OMPLoopScope : public CodeGenFunction::RunCleanupsScope {
   void emitPreInitStmt(CodeGenFunction &CGF, const OMPLoopDirective &S) {
 CodeGenFunction::OMPMapVars PreCondVars;
+llvm::DenseSet EmittedAsPrivate;
 for (const auto *E : S.counters()) {
   const auto *VD = cast(cast(E)->getDecl());
+  EmittedAsPrivate.insert(VD->getCanonicalDecl());
   (void)PreCondVars.setVarAddr(
   CGF, VD, CGF.CreateMemTemp(VD->getType().getNonReferenceType()));
 }
+// Mark private vars as undefs.
+for (const auto *C : S.getClausesOfKind()) {
+  for (const Expr *IRef : C->varlists()) {
+const auto *OrigVD = cast(cast(IRef)->getDecl());
+if (EmittedAsPrivate.insert(OrigVD->getCanonicalDecl()).second) {
+  (void)PreCondVars.setVarAddr(
+  CGF, OrigVD,
+  Address(llvm::UndefValue::get(
+  
CGF.ConvertTypeForMem(CGF.getContext().getPointerType(
+  OrigVD->getType().getNonReferenceType(,
+  CGF.getContext().getDeclAlign(OrigVD)));
+}
+  }
+}
 (void)PreCondVars.apply(CGF);
 if (const auto *PreInits = cast_or_null(S.getPreInits())) {
   for (const auto *I : PreInits->decls())

Modified: cfe/trunk/test/OpenMP/parallel_for_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_for_codegen.cpp?rev=372252&r1=372251&r2=372252&view=diff
==
--- cfe/trunk/test/OpenMP/parallel_for_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/parallel_for_codegen.cpp Wed Sep 18 12:24:07 2019
@@ -35,12 +35,14 @@ void with_var_schedule() {
 // CHECK: [[CHUNK:%.+]] = load i64, i64* %
 // CHECK: call void {{.+}} @__kmpc_fork_call({{.+}}, i64 [[CHUNK]])
 
+// CHECK: [[UNDEF_A:%.+]] = load double, double* undef
+// CHECK: fadd double 2.00e+00, [[UNDEF_A]]
 // CHECK: [[CHUNK_VAL:%.+]] = load i8, i8* %
 // CHECK: [[CHUNK_SIZE:%.+]] = sext i8 [[CHUNK_VAL]] to i64
 // CHECK: call void @__kmpc_for_static_init_8u([[IDENT_T_TY]]* [[LOOP_LOC]], 
i32 [[GTID:%[^,]+]], i32 33, i32* [[IS_LAST:%[^,]+]], i64* [[OMP_LB:%[^,]+]], 
i64* [[OMP_UB:%[^,]+]], i64* [[OMP_ST:%[^,]+]], i64 1, i64 [[CHUNK_SIZE]])
 // CHECK: call void @__kmpc_for_static_fini([[IDENT_T_TY]]* [[LOOP_LOC]], i32 
[[GTID]])
-#pragma omp parallel for schedule(static, char(a))
-  for (unsigned long long i = 1; i < 2; ++i) {
+#pragma omp parallel for schedule(static, char(a)) private(a)
+  for (unsigned long long i = 1; i < 2 + a; ++i) {
   }
 }
 


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

[PATCH] D67730: [CUDA][HIP] Fix typo in `BestViableFunction`

[Michael Liao via Phabricator via cfe-commits]

hliao created this revision.
hliao added a reviewer: tra.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

- Should consider viable ones only when checking SameSide candidates.
- Replace erasing with clearing viable flag to reduce data moving/copying.
- Add one and revise another one as the diagnostic message are more relevant 
compared to previous one.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67730

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCUDA/function-overload.cu
  clang/test/SemaCUDA/implicit-member-target-collision-cxx11.cu


Index: clang/test/SemaCUDA/implicit-member-target-collision-cxx11.cu
===
--- clang/test/SemaCUDA/implicit-member-target-collision-cxx11.cu
+++ clang/test/SemaCUDA/implicit-member-target-collision-cxx11.cu
@@ -74,11 +74,13 @@
 struct C4_with_collision : A4_with_host_copy_ctor, B4_with_device_copy_ctor {
 };
 
-// expected-note@-3 {{copy constructor of 'C4_with_collision' is implicitly 
deleted because base class 'B4_with_device_copy_ctor' has no copy constructor}}
+// expected-note@-3 {{candidate constructor (the implicit copy constructor) 
not viable: call to invalid function from __host__ function}}
+// expected-note@-4 {{implicit copy constructor inferred target collision: 
call to both __host__ and __device__ members}}
+// expected-note@-5 {{candidate constructor (the implicit default constructor) 
not viable: requires 0 arguments, but 1 was provided}}
 
 void hostfoo4() {
   C4_with_collision c;
-  C4_with_collision c2 = c; // expected-error {{call to implicitly-deleted 
copy constructor of 'C4_with_collision'}}
+  C4_with_collision c2 = c; // expected-error {{no matching constructor for 
initialization of 'C4_with_collision'}}
 }
 
 
//--
Index: clang/test/SemaCUDA/function-overload.cu
===
--- clang/test/SemaCUDA/function-overload.cu
+++ clang/test/SemaCUDA/function-overload.cu
@@ -1,8 +1,8 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: nvptx-registered-target
 
-// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify %s
-// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -fsyntax-only -fcuda-is-device 
-verify %s
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-linux-gnu -fsyntax-only 
-verify %s
+// RUN: %clang_cc1 -std=c++11 -triple nvptx64-nvidia-cuda -fsyntax-only 
-fcuda-is-device -verify %s
 
 #include "Inputs/cuda.h"
 
@@ -402,3 +402,20 @@
 __device__ void test_device_template_overload() {
   template_overload(1); // OK. Attribute-based overloading picks __device__ 
variant.
 }
+
+// Two irrelevant classes with `operator-` defined. One of them is device only.
+struct C1 { int m; };
+struct C2 { int *m; };
+__device__
+int operator-(const C1 &x, const C1 &y) { return x.m - y.m; }
+int operator-(const C2 &x, const C2 &y) { return x.m - y.m; }
+
+template 
+constexpr int constexpr_overload(const T &x, const T &y) {
+  return x - y;
+}
+
+// Verify that function overloading doesn't prune candidate wrongly.
+int test_constexpr_overload(C2 x, C2 y) {
+  return constexpr_overload(x, y);
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -9422,17 +9422,19 @@
 const FunctionDecl *Caller = dyn_cast(S.CurContext);
 bool ContainsSameSideCandidate =
 llvm::any_of(Candidates, [&](OverloadCandidate *Cand) {
-  return Cand->Function &&
+  // Consider viable function only.
+  return Cand->Viable && Cand->Function &&
  S.IdentifyCUDAPreference(Caller, Cand->Function) ==
  Sema::CFP_SameSide;
 });
 if (ContainsSameSideCandidate) {
-  auto IsWrongSideCandidate = [&](OverloadCandidate *Cand) {
-return Cand->Function &&
-   S.IdentifyCUDAPreference(Caller, Cand->Function) ==
-   Sema::CFP_WrongSide;
-  };
-  llvm::erase_if(Candidates, IsWrongSideCandidate);
+  // Clear viable flag for WrongSide varible candidates.
+  llvm::for_each(Candidates, [&](OverloadCandidate *Cand) {
+if (Cand->Viable && Cand->Function &&
+S.IdentifyCUDAPreference(Caller, Cand->Function) ==
+Sema::CFP_WrongSide)
+  Cand->Viable = false;
+  });
 }
   }
 


Index: clang/test/SemaCUDA/implicit-member-target-collision-cxx11.cu
===
--- clang/test/SemaCUDA/implicit-member-target-collision-cxx11.cu
+++ clang/test/SemaCUDA/implicit-member-target-collision-cxx11.cu
@@ -74,11 +74,13 @@
 struct C4_with_collision : A4_with_host_copy_ctor, B4_with_device_copy_ctor {
 };
 
-// expected-note@-3 {{copy constructor of 'C4_with_collision' is implicitly dele

[PATCH] D52281: [clang-tidy] Add modernize check to use std::invoke in generic code

[Borsik Gábor via Phabricator via cfe-commits]

boga95 marked an inline comment as done.
boga95 added a comment.

Resolving the problems properly seemed quite difficult. I just finished 
university and started to work, therefore I don't have enough free time to 
finish the checker. Sorry about that.


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

https://reviews.llvm.org/D52281



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

r372261 - On PowerPC, Secure-PLT by default for FreeBSD 13 and higher

[Dimitry Andric via cfe-commits]

Author: dim
Date: Wed Sep 18 13:58:03 2019
New Revision: 372261

URL: http://llvm.org/viewvc/llvm-project?rev=372261&view=rev
Log:
On PowerPC, Secure-PLT by default for FreeBSD 13 and higher

Summary:
In https://svnweb.freebsd.org/changeset/base/349351, FreeBSD 13 and
higher transitioned to Secure-PLT for PowerPC.  This part contains the
changes in clang's PPC architecture defaults.

Reviewers: emaste, jhibbits, hfinkel

Reviewed By: jhibbits

Subscribers: wuzish, nemanjai, krytarowski, kbarton, MaskRay, jsji, shchenz, 
steven.zhang, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp?rev=372261&r1=372260&r2=372261&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp Wed Sep 18 13:58:03 2019
@@ -115,7 +115,8 @@ ppc::ReadGOTPtrMode ppc::getPPCReadGOTPt
   const ArgList &Args) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
+  if ((Triple.isOSFreeBSD() && Triple.getOSMajorVersion() >= 13) ||
+  Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;


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

[PATCH] D67119: On PowerPC, Secure-PLT by default for FreeBSD 13 and higher

[Dimitry Andric via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL372261: On PowerPC, Secure-PLT by default for FreeBSD 13 and 
higher (authored by dim, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67119

Files:
  cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp


Index: cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
@@ -115,7 +115,8 @@
   const ArgList &Args) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
+  if ((Triple.isOSFreeBSD() && Triple.getOSMajorVersion() >= 13) ||
+  Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;


Index: cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/PPC.cpp
@@ -115,7 +115,8 @@
   const ArgList &Args) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
+  if ((Triple.isOSFreeBSD() && Triple.getOSMajorVersion() >= 13) ||
+  Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits