Re: [PATCH] D50645: [clangd] Show non-instantiated decls in signatureHelp

[Yvan Roux via cfe-commits]

Hi Ilya,

This commit broke some of ARM's bots, log are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/3120/steps/ninja%20check%201/logs/stdio

Thanks
Yvan

On Tue, 14 Aug 2018 at 11:37, Phabricator via Phabricator via
cfe-commits  wrote:
>
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL339665: [clangd] Show non-instantiated decls in 
> signatureHelp (authored by ibiryukov, committed by ).
> Herald added a subscriber: llvm-commits.
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D50645
>
> Files:
>   clang-tools-extra/trunk/clangd/CodeComplete.cpp
>   clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
>
>
> Index: clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
> ===
> --- clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
> +++ clang-tools-extra/trunk/unittests/clangd/CodeCompleteTests.cpp
> @@ -1537,6 +1537,59 @@
>EXPECT_EQ(0, Results.activeParameter);
>  }
>
> +TEST(SignatureHelpTest, InstantiatedSignatures) {
> +  EXPECT_THAT(signatures(R"cpp(
> +template 
> +void foo(T, T, T);
> +
> +int main() {
> +  foo(^);
> +}
> +  )cpp")
> +  .signatures,
> +  ElementsAre(Sig("foo(T, T, T) -> void", {"T", "T", "T"})));
> +
> +  EXPECT_THAT(signatures(R"cpp(
> +template 
> +void foo(T, T, T);
> +
> +int main() {
> +  foo(10, ^);
> +})cpp")
> +  .signatures,
> +  ElementsAre(Sig("foo(T, T, T) -> void", {"T", "T", "T"})));
> +
> +  EXPECT_THAT(signatures(R"cpp(
> +template 
> +void foo(T...);
> +
> +int main() {
> +  foo(^);
> +}
> +  )cpp")
> +  .signatures,
> +  ElementsAre(Sig("foo(T...) -> void", {"T..."})));
> +
> +  // It is debatable whether we should substitute the outer template 
> parameter
> +  // ('T') in that case. Currently we don't substitute it in signature help, 
> but
> +  // do substitute in code complete.
> +  // FIXME: make code complete and signature help consistent, figure out 
> which
> +  // way is better.
> +  EXPECT_THAT(signatures(R"cpp(
> +template 
> +struct X {
> +  template 
> +  void foo(T, U);
> +};
> +
> +int main() {
> +  X().foo(^)
> +}
> +  )cpp")
> +  .signatures,
> +  ElementsAre(Sig("foo(T, U) -> void", {"T", "U"})));
> +}
> +
>  } // namespace
>  } // namespace clangd
>  } // namespace clang
> Index: clang-tools-extra/trunk/clangd/CodeComplete.cpp
> ===
> --- clang-tools-extra/trunk/clangd/CodeComplete.cpp
> +++ clang-tools-extra/trunk/clangd/CodeComplete.cpp
> @@ -714,7 +714,15 @@
> "too many arguments");
>  SigHelp.activeParameter = static_cast(CurrentArg);
>  for (unsigned I = 0; I < NumCandidates; ++I) {
> -  const auto &Candidate = Candidates[I];
> +  OverloadCandidate Candidate = Candidates[I];
> +  // We want to avoid showing instantiated signatures, because they may 
> be
> +  // long in some cases (e.g. when 'T' is substituted with 
> 'std::string', we
> +  // would get 'std::basic_string').
> +  if (auto *Func = Candidate.getFunction()) {
> +if (auto *Pattern = Func->getTemplateInstantiationPattern())
> +  Candidate = OverloadCandidate(Pattern);
> +  }
> +
>const auto *CCS = Candidate.CreateSignatureString(
>CurrentArg, S, *Allocator, CCTUInfo, true);
>assert(CCS && "Expected the CodeCompletionString to be non-null");
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxxabi] r339865 - [libcxxabi] Fix test_exception_address_alignment test for ARM

[Yvan Roux via cfe-commits]

Author: yroux
Date: Thu Aug 16 04:38:09 2018
New Revision: 339865

URL: http://llvm.org/viewvc/llvm-project?rev=339865&view=rev
Log:
[libcxxabi] Fix test_exception_address_alignment test for ARM

Check _LIBCXXABI_ARM_EHABI macro instead of libunwind version.

Fixes PR34182

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

Modified:
libcxxabi/trunk/test/test_exception_address_alignment.pass.cpp

Modified: libcxxabi/trunk/test/test_exception_address_alignment.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/test_exception_address_alignment.pass.cpp?rev=339865&r1=339864&r2=339865&view=diff
==
--- libcxxabi/trunk/test/test_exception_address_alignment.pass.cpp (original)
+++ libcxxabi/trunk/test/test_exception_address_alignment.pass.cpp Thu Aug 16 
04:38:09 2018
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include <__cxxabi_config.h>
 
 #include 
 
@@ -27,7 +28,7 @@ struct __attribute__((aligned)) AlignedT
 
 // EHABI  : 8-byte aligned
 // Itanium: Largest supported alignment for the system
-#if defined(_LIBUNWIND_ARM_EHABI)
+#if defined(_LIBCXXABI_ARM_EHABI)
 #  define EXPECTED_ALIGNMENT 8
 #else
 #  define EXPECTED_ALIGNMENT alignof(AlignedType)


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

Re: [PATCH] D46964: Implement class deduction guides for `std::array`

[Yvan Roux via cfe-commits]

Hi Marshall,

ARM and AArch64 libcxx buildbots are broken since that commits, logs
are available at:

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux/builds/107/steps/test.libcxx/logs/FAIL%3A%20libc%2B%2B%3A%3Adeduct.pass.cpp

Thanks
Yvan


On 18 May 2018 at 23:05, Marshall Clow via Phabricator via cfe-commits
 wrote:
> mclow.lists closed this revision.
> mclow.lists added a comment.
>
> Committed as revision 332768
>
>
> https://reviews.llvm.org/D46964
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D51852: [clangd] Implement FuzzyFindRequest JSON (de)serialization

[Yvan Roux via cfe-commits]

Hi Kirill,

This commit broke ARMV8 buildbots, logs are available here:
http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/6493/steps/build%20stage%201/logs/stdio

Thanks
Yvan
On Mon, 10 Sep 2018 at 13:52, Kirill Bobyrev via Phabricator via
llvm-commits  wrote:
>
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL341802: [clangd] Implement FuzzyFindRequest JSON 
> (de)serialization (authored by omtcyfz, committed by ).
> Herald added a subscriber: llvm-commits.
>
> Changed prior to commit:
>   https://reviews.llvm.org/D51852?vs=164648&id=164655#toc
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D51852
>
> Files:
>   clang-tools-extra/trunk/clangd/CodeComplete.cpp
>   clang-tools-extra/trunk/clangd/index/Index.cpp
>   clang-tools-extra/trunk/clangd/index/Index.h
>
>
> Index: clang-tools-extra/trunk/clangd/CodeComplete.cpp
> ===
> --- clang-tools-extra/trunk/clangd/CodeComplete.cpp
> +++ clang-tools-extra/trunk/clangd/CodeComplete.cpp
> @@ -1381,8 +1381,7 @@
>  Req.Scopes = QueryScopes;
>  // FIXME: we should send multiple weighted paths here.
>  Req.ProximityPaths.push_back(FileName);
> -vlog("Code complete: fuzzyFind(\"{0}\", scopes=[{1}])", Req.Query,
> - llvm::join(Req.Scopes.begin(), Req.Scopes.end(), ","));
> +vlog("Code complete: fuzzyFind({0:2})", toJSON(Req));
>
>  if (SpecFuzzyFind)
>SpecFuzzyFind->NewReq = Req;
> Index: clang-tools-extra/trunk/clangd/index/Index.h
> ===
> --- clang-tools-extra/trunk/clangd/index/Index.h
> +++ clang-tools-extra/trunk/clangd/index/Index.h
> @@ -19,8 +19,10 @@
>  #include "llvm/ADT/SmallVector.h"
>  #include "llvm/ADT/StringExtras.h"
>  #include "llvm/ADT/StringRef.h"
> +#include "llvm/Support/JSON.h"
>  #include "llvm/Support/StringSaver.h"
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -435,7 +437,7 @@
>std::vector Scopes;
>/// \brief The number of top candidates to return. The index may choose to
>/// return more than this, e.g. if it doesn't know which candidates are 
> best.
> -  size_t MaxCandidateCount = UINT_MAX;
> +  size_t MaxCandidateCount = std::numeric_limits::max();
>/// If set to true, only symbols for completion support will be considered.
>bool RestrictForCodeCompletion = false;
>/// Contextually relevant files (e.g. the file we're code-completing in).
> @@ -450,6 +452,8 @@
>}
>bool operator!=(const FuzzyFindRequest &Req) const { return !(*this == 
> Req); }
>  };
> +bool fromJSON(const llvm::json::Value &Value, FuzzyFindRequest &Request);
> +llvm::json::Value toJSON(const FuzzyFindRequest &Request);
>
>  struct LookupRequest {
>llvm::DenseSet IDs;
> Index: clang-tools-extra/trunk/clangd/index/Index.cpp
> ===
> --- clang-tools-extra/trunk/clangd/index/Index.cpp
> +++ clang-tools-extra/trunk/clangd/index/Index.cpp
> @@ -175,6 +175,33 @@
>return Index;
>  }
>
> +bool fromJSON(const llvm::json::Value &Parameters, FuzzyFindRequest 
> &Request) {
> +  json::ObjectMapper O(Parameters);
> +  llvm::Optional MaxCandidateCount;
> +  bool OK =
> +  O && O.map("Query", Request.Query) && O.map("Scopes", Request.Scopes) 
> &&
> +  O.map("RestrictForCodeCompletion", Request.RestrictForCodeCompletion) 
> &&
> +  O.map("ProximityPaths", Request.ProximityPaths) &&
> +  O.map("MaxCandidateCount", MaxCandidateCount);
> +  if (MaxCandidateCount)
> +Request.MaxCandidateCount = MaxCandidateCount.getValue();
> +  return OK;
> +}
> +
> +llvm::json::Value toJSON(const FuzzyFindRequest &Request) {
> +  auto Result = json::Object{
> +  {"Query", Request.Query},
> +  {"Scopes", json::Array{Request.Scopes}},
> +  {"RestrictForCodeCompletion", Request.RestrictForCodeCompletion},
> +  {"ProximityPaths", json::Array{Request.ProximityPaths}},
> +  };
> +  // A huge limit means no limit, leave it out.
> +  if (Request.MaxCandidateCount <= std::numeric_limits::max())
> +Result["MaxCandidateCount"] =
> +static_cast(Request.MaxCandidateCount);
> +  return Result;
> +}
> +
>  bool SwapIndex::fuzzyFind(const FuzzyFindRequest &R,
>llvm::function_ref CB) const 
> {
>return snapshot()->fuzzyFind(R, CB);
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D51852: [clangd] Implement FuzzyFindRequest JSON (de)serialization

[Yvan Roux via cfe-commits]

On Mon, 10 Sep 2018 at 16:36, Kirill Bobyrev via Phabricator
 wrote:
>
> kbobyrev added a comment.
>
> In https://reviews.llvm.org/D51852#1228883, @yroux wrote:
>
> > Hi Kirill,
> >
> > This commit broke ARMV8 buildbots, logs are available here:
> >  
> > http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/6493/steps/build%20stage%201/logs/stdio
> >
> > Thanks
> > Yvan
>
>
> Hi! Apologies for inconvenience, https://reviews.llvm.org/rL341832 should 
> solve the issue.

build on his way, but the issue is fixed, Index.cpp compiles with a warning now:

[5/100] Building CXX object
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/index/Index.cpp.o
/home/buildslave/buildslave/clang-cmake-armv8-quick/llvm/tools/clang/tools/extra/clangd/index/Index.cpp:199:33:
warning: comparison of constant 9223372036854775807 with expression of
type 'const size_t' (aka 'const unsigned int') is always true
[-Wtautological-constant-out-of-range-compare]
  if (Request.MaxCandidateCount <= std::numeric_limits::max())
  ~ ^  ~~~
1 warning generated.

Thanks for the quick fix.


> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D51852
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r325850 - [Darwin] Add a test to check clang produces accelerator tables.

[Yvan Roux via cfe-commits]

Hi Davide,


This patch broke ARM and AArch64 bots (x86_64 apple targets are not
available on these bots).
Logs are available here:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/15940/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Adebug-info-section-macho.c

Thanks
Yvan

On 23 February 2018 at 02:25, Davide Italiano via cfe-commits
 wrote:
> Author: davide
> Date: Thu Feb 22 17:25:03 2018
> New Revision: 325850
>
> URL: http://llvm.org/viewvc/llvm-project?rev=325850&view=rev
> Log:
> [Darwin] Add a test to check clang produces accelerator tables.
>
> This test was previously in lldb, and was only checking that clang
> was emitting the correct section. So, it belongs here and not
> in the debugger.
>
> Added:
> cfe/trunk/test/CodeGen/debug-info-section-macho.c
>
> Added: cfe/trunk/test/CodeGen/debug-info-section-macho.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-info-section-macho.c?rev=325850&view=auto
> ==
> --- cfe/trunk/test/CodeGen/debug-info-section-macho.c (added)
> +++ cfe/trunk/test/CodeGen/debug-info-section-macho.c Thu Feb 22 17:25:03 2018
> @@ -0,0 +1,16 @@
> +// Test that clang produces the __apple accelerator tables,
> +// e.g., __apple_types, correctly.
> +// RUN: %clang %s -target x86_64-apple-macosx10.13.0 -c -g -o %t-ex
> +// RUN: llvm-objdump -section-headers %t-ex | FileCheck %s
> +
> +int main (int argc, char const *argv[]) { return argc; }
> +
> +// CHECK: __debug_str
> +// CHECK-NEXT: __debug_abbrev
> +// CHECK-NEXT: __debug_info
> +// CHECK-NEXT: __debug_ranges
> +// CHECK-NEXT: __debug_macinfo
> +// CHECK-NEXT: __apple_names
> +// CHECK-NEXT: __apple_objc
> +// CHECK-NEXT: __apple_namespac
> +// CHECK-NEXT: __apple_types
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r326156 - [analyzer] Logging test typo quickfix.

[Yvan Roux via cfe-commits]

Hi George,

On 27 February 2018 at 02:31, George Karpenkov via cfe-commits
 wrote:
> Author: george.karpenkov
> Date: Mon Feb 26 17:31:06 2018
> New Revision: 326156
>
> URL: http://llvm.org/viewvc/llvm-project?rev=326156&view=rev
> Log:
> [analyzer] Logging test typo quickfix.
>
> Modified:
> cfe/trunk/test/Analysis/region_store_overflow.c
>
> Modified: cfe/trunk/test/Analysis/region_store_overflow.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/region_store_overflow.c?rev=326156&r1=326155&r2=326156&view=diff
> ==
> --- cfe/trunk/test/Analysis/region_store_overflow.c (original)
> +++ cfe/trunk/test/Analysis/region_store_overflow.c Mon Feb 26 17:31:06 2018
> @@ -1,4 +1,4 @@
> -// RUN: %clang_analyze_cc1 -analyze -analyzer-checker=core -mllvm 
> -debug-only MemRegion %s 2>&1 | FileCheck %s
> +// RUN: %clang_analyze_cc1 -analyze -analyzer-checker=core -mllvm 
> -debug-only=MemRegion %s 2>&1 | FileCheck %s
>  // REQUIRES: asserts
>
>  int **h;

This test is still broken on ARM bots:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/38/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aregion_store_overflow.c

Thanks
Yvan

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

Re: r344199 - Add a flag to remap manglings when reading profile data information.

[Yvan Roux via cfe-commits]

Hi Richard,

This patch broke ARM bots which don't have x86_64 target available.
Logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/4326/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aprofile-remap.cpp

Cheers,
Yvan

On Thu, 11 Oct 2018 at 01:15, Richard Smith via cfe-commits
 wrote:
>
> Author: rsmith
> Date: Wed Oct 10 16:13:35 2018
> New Revision: 344199
>
> URL: http://llvm.org/viewvc/llvm-project?rev=344199&view=rev
> Log:
> Add a flag to remap manglings when reading profile data information.
>
> This can be used to preserve profiling information across codebase
> changes that have widespread impact on mangled names, but across which
> most profiling data should still be usable. For example, when switching
> from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
> or even from a 32-bit to a 64-bit build.
>
> The user can provide a remapping file specifying parts of mangled names
> that should be treated as equivalent (eg, std::__1 should be treated as
> equivalent to std::__cxx11), and profile data will be treated as
> applying to a particular function if its name is equivalent to the name
> of a function in the profile data under the provided equivalences. See
> the documentation change for a description of how this is configured.
>
> Remapping is supported for both sample-based profiling and instruction
> profiling. We do not support remapping indirect branch target
> information, but all other profile data should be remapped
> appropriately.
>
> Support is only added for the new pass manager. If someone wants to also
> add support for this for the old pass manager, doing so should be
> straightforward.
>
> Added:
> cfe/trunk/test/CodeGenCXX/Inputs/profile-remap.map
> cfe/trunk/test/CodeGenCXX/Inputs/profile-remap.proftext
> cfe/trunk/test/CodeGenCXX/Inputs/profile-remap.samples
> cfe/trunk/test/CodeGenCXX/profile-remap.cpp
> Modified:
> cfe/trunk/docs/ReleaseNotes.rst
> cfe/trunk/docs/UsersManual.rst
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/include/clang/Frontend/CodeGenOptions.h
> cfe/trunk/lib/CodeGen/BackendUtil.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/test/Driver/clang_f_opts.c
>
> Modified: cfe/trunk/docs/ReleaseNotes.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=344199&r1=344198&r2=344199&view=diff
> ==
> --- cfe/trunk/docs/ReleaseNotes.rst (original)
> +++ cfe/trunk/docs/ReleaseNotes.rst Wed Oct 10 16:13:35 2018
> @@ -46,6 +46,11 @@ sections with improvements to Clang's su
>  Major New Features
>  --
>
> +- Clang supports use of a profile remapping file, which permits
> +  profile data captured for one version of a program to be applied
> +  when building another version where symbols have changed (for
> +  example, due to renaming a class or namespace).
> +  See the :doc:`UsersManual` for details.
>
>  Improvements to Clang's diagnostics
>  ^^^
>
> Modified: cfe/trunk/docs/UsersManual.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=344199&r1=344198&r2=344199&view=diff
> ==
> --- cfe/trunk/docs/UsersManual.rst (original)
> +++ cfe/trunk/docs/UsersManual.rst Wed Oct 10 16:13:35 2018
> @@ -1799,6 +1799,69 @@ In these cases, you can use the flag ``-
>  Note that these flags should appear after the corresponding profile
>  flags to have an effect.
>
> +Profile remapping
> +^
> +
> +When the program is compiled after a change that affects many symbol names,
> +pre-existing profile data may no longer match the program. For example:
> +
> + * switching from libstdc++ to libc++ will result in the mangled names of all
> +   functions taking standard library types to change
> + * renaming a widely-used type in C++ will result in the mangled names of all
> +   functions that have parameters involving that type to change
> + * moving from a 32-bit compilation to a 64-bit compilation may change the
> +   underlying type of ``size_t`` and similar types, resulting in changes to
> +   manglings
> +
> +Clang allows use of a profile remapping file to specify that such differences
> +in mangled names should be ignored when matching the profile data against the
> +program.
> +
> +.. option:: -fprofile-remapping-file=
> +
> +  Specifies a file containing profile remapping information, that will be
> +  used to match mangled names in the profile data to mangled names in the
> +  program.
> +
> +The profile remapping file is a text file containing lines of the form
> +
> +.. code-block::
> +
> +  fragmentkind fragment1 fragment2
> +
> +where ``fragmentkind`` is one of ``name``, ``type``, or ``e

r344593 - Add target requirement to profile remap test.

[Yvan Roux via cfe-commits]

Author: yroux
Date: Tue Oct 16 01:47:36 2018
New Revision: 344593

URL: http://llvm.org/viewvc/llvm-project?rev=344593&view=rev
Log:
 Add target requirement to profile remap test.

 Fix bots which don't have x86_64 target built (ARM/AArch64).

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

Modified:
cfe/trunk/test/CodeGenCXX/profile-remap.cpp

Modified: cfe/trunk/test/CodeGenCXX/profile-remap.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/profile-remap.cpp?rev=344593&r1=344592&r2=344593&view=diff
==
--- cfe/trunk/test/CodeGenCXX/profile-remap.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/profile-remap.cpp Tue Oct 16 01:47:36 2018
@@ -1,3 +1,5 @@
+// REQUIRES: x86-registered-target
+//
 // RUN: %clang_cc1 -triple x86_64-linux-gnu 
-fprofile-sample-use=%S/Inputs/profile-remap.samples 
-fprofile-remapping-file=%S/Inputs/profile-remap.map 
-fexperimental-new-pass-manager -O2 %s -emit-llvm -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-SAMPLES
 // RUN: llvm-profdata merge -output %T.profdata 
%S/Inputs/profile-remap.proftext
 // RUN: %clang_cc1 -triple x86_64-linux-gnu 
-fprofile-instrument-use-path=%T.profdata 
-fprofile-remapping-file=%S/Inputs/profile-remap.map 
-fexperimental-new-pass-manager -O2 %s -emit-llvm -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-INSTR


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

Re: [PATCH] D52840: Include Python binding tests in CMake rules

[Yvan Roux via cfe-commits]

Hi Michal,

AArch64 bots are broken as well, logs are available at:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/15717/steps/ninja%20check%201/logs/stdio

Cheers,
Yvan
On Mon, 15 Oct 2018 at 20:39, Ulrich Weigand via Phabricator via
cfe-commits  wrote:
>
> uweigand added a comment.
>
> In https://reviews.llvm.org/D52840#1265615, @mgorny wrote:
>
> > The first one seems to indicate that your `libclang.so` is broken in 
> > release mode (optimization error?). The second one is correct (some of the 
> > tests test for errors, and apparently don't silence the messages).
>
>
> Ok, thanks for the clarification on the second point.
>
> As to the first issue, it turned out to be more complicated.  The wrong value 
> results from this call in CursorVisitor::Visit
>
>   switch (Visitor(Cursor, Parent, ClientData)) {
>
> This is a callback routine passed in from the caller, which in the case of 
> the Python bindings means that an FFI closure is being called.
>
> Now, due to a historical quirk in the FFI ABI, return values of integral type 
> smaller than the register word size must be passed as the special "ffi_arg" 
> type when using FFI (either for calls or for closures).  It seems the Python 
> 2.7 code that interfaces with FFI does not correctly respect this.  As a 
> result, it seems that when the closure returns a 32-bit value, it is not 
> properly extended and the high bits of the return register contain garbage.
>
> But that violates our ABI, which requires extension to full register size.   
> And it seems the clang code, when built with optimization, does indeed rely 
> on that ABI guarantee.
>
> So there's a bug in Python (or depending on how you want to look at it, in 
> libffi -- that part of the interface has also long been under-documented 
> unfortunately), which hits on our platform.  I'll see if I can do anything 
> about that, but for now we'll probably want to disable those tests on SystemZ.
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D52840
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r347675 - [clangd] textDocument/SymbolInfo extension

[Yvan Roux via cfe-commits]

On Wed, 28 Nov 2018 at 09:56, Mikael Holmén via cfe-commits
 wrote:
>
> Hi Jan,
>
> This code doesn't compile with clang 3.6.0:

And broke ARM bots, logs available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/5582/steps/build%20stage%201/logs/stdio

Cheers,
Yvan

> ../tools/clang/tools/extra/clangd/Protocol.cpp:456:10: error: no viable
> conversion from 'json::Object' to 'llvm::json::Value'
>return result;
>   ^~
> ../include/llvm/Support/JSON.h:291:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'const
> llvm::json::Value &' for 1st argument
>Value(const Value &M) { copyFrom(M); }
>^
> ../include/llvm/Support/JSON.h:292:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'llvm::json::Value
> &&' for 1st argument
>Value(Value &&M) { moveFrom(std::move(M)); }
>^
> ../include/llvm/Support/JSON.h:293:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to
> 'std::initializer_list' for 1st argument
>Value(std::initializer_list Elements);
>^
> ../include/llvm/Support/JSON.h:294:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'json::Array &&' for
> 1st argument
>Value(json::Array &&Elements) : Type(T_Array) {
>^
> ../include/llvm/Support/JSON.h:299:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'json::Object &&' for
> 1st argument
>Value(json::Object &&Properties) : Type(T_Object) {
>^
> ../include/llvm/Support/JSON.h:305:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'std::string' (aka
> 'basic_string') for 1st argument
>Value(std::string V) : Type(T_String) {
>^
> ../include/llvm/Support/JSON.h:312:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'const
> llvm::SmallVectorImpl &' for 1st argument
>Value(const llvm::SmallVectorImpl &V)
>^
> ../include/llvm/Support/JSON.h:314:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'const
> llvm::formatv_object_base &' for 1st argument
>Value(const llvm::formatv_object_base &V) : Value(V.str()){};
>^
> ../include/llvm/Support/JSON.h:316:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'llvm::StringRef' for
> 1st argument
>Value(StringRef V) : Type(T_StringRef) {
>^
> ../include/llvm/Support/JSON.h:323:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'const char *' for
> 1st argument
>Value(const char *V) : Value(StringRef(V)) {}
>^
> ../include/llvm/Support/JSON.h:324:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'std::nullptr_t' (aka
> 'nullptr_t') for 1st argument
>Value(std::nullptr_t) : Type(T_Null) {}
>^
> ../include/llvm/Support/JSON.h:298:3: note: candidate template ignored:
> could not match 'vector allocator >' against 'llvm::json::Object'
>Value(const std::vector &C) : Value(json::Array(C)) {}
>^
> ../include/llvm/Support/JSON.h:303:3: note: candidate template ignored:
> could not match 'map, type-parameter-0-0,
> std::less >, allocator std::basic_string, type-parameter-0-0> > >' against
> 'llvm::json::Object'
>Value(const std::map &C) : Value(json::Object(C)) {}
>^
> ../include/llvm/Support/JSON.h:329:42: note: candidate template ignored:
> disabled by 'enable_if' [with T = llvm::json::Object]
>typename = typename std::enable_if bool>::value>::type,
>   ^
> ../include/llvm/Support/JSON.h:337:42: note: candidate template ignored:
> disabled by 'enable_if' [with T = llvm::json::Object]
>typename = typename std::enable_if::value>::type,
>   ^
> ../include/llvm/Support/JSON.h:345:41: note: candidate template ignored:
> disabled by 'enable_if' [with T = llvm::json::Object]
>  typename
> std::enable_if::value>::type,
>  ^
> ../include/llvm/Support/JSON.h:355:3: note: candidate template ignored:
> substitution failure [with T = llvm::json::Object]: no matching function
> for call to 'toJSON'
>Value(const T &V) : Value(toJSON(V)) {}
>^
> 1 error generated.
>
> ---
>
> It looks very similar to a problem that was fixed in r347539:
>
> -  return Result;
> +  // Older gcc cannot compile 'return Result', even though it is legal.
> +  return json::Value(std::move(Result));
>
> Regards,
> Mikael
>
> On 11/27/18 5:40 PM, Jan Korous via cfe-commits wrote:
> > Author: jkorous
> > Date: Tue Nov 27 08:40:46 2018
> > New Revision: 347675
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=347675&view=rev
> > Log:
> > [clangd] textDocument/SymbolInfo extension
> >
> > New method returning symbol info for given source position.
> >
> > Differential Revision: h

Re: [clang-tools-extra] r347675 - [clangd] textDocument/SymbolInfo extension

[Yvan Roux via cfe-commits]

On Wed, 28 Nov 2018 at 11:16, Mikael Holmén  wrote:
>
>
>
> On 11/28/18 11:09 AM, Jan Korous wrote:
> > Thanks for the notice and sorry for the delay! I somehow missed the
> > failure mails before I went offline yesterday.
> >
> > I am just running tests on my fix now and hopefully pushing shortly.
> >
> > Since I didn’t know we are using old compilers for these builds I am now
> > curious why. Is that intentional? For backward-compatibility?
>
> I can't speak for the ARM bots, but I myself is doing my development on
> ubuntu 14.04 and there I get clang 3.6.0.

ARM bots are running inside Ubuntu 16.04.1 LTS containers in which
default clang version is 3.8

> And
>
> https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library
>
> suggests that even clang 3.1 should work.
>
> /Mikael
>
> >
> > Thanks.
> >
> > Jan
> >
> >> On Nov 28, 2018, at 8:59 AM, Yvan Roux  >> > wrote:
> >>
> >> On Wed, 28 Nov 2018 at 09:56, Mikael Holmén via cfe-commits
> >> mailto:cfe-commits@lists.llvm.org>> wrote:
> >>>
> >>> Hi Jan,
> >>>
> >>> This code doesn't compile with clang 3.6.0:
> >>
> >> And broke ARM bots, logs available here:
> >>
> >> http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/5582/steps/build%20stage%201/logs/stdio
> >>
> >> Cheers,
> >> Yvan
> >>
> >>> ../tools/clang/tools/extra/clangd/Protocol.cpp:456:10: error: no viable
> >>> conversion from 'json::Object' to 'llvm::json::Value'
> >>>   return result;
> >>>  ^~
> >>> ../include/llvm/Support/JSON.h:291:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'const
> >>> llvm::json::Value &' for 1st argument
> >>>   Value(const Value &M) { copyFrom(M); }
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:292:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'llvm::json::Value
> >>> &&' for 1st argument
> >>>   Value(Value &&M) { moveFrom(std::move(M)); }
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:293:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to
> >>> 'std::initializer_list' for 1st argument
> >>>   Value(std::initializer_list Elements);
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:294:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'json::Array &&' for
> >>> 1st argument
> >>>   Value(json::Array &&Elements) : Type(T_Array) {
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:299:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'json::Object &&' for
> >>> 1st argument
> >>>   Value(json::Object &&Properties) : Type(T_Object) {
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:305:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'std::string' (aka
> >>> 'basic_string') for 1st argument
> >>>   Value(std::string V) : Type(T_String) {
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:312:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'const
> >>> llvm::SmallVectorImpl &' for 1st argument
> >>>   Value(const llvm::SmallVectorImpl &V)
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:314:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'const
> >>> llvm::formatv_object_base &' for 1st argument
> >>>   Value(const llvm::formatv_object_base &V) : Value(V.str()){};
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:316:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'llvm::StringRef' for
> >>> 1st argument
> >>>   Value(StringRef V) : Type(T_StringRef) {
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:323:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'const char *' for
> >>> 1st argument
> >>>   Value(const char *V) : Value(StringRef(V)) {}
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:324:3: note: candidate constructor not
> >>> viable: no known conversion from 'json::Object' to 'std::nullptr_t' (aka
> >>> 'nullptr_t') for 1st argument
> >>>   Value(std::nullptr_t) : Type(T_Null) {}
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:298:3: note: candidate template ignored:
> >>> could not match 'vector >>> allocator >' against 'llvm::json::Object'
> >>>   Value(const std::vector &C) : Value(json::Array(C)) {}
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:303:3: note: candidate template ignored:
> >>> could not match 'map, type-parameter-0-0,
> >>> std::less >, allocator >>> std::basic_string, type-parameter-0-0> > >' against
> >>> 'llvm::json::Object'
> >>>   Value(const std::map &C) : Value(json::Object(C)) {}
> >>>   ^
> >>> ../include/llvm/Support/JSON.h:329:42: note: candidate template ignored:
> >>> disabled by 'enable_if' [with T = llvm::json::Object]
> >>>   typename = typename std::enable_if >>> bool>::value>::type,
> >>>   

Re: [clang-tools-extra] r347675 - [clangd] textDocument/SymbolInfo extension

[Yvan Roux via cfe-commits]

On Wed, 28 Nov 2018 at 12:28, Yvan Roux  wrote:
>
> On Wed, 28 Nov 2018 at 11:16, Mikael Holmén  
> wrote:
> >
> >
> >
> > On 11/28/18 11:09 AM, Jan Korous wrote:
> > > Thanks for the notice and sorry for the delay! I somehow missed the
> > > failure mails before I went offline yesterday.
> > >
> > > I am just running tests on my fix now and hopefully pushing shortly.
> > >
> > > Since I didn’t know we are using old compilers for these builds I am now
> > > curious why. Is that intentional? For backward-compatibility?
> >
> > I can't speak for the ARM bots, but I myself is doing my development on
> > ubuntu 14.04 and there I get clang 3.6.0.
>
> ARM bots are running inside Ubuntu 16.04.1 LTS containers in which
> default clang version is 3.8

Bots fixed BTW, Thanks :)

>
> > And
> >
> > https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library
> >
> > suggests that even clang 3.1 should work.
> >
> > /Mikael
> >
> > >
> > > Thanks.
> > >
> > > Jan
> > >
> > >> On Nov 28, 2018, at 8:59 AM, Yvan Roux  > >> > wrote:
> > >>
> > >> On Wed, 28 Nov 2018 at 09:56, Mikael Holmén via cfe-commits
> > >> mailto:cfe-commits@lists.llvm.org>> wrote:
> > >>>
> > >>> Hi Jan,
> > >>>
> > >>> This code doesn't compile with clang 3.6.0:
> > >>
> > >> And broke ARM bots, logs available here:
> > >>
> > >> http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/5582/steps/build%20stage%201/logs/stdio
> > >>
> > >> Cheers,
> > >> Yvan
> > >>
> > >>> ../tools/clang/tools/extra/clangd/Protocol.cpp:456:10: error: no viable
> > >>> conversion from 'json::Object' to 'llvm::json::Value'
> > >>>   return result;
> > >>>  ^~
> > >>> ../include/llvm/Support/JSON.h:291:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'const
> > >>> llvm::json::Value &' for 1st argument
> > >>>   Value(const Value &M) { copyFrom(M); }
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:292:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'llvm::json::Value
> > >>> &&' for 1st argument
> > >>>   Value(Value &&M) { moveFrom(std::move(M)); }
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:293:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to
> > >>> 'std::initializer_list' for 1st argument
> > >>>   Value(std::initializer_list Elements);
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:294:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'json::Array &&' for
> > >>> 1st argument
> > >>>   Value(json::Array &&Elements) : Type(T_Array) {
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:299:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'json::Object &&' for
> > >>> 1st argument
> > >>>   Value(json::Object &&Properties) : Type(T_Object) {
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:305:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'std::string' (aka
> > >>> 'basic_string') for 1st argument
> > >>>   Value(std::string V) : Type(T_String) {
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:312:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'const
> > >>> llvm::SmallVectorImpl &' for 1st argument
> > >>>   Value(const llvm::SmallVectorImpl &V)
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:314:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'const
> > >>> llvm::formatv_object_base &' for 1st argument
> > >>>   Value(const llvm::formatv_object_base &V) : Value(V.str()){};
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:316:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'llvm::StringRef' for
> > >>> 1st argument
> > >>>   Value(StringRef V) : Type(T_StringRef) {
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:323:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'const char *' for
> > >>> 1st argument
> > >>>   Value(const char *V) : Value(StringRef(V)) {}
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:324:3: note: candidate constructor not
> > >>> viable: no known conversion from 'json::Object' to 'std::nullptr_t' (aka
> > >>> 'nullptr_t') for 1st argument
> > >>>   Value(std::nullptr_t) : Type(T_Null) {}
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:298:3: note: candidate template ignored:
> > >>> could not match 'vector > >>> allocator >' against 'llvm::json::Object'
> > >>>   Value(const std::vector &C) : Value(json::Array(C)) {}
> > >>>   ^
> > >>> ../include/llvm/Support/JSON.h:303:3: note: candidate template ignored:
> > >>> could not match 'map, type-parameter-0-0,
> > >>> std::less >, allocator > >>> std::basic_string, type-parameter-0-0> > >' against
> > >>> 'llvm::json::Object'
> > >>>   V

Re: [PATCH] D51438: [clangd] Run SignatureHelp using an up-to-date preamble, waiting if needed.

[Yvan Roux via cfe-commits]

Hi Sam,

It took a very long time to identify it, but this commit broke ARMv7
bots, where this test hangs.  Logs are available here (initial ones
are too old):

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/3685/steps/ninja%20check%201/logs/stdiohttp://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/3685/steps/ninja%20check%201/logs/stdio

Thanks,
YvanOn Thu, 30 Aug 2018 at 17:15, Sam McCall via Phabricator via
cfe-commits  wrote:
>
> sammccall added inline comments.
>
>
> 
> Comment at: clangd/TUScheduler.cpp:474
> +llvm::unique_function)> 
> Callback) {
> +  if (RunSync)
> +return Callback(getPossiblyStalePreamble());
> 
> ilya-biryukov wrote:
> > It seems we could remove the special-casing of `RunSync` and still get 
> > correct results (the Requests queue is always empty).
> > But feel free to keep it for clarity.
> Right, of course :-)
> Replaced this with an assert before we write to the queue.
>
>
> 
> Comment at: clangd/TUScheduler.h:123
> +  /// Controls whether preamble reads wait for the preamble to be up-to-date.
> +  enum PreambleConsistency {
> +/// The preamble is generated from the current version of the file.
> 
> ilya-biryukov wrote:
> > Maybe use a strongly-typed enum outside the class?
> > `TUScheduler::Stale` will turn into `PreambleConsistency::Stale` at the 
> > call-site. The main upside is that it does not pollute completions inside 
> > the class with enumerators.
> >
> > Just a suggestion, feel free to ignore.
> Yeah, the downside to that is that it *does* pollute the clangd:: namespace. 
> So both are a bit sad.
>
> This header is fairly widely visible (since it's included by clangdserver) 
> and this API is fairly narrowly interesting, so as far as completion goes I 
> think I prefer it being hidden in TUScheduler.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D51438
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D51438: [clangd] Run SignatureHelp using an up-to-date preamble, waiting if needed.

[Yvan Roux via cfe-commits]

Seems that it was fixed earlier today.

Thanks,
Yvan

On Tue, 18 Sep 2018 at 19:31, Yvan Roux  wrote:
>
> Hi Sam,
>
> It took a very long time to identify it, but this commit broke ARMv7
> bots, where this test hangs.  Logs are available here (initial ones
> are too old):
>
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/3685/steps/ninja%20check%201/logs/stdiohttp://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/3685/steps/ninja%20check%201/logs/stdio
>
> Thanks,
> YvanOn Thu, 30 Aug 2018 at 17:15, Sam McCall via Phabricator via
> cfe-commits  wrote:
> >
> > sammccall added inline comments.
> >
> >
> > 
> > Comment at: clangd/TUScheduler.cpp:474
> > +llvm::unique_function)> 
> > Callback) {
> > +  if (RunSync)
> > +return Callback(getPossiblyStalePreamble());
> > 
> > ilya-biryukov wrote:
> > > It seems we could remove the special-casing of `RunSync` and still get 
> > > correct results (the Requests queue is always empty).
> > > But feel free to keep it for clarity.
> > Right, of course :-)
> > Replaced this with an assert before we write to the queue.
> >
> >
> > 
> > Comment at: clangd/TUScheduler.h:123
> > +  /// Controls whether preamble reads wait for the preamble to be 
> > up-to-date.
> > +  enum PreambleConsistency {
> > +/// The preamble is generated from the current version of the file.
> > 
> > ilya-biryukov wrote:
> > > Maybe use a strongly-typed enum outside the class?
> > > `TUScheduler::Stale` will turn into `PreambleConsistency::Stale` at the 
> > > call-site. The main upside is that it does not pollute completions inside 
> > > the class with enumerators.
> > >
> > > Just a suggestion, feel free to ignore.
> > Yeah, the downside to that is that it *does* pollute the clangd:: 
> > namespace. So both are a bit sad.
> >
> > This header is fairly widely visible (since it's included by clangdserver) 
> > and this API is fairly narrowly interesting, so as far as completion goes I 
> > think I prefer it being hidden in TUScheduler.
> >
> >
> > Repository:
> >   rL LLVM
> >
> > https://reviews.llvm.org/D51438
> >
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r367675 - [OpenCL] Allow OpenCL C style vector initialization in C++

[Yvan Roux via cfe-commits]

Hi Anastasia,

This commit broke ARMv8 bots, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/14655/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Avector_literals_valid.cl

Thanks,
Yvan

On Fri, 2 Aug 2019 at 13:18, Anastasia Stulova via cfe-commits
 wrote:
>
> Author: stulova
> Date: Fri Aug  2 04:19:35 2019
> New Revision: 367675
>
> URL: http://llvm.org/viewvc/llvm-project?rev=367675&view=rev
> Log:
> [OpenCL] Allow OpenCL C style vector initialization in C++
>
> Allow creating vector literals from other vectors.
>
>  float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
>  float4 v = (float4)(a.s23, a.s01);
>
> Differential revision: https://reviews.llvm.org/D65286
>
>
> Removed:
> cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
> cfe/trunk/test/SemaOpenCL/vector_literals_const.cl
> Modified:
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
> cfe/trunk/test/SemaCXX/vector.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaInit.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=367675&r1=367674&r2=367675&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaInit.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Aug  2 04:19:35 2019
> @@ -1289,7 +1289,16 @@ void InitListChecker::CheckSubElementTyp
>  // FIXME: Better EqualLoc?
>  InitializationKind Kind =
>  InitializationKind::CreateCopy(expr->getBeginLoc(), 
> SourceLocation());
> -InitializationSequence Seq(SemaRef, Entity, Kind, expr,
> +
> +// Vector elements can be initialized from other vectors in which case
> +// we need initialization entity with a type of a vector (and not a 
> vector
> +// element!) initializing multiple vector elements.
> +auto TmpEntity =
> +(ElemType->isExtVectorType() && !Entity.getType()->isExtVectorType())
> +? InitializedEntity::InitializeTemporary(ElemType)
> +: Entity;
> +
> +InitializationSequence Seq(SemaRef, TmpEntity, Kind, expr,
> /*TopLevelOfInitList*/ true);
>
>  // C++14 [dcl.init.aggr]p13:
> @@ -1300,8 +1309,7 @@ void InitListChecker::CheckSubElementTyp
>  // assignment-expression.
>  if (Seq || isa(expr)) {
>if (!VerifyOnly) {
> -ExprResult Result =
> -  Seq.Perform(SemaRef, Entity, Kind, expr);
> +ExprResult Result = Seq.Perform(SemaRef, TmpEntity, Kind, expr);
>  if (Result.isInvalid())
>hadError = true;
>
>
> Removed: cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl?rev=367674&view=auto
> ==
> --- cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl (original)
> +++ cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl (removed)
> @@ -1,23 +0,0 @@
> -// RUN: %clang_cc1 %s -emit-llvm -O3 -o - | FileCheck %s
> -
> -typedef int int2 __attribute((ext_vector_type(2)));
> -typedef int int4 __attribute((ext_vector_type(4)));
> -
> -__constant const int4 itest1 = (int4)(1, 2, ((int2)(3, 4)));
> -// CHECK: constant <4 x i32> 
> -__constant const int4 itest2 = (int4)(1, 2, ((int2)(3)));
> -// CHECK: constant <4 x i32> 
> -
> -typedef float float2 __attribute((ext_vector_type(2)));
> -typedef float float4 __attribute((ext_vector_type(4)));
> -
> -void ftest1(float4 *p) {
> -  *p = (float4)(1.1f, 1.2f, ((float2)(1.3f, 1.4f)));
> -// CHECK: store <4 x float>  0x3FF34000, float 0x3FF4C000, float 0x3FF66000>
> -}
> -
> -float4 ftest2(float4 *p) {
> -   *p =  (float4)(1.1f, 1.2f, ((float2)(1.3f)));
> -// CHECK: store <4 x float>  0x3FF34000, float 0x3FF4C000, float 0x3FF4C000>
> -}
> -
>
> Modified: cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl?rev=367675&r1=367674&r2=367675&view=diff
> ==
> --- cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl (original)
> +++ cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl Fri Aug  2 04:19:35 
> 2019
> @@ -1,22 +1,65 @@
> -// RUN: %clang_cc1 -emit-llvm %s -o %t
> +// RUN: %clang_cc1 -emit-llvm %s -o - -O0 | FileCheck %s
> +// RUN: %clang_cc1 -emit-llvm %s -o - -cl-std=clc++ -O0 | FileCheck %s
>
> -typedef __attribute__(( ext_vector_type(2) ))  int int2;
> -typedef __attribute__(( ext_vector_type(3) ))  int int3;
> -typedef __attribute__(( ext_vector_type(4) ))  int int4;
> -typedef __attribute__(( ext_vector_type(8) ))  int int8;
> -typedef __attribute__(( ext_vector_type(4) ))  float float4;
> +typedef __attribute__((ext_vector_type(2))) int int2;
> +typedef __attribute__((ext_vector_type(3))) int int3

Re: r367675 - [OpenCL] Allow OpenCL C style vector initialization in C++

[Yvan Roux via cfe-commits]

On Mon, 5 Aug 2019 at 13:16, Anastasia Stulova
 wrote:
>
> Hi Yvan,
>
>
> Sorry for this, it should now be fixed  in r367823.

Issue fixed, Thanks Anastasia

>
> Thanks,
>
> Anastasia
>
>
>
> 
> From: Yvan Roux 
> Sent: 02 August 2019 14:09
> To: Anastasia Stulova 
> Cc: cfe-commits 
> Subject: Re: r367675 - [OpenCL] Allow OpenCL C style vector initialization in 
> C++
>
> Hi Anastasia,
>
> This commit broke ARMv8 bots, logs are available here:
>
> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/14655/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Avector_literals_valid.cl
>
> Thanks,
> Yvan
>
> On Fri, 2 Aug 2019 at 13:18, Anastasia Stulova via cfe-commits
>  wrote:
> >
> > Author: stulova
> > Date: Fri Aug  2 04:19:35 2019
> > New Revision: 367675
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=367675&view=rev
> > Log:
> > [OpenCL] Allow OpenCL C style vector initialization in C++
> >
> > Allow creating vector literals from other vectors.
> >
> >  float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
> >  float4 v = (float4)(a.s23, a.s01);
> >
> > Differential revision: https://reviews.llvm.org/D65286
> >
> >
> > Removed:
> > cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
> > cfe/trunk/test/SemaOpenCL/vector_literals_const.cl
> > Modified:
> > cfe/trunk/lib/Sema/SemaInit.cpp
> > cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
> > cfe/trunk/test/SemaCXX/vector.cpp
> >
> > Modified: cfe/trunk/lib/Sema/SemaInit.cpp
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=367675&r1=367674&r2=367675&view=diff
> > ==
> > --- cfe/trunk/lib/Sema/SemaInit.cpp (original)
> > +++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Aug  2 04:19:35 2019
> > @@ -1289,7 +1289,16 @@ void InitListChecker::CheckSubElementTyp
> >  // FIXME: Better EqualLoc?
> >  InitializationKind Kind =
> >  InitializationKind::CreateCopy(expr->getBeginLoc(), 
> > SourceLocation());
> > -InitializationSequence Seq(SemaRef, Entity, Kind, expr,
> > +
> > +// Vector elements can be initialized from other vectors in which case
> > +// we need initialization entity with a type of a vector (and not a 
> > vector
> > +// element!) initializing multiple vector elements.
> > +auto TmpEntity =
> > +(ElemType->isExtVectorType() && 
> > !Entity.getType()->isExtVectorType())
> > +? InitializedEntity::InitializeTemporary(ElemType)
> > +: Entity;
> > +
> > +InitializationSequence Seq(SemaRef, TmpEntity, Kind, expr,
> > /*TopLevelOfInitList*/ true);
> >
> >  // C++14 [dcl.init.aggr]p13:
> > @@ -1300,8 +1309,7 @@ void InitListChecker::CheckSubElementTyp
> >  // assignment-expression.
> >  if (Seq || isa(expr)) {
> >if (!VerifyOnly) {
> > -ExprResult Result =
> > -  Seq.Perform(SemaRef, Entity, Kind, expr);
> > +ExprResult Result = Seq.Perform(SemaRef, TmpEntity, Kind, expr);
> >  if (Result.isInvalid())
> >hadError = true;
> >
> >
> > Removed: cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl?rev=367674&view=auto
> > ==
> > --- cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl (original)
> > +++ cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl (removed)
> > @@ -1,23 +0,0 @@
> > -// RUN: %clang_cc1 %s -emit-llvm -O3 -o - | FileCheck %s
> > -
> > -typedef int int2 __attribute((ext_vector_type(2)));
> > -typedef int int4 __attribute((ext_vector_type(4)));
> > -
> > -__constant const int4 itest1 = (int4)(1, 2, ((int2)(3, 4)));
> > -// CHECK: constant <4 x i32> 
> > -__constant const int4 itest2 = (int4)(1, 2, ((int2)(3)));
> > -// CHECK: constant <4 x i32> 
> > -
> > -typedef float float2 __attribute((ext_vector_type(2)));
> > -typedef float float4 __attribute((ext_vector_type(4)));
> > -
> > -void ftest1(float4 *p) {
> > -  *p = (float4)(1.1f, 1.2f, ((float2)(1.3f, 1.4f)));
> > -// CHECK: store <4 x float>  > 0x3FF34000, float 0x3FF4C000, float 0x3FF66000>
> > -}
> > -
> > -float4 ftest2(float4 *p) {
> > -   *p =  (float4)(1.1f, 1.2f, ((float2)(1.3f)));
> > -// CHECK: store <4 x float>  > 0x3FF34000, float 0x3FF4C000, float 0x3FF4C000>
> > -}
> > -
> >
> > Modified: cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl?rev=367675&r1=367674&r2=367675&view=diff
> > ==
> > --- cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl (original)
> > +++ cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl Fri Aug  2 

Re: [PATCH] D63451: P0840R2: support for [[no_unique_address]] attribute

[Yvan Roux via cfe-commits]

Hi Richard,

This commit broke ARM bots, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/13576/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Atail-padding.cpp

Thanks,
Yvan

On Thu, 20 Jun 2019 at 23:06, John McCall via Phabricator via
llvm-commits  wrote:
>
> rjmccall added a comment.
>
> In D63451#1552609 , @rsmith wrote:
>
> > In D63451#1549563 , @rjmccall 
> > wrote:
> >
> > > Can this attribute not be applied to a base class, or to a type?
> >
> >
> > The standard attribute forbids that right now. We could add a custom 
> > attribute that permits it, but we're required to diagnose application of 
> > the standard attribute to a type -- though a warning would suffice to 
> > satisfy that requirement. (Because this gives "same as a base class" 
> > layout, adding it to a base class wouldn't have any effect right now, but 
> > we could certainly say that the attribute on a class type also implies the 
> > class is not POD for the purpose of layout, to permit tail padding reuse.)
>
>
> I think we're talking about slightly different things.
>
> You're trying to make sure that fields can take advantage of the layout 
> optimizations available to base classes so that library code doesn't need to 
> contort to e.g. use the empty-base-class optimization just to avoid wasting 
> an entire pointer to store an empty allocator.  This attribute seems 
> well-targeted for that.
>
> Totally separately from that — but perhaps better-related to the name of the 
> attribute — I know that some projects have, in the past, had surprising 
> problems with the rule that class layout can't place empty base classes at 
> the same offset as other objects of the same type.  For example, IIRC WebKit 
> used to have a `Noncopyable` class that deleted its copy constructor and 
> copy-assignment operators, and there was an idiom to inherit from this in 
> order to disable copying, and at one point they discovered that some fairly 
> important class was quite a bit larger than expected because of this rule — I 
> think they were also using the base class redundantly throughout the 
> hierarchy because they didn't expect there to be any harm to doing so.  They 
> would've no doubt appreciated the ability to just put the attribute on 
> `Noncopyable`.  But of course they fixed that years ago, so I can't say that 
> it's a serious issue for them now.
>
>
> Repository:
>   rL LLVM
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D63451/new/
>
> https://reviews.llvm.org/D63451
>
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D63451: P0840R2: support for [[no_unique_address]] attribute

[Yvan Roux via cfe-commits]

On Fri, 21 Jun 2019 at 19:38, Richard Smith  wrote:
>
> Thanks, should hopefully be fixed by r364081.

Problem fixed, Thanks richard.

> On Fri, 21 Jun 2019 at 01:12, Yvan Roux via cfe-commits 
>  wrote:
>>
>> Hi Richard,
>>
>> This commit broke ARM bots, logs are available here:
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/13576/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Atail-padding.cpp
>>
>> Thanks,
>> Yvan
>>
>> On Thu, 20 Jun 2019 at 23:06, John McCall via Phabricator via
>> llvm-commits  wrote:
>> >
>> > rjmccall added a comment.
>> >
>> > In D63451#1552609 <https://reviews.llvm.org/D63451#1552609>, @rsmith wrote:
>> >
>> > > In D63451#1549563 <https://reviews.llvm.org/D63451#1549563>, @rjmccall 
>> > > wrote:
>> > >
>> > > > Can this attribute not be applied to a base class, or to a type?
>> > >
>> > >
>> > > The standard attribute forbids that right now. We could add a custom 
>> > > attribute that permits it, but we're required to diagnose application of 
>> > > the standard attribute to a type -- though a warning would suffice to 
>> > > satisfy that requirement. (Because this gives "same as a base class" 
>> > > layout, adding it to a base class wouldn't have any effect right now, 
>> > > but we could certainly say that the attribute on a class type also 
>> > > implies the class is not POD for the purpose of layout, to permit tail 
>> > > padding reuse.)
>> >
>> >
>> > I think we're talking about slightly different things.
>> >
>> > You're trying to make sure that fields can take advantage of the layout 
>> > optimizations available to base classes so that library code doesn't need 
>> > to contort to e.g. use the empty-base-class optimization just to avoid 
>> > wasting an entire pointer to store an empty allocator.  This attribute 
>> > seems well-targeted for that.
>> >
>> > Totally separately from that — but perhaps better-related to the name of 
>> > the attribute — I know that some projects have, in the past, had 
>> > surprising problems with the rule that class layout can't place empty base 
>> > classes at the same offset as other objects of the same type.  For 
>> > example, IIRC WebKit used to have a `Noncopyable` class that deleted its 
>> > copy constructor and copy-assignment operators, and there was an idiom to 
>> > inherit from this in order to disable copying, and at one point they 
>> > discovered that some fairly important class was quite a bit larger than 
>> > expected because of this rule — I think they were also using the base 
>> > class redundantly throughout the hierarchy because they didn't expect 
>> > there to be any harm to doing so.  They would've no doubt appreciated the 
>> > ability to just put the attribute on `Noncopyable`.  But of course they 
>> > fixed that years ago, so I can't say that it's a serious issue for them 
>> > now.
>> >
>> >
>> > Repository:
>> >   rL LLVM
>> >
>> > CHANGES SINCE LAST ACTION
>> >   https://reviews.llvm.org/D63451/new/
>> >
>> > https://reviews.llvm.org/D63451
>> >
>> >
>> >
>> > ___
>> > llvm-commits mailing list
>> > llvm-comm...@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r364080 - [OPENMP]Fix PR42068: Vla type is not captured.

[Yvan Roux via cfe-commits]

Hi Alexey,

This commit broke ARM bots, logs are availabale here:

http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/13627/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aparallel_codegen.cpp

Thanks,
Yvan

On Fri, 21 Jun 2019 at 19:25, Alexey Bataev via cfe-commits
 wrote:
>
> Author: abataev
> Date: Fri Jun 21 10:28:41 2019
> New Revision: 364080
>
> URL: http://llvm.org/viewvc/llvm-project?rev=364080&view=rev
> Log:
> [OPENMP]Fix PR42068: Vla type is not captured.
>
> If the variably modified type is declared outside of the captured region
> and then used in the cast expression along with array subscript
> expression, the type is not captured and it leads to the compiler crash.
>
> Modified:
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/test/OpenMP/parallel_codegen.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=364080&r1=364079&r2=364080&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Fri Jun 21 10:28:41 2019
> @@ -4737,6 +4737,33 @@ Sema::CreateBuiltinArraySubscriptExpr(Ex
>assert(VK == VK_RValue || LangOpts.CPlusPlus ||
>   !ResultType.isCForbiddenLValueType());
>
> +  if (LHSExp->IgnoreParenImpCasts()->getType()->isVariablyModifiedType() &&
> +  FunctionScopes.size() > 1) {
> +if (auto *TT =
> +LHSExp->IgnoreParenImpCasts()->getType()->getAs()) {
> +  for (auto I = FunctionScopes.rbegin(),
> +E = std::prev(FunctionScopes.rend());
> +   I != E; ++I) {
> +auto *CSI = dyn_cast(*I);
> +if (CSI == nullptr)
> +  break;
> +DeclContext *DC = nullptr;
> +if (auto *LSI = dyn_cast(CSI))
> +  DC = LSI->CallOperator;
> +else if (auto *CRSI = dyn_cast(CSI))
> +  DC = CRSI->TheCapturedDecl;
> +else if (auto *BSI = dyn_cast(CSI))
> +  DC = BSI->TheDecl;
> +if (DC) {
> +  if (DC->containsDecl(TT->getDecl()))
> +break;
> +  captureVariablyModifiedType(
> +  Context, LHSExp->IgnoreParenImpCasts()->getType(), CSI);
> +}
> +  }
> +}
> +  }
> +
>return new (Context)
>ArraySubscriptExpr(LHSExp, RHSExp, ResultType, VK, OK, RLoc);
>  }
>
> Modified: cfe/trunk/test/OpenMP/parallel_codegen.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_codegen.cpp?rev=364080&r1=364079&r2=364080&view=diff
> ==
> --- cfe/trunk/test/OpenMP/parallel_codegen.cpp (original)
> +++ cfe/trunk/test/OpenMP/parallel_codegen.cpp Fri Jun 21 10:28:41 2019
> @@ -15,16 +15,20 @@
>  // CHECK-DEBUG-DAG: %struct.ident_t = type { i32, i32, i32, i32, i8* }
>  // CHECK-DEBUG-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x i8] 
> c";unknown;unknown;0;0;;\00"
>  // CHECK-DEBUG-DAG: [[DEF_LOC_2:@.+]] = private unnamed_addr global 
> %struct.ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 
> x i8], [23 x i8]* [[STR]], i32 0, i32 0) }
> -// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}} x 
> i8] c";{{.*}}parallel_codegen.cpp;main;[[@LINE+15]];1;;\00"
> -// CHECK-DEBUG-DAG: [[LOC2:@.+]] = private unnamed_addr constant [{{.+}} x 
> i8] c";{{.*}}parallel_codegen.cpp;tmain;[[@LINE+7]];1;;\00"
> +// CHECK-DEBUG-DAG: [[LOC1:@.+]] = private unnamed_addr constant [{{.+}} x 
> i8] c";{{.*}}parallel_codegen.cpp;main;[[@LINE+19]];1;;\00"
> +// CHECK-DEBUG-DAG: [[LOC2:@.+]] = private unnamed_addr constant [{{.+}} x 
> i8] c";{{.*}}parallel_codegen.cpp;tmain;[[@LINE+8]];1;;\00"
>
>  template 
>  void foo(T argc) {}
>
>  template 
>  int tmain(T argc) {
> +  typedef double (*chunk_t)[argc[0][0]];
>  #pragma omp parallel
> +  {
>foo(argc);
> +  chunk_t var;(void)var[0][0];
> +  }
>return 0;
>  }
>
> @@ -90,7 +94,7 @@ int main (int argc, char **argv) {
>
>  // CHECK:   define linkonce_odr {{[a-z\_\b]*[ ]?i32}} [[TMAIN]](i8** 
> %argc)
>  // CHECK:   store i8** %argc, i8*** [[ARGC_ADDR:%.+]],
> -// CHECK-NEXT:  call {{.*}}void (%struct.ident_t*, i32, void (i32*, i32*, 
> ...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[DEF_LOC_2]], i32 1, void 
> (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***)* [[OMP_OUTLINED:@.+]] to 
> void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]])
> +// CHECK:   call {{.*}}void (%struct.ident_t*, i32, void (i32*, i32*, 
> ...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[DEF_LOC_2]], i32 2, void 
> (i32*, i32*, ...)* bitcast (void (i32*, i32*, i8***, i64)* 
> [[OMP_OUTLINED:@.+]] to void (i32*, i32*, ...)*), i8*** [[ARGC_ADDR]], i64 
> %{{.+}})
>  // CHECK-NEXT:  ret i32 0
>  // CHECK-NEXT:  }
>  // CHECK-DEBUG:   define linkonce_odr i32 [[TMAIN]](i8** %argc)
> @@ -101,23 +105,23 @@ int main (int argc, char **argv) {
>  // CHECK-DEBUG

Re: r349063 - [CodeComplete] Adhere to LLVM naming style in CodeCompletionTest. NFC

[Yvan Roux via cfe-commits]

Hi Ilya,

I'm not sure which one of the commits in that series is to blame, but
ARM bots are broken due to a failure in CodeCompleteTest.cpp, most
recent logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/6090/steps/ninja%20check%201/logs/FAIL%3A%20Clang-Unit%3A%3APreferredTypeTest.BinaryExpr

Cheers,
Yvan

On Thu, 13 Dec 2018 at 18:35, Ilya Biryukov via cfe-commits
 wrote:
>
> Author: ibiryukov
> Date: Thu Dec 13 09:32:38 2018
> New Revision: 349063
>
> URL: http://llvm.org/viewvc/llvm-project?rev=349063&view=rev
> Log:
> [CodeComplete] Adhere to LLVM naming style in CodeCompletionTest. NFC
>
> Also reuses the same var for multiple to reduce the chance of
> accidentally referecing the previous test.
>
> Modified:
> cfe/trunk/unittests/Sema/CodeCompleteTest.cpp
>
> Modified: cfe/trunk/unittests/Sema/CodeCompleteTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Sema/CodeCompleteTest.cpp?rev=349063&r1=349062&r2=349063&view=diff
> ==
> --- cfe/trunk/unittests/Sema/CodeCompleteTest.cpp (original)
> +++ cfe/trunk/unittests/Sema/CodeCompleteTest.cpp Thu Dec 13 09:32:38 2018
> @@ -183,79 +183,80 @@ TEST(SemaCodeCompleteTest, VisitedNSWith
>
>  TEST(PreferredTypeTest, BinaryExpr) {
>// Check various operations for arithmetic types.
> -  StringRef code1 = R"cpp(
> +  StringRef Code = R"cpp(
>  void test(int x) {
>x = ^10;
>x += ^10; x -= ^10; x *= ^10; x /= ^10; x %= ^10;
>x + ^10; x - ^10; x * ^10; x / ^10; x % ^10;
>  })cpp";
> -  EXPECT_THAT(collectPreferredTypes(code1), Each("int"));
> -  StringRef code2 = R"cpp(
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("int"));
> +
> +  Code = R"cpp(
>  void test(float x) {
>x = ^10;
>x += ^10; x -= ^10; x *= ^10; x /= ^10; x %= ^10;
>x + ^10; x - ^10; x * ^10; x / ^10; x % ^10;
>  })cpp";
> -  EXPECT_THAT(collectPreferredTypes(code2), Each("float"));
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("float"));
>
>// Pointer types.
> -  StringRef code3 = R"cpp(
> +  Code = R"cpp(
>  void test(int *ptr) {
>ptr - ^ptr;
>ptr = ^ptr;
>  })cpp";
> -  EXPECT_THAT(collectPreferredTypes(code3), Each("int *"));
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("int *"));
>
> -  StringRef code4 = R"cpp(
> +  Code = R"cpp(
>  void test(int *ptr) {
>ptr + ^10;
>ptr += ^10;
>ptr -= ^10;
>  })cpp";
> -  EXPECT_THAT(collectPreferredTypes(code4), Each("long")); // long is 
> normalized 'ptrdiff_t'.
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("long")); // long is 
> normalized 'ptrdiff_t'.
>
>// Comparison operators.
> -  StringRef code5 = R"cpp(
> +  Code = R"cpp(
>  void test(int i) {
>i <= ^1; i < ^1; i >= ^1; i > ^1; i == ^1; i != ^1;
>  }
>)cpp";
> -  EXPECT_THAT(collectPreferredTypes(code5), Each("int"));
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("int"));
>
> -  StringRef code6 = R"cpp(
> +  Code = R"cpp(
>  void test(int *ptr) {
>ptr <= ^ptr; ptr < ^ptr; ptr >= ^ptr; ptr > ^ptr;
>ptr == ^ptr; ptr != ^ptr;
>  }
>)cpp";
> -  EXPECT_THAT(collectPreferredTypes(code6), Each("int *"));
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("int *"));
>
>// Relational operations.
> -  StringRef code7 = R"cpp(
> +  Code = R"cpp(
>  void test(int i, int *ptr) {
>i && ^1; i || ^1;
>ptr && ^1; ptr || ^1;
>  }
>)cpp";
> -  EXPECT_THAT(collectPreferredTypes(code7), Each("_Bool"));
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("_Bool"));
>
>// Bitwise operations.
> -  StringRef code8 = R"cpp(
> +  Code = R"cpp(
>  void test(long long ll) {
>ll | ^1; ll & ^1;
>  }
>)cpp";
> -  EXPECT_THAT(collectPreferredTypes(code8), Each("long long"));
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("long long"));
>
> -  StringRef code9 = R"cpp(
> +  Code = R"cpp(
>  enum A {};
>  void test(A a) {
>a | ^1; a & ^1;
>  }
>)cpp";
> -  EXPECT_THAT(collectPreferredTypes(code9), Each("enum A"));
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("enum A"));
>
> -  StringRef code10 = R"cpp(
> +  Code = R"cpp(
>  enum class A {};
>  void test(A a) {
>// This is technically illegal with the 'enum class' without overloaded
> @@ -263,10 +264,10 @@ TEST(PreferredTypeTest, BinaryExpr) {
>a | ^a; a & ^a;
>  }
>)cpp";
> -  EXPECT_THAT(collectPreferredTypes(code10), Each("enum A"));
> +  EXPECT_THAT(collectPreferredTypes(Code), Each("enum A"));
>
>// Binary shifts.
> -  StringRef code11 = R"cpp(
> +  Code = R"cpp(
>  void test(int i, long long ll) {
>i << ^1; ll << ^1;
>i <<= ^1; i <<= ^1;
> @@ -274,10 +275,10 @@ TEST(PreferredTypeTest, BinaryExpr) {
>i >>= ^1; i >>= ^1;
>  }
>)cpp";
> -  EXPECT_THAT(collectPreferredTypes(code11), E

Re: r349063 - [CodeComplete] Adhere to LLVM naming style in CodeCompletionTest. NFC

[Yvan Roux via cfe-commits]

On Mon, 17 Dec 2018 at 18:34, Ilya Biryukov  wrote:
>
> Hi Yvan, sorry for the inconvenience.
>
> I believe this is the same as https://llvm.org/PR40033, should be fixed by 
> r349362 (the build hasn't finished yet).
> I'll double check it's fixed tomorrow and make sure to take another look if 
> not.

Thanks Ilya, bots are all green :)

> On Mon, Dec 17, 2018 at 10:46 AM Yvan Roux  wrote:
>>
>> Hi Ilya,
>>
>> I'm not sure which one of the commits in that series is to blame, but
>> ARM bots are broken due to a failure in CodeCompleteTest.cpp, most
>> recent logs are available here:
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/6090/steps/ninja%20check%201/logs/FAIL%3A%20Clang-Unit%3A%3APreferredTypeTest.BinaryExpr
>>
>> Cheers,
>> Yvan
>>
>> On Thu, 13 Dec 2018 at 18:35, Ilya Biryukov via cfe-commits
>>  wrote:
>> >
>> > Author: ibiryukov
>> > Date: Thu Dec 13 09:32:38 2018
>> > New Revision: 349063
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=349063&view=rev
>> > Log:
>> > [CodeComplete] Adhere to LLVM naming style in CodeCompletionTest. NFC
>> >
>> > Also reuses the same var for multiple to reduce the chance of
>> > accidentally referecing the previous test.
>> >
>> > Modified:
>> > cfe/trunk/unittests/Sema/CodeCompleteTest.cpp
>> >
>> > Modified: cfe/trunk/unittests/Sema/CodeCompleteTest.cpp
>> > URL: 
>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Sema/CodeCompleteTest.cpp?rev=349063&r1=349062&r2=349063&view=diff
>> > ==
>> > --- cfe/trunk/unittests/Sema/CodeCompleteTest.cpp (original)
>> > +++ cfe/trunk/unittests/Sema/CodeCompleteTest.cpp Thu Dec 13 09:32:38 2018
>> > @@ -183,79 +183,80 @@ TEST(SemaCodeCompleteTest, VisitedNSWith
>> >
>> >  TEST(PreferredTypeTest, BinaryExpr) {
>> >// Check various operations for arithmetic types.
>> > -  StringRef code1 = R"cpp(
>> > +  StringRef Code = R"cpp(
>> >  void test(int x) {
>> >x = ^10;
>> >x += ^10; x -= ^10; x *= ^10; x /= ^10; x %= ^10;
>> >x + ^10; x - ^10; x * ^10; x / ^10; x % ^10;
>> >  })cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code1), Each("int"));
>> > -  StringRef code2 = R"cpp(
>> > +  EXPECT_THAT(collectPreferredTypes(Code), Each("int"));
>> > +
>> > +  Code = R"cpp(
>> >  void test(float x) {
>> >x = ^10;
>> >x += ^10; x -= ^10; x *= ^10; x /= ^10; x %= ^10;
>> >x + ^10; x - ^10; x * ^10; x / ^10; x % ^10;
>> >  })cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code2), Each("float"));
>> > +  EXPECT_THAT(collectPreferredTypes(Code), Each("float"));
>> >
>> >// Pointer types.
>> > -  StringRef code3 = R"cpp(
>> > +  Code = R"cpp(
>> >  void test(int *ptr) {
>> >ptr - ^ptr;
>> >ptr = ^ptr;
>> >  })cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code3), Each("int *"));
>> > +  EXPECT_THAT(collectPreferredTypes(Code), Each("int *"));
>> >
>> > -  StringRef code4 = R"cpp(
>> > +  Code = R"cpp(
>> >  void test(int *ptr) {
>> >ptr + ^10;
>> >ptr += ^10;
>> >ptr -= ^10;
>> >  })cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code4), Each("long")); // long is 
>> > normalized 'ptrdiff_t'.
>> > +  EXPECT_THAT(collectPreferredTypes(Code), Each("long")); // long is 
>> > normalized 'ptrdiff_t'.
>> >
>> >// Comparison operators.
>> > -  StringRef code5 = R"cpp(
>> > +  Code = R"cpp(
>> >  void test(int i) {
>> >i <= ^1; i < ^1; i >= ^1; i > ^1; i == ^1; i != ^1;
>> >  }
>> >)cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code5), Each("int"));
>> > +  EXPECT_THAT(collectPreferredTypes(Code), Each("int"));
>> >
>> > -  StringRef code6 = R"cpp(
>> > +  Code = R"cpp(
>> >  void test(int *ptr) {
>> >ptr <= ^ptr; ptr < ^ptr; ptr >= ^ptr; ptr > ^ptr;
>> >ptr == ^ptr; ptr != ^ptr;
>> >  }
>> >)cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code6), Each("int *"));
>> > +  EXPECT_THAT(collectPreferredTypes(Code), Each("int *"));
>> >
>> >// Relational operations.
>> > -  StringRef code7 = R"cpp(
>> > +  Code = R"cpp(
>> >  void test(int i, int *ptr) {
>> >i && ^1; i || ^1;
>> >ptr && ^1; ptr || ^1;
>> >  }
>> >)cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code7), Each("_Bool"));
>> > +  EXPECT_THAT(collectPreferredTypes(Code), Each("_Bool"));
>> >
>> >// Bitwise operations.
>> > -  StringRef code8 = R"cpp(
>> > +  Code = R"cpp(
>> >  void test(long long ll) {
>> >ll | ^1; ll & ^1;
>> >  }
>> >)cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code8), Each("long long"));
>> > +  EXPECT_THAT(collectPreferredTypes(Code), Each("long long"));
>> >
>> > -  StringRef code9 = R"cpp(
>> > +  Code = R"cpp(
>> >  enum A {};
>> >  void test(A a) {
>> >a | ^1; a & ^1;
>> >  }
>> >)cpp";
>> > -  EXPECT_THAT(collectPreferredTypes(code9), Each("enum A"));
>> > +  EXPECT_THAT(collectPreferr

Re: r371605 - [Diagnostics] Add -Wsizeof-array-div

[Yvan Roux via cfe-commits]

Hi David,

This commit broken ARMv7 bots, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/10203/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Adiv-sizeof-array.cpp

Thanks,
Yvan



On Wed, 11 Sep 2019 at 12:58, David Bolvansky via cfe-commits
 wrote:
>
> Author: xbolva00
> Date: Wed Sep 11 03:59:47 2019
> New Revision: 371605
>
> URL: http://llvm.org/viewvc/llvm-project?rev=371605&view=rev
> Log:
> [Diagnostics] Add -Wsizeof-array-div
>
> Summary: Clang version of https://www.viva64.com/en/examples/v706/
>
> Reviewers: rsmith
>
> Differential Revision: https://reviews.llvm.org/D67287
>
> Added:
> cfe/trunk/test/Sema/div-sizeof-array.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/Sema/SemaExpr.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=371605&r1=371604&r2=371605&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Wed Sep 11 03:59:47 
> 2019
> @@ -3406,6 +3406,10 @@ def note_pointer_declared_here : Note<
>  def warn_division_sizeof_ptr : Warning<
>"'%0' will return the size of the pointer, not the array itself">,
>InGroup>;
> +def warn_division_sizeof_array : Warning<
> +  "expression does not compute the number of elements in this array; element 
> "
> +  "type is %0, not %1">,
> +  InGroup>;
>
>  def note_function_warning_silence : Note<
>  "prefix with the address-of operator to silence this warning">;
>
> Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=371605&r1=371604&r2=371605&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExpr.cpp Wed Sep 11 03:59:47 2019
> @@ -9158,17 +9158,28 @@ static void DiagnoseDivisionSizeofPointe
>else
>  RHSTy = RUE->getArgumentExpr()->IgnoreParens()->getType();
>
> -  if (!LHSTy->isPointerType() || RHSTy->isPointerType())
> -return;
> -  if (LHSTy->getPointeeType().getCanonicalType().getUnqualifiedType() !=
> -  RHSTy.getCanonicalType().getUnqualifiedType())
> -return;
> +  if (LHSTy->isPointerType() && !RHSTy->isPointerType()) {
> +if (!S.Context.hasSameUnqualifiedType(LHSTy->getPointeeType(), RHSTy))
> +  return;
>
> -  S.Diag(Loc, diag::warn_division_sizeof_ptr) << LHS << 
> LHS->getSourceRange();
> -  if (const auto *DRE = dyn_cast(LHSArg)) {
> -if (const ValueDecl *LHSArgDecl = DRE->getDecl())
> -  S.Diag(LHSArgDecl->getLocation(), diag::note_pointer_declared_here)
> -  << LHSArgDecl;
> +S.Diag(Loc, diag::warn_division_sizeof_ptr) << LHS << 
> LHS->getSourceRange();
> +if (const auto *DRE = dyn_cast(LHSArg)) {
> +  if (const ValueDecl *LHSArgDecl = DRE->getDecl())
> +S.Diag(LHSArgDecl->getLocation(), diag::note_pointer_declared_here)
> +<< LHSArgDecl;
> +}
> +  } else if (const auto *ArrayTy = S.Context.getAsArrayType(LHSTy)) {
> +QualType ArrayElemTy = ArrayTy->getElementType();
> +if (ArrayElemTy->isDependentType() || RHSTy->isDependentType() ||
> +S.Context.getTypeSize(ArrayElemTy) == S.Context.getTypeSize(RHSTy))
> +  return;
> +S.Diag(Loc, diag::warn_division_sizeof_array)
> +<< LHSArg->getSourceRange() << ArrayElemTy << RHSTy;
> +if (const auto *DRE = dyn_cast(LHSArg)) {
> +  if (const ValueDecl *LHSArgDecl = DRE->getDecl())
> +S.Diag(LHSArgDecl->getLocation(), diag::note_array_declared_here)
> +<< LHSArgDecl;
> +}
>}
>  }
>
>
> Added: cfe/trunk/test/Sema/div-sizeof-array.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/div-sizeof-array.cpp?rev=371605&view=auto
> ==
> --- cfe/trunk/test/Sema/div-sizeof-array.cpp (added)
> +++ cfe/trunk/test/Sema/div-sizeof-array.cpp Wed Sep 11 03:59:47 2019
> @@ -0,0 +1,28 @@
> +// RUN: %clang_cc1 %s -verify -Wsizeof-array-div -fsyntax-only
> +
> +template 
> +int f(Ty (&Array)[N]) {
> +  return sizeof(Array) / sizeof(Ty); // Should not warn
> +}
> +
> +typedef int int32;
> +
> +void test(void) {
> +  int arr[12];// expected-note 2 {{array 'arr' declared 
> here}}
> +  unsigned long long arr2[4];
> +  int *p = &arr[0];
> +  int a1 = sizeof(arr) / sizeof(*arr);
> +  int a2 = sizeof arr / sizeof p; // expected-warning {{expression does not 
> compute the number of elements in this array; element type is 'int', not 'int 
> *'}}
> +  int a4 = sizeof arr2 / sizeof p;
> +  int a5 = sizeof(arr) / sizeof(short); // expected-warning {{expression 
> does not compute the number of elements 

[clang] 0e4827a - [ARM][MachineOutliner] Add Machine Outliner support for ARM.

[Yvan Roux via cfe-commits]

Author: Yvan Roux
Date: 2020-05-15T08:44:23+02:00
New Revision: 0e4827aa4e4ae25813f66d3b872db67d93813009

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

LOG: [ARM][MachineOutliner] Add Machine Outliner support for ARM.

Enables Machine Outlining for ARM and Thumb2 modes.  This is the first
patch of the series which adds all the basic logic for the support, and
only handles tail-calls and thunks.

The outliner can be turned on by using clang -moutline option or -mllvm
-enable-machine-outliner one (like AArch64).

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

Added: 
llvm/test/CodeGen/ARM/machine-outliner-tail.ll
llvm/test/CodeGen/ARM/machine-outliner-thunk.ll
llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir

Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
llvm/lib/Target/ARM/ARMBaseInstrInfo.h
llvm/lib/Target/ARM/ARMTargetMachine.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index cd85f9a62986..deb60ed68cfc 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -6149,11 +6149,12 @@ void Clang::ConstructJob(Compilation &C, const 
JobAction &JA,
   if (Arg *A = Args.getLastArg(options::OPT_moutline,
options::OPT_mno_outline)) {
 if (A->getOption().matches(options::OPT_moutline)) {
-  // We only support -moutline in AArch64 right now. If we're not compiling
-  // for AArch64, emit a warning and ignore the flag. Otherwise, add the
-  // proper mllvm flags.
-  if (Triple.getArch() != llvm::Triple::aarch64 &&
-  Triple.getArch() != llvm::Triple::aarch64_32) {
+  // We only support -moutline in AArch64 and ARM targets right now. If
+  // we're not compiling for these, emit a warning and ignore the flag.
+  // Otherwise, add the proper mllvm flags.
+  if (!(Triple.isARM() || Triple.isThumb() ||
+Triple.getArch() == llvm::Triple::aarch64 ||
+Triple.getArch() == llvm::Triple::aarch64_32)) {
 D.Diag(diag::warn_drv_moutline_unsupported_opt) << 
Triple.getArchName();
   } else {
 CmdArgs.push_back("-mllvm");

diff  --git a/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp 
b/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
index cee1de474bbb..c160843fcdba 100644
--- a/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
+++ b/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
@@ -32,6 +32,7 @@
 #include "llvm/CodeGen/MachineInstr.h"
 #include "llvm/CodeGen/MachineInstrBuilder.h"
 #include "llvm/CodeGen/MachineMemOperand.h"
+#include "llvm/CodeGen/MachineModuleInfo.h"
 #include "llvm/CodeGen/MachineOperand.h"
 #include "llvm/CodeGen/MachineRegisterInfo.h"
 #include "llvm/CodeGen/ScoreboardHazardRecognizer.h"
@@ -5517,3 +5518,372 @@ bool llvm::HasLowerConstantMaterializationCost(unsigned 
Val1, unsigned Val2,
   return ConstantMaterializationCost(Val1, Subtarget, !ForCodesize) <
  ConstantMaterializationCost(Val2, Subtarget, !ForCodesize);
 }
+
+/// Constants defining how certain sequences should be outlined.
+/// This encompasses how an outlined function should be called, and what kind 
of
+/// frame should be emitted for that outlined function.
+///
+/// \p MachineOutlinerTailCall implies that the function is being created from
+/// a sequence of instructions ending in a return.
+///
+/// That is,
+///
+/// I1OUTLINED_FUNCTION:
+/// I2--> B OUTLINED_FUNCTION I1
+/// BX LR I2
+///   BX LR
+///
+/// +-++-+
+/// | | Thumb2 | ARM |
+/// +-++-+
+/// | Call overhead in Bytes  |  4 |   4 |
+/// | Frame overhead in Bytes |  0 |   0 |
+/// | Stack fixup required| No |  No |
+/// +-++-+
+///
+/// \p MachineOutlinerThunk implies that the function is being created from
+/// a sequence of instructions ending in a call. The outlined function is
+/// called with a BL instruction, and the outlined function tail-calls the
+/// original call destination.
+///
+/// That is,
+///
+/// I1OUTLINED_FUNCTION:
+/// I2   --> BL OUTLINED_FUNCTION I1
+/// BL f  I2
+///   B f
+///
+/// +-++-+
+/// | | Thumb2 | ARM |
+/// +-++-+
+/// | Call overhead in Bytes  |  4 |   4 |
+/// | Frame overhead in Bytes |  0 |   0 |
+/// | Stack fixup required   

Re: r371182 - Reland [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

[Yvan Roux via cfe-commits]

Hi Matthias,

this commit broke AArch64 bots, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/19917/steps/ninja%20check%201/logs/stdio

Thanks,
Yvan

On Fri, 6 Sep 2019 at 10:54, Matthias Gehre via cfe-commits
 wrote:
>
> Author: mgehre
> Date: Fri Sep  6 01:56:30 2019
> New Revision: 371182
>
> URL: http://llvm.org/viewvc/llvm-project?rev=371182&view=rev
> Log:
> Reland [LifetimeAnalysis] Support more STL idioms (template forward 
> declaration and DependentNameType)
>
> Reland after https://reviews.llvm.org/D66806 fixed the false-positive 
> diagnostics.
>
> Summary:
> This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ 
> (the typedef for iterator
> on the template is a DependentNameType - we can only put the gsl::Pointer 
> attribute
> on the underlaying record after instantiation)
>
> inference of gsl::Pointer on std::vector::iterator with libc++ (the class was 
> forward-declared,
> we added the gsl::Pointer on the canonical decl (the forward decl), and later 
> when the
> template was instantiated, there was no attribute on the definition so it was 
> not instantiated).
>
> and a duplicate gsl::Pointer on some class with libstdc++ (we first added an 
> attribute to
> a incomplete instantiation, and then another was copied from the template 
> definition
> when the instantiation was completed).
>
> We now add the attributes to all redeclarations to fix thos issues and make 
> their usage easier.
>
> Reviewers: gribozavr
>
> Subscribers: Szelethus, xazax.hun, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D66179
>
> Added:
> cfe/trunk/unittests/Sema/GslOwnerPointerInference.cpp
> Modified:
> cfe/trunk/lib/Sema/SemaAttr.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
> cfe/trunk/test/SemaCXX/attr-gsl-owner-pointer.cpp
> cfe/trunk/unittests/Sema/CMakeLists.txt
>
> Modified: cfe/trunk/lib/Sema/SemaAttr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaAttr.cpp?rev=371182&r1=371181&r2=371182&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaAttr.cpp Fri Sep  6 01:56:30 2019
> @@ -88,13 +88,11 @@ void Sema::AddMsStructLayoutForRecord(Re
>  template 
>  static void addGslOwnerPointerAttributeIfNotExisting(ASTContext &Context,
>   CXXRecordDecl *Record) {
> -  CXXRecordDecl *Canonical = Record->getCanonicalDecl();
> -  if (Canonical->hasAttr() || Canonical->hasAttr())
> +  if (Record->hasAttr() || Record->hasAttr())
>  return;
>
> -  Canonical->addAttr(::new (Context) Attribute(SourceRange{}, Context,
> -   /*DerefType*/ nullptr,
> -   /*Spelling=*/0));
> +  for (Decl *Redecl : Record->redecls())
> +Redecl->addAttr(Attribute::CreateImplicit(Context, 
> /*DerefType=*/nullptr));
>  }
>
>  void Sema::inferGslPointerAttribute(NamedDecl *ND,
> @@ -189,8 +187,7 @@ void Sema::inferGslOwnerPointerAttribute
>
>// Handle classes that directly appear in std namespace.
>if (Record->isInStdNamespace()) {
> -CXXRecordDecl *Canonical = Record->getCanonicalDecl();
> -if (Canonical->hasAttr() || Canonical->hasAttr())
> +if (Record->hasAttr() || Record->hasAttr())
>return;
>
>  if (StdOwners.count(Record->getName()))
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=371182&r1=371181&r2=371182&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Fri Sep  6 01:56:30 2019
> @@ -4592,9 +4592,11 @@ static void handleLifetimeCategoryAttr(S
>}
>return;
>  }
> -D->addAttr(::new (S.Context)
> -   OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
> - AL.getAttributeSpellingListIndex()));
> +for (Decl *Redecl : D->redecls()) {
> +  Redecl->addAttr(::new (S.Context)
> +  OwnerAttr(AL.getRange(), S.Context, DerefTypeLoc,
> +AL.getAttributeSpellingListIndex()));
> +}
>} else {
>  if (checkAttrMutualExclusion(S, D, AL))
>return;
> @@ -4609,9 +4611,11 @@ static void handleLifetimeCategoryAttr(S
>}
>return;
>  }
> -D->addAttr(::new (S.Context)
> -   PointerAttr(AL.getRange(), S.Context, DerefTypeLoc,
> -   AL.getAttributeSpellingListIndex()));
> +for (Decl *Redecl : D->redecls()) {
> +  Redecl->addAttr(::new (S.Context)

Re: [PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

[Yvan Roux via cfe-commits]

Hi Louis,

ARM and AArch64 libcxx bots are still broken after this commit (host
compiler is clang-8), logs are available here:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/3143

Cheers,
Yvan

On Mon, 28 Sep 2020 at 23:44, Louis Dionne via Phabricator via
cfe-commits  wrote:
>
> ldionne added a comment.
>
> In D68364#2294569 , @jwakely wrote:
>
> > In D68364#2293971 , @leonardchan 
> > wrote:
> >
> >> Is there a recommended way for working around this? We're using GCC 
> >> 10.2.1. Thanks.
> >
> > I don't think your implementation is valid. I think P0784 only allows 
> > new-expressions and calls to `std::allocator::allocate` in constexpr 
> > functions, not calls to `operator new`.
>
> Hmm, right. It's actually impossible to implement `__libcpp_allocate` in a 
> constexpr-friendly manner, since it's just allocating bytes.
>
> > Can you use something like `if (__builtin_is_constant_evaluated()) return 
> > new unsigned char[n];` and the equivalent in the corresponding deallocation 
> > function?
>
> That doesn't work, since we can't use `unsigned char`s as storage for 
> arbitrary `T`s in `constexpr`.
>
> I fixed it by marking `__libcpp_allocate` as non-`constexpr` and calling 
> `operator new` in `allocator::allocate`, which seems to work on GCC.
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D68364/new/
>
> https://reviews.llvm.org/D68364
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D69876: Support output constraints on "asm goto"

[Yvan Roux via cfe-commits]

Hi Bill,

This commit broke AArch64 bots, logs are available here:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/22291/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Auninit-asm-goto.cpp

Thanks
Yvan

On Tue, 25 Feb 2020 at 04:01, Bill Wendling via Phabricator via
llvm-commits  wrote:
>
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rG50cac248773c: Support output constraints on "asm 
> goto" (authored by void).
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D69876/new/
>
> https://reviews.llvm.org/D69876
>
> Files:
>   clang/docs/LanguageExtensions.rst
>   clang/include/clang/AST/Stmt.h
>   clang/include/clang/Basic/Features.def
>   clang/lib/AST/Stmt.cpp
>   clang/lib/Analysis/UninitializedValues.cpp
>   clang/lib/CodeGen/CGStmt.cpp
>   clang/lib/Parse/ParseStmtAsm.cpp
>   clang/lib/Sema/SemaStmtAsm.cpp
>   clang/test/Analysis/uninit-asm-goto.cpp
>   clang/test/CodeGen/asm-goto.c
>   clang/test/Parser/asm-goto.c
>   clang/test/Parser/asm-goto.cpp
>   clang/test/Sema/asm-goto.cpp
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D71186: Reland "[AST] Traverse the class type loc inside the member type loc.""

[Yvan Roux via cfe-commits]

Hi Haojian,

AArch64 bots are broken after this commit, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/21125/steps/ninja%20check%201/logs/stdio

Thanks
Yvan

On Mon, 9 Dec 2019 at 11:30, pre-merge checks [bot] via Phabricator
via cfe-commits  wrote:
>
> merge_guards_bot added a comment.
>
> Build result: pass - 60555 tests passed, 0 failed and 726 were skipped.
>
> Log files: console-log.txt 
> ,
>  CMakeCache.txt 
> 
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D71186/new/
>
> https://reviews.llvm.org/D71186
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] bc24014 - [c++20] Implement P1185R2 (as modified by P2002R0).

[Yvan Roux via cfe-commits]

Hi Richard,

ARM bots are broken after this commit, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/12109/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Acxx2a-three-way-comparison.cpp

Thanks,
Yvan

On Wed, 11 Dec 2019 at 02:24, Richard Smith via cfe-commits
 wrote:
>
>
> Author: Richard Smith
> Date: 2019-12-10T17:24:27-08:00
> New Revision: bc24014b9765a454cb5214f4871451a41ffb7d29
>
> URL: 
> https://github.com/llvm/llvm-project/commit/bc24014b9765a454cb5214f4871451a41ffb7d29
> DIFF: 
> https://github.com/llvm/llvm-project/commit/bc24014b9765a454cb5214f4871451a41ffb7d29.diff
>
> LOG: [c++20] Implement P1185R2 (as modified by P2002R0).
>
> For each defaulted operator<=> in a class that doesn't explicitly
> declare any operator==, also inject a matching implicit defaulted
> operator==.
>
> Added:
> clang/test/CXX/class/class.compare/class.compare.default/p4.cpp
>
> Modified:
> clang/include/clang/Basic/DiagnosticSemaKinds.td
> clang/include/clang/Sema/Sema.h
> clang/include/clang/Sema/Template.h
> clang/lib/Frontend/FrontendActions.cpp
> clang/lib/Sema/SemaDeclCXX.cpp
> clang/lib/Sema/SemaOverload.cpp
> clang/lib/Sema/SemaTemplateInstantiate.cpp
> clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
> clang/test/CodeGenCXX/cxx2a-three-way-comparison.cpp
>
> Removed:
>
>
>
> 
> diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
> b/clang/include/clang/Basic/DiagnosticSemaKinds.td
> index aeeff2b9a76e..a5f35996cfdc 100644
> --- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
> +++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
> @@ -3840,6 +3840,7 @@ def select_ovl_candidate_kind : TextSubstitution<
>  "constructor (the implicit move constructor)|"
>  "function (the implicit copy assignment operator)|"
>  "function (the implicit move assignment operator)|"
> +"function (the implicit 'operator==' for this 'operator<=>)'|"
>  "inherited constructor}0%select{| template| %2}1">;
>
>  def note_ovl_candidate : Note<
> @@ -8207,7 +8208,8 @@ def warn_defaulted_comparison_deleted : Warning<
>"explicitly defaulted %sub{select_defaulted_comparison_kind}0 is 
> implicitly "
>"deleted">, InGroup;
>  def err_non_first_default_compare_deletes : Error<
> -  "defaulting this %sub{select_defaulted_comparison_kind}0 "
> +  "defaulting %select{this %sub{select_defaulted_comparison_kind}1|"
> +  "the corresponding implicit 'operator==' for this defaulted 
> 'operator<=>'}0 "
>"would delete it after its first declaration">;
>  def note_defaulted_comparison_union : Note<
>"defaulted %0 is implicitly deleted because "
> @@ -8237,14 +8239,19 @@ def note_defaulted_comparison_cannot_deduce : Note<
>  def note_defaulted_comparison_cannot_deduce_callee : Note<
>"selected 'operator<=>' for %select{|member|base class}0 %1 declared 
> here">;
>  def err_incorrect_defaulted_comparison_constexpr : Error<
> -  "defaulted definition of %sub{select_defaulted_comparison_kind}0 "
> -  "cannot be declared %select{constexpr|consteval}1 because it invokes "
> -  "a non-constexpr comparison function">;
> +  "defaulted definition of %select{%sub{select_defaulted_comparison_kind}1|"
> +  "three-way comparison operator}0 "
> +  "cannot be declared %select{constexpr|consteval}2 because "
> +  "%select{it|the corresponding implicit 'operator=='}0 "
> +  "invokes a non-constexpr comparison function">;
>  def note_defaulted_comparison_not_constexpr : Note<
>"non-constexpr comparison function would be used to compare "
>"%select{|member %1|base class %1}0">;
>  def note_defaulted_comparison_not_constexpr_here : Note<
>"non-constexpr comparison function declared here">;
> +def note_in_declaration_of_implicit_equality_comparison : Note<
> +  "while declaring the corresponding implicit 'operator==' "
> +  "for this defaulted 'operator<=>'">;
>
>  def ext_implicit_exception_spec_mismatch : ExtWarn<
>"function previously declared with an %select{explicit|implicit}0 
> exception "
>
> diff  --git a/clang/include/clang/Sema/Sema.h 
> b/clang/include/clang/Sema/Sema.h
> index 1cdaab3dc28c..5a1ee507218c 100644
> --- a/clang/include/clang/Sema/Sema.h
> +++ b/clang/include/clang/Sema/Sema.h
> @@ -6524,6 +6524,8 @@ class Sema final {
>
>bool CheckExplicitlyDefaultedComparison(Scope *S, FunctionDecl *MD,
>DefaultedComparisonKind DCK);
> +  void DeclareImplicitEqualityComparison(CXXRecordDecl *RD,
> + FunctionDecl *Spaceship);
>void DefineDefaultedComparison(SourceLocation Loc, FunctionDecl *FD,
>   DefaultedComparisonKind DCK);
>
> @@ -7838,6 +7840,10 @@ class Sema final {
>/// We are declaring an implicit special member function.
>DeclaringSpecialMember,
>
> +  /// We are declaring an implicit 'op

Re: [PATCH] D71186: Reland "[AST] Traverse the class type loc inside the member type loc.""

[Yvan Roux via cfe-commits]

On Tue, 10 Dec 2019 at 10:24, Ilya Biryukov  wrote:
>
> Ah, some older gcc versions can't handle raw string literals inside macro 
> arguments.
> +Haojian Wu, could you fix this?

When do you plan to fix this, bots are now broken for a while... (I
don't have my SVN/Github access in place to revert or fix it myself)

> On Tue, Dec 10, 2019 at 12:22 PM Yvan Roux  wrote:
>>
>> Hi Haojian,
>>
>> AArch64 bots are broken after this commit, logs are available here:
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/21125/steps/ninja%20check%201/logs/stdio
>>
>> Thanks
>> Yvan
>>
>> On Mon, 9 Dec 2019 at 11:30, pre-merge checks [bot] via Phabricator
>> via cfe-commits  wrote:
>> >
>> > merge_guards_bot added a comment.
>> >
>> > Build result: pass - 60555 tests passed, 0 failed and 726 were skipped.
>> >
>> > Log files: console-log.txt 
>> > ,
>> >  CMakeCache.txt 
>> > 
>> >
>> >
>> > Repository:
>> >   rG LLVM Github Monorepo
>> >
>> > CHANGES SINCE LAST ACTION
>> >   https://reviews.llvm.org/D71186/new/
>> >
>> > https://reviews.llvm.org/D71186
>> >
>> >
>> >
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
> --
> Regards,
> Ilya Biryukov
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D71186: Reland "[AST] Traverse the class type loc inside the member type loc.""

[Yvan Roux via cfe-commits]

On Thu, 12 Dec 2019 at 10:54, Ilya Biryukov  wrote:
>
> Should be fixed in 7d7789899f4.

Thanks a lot Ilya

> On Thu, Dec 12, 2019 at 12:50 PM Ilya Biryukov  wrote:
>>
>> Will fix right away, sorry for the delay.
>>
>> On Thu, Dec 12, 2019 at 12:42 PM Yvan Roux  wrote:
>>>
>>> On Tue, 10 Dec 2019 at 10:24, Ilya Biryukov  wrote:
>>> >
>>> > Ah, some older gcc versions can't handle raw string literals inside macro 
>>> > arguments.
>>> > +Haojian Wu, could you fix this?
>>>
>>> When do you plan to fix this, bots are now broken for a while... (I
>>> don't have my SVN/Github access in place to revert or fix it myself)
>>>
>>> > On Tue, Dec 10, 2019 at 12:22 PM Yvan Roux  wrote:
>>> >>
>>> >> Hi Haojian,
>>> >>
>>> >> AArch64 bots are broken after this commit, logs are available here:
>>> >>
>>> >> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/21125/steps/ninja%20check%201/logs/stdio
>>> >>
>>> >> Thanks
>>> >> Yvan
>>> >>
>>> >> On Mon, 9 Dec 2019 at 11:30, pre-merge checks [bot] via Phabricator
>>> >> via cfe-commits  wrote:
>>> >> >
>>> >> > merge_guards_bot added a comment.
>>> >> >
>>> >> > Build result: pass - 60555 tests passed, 0 failed and 726 were skipped.
>>> >> >
>>> >> > Log files: console-log.txt 
>>> >> > ,
>>> >> >  CMakeCache.txt 
>>> >> > 
>>> >> >
>>> >> >
>>> >> > Repository:
>>> >> >   rG LLVM Github Monorepo
>>> >> >
>>> >> > CHANGES SINCE LAST ACTION
>>> >> >   https://reviews.llvm.org/D71186/new/
>>> >> >
>>> >> > https://reviews.llvm.org/D71186
>>> >> >
>>> >> >
>>> >> >
>>> >> > ___
>>> >> > cfe-commits mailing list
>>> >> > cfe-commits@lists.llvm.org
>>> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>> >
>>> >
>>> >
>>> > --
>>> > Regards,
>>> > Ilya Biryukov
>>
>>
>>
>> --
>> Regards,
>> Ilya Biryukov
>
>
>
> --
> Regards,
> Ilya Biryukov
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D71414: [clangd] Introduce codeblocks

[Yvan Roux via cfe-commits]

Hi, it is still broken on AArch64 bots, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/21251/steps/ninja%20check%201/logs/stdio

Thanks,
Yvan

On Sat, 14 Dec 2019 at 16:15, Nico Weber via Phabricator via
cfe-commits  wrote:
>
> thakis added inline comments.
>
>
> 
> Comment at: clang-tools-extra/clangd/unittests/FormattedStringTests.cpp:126
> +test
> +```
> +bar)md");
> 
> Older (but still supported) gccs can't handle multiline raw strings in macro 
> arguments, see e.g. 
> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/21230/steps/ninja%20check%201/logs/stdio
>
> I fixed this for you in 687e98d294c4f77e. It's been broken for 3 days, please 
> watch bots and your inbox after committing.
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D71414/new/
>
> https://reviews.llvm.org/D71414
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D71414: [clangd] Introduce codeblocks

[Yvan Roux via cfe-commits]

Thanks Kadir, bots are back to green :)

On Mon, 16 Dec 2019 at 09:18, Kadir Çetinkaya  wrote:
>
> sent out 0f959c87cc7867beb67bfab2d5e3cf90708b2f98
>
> On Mon, Dec 16, 2019 at 9:08 AM Yvan Roux  wrote:
>>
>> Hi, it is still broken on AArch64 bots, logs are available here:
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/21251/steps/ninja%20check%201/logs/stdio
>>
>> Thanks,
>> Yvan
>>
>> On Sat, 14 Dec 2019 at 16:15, Nico Weber via Phabricator via
>> cfe-commits  wrote:
>> >
>> > thakis added inline comments.
>> >
>> >
>> > 
>> > Comment at: clang-tools-extra/clangd/unittests/FormattedStringTests.cpp:126
>> > +test
>> > +```
>> > +bar)md");
>> > 
>> > Older (but still supported) gccs can't handle multiline raw strings in 
>> > macro arguments, see e.g. 
>> > http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/21230/steps/ninja%20check%201/logs/stdio
>> >
>> > I fixed this for you in 687e98d294c4f77e. It's been broken for 3 days, 
>> > please watch bots and your inbox after committing.
>> >
>> >
>> > Repository:
>> >   rG LLVM Github Monorepo
>> >
>> > CHANGES SINCE LAST ACTION
>> >   https://reviews.llvm.org/D71414/new/
>> >
>> > https://reviews.llvm.org/D71414
>> >
>> >
>> >
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D44691: [CUDA] Disable LTO for device-side compilations.

[Yvan Roux via cfe-commits]

Hi Artem,

On 21 March 2018 at 23:25, Artem Belevich via Phabricator via
cfe-commits  wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL328161: [CUDA] Disable LTO for device-side compilations. 
> (authored by tra, committed by ).
> Herald added a subscriber: llvm-commits.
>
> Changed prior to commit:
>   https://reviews.llvm.org/D44691?vs=139151&id=139381#toc
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D44691
>
> Files:
>   cfe/trunk/include/clang/Driver/Driver.h
>   cfe/trunk/lib/Driver/Driver.cpp
>   cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>   cfe/trunk/test/Driver/lto.cu
>   cfe/trunk/test/Driver/thinlto.cu

This patch broke ARM/AArch64 bots, see:
http://lab.llvm.org:8011/builders/clang-cmake-armv8-full/builds/841/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Athinlto.cu

Thanks
Yvan

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

Re: [PATCH] D42157: [clang-cl] Let /FA output use intel assembly.

[Yvan Roux via cfe-commits]

Hi Nico,

On 17 January 2018 at 14:35, Nico Weber via Phabricator via
cfe-commits  wrote:
> thakis closed this revision.
> thakis added a comment.
>
> r322652, thanks!

This commit broke ARM bots:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/14839

Cheers,
Yvan

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

Re: [PATCH] D42157: [clang-cl] Let /FA output use intel assembly.

[Yvan Roux via cfe-commits]

On 17 January 2018 at 17:05, Nico Weber  wrote:
> r322674 attempts to fix.

Fixed on ARM bots. Thanks

> On Wed, Jan 17, 2018 at 10:54 AM, Yvan Roux via cfe-commits
>  wrote:
>>
>> Hi Nico,
>>
>> On 17 January 2018 at 14:35, Nico Weber via Phabricator via
>> cfe-commits  wrote:
>> > thakis closed this revision.
>> > thakis added a comment.
>> >
>> > r322652, thanks!
>>
>> This commit broke ARM bots:
>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/14839
>>
>> Cheers,
>> Yvan
>>
>> >
>> > https://reviews.llvm.org/D42157
>> >
>> >
>> >
>> > ___
>> > cfe-commits mailing list
>> > cfe-commits@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D41271: [RISCV] Propagate -mabi and -march values to GNU assembler.

[Yvan Roux via cfe-commits]

Hi Ana

On 17 January 2018 at 23:14, Ana Pazos via Phabricator via cfe-commits
 wrote:
> apazos added a comment.
>
> Committed R32276

This commit broke ARM/AArch64 buildbots. riscv-gnutools.c test fails
on these boxes.

logs are available here:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/3932/steps/ninja%20check%202/logs/FAIL%3A%20Clang%3A%3Ariscv-gnutools.c

Cheers,
Yvan

>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D41271
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D97785: [SystemZ][z/OS] Distinguish between text and binary files on z/OS

[Yvan Roux via cfe-commits]

I Abhina,

I think this patch broke Windows on ARM bots, the first failure observed 6
days ago in this build:

https://lab.llvm.org/buildbot/#/builders/65/builds/1245

I don't really get what the problem is, but the issue is related to
tablegen generated file AbstractTypeReader.inc and your patch is the only
one in the set which is touching that area.

Does it ring a bell for you ?

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

Re: [PATCH] D97785: [SystemZ][z/OS] Distinguish between text and binary files on z/OS

[Yvan Roux via cfe-commits]

On Thu, 25 Mar 2021 at 18:13, Abhina Sree via Phabricator <
revi...@reviews.llvm.org> wrote:

> abhina.sreeskantharajan added a comment.
>
> In D97785#2650824 , @yroux wrote:
>
> > Hi Abhina,
> >
> > I think this patch broke Windows on ARM bots, the first failure observed
> 6
> > days ago in this build:
> >
> > https://lab.llvm.org/buildbot/#/builders/65/builds/1245
> >
> > I don't really get what the problem is, but the issue is related to
> > tablegen generated file AbstractTypeReader.inc and your patch is the only
> > one in the set which is touching that area.
> >
> > Does it ring a bell for you ?
> >
> > Cheers,
> > Yvan
>
> Hi, thanks for bringing this to my attention. Since only Windows seems to
> have this error, it may be caused by my patch. I suspect that setting
> OF_None flag/Binary mode for Windows in getFile() should fix it if that is
> the case. I'll work on a patch to hopefully fix the issue.
>

Ok, great thanks.


>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D97785/new/
>
> https://reviews.llvm.org/D97785
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 0c41b1c - [Driver][MachineOutliner] Support outlining option with LTO

[Yvan Roux via cfe-commits]

Author: Yvan Roux
Date: 2021-01-06T16:01:38+01:00
New Revision: 0c41b1c9f93c09966b87126820d3cf41d8eebbf9

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

LOG: [Driver][MachineOutliner] Support outlining option with LTO

This patch propagates the -moutline flag when LTO is enabled and avoids
passing it explicitly to the linker plugin.

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

Added: 
clang/test/Driver/arm-machine-outliner.c

Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/CommonArgs.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index f8b9bf25373e..917601836c0a 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -6396,26 +6396,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
 options::OPT_fno_cxx_static_destructors, true))
 CmdArgs.push_back("-fno-c++-static-destructors");
 
-  if (Arg *A = Args.getLastArg(options::OPT_moutline,
-   options::OPT_mno_outline)) {
-if (A->getOption().matches(options::OPT_moutline)) {
-  // We only support -moutline in AArch64 and ARM targets right now. If
-  // we're not compiling for these, emit a warning and ignore the flag.
-  // Otherwise, add the proper mllvm flags.
-  if (!(Triple.isARM() || Triple.isThumb() ||
-Triple.getArch() == llvm::Triple::aarch64 ||
-Triple.getArch() == llvm::Triple::aarch64_32)) {
-D.Diag(diag::warn_drv_moutline_unsupported_opt) << 
Triple.getArchName();
-  } else {
-CmdArgs.push_back("-mllvm");
-CmdArgs.push_back("-enable-machine-outliner");
-  }
-} else {
-  // Disable all outlining behaviour.
-  CmdArgs.push_back("-mllvm");
-  CmdArgs.push_back("-enable-machine-outliner=never");
-}
-  }
+  addMachineOutlinerArgs(D, Args, CmdArgs, Triple, /*IsLTO=*/false);
 
   if (Arg *A = Args.getLastArg(options::OPT_moutline_atomics,
options::OPT_mno_outline_atomics)) {

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index fe5e7536d380..6a95aa5ec628 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -624,6 +624,9 @@ void tools::addLTOOptions(const ToolChain &ToolChain, const 
ArgList &Args,
 
   // Handle remarks hotness/threshold related options.
   renderRemarksHotnessOptions(Args, CmdArgs);
+
+  addMachineOutlinerArgs(D, Args, CmdArgs, ToolChain.getEffectiveTriple(),
+ /*IsLTO=*/true);
 }
 
 void tools::addArchSpecificRPath(const ToolChain &TC, const ArgList &Args,
@@ -1586,3 +1589,36 @@ unsigned tools::getOrCheckAMDGPUCodeObjectVersion(
   }
   return CodeObjVer;
 }
+
+void tools::addMachineOutlinerArgs(const Driver &D,
+   const llvm::opt::ArgList &Args,
+   llvm::opt::ArgStringList &CmdArgs,
+   const llvm::Triple &Triple, bool IsLTO) {
+  auto addArg = [&, IsLTO](const Twine &Arg) {
+if (IsLTO) {
+  CmdArgs.push_back(Args.MakeArgString("-plugin-opt=" + Arg));
+} else {
+  CmdArgs.push_back("-mllvm");
+  CmdArgs.push_back(Args.MakeArgString(Arg));
+}
+  };
+
+  if (Arg *A = Args.getLastArg(options::OPT_moutline,
+   options::OPT_mno_outline)) {
+if (A->getOption().matches(options::OPT_moutline)) {
+  // We only support -moutline in AArch64 and ARM targets right now. If
+  // we're not compiling for these, emit a warning and ignore the flag.
+  // Otherwise, add the proper mllvm flags.
+  if (!(Triple.isARM() || Triple.isThumb() ||
+Triple.getArch() == llvm::Triple::aarch64 ||
+Triple.getArch() == llvm::Triple::aarch64_32)) {
+D.Diag(diag::warn_drv_moutline_unsupported_opt) << 
Triple.getArchName();
+  } else {
+addArg(Twine("-enable-machine-outliner"));
+  }
+} else {
+  // Disable all outlining behaviour.
+  addArg(Twine("-enable-machine-outliner=never"));
+}
+  }
+}

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.h 
b/clang/lib/Driver/ToolChains/CommonArgs.h
index 9a365f376022..187c340d1c3c 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.h
+++ b/clang/lib/Driver/ToolChains/CommonArgs.h
@@ -141,6 +141,10 @@ void addX86AlignBranchArgs(const Driver &D, const 
llvm::opt::ArgList &Args,
 unsigned getOrCheckAMDGPUCodeObjectVersion(const Driver &D,
const llvm::opt::ArgList &Args,