[llvm-branch-commits] [cfe-branch] r323179 - [ReleaseNotes] Mention OpenMP Tools Interface in runtime library

2018-01-24 Thread Jonas Hahnfeld via llvm-branch-commits 
Author: hahnfeld
Date: Mon Jan 22 23:50:11 2018
New Revision: 323179

URL: http://llvm.org/viewvc/llvm-project?rev=323179&view=rev
Log:
[ReleaseNotes] Mention OpenMP Tools Interface in runtime library

The OpenMP runtime has no dedicated Release Notes, so add it to Clang's
section about OpenMP.

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


Modified:
cfe/branches/release_60/docs/ReleaseNotes.rst

Modified: cfe/branches/release_60/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff
==
--- cfe/branches/release_60/docs/ReleaseNotes.rst (original)
+++ cfe/branches/release_60/docs/ReleaseNotes.rst Mon Jan 22 23:50:11 2018
@@ -231,6 +231,13 @@ OpenMP Support in Clang
 - Added support for `reduction`-based clauses on `task`-based directives from
   upcoming OpenMP 5.0.
 
+- The LLVM OpenMP runtime `libomp` now supports the OpenMP Tools Interface 
(OMPT)
+  on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS. If you 
observe
+  a measurable performance impact on one of your applications without a tool
+  attached, please rebuild the runtime library with 
`-DLIBOMP_OMPT_SUPPORT=OFF` and
+  file a bug at `LLVM's Bugzilla `_ or send a message 
to the
+  `OpenMP development list 
`_.
+
 Internal API Changes
 
 


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

[llvm-branch-commits] [cfe-branch] r323128 - Merging r323123:

2018-01-24 Thread Jonas Hahnfeld via llvm-branch-commits 
Author: hahnfeld
Date: Mon Jan 22 07:38:26 2018
New Revision: 323128

URL: http://llvm.org/viewvc/llvm-project?rev=323128&view=rev
Log:
Merging r323123:

r323123 | hahnfeld | 2018-01-22 16:27:45 +0100 (Mon, 22 Jan 2018) | 6 lines

[DOCS] Mention OpenMP Tools Interface in runtime library

Also list supported configurations (architectures + operating
systems).

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


Modified:
cfe/branches/release_60/   (props changed)
cfe/branches/release_60/docs/OpenMPSupport.rst

Propchange: cfe/branches/release_60/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Jan 22 07:38:26 2018
@@ -1,4 +1,4 @@
 /cfe/branches/type-system-rewrite:134693-134817
-/cfe/trunk:321754,321771,321777,321779,321933,322018,322236,322246,322350,322390,322405,322420,322518,322593,322813,322901,322904,322984
+/cfe/trunk:321754,321771,321777,321779,321933,322018,322236,322246,322350,322390,322405,322420,322518,322593,322813,322901,322904,322984,323123
 /cfe/trunk/test:170344
 /cfe/trunk/test/SemaTemplate:126920

Modified: cfe/branches/release_60/docs/OpenMPSupport.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/OpenMPSupport.rst?rev=323128&r1=323127&r2=323128&view=diff
==
--- cfe/branches/release_60/docs/OpenMPSupport.rst (original)
+++ cfe/branches/release_60/docs/OpenMPSupport.rst Mon Jan 22 07:38:26 2018
@@ -65,4 +65,4 @@ Combined directives
 * #pragma omp target teams distribute parallel for [simd]: :partial:`Partial`. 
 No full codegen support.
 
 Clang does not support any constructs/updates from upcoming OpenMP 5.0 except 
for `reduction`-based clauses in the `task` and `target`-based directives.
-
+In addition, the LLVM OpenMP runtime `libomp` supports the OpenMP Tools 
Interface (OMPT) on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and mac 
OS.


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

[llvm-branch-commits] [cfe-branch] r323066 - [docs] Fix typo in Release Notes

2018-01-24 Thread Jonas Hahnfeld via llvm-branch-commits 
Author: hahnfeld
Date: Sun Jan 21 03:43:32 2018
New Revision: 323066

URL: http://llvm.org/viewvc/llvm-project?rev=323066&view=rev
Log:
[docs] Fix typo in Release Notes

Modified:
cfe/branches/release_60/docs/ReleaseNotes.rst

Modified: cfe/branches/release_60/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/ReleaseNotes.rst?rev=323066&r1=323065&r2=323066&view=diff
==
--- cfe/branches/release_60/docs/ReleaseNotes.rst (original)
+++ cfe/branches/release_60/docs/ReleaseNotes.rst Sun Jan 21 03:43:32 2018
@@ -209,7 +209,7 @@ OpenCL C Language Changes in Clang
 OpenMP Support in Clang
 --
 
-- Added options `-f[no]-openmp-simd` that support code emission only foe OpenMP
+- Added options `-f[no]-openmp-simd` that support code emission only for OpenMP
   SIMD-based directives, like `#pragma omp simd`, `#pragma omp parallel for 
simd`
   etc. The code is emitted only for simd-based part of the combined directives
   and clauses.


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

Re: [llvm-branch-commits] [cfe-branch] r323179 - [ReleaseNotes] Mention OpenMP Tools Interface in runtime library

2018-02-01 Thread Jonas Hahnfeld via llvm-branch-commits 
I think it actually works _if_ you get Clang to link to the right 
runtime library... Adding Joachim and Olga who have been working on this 
lately.


Am 2018-02-01 10:26, schrieb Hans Wennborg:

As far as I understand, this doesn't actually work on Windows. Should
we update the text?

On Tue, Jan 23, 2018 at 8:50 AM, Jonas Hahnfeld via
llvm-branch-commits  wrote:


Author: hahnfeld
Date: Mon Jan 22 23:50:11 2018
New Revision: 323179

URL: http://llvm.org/viewvc/llvm-project?rev=323179&view=rev [1]
Log:
[ReleaseNotes] Mention OpenMP Tools Interface in runtime library

The OpenMP runtime has no dedicated Release Notes, so add it to
Clang's
section about OpenMP.

Differential Revision: https://reviews.llvm.org/D42352 [2]

Modified:
cfe/branches/release_60/docs/ReleaseNotes.rst

Modified: cfe/branches/release_60/docs/ReleaseNotes.rst
URL:


http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff

[3]


==

--- cfe/branches/release_60/docs/ReleaseNotes.rst (original)
+++ cfe/branches/release_60/docs/ReleaseNotes.rst Mon Jan 22
23:50:11 2018
@@ -231,6 +231,13 @@ OpenMP Support in Clang
- Added support for `reduction`-based clauses on `task`-based
directives from
upcoming OpenMP 5.0.

+- The LLVM OpenMP runtime `libomp` now supports the OpenMP Tools
Interface (OMPT)
+  on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
If you observe
+  a measurable performance impact on one of your applications
without a tool
+  attached, please rebuild the runtime library with
`-DLIBOMP_OMPT_SUPPORT=OFF` and
+  file a bug at `LLVM's Bugzilla <https://bugs.llvm.org/>`_ or send
a message to the
+  `OpenMP development list
<http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev [4]>`_.
+
Internal API Changes


___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[5]




Links:
--
[1] http://llvm.org/viewvc/llvm-project?rev=323179&view=rev
[2] https://reviews.llvm.org/D42352
[3]
http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff
[4] http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
[5] http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

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

Re: [llvm-branch-commits] [cfe-branch] r323179 - [ReleaseNotes] Mention OpenMP Tools Interface in runtime library

2018-02-01 Thread Jonas Hahnfeld via llvm-branch-commits 
No, there isn't and I fully agree that this is far from ideal. However, 
we are only running an x86 Linux cluster and that's where I try to get 
coverage for.


From my part, feel free to remove the part about Windows if you think 
it's better for user experience. I've never used OpenMP on Windows and 
certainly won't look into issues there.


Thanks,
Jonas

Am 2018-02-01 10:38, schrieb Hans Wennborg:

Is there a buildbot that tests it regularly on Windows, ideally built
with Clang?

I'm sorry that I seem grumpy about this, but there appears to be a
problem here.

On Thu, Feb 1, 2018 at 10:30 AM, Jonas Hahnfeld 
wrote:


I think it actually works _if_ you get Clang to link to the right
runtime library... Adding Joachim and Olga who have been working on
this lately.

Am 2018-02-01 10:26, schrieb Hans Wennborg:
As far as I understand, this doesn't actually work on Windows.
Should
we update the text?

On Tue, Jan 23, 2018 at 8:50 AM, Jonas Hahnfeld via
llvm-branch-commits  wrote:

Author: hahnfeld
Date: Mon Jan 22 23:50:11 2018
New Revision: 323179

URL: http://llvm.org/viewvc/llvm-project?rev=323179&view=rev [1]
[1]
Log:
[ReleaseNotes] Mention OpenMP Tools Interface in runtime library

The OpenMP runtime has no dedicated Release Notes, so add it to
Clang's
section about OpenMP.

Differential Revision: https://reviews.llvm.org/D42352 [2] [2]

Modified:
cfe/branches/release_60/docs/ReleaseNotes.rst

Modified: cfe/branches/release_60/docs/ReleaseNotes.rst
URL:



http://llvm.org/viewvc/llvm-project/cfe/branches/release_60/docs/ReleaseNotes.rst?rev=323179&r1=323178&r2=323179&view=diff

[3]
[3]



==

--- cfe/branches/release_60/docs/ReleaseNotes.rst (original)
+++ cfe/branches/release_60/docs/ReleaseNotes.rst Mon Jan 22
23:50:11 2018
@@ -231,6 +231,13 @@ OpenMP Support in Clang
- Added support for `reduction`-based clauses on `task`-based
directives from
upcoming OpenMP 5.0.

+- The LLVM OpenMP runtime `libomp` now supports the OpenMP Tools
Interface (OMPT)
+  on x86, x86_64, AArch64, and PPC64 on Linux, Windows, and macOS.
If you observe
+  a measurable performance impact on one of your applications
without a tool
+  attached, please rebuild the runtime library with
`-DLIBOMP_OMPT_SUPPORT=OFF` and
+  file a bug at `LLVM's Bugzilla <https://bugs.llvm.org/>`_ or send
a message to the
+  `OpenMP development list
<http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev [4]
[4]>`_.
+
Internal API Changes


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

[llvm-branch-commits] [llvm] 6e890ec - [CMake] Avoid __FakeVCSRevision.h with no git repository

2020-12-16 Thread Jonas Hahnfeld via llvm-branch-commits 

Author: Jonas Hahnfeld
Date: 2020-12-16T17:33:20+01:00
New Revision: 6e890ec7beb0874464a0af9f84e41a987f968b23

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

LOG: [CMake] Avoid __FakeVCSRevision.h with no git repository

Set the return variable to "" in find_first_existing_vc_file to
say that there is a repository, but no file to depend on. This works
transparently for all other callers that handle undefinedness and
equality to an empty string the same way.

Use the knowledge to avoid depending on __FakeVCSRevision.h if there
is no git repository at all (for example when building a release) as
there is no point in regenerating an empty VCSRevision.h.

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

Added: 


Modified: 
llvm/cmake/modules/AddLLVM.cmake
llvm/include/llvm/Support/CMakeLists.txt

Removed: 




diff  --git a/llvm/cmake/modules/AddLLVM.cmake 
b/llvm/cmake/modules/AddLLVM.cmake
index a3e9eaeeb262..b86fbdaaa6d8 100644
--- a/llvm/cmake/modules/AddLLVM.cmake
+++ b/llvm/cmake/modules/AddLLVM.cmake
@@ -2135,6 +2135,13 @@ function(setup_dependency_debugging name)
   set_target_properties(${name} PROPERTIES RULE_LAUNCH_COMPILE 
${sandbox_command})
 endfunction()
 
+# If the sources at the given `path` are under version control, set `out_var`
+# to the the path of a file which will be modified when the VCS revision
+# changes, attempting to create that file if it does not exist; if no such
+# file exists and one cannot be created, instead set `out_var` to the
+# empty string.
+#
+# If the sources are not under version control, do not define `out_var`.
 function(find_first_existing_vc_file path out_var)
   if(NOT EXISTS "${path}")
 return()
@@ -2156,6 +2163,7 @@ function(find_first_existing_vc_file path out_var)
   RESULT_VARIABLE touch_head_result
   ERROR_QUIET)
 if (NOT touch_head_result EQUAL 0)
+  set(${out_var} "" PARENT_SCOPE)
   return()
 endif()
   endif()

diff  --git a/llvm/include/llvm/Support/CMakeLists.txt 
b/llvm/include/llvm/Support/CMakeLists.txt
index aa71b5572181..aeb5866ecbdd 100644
--- a/llvm/include/llvm/Support/CMakeLists.txt
+++ b/llvm/include/llvm/Support/CMakeLists.txt
@@ -11,7 +11,7 @@ if(LLVM_APPEND_VC_REV)
   # A fake version file and is not expected to exist. It is being used to
   # force regeneration of VCSRevision.h for source directory with no write
   # permission available.
-  if (NOT llvm_vc)
+  if (llvm_vc STREQUAL "")
 set(fake_version_inc "${CMAKE_CURRENT_BINARY_DIR}/__FakeVCSRevision.h")
   endif()
 endif()



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

[llvm-branch-commits] [clang] release/20.x: [clang] Forward TPL of NestedNameSpecifier (PR #137806)

2025-04-29 Thread Jonas Hahnfeld via llvm-branch-commits 

hahnjo wrote:

Hi @shafik, the issue is an inconsistency in the treatment of template 
specialization types depending on whether they are the prefix or the "final" 
type. To stay with the example of the test, the result without this patch is 
`A<1>` and `A<2>`, but `A<1U>::B<3>` and `A<2U>::B<4>`. This is affecting us 
downstream (ROOT, Cling, LHC experiments) where we try to normalize user types 
to a canonical string, irrespective of what the code may have spelled in 
different occasions. The latter means we cannot use the `Decl`, but we have to 
recursively normalize all scopes, class names, and template arguments. The 
inconsistency now causes a problem because we also have a "cheap" normalization 
routine based on string manipulation that just looks at the integer constant 
and keeps it without type suffix.

There is no issue for this because the problem is not present anymore in 
`main`, see https://github.com/llvm/llvm-project/pull/137804 (and it actually 
took me quite some time to understand how I could trigger the problem upstream 
without copying thousands of lines from the name normalization). If you insist, 
I can create an issue and immediately close it (?) but I personally don't see 
the advantage. The commit message and PR summary already explain that the 
change forwards the `TPL` and this avoids "avoids type suffixes for integer 
constants when the type can be inferred from the template parameter." I don't 
know how to improve this, but I'm open for suggestions.

https://github.com/llvm/llvm-project/pull/137806
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/20.x: [clang] Forward TPL of NestedNameSpecifier (PR #137806)

2025-04-29 Thread Jonas Hahnfeld via llvm-branch-commits 

https://github.com/hahnjo milestoned 
https://github.com/llvm/llvm-project/pull/137806
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/20.x: [clang] Forward TPL of NestedNameSpecifier (PR #137806)

2025-04-29 Thread Jonas Hahnfeld via llvm-branch-commits 

https://github.com/hahnjo created 
https://github.com/llvm/llvm-project/pull/137806

This avoids type suffixes for integer constants when the type can be inferred 
from the template parameter, such as the `unsigned` parameter of `A<1>` and 
`A<2>` in the added test.

---

Note: This issue does not exist anymore in `main`, see 
https://github.com/llvm/llvm-project/pull/137804. However, I don't think 
dc17429ae6961a6783371dcf6749eea657b5446a should be backported to 
`release/20.x`, so I'm proposing a targeted fix.

>From d787edd6017104fc2dc15effdbceb02490d7bc19 Mon Sep 17 00:00:00 2001
From: Jonas Hahnfeld 
Date: Tue, 29 Apr 2025 14:54:30 +0200
Subject: [PATCH] [clang] Forward TPL of NestedNameSpecifier

This avoids type suffixes for integer constants when the type can be
inferred from the template parameter, such as the unsigned parameter
of A<1> and A<2> in the added test.
---
 clang/lib/AST/NestedNameSpecifier.cpp | 17 ++--
 clang/unittests/Tooling/QualTypeNamesTest.cpp | 96 +++
 2 files changed, 106 insertions(+), 7 deletions(-)

diff --git a/clang/lib/AST/NestedNameSpecifier.cpp 
b/clang/lib/AST/NestedNameSpecifier.cpp
index 76c77569da9fd..c043996f1ada3 100644
--- a/clang/lib/AST/NestedNameSpecifier.cpp
+++ b/clang/lib/AST/NestedNameSpecifier.cpp
@@ -283,13 +283,16 @@ void NestedNameSpecifier::print(raw_ostream &OS, const 
PrintingPolicy &Policy,
   case TypeSpec: {
 const auto *Record =
 
dyn_cast_or_null(getAsRecordDecl());
-if (ResolveTemplateArguments && Record) {
+const TemplateParameterList *TPL = nullptr;
+if (Record) {
+  TPL = Record->getSpecializedTemplate()->getTemplateParameters();
+  if (ResolveTemplateArguments) {
 // Print the type trait with resolved template parameters.
 Record->printName(OS, Policy);
-printTemplateArgumentList(
-OS, Record->getTemplateArgs().asArray(), Policy,
-Record->getSpecializedTemplate()->getTemplateParameters());
+printTemplateArgumentList(OS, Record->getTemplateArgs().asArray(),
+  Policy, TPL);
 break;
+  }
 }
 const Type *T = getAsType();
 
@@ -313,8 +316,8 @@ void NestedNameSpecifier::print(raw_ostream &OS, const 
PrintingPolicy &Policy,
 TemplateName::Qualified::None);
 
   // Print the template argument list.
-  printTemplateArgumentList(OS, SpecType->template_arguments(),
-InnerPolicy);
+  printTemplateArgumentList(OS, SpecType->template_arguments(), 
InnerPolicy,
+TPL);
 } else if (const auto *DepSpecType =
dyn_cast(T)) {
   // Print the template name without its corresponding
@@ -322,7 +325,7 @@ void NestedNameSpecifier::print(raw_ostream &OS, const 
PrintingPolicy &Policy,
   OS << DepSpecType->getIdentifier()->getName();
   // Print the template argument list.
   printTemplateArgumentList(OS, DepSpecType->template_arguments(),
-InnerPolicy);
+InnerPolicy, TPL);
 } else {
   // Print the type normally
   QualType(T, 0).print(OS, InnerPolicy);
diff --git a/clang/unittests/Tooling/QualTypeNamesTest.cpp 
b/clang/unittests/Tooling/QualTypeNamesTest.cpp
index 5ded64d4fcc8c..49c40d633ad4b 100644
--- a/clang/unittests/Tooling/QualTypeNamesTest.cpp
+++ b/clang/unittests/Tooling/QualTypeNamesTest.cpp
@@ -265,6 +265,102 @@ TEST(QualTypeNameTest, InlineNamespace) {
   TypeNameVisitor::Lang_CXX11);
 }
 
+TEST(QualTypeNameTest, TemplatedClass) {
+  std::unique_ptr AST =
+  tooling::buildASTFromCode("template  struct A {\n"
+"  template  struct B {};\n"
+"};\n"
+"template struct A<1>;\n"
+"template struct A<2u>;\n"
+"template struct A<1>::B<3>;\n"
+"template struct A<2u>::B<4u>;\n");
+
+  auto &Context = AST->getASTContext();
+  auto &Policy = Context.getPrintingPolicy();
+  auto getFullyQualifiedName = [&](QualType QT) {
+return TypeName::getFullyQualifiedName(QT, Context, Policy);
+  };
+
+  auto *A = Context.getTranslationUnitDecl()
+->lookup(&Context.Idents.get("A"))
+.find_first();
+  ASSERT_NE(A, nullptr);
+
+  // A has two explicit instantiations: A<1> and A<2u>
+  auto ASpec = A->spec_begin();
+  ASSERT_NE(ASpec, A->spec_end());
+  auto *A1 = *ASpec;
+  ASpec++;
+  ASSERT_NE(ASpec, A->spec_end());
+  auto *A2 = *ASpec;
+
+  // Their type names follow the records.
+  QualType A1RecordTy = Context.getRecordType(A1);
+  EXPECT_EQ(getFullyQualifiedName(A1RecordTy), "A<1>");
+  QualType A2RecordTy = Context.getRecordType(A2);
+  EXPECT_EQ(getFullyQualifiedName(A2RecordTy), "A<2U>");
+
+  // getTemplateSpecializationTyp

[llvm-branch-commits] [clang] release/20.x: [clang] Forward TPL of NestedNameSpecifier (PR #137806)

2025-05-09 Thread Jonas Hahnfeld via llvm-branch-commits 

hahnjo wrote:

@shafik do the explanations make sense?

https://github.com/llvm/llvm-project/pull/137806
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits