[PATCH] D91944: OpenMP 5.0 metadirective

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Also, when this lands again, please ensure that all the tests don't 
accidentally dump build artifacts into the source directory. Specifically, the 
following test was missing `-o -`: clang/test/OpenMP/metadirective_messages.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91944

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Yes, Fedora 34 (x86-64).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

It's still failing but I can disable HSA on this machine for now. FYI --

  FAILED: 
tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o
  /p/tllvm/bin/clang++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/tools/amdgpu-arch -I/home/dave/ro_s/lp/clang/tools/amdgpu-arch 
-I/home/dave/ro_s/lp/clang/include -Itools/clang/include -Iinclude 
-I/home/dave/ro_s/lp/llvm/include -Werror=switch -Wno-deprecated-copy 
-stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
-Woverloaded-virtual -Wno-nested-anon-types -O2 -DNDEBUG  -march=skylake 
-fno-vectorize -fno-slp-vectorize -fno-tree-slp-vectorize -fno-exceptions 
-fno-rtti -std=c++14 -MD -MT 
tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o -MF 
tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o.d -o 
tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o -c 
/home/dave/ro_s/lp/clang/tools/amdgpu-arch/AMDGPUArch.cpp
  /home/dave/ro_s/lp/clang/tools/amdgpu-arch/AMDGPUArch.cpp:14:10: fatal error: 
'hsa.h' file not found
  #include 
   ^~~
  1 error generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I removed all HSA/ROCM via the package manager and everything is fine now. Have 
you considered using __has_include() instead of CMake? It seems to be supported 
by all contemporary compilers, even MSVC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D99949#2709785 , @JonChesterfield 
wrote:

> It's not obvious to me why any of those stages would get a different result 
> for the search for rocr. Do you do things with chroot/jails to ensure 
> isolation for some of them?

Technically? Yes. Practically? No. My setup just remounts a temporary /tmp 
during the build to garbage collect stuff the build puts in /tmp. And the 
second/third stages use the clang built/installed from the first stage but 
otherwise it's not different.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D99949#2709673 , @JonChesterfield 
wrote:

> That's interesting. The various permutations I have on disk are also all 
> path/include/hsa/hsa.h. The existing in tree use of hsa.h is the amdgpu 
> plugin, which uses `#include "hsa.h"` and `#include `, which seems 
> unlikely to be correct.
>
> I'm going to patch this on the fly to hsa/hsa.h as that looks very likely to 
> be the fix.
>
> edit: or not, the include path cmake summons on my local system is `-isystem 
> $HOME/llvm-install/include/hsa`, so hsa/hsa doesn't work.
>
> Tiresome. Will revert this for now.

Ya, I bet. I also find this interesting because this fails my "three stage" 
test at the third stage which is rare. My stages:

1. build and test llvm+clang (release without asserts) with the system compiler 
release
2. build and test llvm+clang (release with asserts) with the just build compiler
3. build and test llvm+clang (release without assert) with compiler built in 
stage one


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

And if it helps:

$ sudo find / -xdev -name hsa.h
/usr/include/hsa/hsa.h
/opt/rocm-3.10.0/include/hsa/hsa.h
/opt/rocm-4.0.0/include/hsa/hsa.h


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D99949#2709497 , @JonChesterfield 
wrote:

> In D99949#2709297 , @davezarzycki 
> wrote:
>
>> This change broke multi-stage builds (even if AMDGPU is disabled as a 
>> target). The problem is that clang/tools/amdgpu-arch/AMDGPUArch.cpp can't 
>> find hsa.h. Is there a quick fix?
>
> That should not be the case. The cmake for building AMDGPUArch.cpp is guarded 
> by
>
>   find_package(hsa-runtime64 QUIET 1.2.0 HINTS ${CMAKE_INSTALL_PREFIX} PATHS 
> /opt/rocm)
>   if (NOT ${hsa-runtime64_FOUND})
>   return
>
> The intent is for this to be built only when hsa-runtime64 is found on disk, 
> at which point hsa.h is meant to be found within that package via cmake 
> magic. Perhaps we need to explicitly specify the include directory, though we 
> do not do so in the openmp plugin this was copied from, and I do not have 
> hsa.h on any global search path.
>
> Little harm will be done by reverting this (again...) and reapplying, but it 
> would be really helpful if you can share some more information about the 
> build config that is failing.

As it turns out, I do have the HSA runtime installed so perhaps the problem is 
that the header is actually hsa/hsa.h and not hsa.h?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This change broke multi-stage builds (even if AMDGPU is disabled as a target). 
The problem is that clang/tools/amdgpu-arch/AMDGPUArch.cpp can't find hsa.h. Is 
there a quick fix?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added inline comments.



Comment at: clang/lib/CodeGen/CGValue.h:18
 #include "clang/AST/ASTContext.h"
+#include "clang/Sema/Sema.h"
 #include "clang/AST/Type.h"

aaron.ballman wrote:
> davezarzycki wrote:
> > aaron.ballman wrote:
> > > davezarzycki wrote:
> > > > aaron.ballman wrote:
> > > > > rnk wrote:
> > > > > > This includes Sema.h into every codegen file that uses CGValue.h 
> > > > > > (most of them). That seems bad for build time. :(
> > > > > > 
> > > > > > This also seems like a layering violation. CodeGen has no 
> > > > > > dependency on Sema:
> > > > > > https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/CMakeLists.txt#L104
> > > > > I agree that this is a layering violation (Sema relies on CodeGen 
> > > > > which now relies on Sema due to this change). We just ran into it in 
> > > > > a downstream fork when we had to add `clangSema` to the codegen 
> > > > > linker input to avoid linking errors. I'm a bit surprised given that 
> > > > > the only use appears to be a `static_assert` that shouldn't require 
> > > > > anything to be linked in, but here we are just the same.
> > > > > 
> > > > > I think this should be rolled back so that we don't get additional 
> > > > > dependencies on Sema within CodeGen by accident. It helps that @rnk 
> > > > > moved this change into CGDecl.cpp (limits the scope of where we may 
> > > > > introduce accidental dependencies), but I don't think we should be 
> > > > > including anything from Sema.h here.
> > > > It was fixed over a year ago: 01943a59f51d8b5ede062305941c1f864b8a6a13
> > > That fixes the transitive include issues @rnk raised, but is not a fix 
> > > for the layering violation. It's still a layering violation because it's 
> > > including Sema from within CodeGen.
> > Ah, sorry. It does seem odd and probably a bug that a static_assert would 
> > trigger this. Did you verify that the imported symbol dependency is 
> > triggered by this static_assert? Or is the problem the mere inclusion, not 
> > the static_assert itself? And is the actual dependency only happen in 
> > unoptimized/debug builds or release too?
> > 
> > In any case, I believe it was discussed at the time that the LLVM variable 
> > ought to be moved to some kind of policy/config header that both LLVM's 
> > CodeGen and clang's Sema can include. Would you be open to that?
> > Ah, sorry. It does seem odd and probably a bug that a static_assert would 
> > trigger this. Did you verify that the imported symbol dependency is 
> > triggered by this static_assert? Or is the problem the mere inclusion, not 
> > the static_assert itself? And is the actual dependency only happen in 
> > unoptimized/debug builds or release too?
> 
> I'd have to go back to the developer who found it to get the exact details, 
> but my belief is that it's the inclusion more so than the static assertion 
> itself. FWIW, the dependency was happening when doing a shared libraries 
> build (I believe in release mode). I can dig up those details if you'd like, 
> but my concern is that even if the issue is the static assertion, including 
> the header file makes it easy for someone to accidentally use other 
> facilities from Sema.h under the mistaken belief they're fine to do so.
> 
> > In any case, I believe it was discussed at the time that the LLVM variable 
> > ought to be moved to some kind of policy/config header that both LLVM's 
> > CodeGen and clang's Sema can include. Would you be open to that?
> 
> That sounds like a very good idea to me!
Okay. I sent out the RFC to llvm-dev. It was long overdue. Somebody just needed 
to volunteer, start the discussion, and get it over with.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73363

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

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added inline comments.



Comment at: clang/lib/CodeGen/CGValue.h:18
 #include "clang/AST/ASTContext.h"
+#include "clang/Sema/Sema.h"
 #include "clang/AST/Type.h"

aaron.ballman wrote:
> davezarzycki wrote:
> > aaron.ballman wrote:
> > > rnk wrote:
> > > > This includes Sema.h into every codegen file that uses CGValue.h (most 
> > > > of them). That seems bad for build time. :(
> > > > 
> > > > This also seems like a layering violation. CodeGen has no dependency on 
> > > > Sema:
> > > > https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/CMakeLists.txt#L104
> > > I agree that this is a layering violation (Sema relies on CodeGen which 
> > > now relies on Sema due to this change). We just ran into it in a 
> > > downstream fork when we had to add `clangSema` to the codegen linker 
> > > input to avoid linking errors. I'm a bit surprised given that the only 
> > > use appears to be a `static_assert` that shouldn't require anything to be 
> > > linked in, but here we are just the same.
> > > 
> > > I think this should be rolled back so that we don't get additional 
> > > dependencies on Sema within CodeGen by accident. It helps that @rnk moved 
> > > this change into CGDecl.cpp (limits the scope of where we may introduce 
> > > accidental dependencies), but I don't think we should be including 
> > > anything from Sema.h here.
> > It was fixed over a year ago: 01943a59f51d8b5ede062305941c1f864b8a6a13
> That fixes the transitive include issues @rnk raised, but is not a fix for 
> the layering violation. It's still a layering violation because it's 
> including Sema from within CodeGen.
Ah, sorry. It does seem odd and probably a bug that a static_assert would 
trigger this. Did you verify that the imported symbol dependency is triggered 
by this static_assert? Or is the problem the mere inclusion, not the 
static_assert itself? And is the actual dependency only happen in 
unoptimized/debug builds or release too?

In any case, I believe it was discussed at the time that the LLVM variable 
ought to be moved to some kind of policy/config header that both LLVM's CodeGen 
and clang's Sema can include. Would you be open to that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73363

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

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added inline comments.



Comment at: clang/lib/CodeGen/CGValue.h:18
 #include "clang/AST/ASTContext.h"
+#include "clang/Sema/Sema.h"
 #include "clang/AST/Type.h"

aaron.ballman wrote:
> rnk wrote:
> > This includes Sema.h into every codegen file that uses CGValue.h (most of 
> > them). That seems bad for build time. :(
> > 
> > This also seems like a layering violation. CodeGen has no dependency on 
> > Sema:
> > https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/CMakeLists.txt#L104
> I agree that this is a layering violation (Sema relies on CodeGen which now 
> relies on Sema due to this change). We just ran into it in a downstream fork 
> when we had to add `clangSema` to the codegen linker input to avoid linking 
> errors. I'm a bit surprised given that the only use appears to be a 
> `static_assert` that shouldn't require anything to be linked in, but here we 
> are just the same.
> 
> I think this should be rolled back so that we don't get additional 
> dependencies on Sema within CodeGen by accident. It helps that @rnk moved 
> this change into CGDecl.cpp (limits the scope of where we may introduce 
> accidental dependencies), but I don't think we should be including anything 
> from Sema.h here.
It was fixed over a year ago: 01943a59f51d8b5ede062305941c1f864b8a6a13


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73363

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

[PATCH] D93594: [X86] Pass to transform amx intrinsics to scalar operation.

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D93594#2606157 , @RKSimon wrote:

> @yubing I've reverted this as it was failing on a lot of buildbots: 
> http://lab.llvm.org:8011/#/builders/109/builds/9867

Thanks – I was just about to point out this broke downstream testing too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93594

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

[PATCH] D95877: [analyzer] Fix static_cast on pointer-to-member handling

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

The test seems to be broken on Fedora 33 (x86-64 with clang-11):

  XPASS: Clang :: Analysis/reinterpret-cast-pointer-to-member.cpp (6531 of 
74360)
   TEST 'Clang :: 
Analysis/reinterpret-cast-pointer-to-member.cpp' FAILED 
  Script:
  --
  : 'RUN: at line 1';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/13.0.0/include -nostdsysteminc -analyze 
-analyzer-constraints=range -setup-static-analyzer 
-analyzer-checker=core,debug.ExprInspection -verify 
/home/dave/ro_s/lp/clang/test/Analysis/reinterpret-cast-pointer-to-member.cpp
  --
  Exit Code: 0


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95877

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

[PATCH] D91488: Consider reference, pointer, and pointer-to-membber TemplateArguments to be different if they have different types.

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Thanks. I just verified that reverting this change fixes the second stage 
regression and was about to commit the revert.

@rsmith – If you need help testing a fix, please let me know.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91488

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

[PATCH] D91488: Consider reference, pointer, and pointer-to-membber TemplateArguments to be different if they have different types.

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This change is causing second stage build failures on Fedora 33 (x86-64). I'll 
probably revert this soon, but in the mean time, here is a snippet of the build 
output:

  FAILED: 
lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o
  /p/tllvm/bin/clang++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Ilib/ExecutionEngine/JITLink 
-I/home/dave/ro_s/lp/llvm/lib/ExecutionEngine/JITLink -Iinclude 
-I/home/dave/ro_s/lp/llvm/include -Werror=switch -Wno-deprecated-copy 
-stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default 
-Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wsuggest-override -Wstring-conversion -fdiagnostics-color -ffunction-sections 
-fdata-sections -O2   -march=skylake -fno-vectorize -fno-slp-vectorize 
-fno-tree-slp-vectorize -fno-exceptions -fno-rtti -UNDEBUG -std=c++14 -MD -MT 
lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o -MF 
lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o.d 
-o lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o 
-c /home/dave/ro_s/lp/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.cpp
  In file included from 
/home/dave/ro_s/lp/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.cpp:13:
  /home/dave/ro_s/lp/llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.h:150:18: 
error: invalid operands to binary expression 
('llvm::jitlink::LinkGraph::nested_collection_iterator *>, llvm::jitlink::Section>, 
llvm::detail::DenseSetImpl, 
llvm::detail::DenseSetPair>, 
llvm::DenseMapInfo>::Iterator, llvm::jitlink::Block *, 
&llvm::jitlink::LinkGraph::getSectionBlocks>' and 
'llvm::jitlink::LinkGraph::nested_collection_iterator *>, llvm::jitlink::Section>, 
llvm::detail::DenseSetImpl, 
llvm::detail::DenseSetPair>, 
llvm::DenseMapInfo>::Iterator, llvm::jitlink::Block *, 
&llvm::jitlink::LinkGraph::getSectionBlocks>')
  for (auto *B : G.blocks()) {
   ^
  /home/dave/ro_s/lp/llvm/include/llvm/ADT/APInt.h:2037:13: note: candidate 
function not viable: no known conversion from 
'llvm::jitlink::LinkGraph::nested_collection_iterator *>, llvm::jitlink::Section>, 
llvm::detail::DenseSetImpl, 
llvm::detail::DenseSetPair>, 
llvm::DenseMapInfo>::Iterator, llvm::jitlink::Block *, 
&llvm::jitlink::LinkGraph::getSectionBlocks>' to 'uint64_t' (aka 'unsigned 
long') for 1st argument
  inline bool operator!=(uint64_t V1, const APInt &V2) { return V2 != V1; }
  ^
  /home/dave/ro_s/lp/llvm/include/llvm/ADT/APSInt.h:340:13: note: candidate 
function not viable: no known conversion from 
'llvm::jitlink::LinkGraph::nested_collection_iterator *>, llvm::jitlink::Section>, 
llvm::detail::DenseSetImpl, 
llvm::detail::DenseSetPair>, 
llvm::DenseMapInfo>::Iterator, llvm::jitlink::Block *, 
&llvm::jitlink::LinkGraph::getSectionBlocks>' to 'int64_t' (aka 'long') for 1st 
argument
  inline bool operator!=(int64_t V1, const APSInt &V2) { return V2 != V1; }
  ^
  /home/dave/ro_s/lp/llvm/include/llvm/ADT/StringRef.h:904:15: note: candidate 
function not viable: no known conversion from 
'llvm::jitlink::LinkGraph::nested_collection_iterator *>, llvm::jitlink::Section>, 
llvm::detail::DenseSetImpl, 
llvm::detail::DenseSetPair>, 
llvm::DenseMapInfo>::Iterator, llvm::jitlink::Block *, 
&llvm::jitlink::LinkGraph::getSectionBlocks>' to 'llvm::StringRef' for 1st 
argument
inline bool operator!=(StringRef LHS, StringRef RHS) { return !(LHS == 
RHS); }
^
  /p/tllvm/bin/../include/c++/v1/system_error:419:1: note: candidate function 
not viable: no known conversion from 
'llvm::jitlink::LinkGraph::nested_collection_iterator *>, llvm::jitlink::Section>, 
llvm::detail::DenseSetImpl, 
llvm::detail::DenseSetPair>, 
llvm::DenseMapInfo>::Iterator, llvm::jitlink::Block *, 
&llvm::jitlink::LinkGraph::getSectionBlocks>' to 'const std::error_code' for 
1st argument
  operator!=(const error_code& __x, const error_code& __y) _NOEXCEPT
  ^
  /p/tllvm/bin/../include/c++/v1/system_error:424:1: note: candidate function 
not viable: no known conversion from 
'llvm::jitlink::LinkGraph::nested_collection_iterator *>, llvm::jitlink::Section>, 
llvm::detail::DenseSetImpl, 
llvm::detail::DenseSetPair>, 
llvm::DenseMapInfo>::Iterator, llvm::jitlink::Block *, 
&llvm::jitlink::LinkGraph::getSectionBlocks>' to 'const std::error_code' for 
1st argument
  operator!=(const error_code& __x, const error_condition& __y) _NOEXCEPT
  ^
  /p/tllvm/bin/../include/c++/v1/system_error:429:1: note: candidate function 
not viable: no known conversion from 
'llvm::jitlink::LinkGraph::nested_collection_iterator *>, llvm::jitlink::Section>, 
llvm::detail::DenseSetImpl, 
llvm::detail::Dens

[PATCH] D92028: Fix driver test from e16c0a9a689719

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This is breaking building on Fedora 33 (x86-64). Can we revert this or get a 
quick fix?

  --
  Exit Code: 1
  
  Command Output (stdout):
  --
   "/tmp/_update_lc/r/bin/ld64.lld" "-demangle" "-dynamic" "-arch" "i386" 
"-macosx_version_min" "10.5.0" "-o" "/tmp/darwin-ld-24b2aa.out" "-lcrt1.10.5.o" 
"/tmp/darwin-ld-44e1b0.o" "-arch_multiple" "-final_output" "foo" "-lSystem"
   "/tmp/_update_lc/r/bin/ld64.lld" "-demangle" "-dynamic" "-arch" "x86_64" 
"-macosx_version_min" "10.5.0" "-o" "/tmp/darwin-ld-9401c6.out" "-lcrt1.10.5.o" 
"/tmp/darwin-ld-76c470.o" "-arch_multiple" "-final_output" "foo" "-lSystem"
   "/tmp/_update_lc/r/bin/dsymutil" "-o" "BAR.dSYM" "BAR"
   "/tmp/_update_lc/r/bin/dsymutil" "-o" "BAR.dSYM" "BAR"
  
  --
  Command Output (stderr):
  --
  /home/dave/ro_s/lp/clang/test/Driver/darwin-ld.c:102:31: error: 
LINK_OLDER_NODEMANGLE-NOT: excluded string found in input
  // LINK_OLDER_NODEMANGLE-NOT: "-demangle"
^
  :5:35: note: found here
   "/tmp/_update_lc/r/bin/ld64.lld" "-demangle" "-dynamic" "-arch" "x86_64" 
"-macosx_version_min" "10.6.0" "-o" "a.out" "-lcrt1.10.6.o" 
"/tmp/_update_lc/r/tools/clang/test/Driver/Output/darwin-ld.c.tmp.o" "-lSystem"
^~~
  
  Input file: 
  Check file: /home/dave/ro_s/lp/clang/test/Driver/darwin-ld.c
  
  -dump-input=help explains the following input dump.
  
  Input was:
  <<
   1: clang version 12.0.0 (https://github.com/llvm/llvm-project.git 
e4d9380245518ee8dcb765eb2e5f4f2788b53cc6)
   2: Target: x86_64-apple-darwin10
   3: Thread model: posix
   4: InstalledDir: /tmp/_update_lc/r/bin
   5:  "/tmp/_update_lc/r/bin/ld64.lld" "-demangle" "-dynamic" "-arch" 
"x86_64" "-macosx_version_min" "10.6.0" "-o" "a.out" "-lcrt1.10.6.o" 
"/tmp/_update_lc/r/tools/clang/test/Driver/Output/darwin-ld.c.tmp.o" "-lSystem"
  not:102   !~~ 

error: no 
match expected
  >>
  
  --
  
  
  Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
  
  Failed Tests (1):
Clang :: Driver/darwin-ld.c
  
  
  Testing Time: 103.43s
Unsupported  : 11105
Passed   : 60786
Expectedly Failed:   100
Failed   : 1
  FAILED: CMakeFiles/check-all


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92028

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

[PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I think I fixed it. Please verify: 87f6de72bcd346bbbf468e9f9a0e9d1bbf0630a9


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89500

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

[PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

A git bisect run blamed this patch for breaking the ability to build with a 
read-only source tree. Can we revert this or make a quick fix?

  FAIL: Clang :: CodeGen/basic-block-sections.c (3385 of 26774)
   TEST 'Clang :: CodeGen/basic-block-sections.c' FAILED 

  Script:
  --
  : 'RUN: at line 3';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -triple x86_64 -S -o 
- < /home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c | 
/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c 
--check-prefix=PLAIN
  : 'RUN: at line 4';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -triple x86_64 -S 
-fbasic-block-sections=all -fbasic-block-sections=none -o - < 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c | 
/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c 
--check-prefix=PLAIN
  : 'RUN: at line 6';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -triple x86_64 -S 
-fbasic-block-sections=all -o - < 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c | 
/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c 
--check-prefix=BB_WORLD --check-prefix=BB_ALL
  : 'RUN: at line 7';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -triple x86_64 -S 
-fbasic-block-sections=list=/home/dave/ro_s/lp/clang/test/CodeGen/Inputs/basic-block-sections.funcnames
 -o - < /home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c | 
/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c 
--check-prefix=BB_WORLD --check-prefix=BB_LIST
  : 'RUN: at line 8';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -triple x86_64 -S 
-fbasic-block-sections=all -funique-basic-block-section-names -o - < 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c | 
/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c 
--check-prefix=UNIQUE
  : 'RUN: at line 9';   not /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc 
-fbasic-block-sections=list= -emit-obj 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c 2>&1 | 
/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c 
--check-prefix=ERROR
  --
  Exit Code: 1
  
  Command Output (stderr):
  --
  /home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c:42:11: error: 
ERROR: expected string not found in input
  // ERROR: error: unable to load basic block sections function list: 'No such 
file or directory'
^
  :1:1: note: scanning from here
  error: unable to open output file '': 'Read-only file system'
  ^
  
  Input file: 
  Check file: /home/dave/ro_s/lp/clang/test/CodeGen/basic-block-sections.c
  
  -dump-input=help explains the following input dump.
  
  Input was:
  <<
1: error: unable to open output file '': 'Read-only file system'
  check:42 X 
error: no match found
2: 1 error generated.
  check:42 ~~
  >>
  
  --
  
  
  
  Failed Tests (1):
Clang :: CodeGen/basic-block-sections.c
  
  
  Testing Time: 76.20s
Unsupported  :   341
Passed   : 26404
Expectedly Failed:28
Failed   : 1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89500

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

[PATCH] D84013: Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Not fighting with how `lit`, `FileCheck`, and shell input/output work would 
help here:

  FAIL: Clang :: Modules/ModuleDebugInfoDwoId.cpp (1 of 1)
   TEST 'Clang :: Modules/ModuleDebugInfoDwoId.cpp' FAILED 

  Script:
  --
  : 'RUN: at line 3';   rm -rf 
/tmp/l/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.cache
  : 'RUN: at line 4';   /tmp/l/r/bin/clang -cc1 -internal-isystem 
/tmp/l/r/lib/clang/12.0.0/include -nostdsysteminc -triple 
x86_64-unknown-linux-gnu -x objective-c++ -std=c++11 -debugger-tuning=lldb 
-debug-info-kind=limited -fmodules -fmodule-format=obj -dwarf-ext-refs 
-fimplicit-module-maps 
-fmodules-cache-path=/tmp/l/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.cache
 /home/dave/s/l/clang/test/Modules/ModuleDebugInfoDwoId.cpp -I 
/home/dave/s/l/clang/test/Modules/Inputs -emit-llvm -o - -mllvm 
-debug-only=pchcontainer | /tmp/l/r/bin/FileCheck 
--check-prefixes=CHECK,CHECK-REALIDS 
/home/dave/s/l/clang/test/Modules/ModuleDebugInfoDwoId.cpp
  --
  Exit Code: 2
  
  Command Output (stderr):
  --
  clang (LLVM option parsing): Unknown command line argument 
'-debug-only=pchcontainer'.  Try: 'clang (LLVM option parsing) --help'
  clang (LLVM option parsing): Did you mean '--debug-pass=pchcontainer'?
  FileCheck error: '' is empty.
  FileCheck command line:  /tmp/l/r/bin/FileCheck 
--check-prefixes=CHECK,CHECK-REALIDS 
/home/dave/s/l/clang/test/Modules/ModuleDebugInfoDwoId.cpp
  
  --
  
  
  
  Failed Tests (1):
Clang :: Modules/ModuleDebugInfoDwoId.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84013

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

[PATCH] D84013: Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I have an auto-bisecting cron job that has identified the "reland" as breaking 
the test suite on Fedora 32 (x86). Is there a quick fix or can we revert the 
reland?

  FAIL: Clang :: Modules/ModuleDebugInfoDwoId.cpp (12657 of 68968)
   TEST 'Clang :: Modules/ModuleDebugInfoDwoId.cpp' FAILED 

  Script:
  --
  : 'RUN: at line 3';   rm -rf 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.cache
  : 'RUN: at line 4';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -triple 
x86_64-unknown-linux-gnu -x objective-c++ -std=c++11 -debugger-tuning=lldb 
-debug-info-kind=limited -fmodules -fmodule-format=obj -dwarf-ext-refs 
-fimplicit-module-maps 
-fmodules-cache-path=/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.cache
 /home/dave/ro_s/lp/clang/test/Modules/ModuleDebugInfoDwoId.cpp -I 
/home/dave/ro_s/lp/clang/test/Modules/Inputs -emit-llvm -o 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.ll
 -mllvm -debug-only=pchcontainer 2> 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.mod-out
  : 'RUN: at line 5';   cat 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.ll
 > 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.combined_output
  : 'RUN: at line 6';   cat 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.mod-out
 >> 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.combined_output
  : 'RUN: at line 7';   cat 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.combined_output
 | /tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/Modules/ModuleDebugInfoDwoId.cpp
  : 'RUN: at line 8';   cat 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.ll
 | /tmp/_update_lc/r/bin/FileCheck --check-prefix=CHECK-REALIDS 
/home/dave/ro_s/lp/clang/test/Modules/ModuleDebugInfoDwoId.cpp
  : 'RUN: at line 9';   cat 
/tmp/_update_lc/r/tools/clang/test/Modules/Output/ModuleDebugInfoDwoId.cpp.tmp.mod-out
 | /tmp/_update_lc/r/bin/FileCheck --check-prefix=CHECK-REALIDS 
/home/dave/ro_s/lp/clang/test/Modules/ModuleDebugInfoDwoId.cpp
  --
  Exit Code: 1
  
  
  
  Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
  
  Failed Tests (1):
Clang :: Modules/ModuleDebugInfoDwoId.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84013

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

[PATCH] D82822: [OpenMP][FIX] Consistently use OpenMPIRBuilder if requested

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hello, I have a twice-daily auto-bisecting multi-stage cron job running on 
Fedora 32 (x86-64) that has identified this commit as failing my first stage 
test (release + no asserts). Is this expected? Can we get a quick fix or revert 
this?

FAIL: Clang :: OpenMP/irbuilder_nested_parallel_for.c (13233 of 67864)

- TEST 'Clang :: OpenMP/irbuilder_nested_parallel_for.c' FAILED 


Script:
---

: 'RUN: at line 2';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -verify -fopenmp 
-fopenmp-enable-irbuilder -x c++ -emit-llvm 
/home/dave/ro_s/lp/clang/test/OpenMP/irbuilder_nested_parallel_for.c -triple 
x86_64-unknown-unknown -fexceptions -fcxx-exceptions -o - | 
/tmp/_update_lc/r/bin/FileCheck --check-prefixes=CHECK 
/home/dave/ro_s/lp/clang/test/OpenMP/irbuilder_nested_parallel_for.c

: 'RUN: at line 3';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -fopenmp 
-fopenmp-enable-irbuilder -x c++ -triple x86_64-unknown-unknown -fexceptions 
-fcxx-exceptions -debug-info-kind=limited -std=c++11 -verify 
/home/dave/ro_s/lp/clang/test/OpenMP/irbuilder_nested_parallel_for.c -emit-llvm 
-o - | /tmp/_update_lc/r/bin/FileCheck --check-prefixes=CHECK-DEBUG 
/home/dave/ro_s/lp/clang/test/OpenMP/irbuilder_nested_parallel_for.c
---

Exit Code: 1

Command Output (stderr):


/home/dave/ro_s/lp/clang/test/OpenMP/irbuilder_nested_parallel_for.c:74:22: 
error: CHECK-DEBUG-NEXT: is not on the line after the previous match
// CHECK-DEBUG-NEXT: [[OMP_GLOBAL_THREAD_NUM:%.*]] = call i32 
@__kmpc_global_thread_num(%struct.ident_t* @12), !dbg !{{[0-9]*}}

  ^

:252:2: note: 'next' match was here
 %omp_global_thread_num1 = call i32 @__kmpc_global_thread_num(%struct.ident_t* 
@12), !dbg !52
 ^
:224:105: note: previous match ended here
 call void @llvm.dbg.declare(metadata double* %b.addr, metadata !45, metadata 
!DIExpression()), !dbg !46

  ^

:225:1: note: non-matching line after previous match is here
 %omp_global_thread_num = call i32 @__kmpc_global_thread_num(%struct.ident_t* 
@10), !dbg !47
^
/home/dave/ro_s/lp/clang/test/OpenMP/irbuilder_nested_parallel_for.c:192:22: 
error: CHECK-DEBUG-NEXT: expected string not found in input
// CHECK-DEBUG-NEXT: [[OMP_GLOBAL_THREAD_NUM:%.*]] = call i32 
@__kmpc_global_thread_num(%struct.ident_t* @25), !dbg !{{[0-9]*}}

  ^

:381:2: note: scanning from here
 %omp_global_thread_num = call i32 @__kmpc_global_thread_num(%struct.ident_t* 
@21), !dbg !83
 ^
:381:19: note: possible intended match here
 %omp_global_thread_num = call i32 @__kmpc_global_thread_num(%struct.ident_t* 
@21), !dbg !83

  ^

Input file: 
Check file: /home/dave/ro_s/lp/clang/test/OpenMP/irbuilder_nested_parallel_for.c

-dump-input=help explains the following input dump.

Input was:
<<

.
.
.
  247:
  248: omp.par.outlined.exit19.exitStub: ; preds = %omp.par.pre_finalize
  249:  ret void
  250:
  251: omp.par.region: ; preds = %omp.par.entry
  252:  %omp_global_thread_num1 = call i32 
@__kmpc_global_thread_num(%struct.ident_t* @12), !dbg !52

next:74 
!~~~
 error: match on wrong line

  253:  br label %omp_parallel
  254:
  255: omp_parallel: ; preds = %omp.par.region
  256:  call void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) 
@__kmpc_fork_call(%struct.ident_t* @12, i32 3, void (i32*, i32*, ...)* bitcast 
(void (i32*, i32*, i32*, double*, float**)* @_Z14parallel_for_1Pfid..omp_par to 
void (i32*, i32*, ...)*), i32* %a.addr, double* %b.addr, float** %r.addr), !dbg 
!53
  257:  br label %omp.par.outlined.exit
.
.
.
  376:  call void @llvm.dbg.declare(metadata float** %r.addr, metadata !77, 
metadata !DIExpression()), !dbg !78
  377:  store i32 %a, i32* %a.addr, align 4
  378:  call void @llvm.dbg.declare(metadata i32* %a.addr, metadata !79, 
metadata !DIExpression()), !dbg !80
  379:  store double %b, double* %b.addr, align 8
  380:  call void @llvm.dbg.declare(metadata double* %b.addr, metadata !81, 
metadata !DIExpression()), !dbg !82
  381:  %omp_global_thread_num = call i32 
@__kmpc_global_thread_num(%struct.ident_t* @21), !dbg !83

next:192'0  
X~~
 error: no match found
next:192'1 

[PATCH] D81728: [InstCombine] Add target-specific inst combining

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I have a multi-stage, auto-git-bisecting bot that has identifying this commit 
as the source of a regression on Fedora 32 (x86-64). This commit broke my first 
stage test (release, no asserts). Might a quick fix happen or do we need to 
revert this?

  FAIL: Clang :: CodeGen/aarch64-bf16-ldst-intrinsics.c (7188 of 67650)
   TEST 'Clang :: CodeGen/aarch64-bf16-ldst-intrinsics.c' 
FAILED 
  Script:
  --
  : 'RUN: at line 1';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -triple 
aarch64-arm-none-eabi -target-feature +neon -target-feature +bf16   -O2 
-emit-llvm /home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c 
-o - | /tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c 
--check-prefixes=CHECK,CHECK64
  : 'RUN: at line 3';   /tmp/_update_lc/r/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/r/lib/clang/12.0.0/include -nostdsysteminc -triple 
armv8.6a-arm-none-eabi -target-feature +neon -target-feature +bf16 -mfloat-abi 
hard   -O2 -emit-llvm 
/home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c -o - | 
/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c 
--check-prefixes=CHECK,CHECK32
  --
  Exit Code: 1
  
  Command Output (stderr):
  --
  /home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c:14:13: 
error: CHECK32: expected string not found in input
  // CHECK32: %1 = load <4 x bfloat>, <4 x bfloat>* %0, align 2
  ^
  :7:52: note: scanning from here
  define arm_aapcs_vfpcc <4 x bfloat> @test_vld1_bf16(bfloat* readonly %ptr) 
local_unnamed_addr #0 {
 ^
  :10:5: note: possible intended match here
   %vld1 = tail call <4 x bfloat> @llvm.arm.neon.vld1.v4bf16.p0i8(i8* %0, i32 2)
  ^
  /home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c:23:13: 
error: CHECK32: expected string not found in input
  // CHECK32: %1 = load <8 x bfloat>, <8 x bfloat>* %0, align 2
  ^
  :18:53: note: scanning from here
  define arm_aapcs_vfpcc <8 x bfloat> @test_vld1q_bf16(bfloat* readonly %ptr) 
local_unnamed_addr #2 {
  ^
  :21:5: note: possible intended match here
   %vld1 = tail call <8 x bfloat> @llvm.arm.neon.vld1.v8bf16.p0i8(i8* %0, i32 2)
  ^
  
  Input file: 
  Check file: 
/home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c
  
  -dump-input=help explains the following input dump.
  
  Input was:
  <<
  1: ; ModuleID = 
'/home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c'
  2: source_filename = 
"/home/dave/ro_s/lp/clang/test/CodeGen/aarch64-bf16-ldst-intrinsics.c"
  3: target datalayout = 
"e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
  4: target triple = "armv8.6a-arm-none-eabi"
  5:
  6: ; Function Attrs: nounwind readonly
  7: define arm_aapcs_vfpcc <4 x bfloat> @test_vld1_bf16(bfloat* 
readonly %ptr) local_unnamed_addr #0 {
  check:14'0
X~~ error: no match found
  8: entry:
  check:14'0 ~~
  9:  %0 = bitcast bfloat* %ptr to i8*
  check:14'0 ~
 10:  %vld1 = tail call <4 x bfloat> 
@llvm.arm.neon.vld1.v4bf16.p0i8(i8* %0, i32 2)
  check:14'0 
~~
  check:14'1 ?  
possible intended match
 11:  ret <4 x bfloat> %vld1
  check:14'0 ~~~
 12: }
  check:14'0 ~
 13:
  check:14'0 ~
 14: ; Function Attrs: argmemonly nounwind readonly
  check:14'0 ~~
 15: declare <4 x bfloat> @llvm.arm.neon.vld1.v4bf16.p0i8(i8*, i32) 
#1
  check:14'0 
~
 16:
  check:14'0 ~
 17: ; Function Attrs: nounwind readonly
  check:14'0 ~~~
 18: define arm_aapcs_vfpcc <8 x bfloat> @test_vld1q_bf16(bfloat* 
readonly %ptr) local_unnamed_addr #2 {
  check:14'0 
  check:23'0 
X~~ error: no match found
 19: entry:
  check:23'0 ~~
 20:  %0 = bitcast bfloat* %ptr to i8*
  check:23'0 ~
 21:  %vld1 = tail call <8 x bfloat> 
@llvm.arm.neon.vld1.v8bf16.p0i8(i8* %0, i32 

[PATCH] D82085: [TRE] allow TRE for non-capturing calls.

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hello. I have an auto-bisecting multi-stage bot that is failing on two after 
this change. Can we please revert this or commit a quick fix?

  FAIL: Clang :: CXX/class/class.compare/class.spaceship/p1.cpp (6232 of 64222)
   TEST 'Clang :: 
CXX/class/class.compare/class.spaceship/p1.cpp' FAILED 
  Script:
  --
  : 'RUN: at line 1';   /tmp/_update_lc/t/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/t/lib/clang/11.0.0/include -nostdsysteminc -std=c++2a -verify 
/home/dave/s/lp/clang/test/CXX/class/class.compare/class.spaceship/p1.cpp 
-fcxx-exceptions
  --
  Exit Code: 134
  
  Command Output (stderr):
  --
  clang: /home/dave/s/lp/clang/lib/Basic/SourceManager.cpp:917: clang::FileID 
clang::SourceManager::getFileIDLoaded(unsigned int) const: Assertion `0 && 
"Invalid SLocOffset or bad function choice"' failed.
  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.  Program arguments: /tmp/_update_lc/t/bin/clang -cc1 -internal-isystem 
/tmp/_update_lc/t/lib/clang/11.0.0/include -nostdsysteminc -std=c++2a -verify 
/home/dave/s/lp/clang/test/CXX/class/class.compare/class.spaceship/p1.cpp 
-fcxx-exceptions
  1.  
/home/dave/s/lp/clang/test/CXX/class/class.compare/class.spaceship/p1.cpp:127:38:
 current parser token ','
  2.  
/home/dave/s/lp/clang/test/CXX/class/class.compare/class.spaceship/p1.cpp:39:1: 
parsing namespace 'Deletedness'
  3.  
/home/dave/s/lp/clang/test/CXX/class/class.compare/class.spaceship/p1.cpp:123:12:
 parsing function body 'Deletedness::g'
  4.  
/home/dave/s/lp/clang/test/CXX/class/class.compare/class.spaceship/p1.cpp:123:12:
 in compound statement ('{}')
   #0 0x0359273f llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(/tmp/_update_lc/t/bin/clang+0x359273f)
   #1 0x03590912 llvm::sys::RunSignalHandlers() 
(/tmp/_update_lc/t/bin/clang+0x3590912)
   #2 0x03592bb5 SignalHandler(int) 
(/tmp/_update_lc/t/bin/clang+0x3592bb5)
   #3 0x77fa6a90 __restore_rt (/lib64/libpthread.so.0+0x14a90)
   #4 0x77b3da25 raise (/lib64/libc.so.6+0x3ca25)
   #5 0x77b26895 abort (/lib64/libc.so.6+0x25895)
   #6 0x77b26769 _nl_load_domain.cold (/lib64/libc.so.6+0x25769)
   #7 0x77b35e86 (/lib64/libc.so.6+0x34e86)
   #8 0x0375636c clang::SourceManager::getFileIDLoaded(unsigned int) 
const (/tmp/_update_lc/t/bin/clang+0x375636c)
   #9 0x03ee0bbb 
clang::VerifyDiagnosticConsumer::HandleDiagnostic(clang::DiagnosticsEngine::Level,
 clang::Diagnostic const&) (/tmp/_update_lc/t/bin/clang+0x3ee0bbb)
  #10 0x037501ab 
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const 
(/tmp/_update_lc/t/bin/clang+0x37501ab)
  #11 0x03749fca clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) 
(/tmp/_update_lc/t/bin/clang+0x3749fca)
  #12 0x04df0c60 clang::Sema::EmitCurrentDiagnostic(unsigned int) 
(/tmp/_update_lc/t/bin/clang+0x4df0c60)
  #13 0x05092783 (anonymous 
namespace)::DefaultedComparisonAnalyzer::visitBinaryOperator(clang::OverloadedOperatorKind,
 llvm::ArrayRef, (anonymous 
namespace)::DefaultedComparisonSubobject, clang::OverloadCandidateSet*) 
(/tmp/_update_lc/t/bin/clang+0x5092783)
  #14 0x05091dba (anonymous 
namespace)::DefaultedComparisonAnalyzer::visitExpandedSubobject(clang::QualType,
 (anonymous namespace)::DefaultedComparisonSubobject) 
(/tmp/_update_lc/t/bin/clang+0x5091dba)
  #15 0x05091b86 (anonymous 
namespace)::DefaultedComparisonVisitor<(anonymous 
namespace)::DefaultedComparisonAnalyzer, (anonymous 
namespace)::DefaultedComparisonInfo, (anonymous 
namespace)::DefaultedComparisonInfo, (anonymous 
namespace)::DefaultedComparisonSubobject>::visitSubobjects((anonymous 
namespace)::DefaultedComparisonInfo&, clang::CXXRecordDecl*, clang::Qualifiers) 
(/tmp/_update_lc/t/bin/clang+0x5091b86)
  #16 0x05058c8c (anonymous 
namespace)::DefaultedComparisonAnalyzer::visit() 
(/tmp/_update_lc/t/bin/clang+0x5058c8c)
  #17 0x0505ab22 
clang::Sema::DiagnoseDeletedDefaultedFunction(clang::FunctionDecl*) 
(/tmp/_update_lc/t/bin/clang+0x505ab22)
  #18 0x053e60ed 
clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, 
clang::BinaryOperatorKind, clang::UnresolvedSetImpl const&, clang::Expr*, 
clang::Expr*, bool, bool, clang::FunctionDecl*) 
(/tmp/_update_lc/t/bin/clang+0x53e60ed)
  #19 0x0514270a BuildOverloadedBinOp(clang::Sema&, clang::Scope*, 
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) 
(/tmp/_update_lc/t/bin/clang+0x514270a)
  #20 0x050fbf49 clang::Sema::ActOnBinOp(clang::Scope*, 
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) 
(/tmp/_update_lc/t/bin/clang+0x50fbf49)
  #21 0x04d52ccc 
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) (/tmp/_update_lc/t/bin/clang+0x4d52cc

[PATCH] D82259: Deprecate error prone temporary directory APIs

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki abandoned this revision.
davezarzycki added a comment.

Now that my core concern is addressed (moving clang's default module cache out 
of /tmp), I don't have the time to push for this deprecation. Sorry.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82259



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

[PATCH] D82362: Move default module cache from system temporary directory

[David Zarzycki via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbb26838ceffb: [clang driver] Move default module cache from 
system temporary directory (authored by davezarzycki).

Changed prior to commit:
  https://reviews.llvm.org/D82362?vs=272655&id=273674#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82362

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/modules-cache-path.m
  clang/unittests/Driver/ModuleCacheTest.cpp
  llvm/lib/Support/Unix/Path.inc

Index: llvm/lib/Support/Unix/Path.inc
===
--- llvm/lib/Support/Unix/Path.inc
+++ llvm/lib/Support/Unix/Path.inc
@@ -1133,19 +1133,6 @@
   return true;
 }
 
-bool cache_directory(SmallVectorImpl &result) {
-  if (const char *RequestedDir = getenv("XDG_CACHE_HOME")) {
-result.clear();
-result.append(RequestedDir, RequestedDir + strlen(RequestedDir));
-return true;
-  }
-  if (!home_directory(result)) {
-return false;
-  }
-  append(result, ".cache");
-  return true;
-}
-
 static bool getDarwinConfDir(bool TempDir, SmallVectorImpl &Result) {
   #if defined(_CS_DARWIN_USER_TEMP_DIR) && defined(_CS_DARWIN_USER_CACHE_DIR)
   // On Darwin, use DARWIN_USER_TEMP_DIR or DARWIN_USER_CACHE_DIR.
@@ -1171,6 +1158,27 @@
   return false;
 }
 
+bool cache_directory(SmallVectorImpl &result) {
+#ifdef __APPLE__
+  if (getDarwinConfDir(false/*tempDir*/, result)) {
+return true;
+  }
+#else
+  // XDG_CACHE_HOME as defined in the XDG Base Directory Specification:
+  // http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
+  if (const char *RequestedDir = getenv("XDG_CACHE_HOME")) {
+result.clear();
+result.append(RequestedDir, RequestedDir + strlen(RequestedDir));
+return true;
+  }
+#endif
+  if (!home_directory(result)) {
+return false;
+  }
+  append(result, ".cache");
+  return true;
+}
+
 static const char *getEnvTempDir() {
   // Check whether the temporary directory is specified by an environment
   // variable.
Index: clang/unittests/Driver/ModuleCacheTest.cpp
===
--- clang/unittests/Driver/ModuleCacheTest.cpp
+++ clang/unittests/Driver/ModuleCacheTest.cpp
@@ -21,7 +21,7 @@
   SmallString<128> Buf;
   Driver::getDefaultModuleCachePath(Buf);
   StringRef Path = Buf;
-  EXPECT_TRUE(Path.find("org.llvm.clang") != Path.npos);
+  EXPECT_TRUE(Path.find("clang") != Path.npos);
   EXPECT_TRUE(Path.endswith("ModuleCache"));  
 }
 } // end anonymous namespace.
Index: clang/test/Driver/modules-cache-path.m
===
--- clang/test/Driver/modules-cache-path.m
+++ clang/test/Driver/modules-cache-path.m
@@ -1,5 +1,2 @@
-// RUN: env USERNAME=asdf LOGNAME=asdf %clang -fmodules -### %s 2>&1 | FileCheck %s -check-prefix=CHECK-SET
-// CHECK-SET: -fmodules-cache-path={{.*}}org.llvm.clang.asdf{{[/\\]+}}ModuleCache
-
 // RUN: %clang -fmodules -### %s 2>&1 | FileCheck %s -check-prefix=CHECK-DEFAULT
-// CHECK-DEFAULT: -fmodules-cache-path={{.*}}org.llvm.clang.{{[A-Za-z0-9_]*[/\\]+}}ModuleCache
+// CHECK-DEFAULT: -fmodules-cache-path={{.*}}clang{{[/\\]+}}ModuleCache
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -721,38 +721,6 @@
   }
 }
 
-static void appendUserToPath(SmallVectorImpl &Result) {
-#ifdef LLVM_ON_UNIX
-  const char *Username = getenv("LOGNAME");
-#else
-  const char *Username = getenv("USERNAME");
-#endif
-  if (Username) {
-// Validate that LoginName can be used in a path, and get its length.
-size_t Len = 0;
-for (const char *P = Username; *P; ++P, ++Len) {
-  if (!clang::isAlphanumeric(*P) && *P != '_') {
-Username = nullptr;
-break;
-  }
-}
-
-if (Username && Len > 0) {
-  Result.append(Username, Username + Len);
-  return;
-}
-  }
-
-// Fallback to user id.
-#ifdef LLVM_ON_UNIX
-  std::string UID = llvm::utostr(getuid());
-#else
-  // FIXME: Windows seems to have an 'SID' that might work.
-  std::string UID = "";
-#endif
-  Result.append(UID.begin(), UID.end());
-}
-
 static void addPGOAndCoverageFlags(const ToolChain &TC, Compilation &C,
const Driver &D, const InputInfo &Output,
const ArgList &Args,
@@ -3201,11 +3169,13 @@
 CmdArgs.push_back("-fno-math-builtin");
 }
 
-void Driver::getDefaultModuleCachePath(SmallVectorImpl &Result) {
-  llvm::sys::path::system_temp_directory(/*erasedOnReboot=*/false, Result);
-  llvm::sys::path::append(Result, "org.llvm.clang.");
-  appendUserToPath(Result);
-  llvm::sys::path::append(Result, "ModuleCache");
+bool Dri

[PATCH] D82362: Move default module cache from system temporary directory

[David Zarzycki via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:3253
+  CmdArgs.push_back(Args.MakeArgString(Path));
+}
   }

sammccall wrote:
> what happens in the else case?
No module caching.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82362



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

[PATCH] D82362: Move default module cache from system temporary directory

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki created this revision.
davezarzycki added reviewers: compnerd, aprantl, jakehehrlich, espindola, 
respindola, ilya-biryukov, pcc, sammccall.
davezarzycki added projects: clang, LLVM.
Herald added a subscriber: hiraditya.

1. Shared writable directories like /tmp are a security problem.
2. Systems provide dedicated cache directories these days anyway.

As a followup, I hope to deprecate LLVM's 
`llvm::sys::path::system_temp_directory()`. See: https://reviews.llvm.org/D82259


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D82362

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/modules-cache-path.m
  clang/unittests/Driver/ModuleCacheTest.cpp
  llvm/lib/Support/Unix/Path.inc

Index: llvm/lib/Support/Unix/Path.inc
===
--- llvm/lib/Support/Unix/Path.inc
+++ llvm/lib/Support/Unix/Path.inc
@@ -1133,19 +1133,6 @@
   return true;
 }
 
-bool cache_directory(SmallVectorImpl &result) {
-  if (const char *RequestedDir = getenv("XDG_CACHE_HOME")) {
-result.clear();
-result.append(RequestedDir, RequestedDir + strlen(RequestedDir));
-return true;
-  }
-  if (!home_directory(result)) {
-return false;
-  }
-  append(result, ".cache");
-  return true;
-}
-
 static bool getDarwinConfDir(bool TempDir, SmallVectorImpl &Result) {
   #if defined(_CS_DARWIN_USER_TEMP_DIR) && defined(_CS_DARWIN_USER_CACHE_DIR)
   // On Darwin, use DARWIN_USER_TEMP_DIR or DARWIN_USER_CACHE_DIR.
@@ -1171,6 +1158,27 @@
   return false;
 }
 
+bool cache_directory(SmallVectorImpl &result) {
+#ifdef __APPLE__
+  if (getDarwinConfDir(false/*tempDir*/, result)) {
+return true;
+  }
+#else
+  // XDG_CACHE_HOME as defined in the XDG Base Directory Specification:
+  // http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
+  if (const char *RequestedDir = getenv("XDG_CACHE_HOME")) {
+result.clear();
+result.append(RequestedDir, RequestedDir + strlen(RequestedDir));
+return true;
+  }
+#endif
+  if (!home_directory(result)) {
+return false;
+  }
+  append(result, ".cache");
+  return true;
+}
+
 static const char *getEnvTempDir() {
   // Check whether the temporary directory is specified by an environment
   // variable.
Index: clang/unittests/Driver/ModuleCacheTest.cpp
===
--- clang/unittests/Driver/ModuleCacheTest.cpp
+++ clang/unittests/Driver/ModuleCacheTest.cpp
@@ -21,7 +21,7 @@
   SmallString<128> Buf;
   Driver::getDefaultModuleCachePath(Buf);
   StringRef Path = Buf;
-  EXPECT_TRUE(Path.find("org.llvm.clang") != Path.npos);
+  EXPECT_TRUE(Path.find("clang") != Path.npos);
   EXPECT_TRUE(Path.endswith("ModuleCache"));  
 }
 } // end anonymous namespace.
Index: clang/test/Driver/modules-cache-path.m
===
--- clang/test/Driver/modules-cache-path.m
+++ clang/test/Driver/modules-cache-path.m
@@ -1,5 +1,2 @@
-// RUN: env USERNAME=asdf LOGNAME=asdf %clang -fmodules -### %s 2>&1 | FileCheck %s -check-prefix=CHECK-SET
-// CHECK-SET: -fmodules-cache-path={{.*}}org.llvm.clang.asdf{{[/\\]+}}ModuleCache
-
 // RUN: %clang -fmodules -### %s 2>&1 | FileCheck %s -check-prefix=CHECK-DEFAULT
-// CHECK-DEFAULT: -fmodules-cache-path={{.*}}org.llvm.clang.{{[A-Za-z0-9_]*[/\\]+}}ModuleCache
+// CHECK-DEFAULT: -fmodules-cache-path={{.*}}clang{{[/\\]+}}ModuleCache
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -733,38 +733,6 @@
   }
 }
 
-static void appendUserToPath(SmallVectorImpl &Result) {
-#ifdef LLVM_ON_UNIX
-  const char *Username = getenv("LOGNAME");
-#else
-  const char *Username = getenv("USERNAME");
-#endif
-  if (Username) {
-// Validate that LoginName can be used in a path, and get its length.
-size_t Len = 0;
-for (const char *P = Username; *P; ++P, ++Len) {
-  if (!clang::isAlphanumeric(*P) && *P != '_') {
-Username = nullptr;
-break;
-  }
-}
-
-if (Username && Len > 0) {
-  Result.append(Username, Username + Len);
-  return;
-}
-  }
-
-// Fallback to user id.
-#ifdef LLVM_ON_UNIX
-  std::string UID = llvm::utostr(getuid());
-#else
-  // FIXME: Windows seems to have an 'SID' that might work.
-  std::string UID = "";
-#endif
-  Result.append(UID.begin(), UID.end());
-}
-
 static void addPGOAndCoverageFlags(const ToolChain &TC, Compilation &C,
const Driver &D, const InputInfo &Output,
const ArgList &Args,
@@ -3203,11 +3171,13 @@
 CmdArgs.push_back("-fno-math-builtin");
 }
 
-void Driver::getDefaultModuleCachePath(SmallVectorImpl &Result) {
-  llvm::sys::path::system_temp_directory(/*erasedOnReboot=*/false, Result);
-  llvm::sy

[PATCH] D82259: Deprecate error prone temporary directory APIs

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki updated this revision to Diff 272661.
davezarzycki added a comment.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Moved clang specific changes to: https://reviews.llvm.org/D82362


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82259

Files:
  lldb/source/Core/ModuleList.cpp
  llvm/include/llvm/Support/FileSystem.h
  llvm/include/llvm/Support/Path.h
  llvm/lib/Support/Path.cpp

Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -164,6 +164,41 @@
   FS_Name
 };
 
+// Avoid a deprecation warning by moving the createUniquePath body here.
+static void _createUniquePath(const Twine &Model,
+  SmallVectorImpl &ResultPath,
+  bool MakeAbsolute) {
+  SmallString<128> ModelStorage;
+  Model.toVector(ModelStorage);
+
+  if (MakeAbsolute) {
+// Make model absolute by prepending a temp directory if it's not already.
+if (!sys::path::is_absolute(Twine(ModelStorage))) {
+  SmallString<128> TDir;
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wdeprecated-declarations"
+#endif
+  sys::path::system_temp_directory(true, TDir);
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
+  sys::path::append(TDir, Twine(ModelStorage));
+  ModelStorage.swap(TDir);
+}
+  }
+
+  ResultPath = ModelStorage;
+  ResultPath.push_back(0);
+  ResultPath.pop_back();
+
+  // Replace '%' with random chars.
+  for (unsigned i = 0, e = ModelStorage.size(); i != e; ++i) {
+if (ModelStorage[i] == '%')
+  ResultPath[i] = "0123456789abcdef"[sys::Process::GetRandomNumber() & 15];
+  }
+}
+
 static std::error_code
 createUniqueEntity(const Twine &Model, int &ResultFD,
SmallVectorImpl &ResultPath, bool MakeAbsolute,
@@ -176,7 +211,7 @@
   // Checking which is racy, so we try a number of times, then give up.
   std::error_code EC;
   for (int Retries = 128; Retries > 0; --Retries) {
-sys::fs::createUniquePath(Model, ResultPath, MakeAbsolute);
+_createUniquePath(Model, ResultPath, MakeAbsolute);
 // Try to open + create the file.
 switch (Type) {
 case FS_File: {
@@ -778,28 +813,7 @@
 
 void createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
   bool MakeAbsolute) {
-  SmallString<128> ModelStorage;
-  Model.toVector(ModelStorage);
-
-  if (MakeAbsolute) {
-// Make model absolute by prepending a temp directory if it's not already.
-if (!sys::path::is_absolute(Twine(ModelStorage))) {
-  SmallString<128> TDir;
-  sys::path::system_temp_directory(true, TDir);
-  sys::path::append(TDir, Twine(ModelStorage));
-  ModelStorage.swap(TDir);
-}
-  }
-
-  ResultPath = ModelStorage;
-  ResultPath.push_back(0);
-  ResultPath.pop_back();
-
-  // Replace '%' with random chars.
-  for (unsigned i = 0, e = ModelStorage.size(); i != e; ++i) {
-if (ModelStorage[i] == '%')
-  ResultPath[i] = "0123456789abcdef"[sys::Process::GetRandomNumber() & 15];
-  }
+  return _createUniquePath(Model, ResultPath, MakeAbsolute);
 }
 
 std::error_code createUniqueFile(const Twine &Model, int &ResultFd,
Index: llvm/include/llvm/Support/Path.h
===
--- llvm/include/llvm/Support/Path.h
+++ llvm/include/llvm/Support/Path.h
@@ -363,7 +363,10 @@
 /// (e.g., TEMP on Windows, TMPDIR on *nix) to specify a temporary directory.
 ///
 /// @param result Holds the resulting path name.
-void system_temp_directory(bool erasedOnReboot, SmallVectorImpl &result);
+LLVM_ATTRIBUTE_DEPRECATED(
+void system_temp_directory(bool erasedOnReboot,
+   SmallVectorImpl &result),
+"Only meant for debugging due to trivial security problems");
 
 /// Get the user's home directory.
 ///
Index: llvm/include/llvm/Support/FileSystem.h
===
--- llvm/include/llvm/Support/FileSystem.h
+++ llvm/include/llvm/Support/FileSystem.h
@@ -800,8 +800,10 @@
 /// @param Model Name to base unique path off of.
 /// @param ResultPath Set to the file's path.
 /// @param MakeAbsolute Whether to use the system temp directory.
-void createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
-  bool MakeAbsolute);
+LLVM_ATTRIBUTE_DEPRECATED(
+void createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
+  bool MakeAbsolute),
+"Use createUniqueFile() or createUniqueDirectory()");
 
 /// Create a uniquely named file.
 ///
Index: lldb/source/Core/ModuleList.cpp
===
--- lldb/source/Core/ModuleList.cpp
+++ lldb/source/Core/ModuleList.cpp
@@ -82,8 +82,8 @@

[PATCH] D82259: Deprecate error prone temporary directory APIs

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki updated this revision to Diff 272434.
davezarzycki added a comment.

1. Respect Darwin and XDG cache directories.
2. Drop atypical reverse DNS in the path.
3. Make clang more robust if the default module path cannot be determined.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82259

Files:
  include/clang/Driver/Driver.h
  include/llvm/Support/FileSystem.h
  include/llvm/Support/Path.h
  lib/Driver/ToolChains/Clang.cpp
  lib/Support/Path.cpp
  lib/Support/Unix/Path.inc
  source/Core/ModuleList.cpp
  test/Driver/modules-cache-path.m
  unittests/Driver/ModuleCacheTest.cpp

Index: lib/Support/Unix/Path.inc
===
--- lib/Support/Unix/Path.inc
+++ lib/Support/Unix/Path.inc
@@ -1133,19 +1133,6 @@
   return true;
 }
 
-bool cache_directory(SmallVectorImpl &result) {
-  if (const char *RequestedDir = getenv("XDG_CACHE_HOME")) {
-result.clear();
-result.append(RequestedDir, RequestedDir + strlen(RequestedDir));
-return true;
-  }
-  if (!home_directory(result)) {
-return false;
-  }
-  append(result, ".cache");
-  return true;
-}
-
 static bool getDarwinConfDir(bool TempDir, SmallVectorImpl &Result) {
   #if defined(_CS_DARWIN_USER_TEMP_DIR) && defined(_CS_DARWIN_USER_CACHE_DIR)
   // On Darwin, use DARWIN_USER_TEMP_DIR or DARWIN_USER_CACHE_DIR.
@@ -1171,6 +1158,27 @@
   return false;
 }
 
+bool cache_directory(SmallVectorImpl &result) {
+#ifdef __APPLE__
+  if (getDarwinConfDir(false/*tempDir*/, result)) {
+return true;
+  }
+#else
+  // XDG_CACHE_HOME as defined in the XDG Base Directory Specification:
+  // http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
+  if (const char *RequestedDir = getenv("XDG_CACHE_HOME")) {
+result.clear();
+result.append(RequestedDir, RequestedDir + strlen(RequestedDir));
+return true;
+  }
+#endif
+  if (!home_directory(result)) {
+return false;
+  }
+  append(result, ".cache");
+  return true;
+}
+
 static const char *getEnvTempDir() {
   // Check whether the temporary directory is specified by an environment
   // variable.
Index: lib/Support/Path.cpp
===
--- lib/Support/Path.cpp
+++ lib/Support/Path.cpp
@@ -164,6 +164,41 @@
   FS_Name
 };
 
+// Avoid a deprecation warning by moving the createUniquePath body here.
+static void _createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
+  bool MakeAbsolute) {
+  SmallString<128> ModelStorage;
+  Model.toVector(ModelStorage);
+
+  if (MakeAbsolute) {
+// Make model absolute by prepending a temp directory if it's not already.
+if (!sys::path::is_absolute(Twine(ModelStorage))) {
+  SmallString<128> TDir;
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wdeprecated-declarations"
+#endif
+  sys::path::system_temp_directory(true, TDir);
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
+  sys::path::append(TDir, Twine(ModelStorage));
+  ModelStorage.swap(TDir);
+}
+  }
+
+  ResultPath = ModelStorage;
+  ResultPath.push_back(0);
+  ResultPath.pop_back();
+
+  // Replace '%' with random chars.
+  for (unsigned i = 0, e = ModelStorage.size(); i != e; ++i) {
+if (ModelStorage[i] == '%')
+  ResultPath[i] = "0123456789abcdef"[sys::Process::GetRandomNumber() & 15];
+  }
+}
+
+
 static std::error_code
 createUniqueEntity(const Twine &Model, int &ResultFD,
SmallVectorImpl &ResultPath, bool MakeAbsolute,
@@ -176,7 +211,7 @@
   // Checking which is racy, so we try a number of times, then give up.
   std::error_code EC;
   for (int Retries = 128; Retries > 0; --Retries) {
-sys::fs::createUniquePath(Model, ResultPath, MakeAbsolute);
+_createUniquePath(Model, ResultPath, MakeAbsolute);
 // Try to open + create the file.
 switch (Type) {
 case FS_File: {
@@ -777,29 +812,8 @@
 }
 
 void createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
-  bool MakeAbsolute) {
-  SmallString<128> ModelStorage;
-  Model.toVector(ModelStorage);
-
-  if (MakeAbsolute) {
-// Make model absolute by prepending a temp directory if it's not already.
-if (!sys::path::is_absolute(Twine(ModelStorage))) {
-  SmallString<128> TDir;
-  sys::path::system_temp_directory(true, TDir);
-  sys::path::append(TDir, Twine(ModelStorage));
-  ModelStorage.swap(TDir);
-}
-  }
-
-  ResultPath = ModelStorage;
-  ResultPath.push_back(0);
-  ResultPath.pop_back();
-
-  // Replace '%' with random chars.
-  for (unsigned i = 0, e = ModelStorage.size(); i != e; ++i) {
-if (ModelStorage[i] == '%')
-  ResultPath[i] = "0123456789abcdef"[sys::Process::GetRandomNumber() & 15];
-  }
+  bool MakeAbsolute) {
+  return _createUniquePath(Model, ResultPath, MakeAbsolute);
 }
 
 std::error

[PATCH] D82259: Deprecate error prone temporary directory APIs

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Sure, we can honor XDG_CACHE_DIR. Maybe as a followup, somebody can wire up 
Darwin's cache directory (which is retrievable via a BSD specific `confstr()` 
API with `_CS_DARWIN_USER_CACHE_DIR`). I'm not sure about other platforms.

I'll wait for more feedback before updating the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82259



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

[PATCH] D82259: Deprecate error prone temporary directory APIs

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki created this revision.
davezarzycki added reviewers: compnerd, aprantl, jakehehrlich, espindola, 
respindola, ilya-biryukov, pcc, sammccall.
davezarzycki added a project: LLVM.
Herald added subscribers: cfe-commits, hiraditya.
Herald added a project: clang.

Naive usage of shared temporary directories in Unix is a classic security 
problem. Let's deprecate two APIs that enable unsafe code and encourage people 
to use `createUniqueFile` or `createUniqueDirectory` instead.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D82259

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/include/llvm/Support/FileSystem.h
  llvm/include/llvm/Support/Path.h
  llvm/lib/Support/Path.cpp

Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -164,6 +164,41 @@
   FS_Name
 };
 
+// Avoid a deprecation warning by moving the createUniquePath body here.
+static void _createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
+  bool MakeAbsolute) {
+  SmallString<128> ModelStorage;
+  Model.toVector(ModelStorage);
+
+  if (MakeAbsolute) {
+// Make model absolute by prepending a temp directory if it's not already.
+if (!sys::path::is_absolute(Twine(ModelStorage))) {
+  SmallString<128> TDir;
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wdeprecated-declarations"
+#endif
+  sys::path::system_temp_directory(true, TDir);
+#ifdef __clang__
+#pragma clang diagnostic pop
+#endif
+  sys::path::append(TDir, Twine(ModelStorage));
+  ModelStorage.swap(TDir);
+}
+  }
+
+  ResultPath = ModelStorage;
+  ResultPath.push_back(0);
+  ResultPath.pop_back();
+
+  // Replace '%' with random chars.
+  for (unsigned i = 0, e = ModelStorage.size(); i != e; ++i) {
+if (ModelStorage[i] == '%')
+  ResultPath[i] = "0123456789abcdef"[sys::Process::GetRandomNumber() & 15];
+  }
+}
+
+
 static std::error_code
 createUniqueEntity(const Twine &Model, int &ResultFD,
SmallVectorImpl &ResultPath, bool MakeAbsolute,
@@ -176,7 +211,7 @@
   // Checking which is racy, so we try a number of times, then give up.
   std::error_code EC;
   for (int Retries = 128; Retries > 0; --Retries) {
-sys::fs::createUniquePath(Model, ResultPath, MakeAbsolute);
+_createUniquePath(Model, ResultPath, MakeAbsolute);
 // Try to open + create the file.
 switch (Type) {
 case FS_File: {
@@ -777,29 +812,8 @@
 }
 
 void createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
-  bool MakeAbsolute) {
-  SmallString<128> ModelStorage;
-  Model.toVector(ModelStorage);
-
-  if (MakeAbsolute) {
-// Make model absolute by prepending a temp directory if it's not already.
-if (!sys::path::is_absolute(Twine(ModelStorage))) {
-  SmallString<128> TDir;
-  sys::path::system_temp_directory(true, TDir);
-  sys::path::append(TDir, Twine(ModelStorage));
-  ModelStorage.swap(TDir);
-}
-  }
-
-  ResultPath = ModelStorage;
-  ResultPath.push_back(0);
-  ResultPath.pop_back();
-
-  // Replace '%' with random chars.
-  for (unsigned i = 0, e = ModelStorage.size(); i != e; ++i) {
-if (ModelStorage[i] == '%')
-  ResultPath[i] = "0123456789abcdef"[sys::Process::GetRandomNumber() & 15];
-  }
+  bool MakeAbsolute) {
+  return _createUniquePath(Model, ResultPath, MakeAbsolute);
 }
 
 std::error_code createUniqueFile(const Twine &Model, int &ResultFd,
Index: llvm/include/llvm/Support/Path.h
===
--- llvm/include/llvm/Support/Path.h
+++ llvm/include/llvm/Support/Path.h
@@ -363,7 +363,10 @@
 /// (e.g., TEMP on Windows, TMPDIR on *nix) to specify a temporary directory.
 ///
 /// @param result Holds the resulting path name.
-void system_temp_directory(bool erasedOnReboot, SmallVectorImpl &result);
+LLVM_ATTRIBUTE_DEPRECATED(
+void system_temp_directory(bool erasedOnReboot, SmallVectorImpl &result),
+  "Only meant for debugging due to trivial security problems"
+);
 
 /// Get the user's home directory.
 ///
Index: llvm/include/llvm/Support/FileSystem.h
===
--- llvm/include/llvm/Support/FileSystem.h
+++ llvm/include/llvm/Support/FileSystem.h
@@ -800,8 +800,11 @@
 /// @param Model Name to base unique path off of.
 /// @param ResultPath Set to the file's path.
 /// @param MakeAbsolute Whether to use the system temp directory.
-void createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
-  bool MakeAbsolute);
+LLVM_ATTRIBUTE_DEPRECATED(
+  void createUniquePath(const Twine &Model, SmallVectorImpl &ResultPath,
+bool MakeAbsolute),
+  "Use createUniqueFile() or createUniqueDirectory()"
+);
 
 /// Create a uniquely named file.
 ///
Index: clang/lib/Driver/ToolChains/Clang

[PATCH] D79673: Allow 32-bit pointer extensions to be used without -fms-extensions

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki abandoned this revision.
davezarzycki added a comment.

I'm going to abandon this change for now. The problem is that the MS extensions 
are not as pervasive through the language as I wanted. For example, I'd really 
like them to work on aggregate types. This would allow all of the pointers to 
said types to not need annotation, unlike the current MS model.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79673



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

[PATCH] D79673: Allow 32-bit pointer extensions to be used without -fms-extensions

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D79673#2028204 , @rnk wrote:

> Needs a test.
>
> I believe these are only implemented for x86 in LLVM. What happens if you try 
> to use this on non-x86? I wouldn't be surprised if we crash, but we should 
> probably produce a proper error and test it.


I just tested top-of-tree `clang -fms-extensions -target arm64-unknown-linux` 
(sans this patch) and apparently the attributes are ignored, which could cause 
crashes at run time if a later compiler actually honors this attributes on 
non-x86 targets and people try to mix object files created by older and newer 
compilers.

I agree that the bugs you point out are worth fixing. That being said, I'm not 
looking to fix all of the bugs with these attributes with this patch. If it's 
okay, I'd like to focus on exposing the feature outside of `-fms-extensions`. 
If people want to ignore the Microsoft extension and design how this feature 
"should" work, that's fine too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79673



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

[PATCH] D79673: Allow 32-bit pointer extensions to be used without -fms-extensions

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki created this revision.
davezarzycki added reviewers: akhuang, rnk, rsmith.
davezarzycki added a project: clang.
Herald added a reviewer: aaron.ballman.

One should not need to use `-fms-extensions` in order to use 32-bit pointers on 
64-bit platforms.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79673

Files:
  clang/include/clang/Basic/Attr.td


Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -3080,22 +3080,22 @@
 }
 
 def Ptr32 : TypeAttr {
-  let Spellings = [Keyword<"__ptr32">];
+  let Spellings = [Keyword<"__ptr32">, Clang<"ptr32">];
   let Documentation = [Ptr32Docs];
 }
 
 def Ptr64 : TypeAttr {
-  let Spellings = [Keyword<"__ptr64">];
+  let Spellings = [Keyword<"__ptr64">, Clang<"ptr64">];
   let Documentation = [Ptr64Docs];
 }
 
 def SPtr : TypeAttr {
-  let Spellings = [Keyword<"__sptr">];
+  let Spellings = [Keyword<"__sptr">, Clang<"sptr">];
   let Documentation = [SPtrDocs];
 }
 
 def UPtr : TypeAttr {
-  let Spellings = [Keyword<"__uptr">];
+  let Spellings = [Keyword<"__uptr">, Clang<"uptr">];
   let Documentation = [UPtrDocs];
 }
 


Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -3080,22 +3080,22 @@
 }
 
 def Ptr32 : TypeAttr {
-  let Spellings = [Keyword<"__ptr32">];
+  let Spellings = [Keyword<"__ptr32">, Clang<"ptr32">];
   let Documentation = [Ptr32Docs];
 }
 
 def Ptr64 : TypeAttr {
-  let Spellings = [Keyword<"__ptr64">];
+  let Spellings = [Keyword<"__ptr64">, Clang<"ptr64">];
   let Documentation = [Ptr64Docs];
 }
 
 def SPtr : TypeAttr {
-  let Spellings = [Keyword<"__sptr">];
+  let Spellings = [Keyword<"__sptr">, Clang<"sptr">];
   let Documentation = [SPtrDocs];
 }
 
 def UPtr : TypeAttr {
-  let Spellings = [Keyword<"__uptr">];
+  let Spellings = [Keyword<"__uptr">, Clang<"uptr">];
   let Documentation = [UPtrDocs];
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75068: libclang: Add static build support for Windows

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D75068#2004885 , @cristian.adam 
wrote:

> In D75068#2004072 , @davezarzycki 
> wrote:
>
> > Rather than wholly reverting this, I committed a fix: 
> > 665471907a5c072c6653a38c35f35e5d54cef220 
> > 
> >
> > The problem is that "NOT LIBCLANG_BUILD_STATIC" does not imply PIC, so 
> > there is no point in trying to build the SHARED version. Please let me know 
> > if I somehow missed something. Thanks!
>
>
> @thakis  has a use case at https://reviews.llvm.org/D74907 building a SHARED 
> libclang with `LLVM_ENABLE_PIC` set to `OFF`.
>
> Would the variant `if(LLVM_ENABLE_PIC OR (WIN32 AND NOT 
> LIBCLANG_BUILD_STATIC))`  work for the Fedora case?


Fedora is not WIN32, so sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75068



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

[PATCH] D75068: libclang: Add static build support for Windows

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Rather than wholly reverting this, I committed a fix: 
665471907a5c072c6653a38c35f35e5d54cef220 


The problem is that "NOT LIBCLANG_BUILD_STATIC" does not imply PIC, so there is 
no point in trying to build the SHARED version. Please let me know if I somehow 
missed something. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75068



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

[PATCH] D75068: libclang: Add static build support for Windows

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This breaks building libclang on Fedora 32 with clang 10.0 and lld 10.0. Do you 
mind if I revert this tomorrow if a quick fix cannot be found? Here is the 
relevant diagnostics:

FAILED: lib64/libclang.so.11
: && /usr/bin/clang++ -fPIC -Werror=switch -stdlib=libc++ 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default 
-Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections 
-fno-common -Woverloaded-virtual -Wno-nested-anon-types -O2 -DNDEBUG  
-stdlib=libc++ -Wl,-z,defs -Wl,-z,nodelete -fuse-ld=lld -Wl,--color-diagnostics 
  -Wl,-O3 -Wl,--gc-sections  
-Wl,--version-script,"/tmp/_update_lc/r/tools/clang/tools/libclang/libclang.exports"
 -shared -Wl,-soname,libclang.so.11git -o lib64/libclang.so.11 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/ARCMigrate.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/BuildSystem.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CIndex.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CIndexCXX.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CIndexCodeCompletion.cpp.o
 tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CIndexDiagnostic.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CIndexHigh.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CIndexInclusionStack.cpp.o
 tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CIndexUSRs.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CIndexer.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXComment.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXCursor.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXIndexDataConsumer.cpp.o
 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXCompilationDatabase.cpp.o
 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXLoadedDiagnostic.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXSourceLocation.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXStoredDiagnostic.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXString.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/CXType.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/Indexing.cpp.o 
tools/clang/tools/libclang/CMakeFiles/obj.libclang.dir/FatalErrorHandler.cpp.o  
-Wl,-rpath,"\$ORIGIN/../lib64"  lib64/libclangAST.a  lib64/libclangBasic.a  
lib64/libclangDriver.a  lib64/libclangFrontend.a  lib64/libclangIndex.a  
lib64/libclangLex.a  lib64/libclangSema.a  lib64/libclangSerialization.a  
lib64/libclangTooling.a  lib64/libLLVMSupport.a  lib64/libclangARCMigrate.a  
-ldl  lib64/libLLVMX86CodeGen.a  lib64/libLLVMX86AsmParser.a  
lib64/libLLVMX86Desc.a  lib64/libLLVMX86Disassembler.a  lib64/libLLVMX86Info.a  
lib64/libLLVMAArch64CodeGen.a  lib64/libLLVMAArch64AsmParser.a  
lib64/libLLVMAArch64Desc.a  lib64/libLLVMAArch64Disassembler.a  
lib64/libLLVMAArch64Info.a  lib64/libLLVMAArch64Utils.a  
lib64/libLLVMPowerPCCodeGen.a  lib64/libLLVMPowerPCAsmParser.a  
lib64/libLLVMPowerPCDesc.a  lib64/libLLVMPowerPCDisassembler.a  
lib64/libLLVMPowerPCInfo.a  lib64/libLLVMRISCVCodeGen.a  
lib64/libLLVMRISCVAsmParser.a  lib64/libLLVMRISCVDesc.a  
lib64/libLLVMRISCVDisassembler.a  lib64/libLLVMRISCVInfo.a  
lib64/libLLVMRISCVUtils.a  lib64/libLLVMCore.a  lib64/libLLVMSupport.a  
lib64/libclangFormat.a  lib64/libclangToolingInclusions.a  
lib64/libclangToolingCore.a  lib64/libclangFrontend.a  lib64/libclangDriver.a  
lib64/libLLVMOption.a  lib64/libclangParse.a  lib64/libclangSerialization.a  
lib64/libclangSema.a  lib64/libclangEdit.a  lib64/libclangRewrite.a  
lib64/libclangAnalysis.a  lib64/libclangASTMatchers.a  lib64/libclangAST.a  
lib64/libclangLex.a  lib64/libclangBasic.a  lib64/libLLVMFrontendOpenMP.a  
lib64/libLLVMCFGuard.a  lib64/libLLVMAArch64Desc.a  lib64/libLLVMAArch64Info.a  
lib64/libLLVMAArch64Utils.a  lib64/libLLVMAsmPrinter.a  
lib64/libLLVMDebugInfoDWARF.a  lib64/libLLVMGlobalISel.a  
lib64/libLLVMSelectionDAG.a  lib64/libLLVMCodeGen.a  lib64/libLLVMScalarOpts.a  
lib64/libLLVMAggressiveInstCombine.a  lib64/libLLVMInstCombine.a  
lib64/libLLVMBitWriter.a  lib64/libLLVMTransformUtils.a  lib64/libLLVMTarget.a  
lib64/libLLVMAnalysis.a  lib64/libLLVMProfileData.a  lib64/libLLVMObject.a  
lib64/libLLVMBitReader.a  lib64/libLLVMCore.a  lib64/libLLVMRemarks.a  
lib64/libLLVMBitstreamReader.a  lib64/libLLVMTextAPI.a  lib64/libLLVMMCParser.a 
 lib64/libLLVMMCDisassembler.a  lib64/libLLVMMC.a  lib64/libLLVMBinaryFormat.a  
lib64/libLLVMDebugInfoCodeView.a  lib64/libLLVMDebugInfoMSF.a  
lib64/libLLVMSupport.a  -lz  -lrt  -ldl  -ltinfo  -lpthread  -lm  
/usr/lib64/libz3.so  lib64/libLLVMDemangle.a && :
ld.lld:

[PATCH] D74298: Honor -finline-functions and -finline-hint-functions at -O0

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki abandoned this revision.
davezarzycki added a comment.

I'm abandoning this due to lack of time and the problem being more involved 
than I thought.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74298



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

[PATCH] D74298: Honor -finline-functions and -finline-hint-functions at -O0

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hi @MaskRay – I was just looking at the source history. I didn't test the old 
way. As it turns out there isn't a regression, but just some unexplained code 
in the current clang option parsing. And the `-disable-O0-optnone` is a useful 
hint. Thanks! I've been hacking on clang and trying to get the normal inliner 
pass to run at -O0, but with no luck so far.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74298



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

[PATCH] D74298: Honor -finline-functions and -finline-hint-functions at -O0

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hi @lebedev.ri – Before I add a small new test file, is there an existing one 
that you know of that would be good to extend?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74298



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

[PATCH] D74298: Honor -finline-functions and -finline-hint-functions at -O0

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki created this revision.
davezarzycki added a reviewer: chandlerc.
davezarzycki added a project: clang.

This fixes a regression introduced (over three years ago!) by 
fcd33149b48885ab8e4ca4ffb6977bce5be2e623.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D74298

Files:
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -694,19 +694,23 @@
   Opts.setInlining((Opts.OptimizationLevel == 0)
? CodeGenOptions::OnlyAlwaysInlining
: CodeGenOptions::NormalInlining);
-  // Explicit inlining flags can disable some or all inlining even at
-  // optimization levels above zero.
+  // Handle inlining overrides
   if (Arg *InlineArg = Args.getLastArg(
   options::OPT_finline_functions, options::OPT_finline_hint_functions,
   options::OPT_fno_inline_functions, options::OPT_fno_inline)) {
-if (Opts.OptimizationLevel > 0) {
-  const Option &InlineOpt = InlineArg->getOption();
-  if (InlineOpt.matches(options::OPT_finline_functions))
-Opts.setInlining(CodeGenOptions::NormalInlining);
-  else if (InlineOpt.matches(options::OPT_finline_hint_functions))
-Opts.setInlining(CodeGenOptions::OnlyHintInlining);
-  else
-Opts.setInlining(CodeGenOptions::OnlyAlwaysInlining);
+const Option &InlineOpt = InlineArg->getOption();
+if (InlineOpt.matches(options::OPT_fno_inline)) {
+  Opts.setInlining(CodeGenOptions::OnlyAlwaysInlining);
+} else if (InlineOpt.matches(options::OPT_fno_inline_functions)) {
+  Opts.setInlining(CodeGenOptions::OnlyAlwaysInlining);
+} else if (InlineOpt.matches(options::OPT_finline_functions)) {
+  Opts.setInlining(CodeGenOptions::NormalInlining);
+} else {
+  assert(InlineOpt.matches(options::OPT_finline_hint_functions) &&
+ "Option parsing bug");
+  Opts.setInlining(Args.hasArg(OPT_finline_functions)
+   ? CodeGenOptions::NormalInlining
+   : CodeGenOptions::OnlyHintInlining);
 }
   }
 


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -694,19 +694,23 @@
   Opts.setInlining((Opts.OptimizationLevel == 0)
? CodeGenOptions::OnlyAlwaysInlining
: CodeGenOptions::NormalInlining);
-  // Explicit inlining flags can disable some or all inlining even at
-  // optimization levels above zero.
+  // Handle inlining overrides
   if (Arg *InlineArg = Args.getLastArg(
   options::OPT_finline_functions, options::OPT_finline_hint_functions,
   options::OPT_fno_inline_functions, options::OPT_fno_inline)) {
-if (Opts.OptimizationLevel > 0) {
-  const Option &InlineOpt = InlineArg->getOption();
-  if (InlineOpt.matches(options::OPT_finline_functions))
-Opts.setInlining(CodeGenOptions::NormalInlining);
-  else if (InlineOpt.matches(options::OPT_finline_hint_functions))
-Opts.setInlining(CodeGenOptions::OnlyHintInlining);
-  else
-Opts.setInlining(CodeGenOptions::OnlyAlwaysInlining);
+const Option &InlineOpt = InlineArg->getOption();
+if (InlineOpt.matches(options::OPT_fno_inline)) {
+  Opts.setInlining(CodeGenOptions::OnlyAlwaysInlining);
+} else if (InlineOpt.matches(options::OPT_fno_inline_functions)) {
+  Opts.setInlining(CodeGenOptions::OnlyAlwaysInlining);
+} else if (InlineOpt.matches(options::OPT_finline_functions)) {
+  Opts.setInlining(CodeGenOptions::NormalInlining);
+} else {
+  assert(InlineOpt.matches(options::OPT_finline_hint_functions) &&
+ "Option parsing bug");
+  Opts.setInlining(Args.hasArg(OPT_finline_functions)
+   ? CodeGenOptions::NormalInlining
+   : CodeGenOptions::OnlyHintInlining);
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

[David Zarzycki via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0d61cd25a692: Verify that clang's max alignment is 
<= LLVM's max alignment (authored by davezarzycki).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73363

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGValue.h


Index: clang/lib/CodeGen/CGValue.h
===
--- clang/lib/CodeGen/CGValue.h
+++ clang/lib/CodeGen/CGValue.h
@@ -15,12 +15,16 @@
 #define LLVM_CLANG_LIB_CODEGEN_CGVALUE_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Sema/Sema.h"
 #include "clang/AST/Type.h"
 #include "llvm/IR/Value.h"
 #include "llvm/IR/Type.h"
 #include "Address.h"
 #include "CodeGenTBAA.h"
 
+static_assert(clang::Sema::MaximumAlignment <= llvm::Value::MaximumAlignment,
+  "Clang max alignment greater than what LLVM supports?");
+
 namespace llvm {
   class Constant;
   class MDNode;
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -372,16 +372,17 @@
   QualType ResultTy,
   ArrayRef Args);
 
+public:
   /// The maximum alignment, same as in llvm::Value. We duplicate them here
   /// because that allows us not to duplicate the constants in clang code,
   /// which we must to since we can't directly use the llvm constants.
+  /// The value is verified against llvm here: lib/CodeGen/CGValue.h
   ///
   /// This is the greatest alignment value supported by load, store, and alloca
   /// instructions, and global values.
   static const unsigned MaxAlignmentExponent = 29;
   static const unsigned MaximumAlignment = 1u << MaxAlignmentExponent;
 
-public:
   typedef OpaquePtr DeclGroupPtrTy;
   typedef OpaquePtr TemplateTy;
   typedef OpaquePtr TypeTy;


Index: clang/lib/CodeGen/CGValue.h
===
--- clang/lib/CodeGen/CGValue.h
+++ clang/lib/CodeGen/CGValue.h
@@ -15,12 +15,16 @@
 #define LLVM_CLANG_LIB_CODEGEN_CGVALUE_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Sema/Sema.h"
 #include "clang/AST/Type.h"
 #include "llvm/IR/Value.h"
 #include "llvm/IR/Type.h"
 #include "Address.h"
 #include "CodeGenTBAA.h"
 
+static_assert(clang::Sema::MaximumAlignment <= llvm::Value::MaximumAlignment,
+  "Clang max alignment greater than what LLVM supports?");
+
 namespace llvm {
   class Constant;
   class MDNode;
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -372,16 +372,17 @@
   QualType ResultTy,
   ArrayRef Args);
 
+public:
   /// The maximum alignment, same as in llvm::Value. We duplicate them here
   /// because that allows us not to duplicate the constants in clang code,
   /// which we must to since we can't directly use the llvm constants.
+  /// The value is verified against llvm here: lib/CodeGen/CGValue.h
   ///
   /// This is the greatest alignment value supported by load, store, and alloca
   /// instructions, and global values.
   static const unsigned MaxAlignmentExponent = 29;
   static const unsigned MaximumAlignment = 1u << MaxAlignmentExponent;
 
-public:
   typedef OpaquePtr DeclGroupPtrTy;
   typedef OpaquePtr TemplateTy;
   typedef OpaquePtr TypeTy;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki created this revision.
davezarzycki added a reviewer: lebedev.ri.
davezarzycki added projects: LLVM, clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D73363

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGValue.h


Index: clang/lib/CodeGen/CGValue.h
===
--- clang/lib/CodeGen/CGValue.h
+++ clang/lib/CodeGen/CGValue.h
@@ -15,12 +15,16 @@
 #define LLVM_CLANG_LIB_CODEGEN_CGVALUE_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Sema/Sema.h"
 #include "clang/AST/Type.h"
 #include "llvm/IR/Value.h"
 #include "llvm/IR/Type.h"
 #include "Address.h"
 #include "CodeGenTBAA.h"
 
+static_assert(clang::Sema::MaximumAlignment <= llvm::Value::MaximumAlignment,
+  "Clang max alignment greater than what LLVM supports?");
+
 namespace llvm {
   class Constant;
   class MDNode;
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -372,16 +372,17 @@
   QualType ResultTy,
   ArrayRef Args);
 
+public:
   /// The maximum alignment, same as in llvm::Value. We duplicate them here
   /// because that allows us not to duplicate the constants in clang code,
   /// which we must to since we can't directly use the llvm constants.
+  /// The value is verified against llvm here: lib/CodeGen/CGValue.h
   ///
   /// This is the greatest alignment value supported by load, store, and alloca
   /// instructions, and global values.
   static const unsigned MaxAlignmentExponent = 29;
   static const unsigned MaximumAlignment = 1u << MaxAlignmentExponent;
 
-public:
   typedef OpaquePtr DeclGroupPtrTy;
   typedef OpaquePtr TemplateTy;
   typedef OpaquePtr TypeTy;


Index: clang/lib/CodeGen/CGValue.h
===
--- clang/lib/CodeGen/CGValue.h
+++ clang/lib/CodeGen/CGValue.h
@@ -15,12 +15,16 @@
 #define LLVM_CLANG_LIB_CODEGEN_CGVALUE_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/Sema/Sema.h"
 #include "clang/AST/Type.h"
 #include "llvm/IR/Value.h"
 #include "llvm/IR/Type.h"
 #include "Address.h"
 #include "CodeGenTBAA.h"
 
+static_assert(clang::Sema::MaximumAlignment <= llvm::Value::MaximumAlignment,
+  "Clang max alignment greater than what LLVM supports?");
+
 namespace llvm {
   class Constant;
   class MDNode;
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -372,16 +372,17 @@
   QualType ResultTy,
   ArrayRef Args);
 
+public:
   /// The maximum alignment, same as in llvm::Value. We duplicate them here
   /// because that allows us not to duplicate the constants in clang code,
   /// which we must to since we can't directly use the llvm constants.
+  /// The value is verified against llvm here: lib/CodeGen/CGValue.h
   ///
   /// This is the greatest alignment value supported by load, store, and alloca
   /// instructions, and global values.
   static const unsigned MaxAlignmentExponent = 29;
   static const unsigned MaximumAlignment = 1u << MaxAlignmentExponent;
 
-public:
   typedef OpaquePtr DeclGroupPtrTy;
   typedef OpaquePtr TemplateTy;
   typedef OpaquePtr TypeTy;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72998: [IR] Attribute/AttrBuilder: use Value::MaximumAlignment magic constant

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I understand not wanting to have trivial dependencies on IR for values like 
this, but what about creating `llvm/Support/InternalLimits.h` to hold values 
like this, and then *either* have `llvm::Value::MaximumAlignment` derive from 
the constant in the new file, or `static_assert` that the internal limit 
constant equals `llvm::Value::MaximumAlignment`?

At the very least, something in clang's IR generation logic should 
static_assert that the Sema constant is less than or equal to the LLVM constant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72998



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

[PATCH] D71154: Driver: Don't look for libc++ headers in the install directory on Android.

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Sorry, I had to revert this for breaking things. Please ping me when you have a 
new patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71154



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

[PATCH] D71154: Driver: Don't look for libc++ headers in the install directory on Android.

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Can we revert this? It doesn't seem to work on my Fedora 31 box:

  FAIL: Clang :: Driver/android-no-installed-libcxx.cpp (9249 of 59761)
   TEST 'Clang :: Driver/android-no-installed-libcxx.cpp' 
FAILED 
  Script:
  --
  : 'RUN: at line 4';   mkdir -p 
/tmp/_update_lc/r/tools/clang/test/Driver/Output/android-no-installed-libcxx.cpp.tmp/bin
  : 'RUN: at line 5';   mkdir -p 
/tmp/_update_lc/r/tools/clang/test/Driver/Output/android-no-installed-libcxx.cpp.tmp/include/c++/v1
  : 'RUN: at line 6';   /tmp/_update_lc/r/bin/clang -target 
aarch64-linux-android -ccc-install-dir 
/tmp/_update_lc/r/tools/clang/test/Driver/Output/android-no-installed-libcxx.cpp.tmp/bin
-stdlib=libc++ -fsyntax-only 
/home/dave/s/lp/clang/test/Driver/android-no-installed-libcxx.cpp -### 2>&1 | 
/tmp/_update_lc/r/bin/FileCheck 
/home/dave/s/lp/clang/test/Driver/android-no-installed-libcxx.cpp
  --
  Exit Code: 1
  
  Command Output (stderr):
  --
  /home/dave/s/lp/clang/test/Driver/android-no-installed-libcxx.cpp:8:15: 
error: CHECK-NOT: excluded string found in input
  // CHECK-NOT: "-internal-isystem" "{{.*}}v1"
^
  :5:653: note: found here
   "/tmp/_update_lc/r/bin/clang-10" "-cc1" "-triple" 
"aarch64-unknown-linux-android" "-fsyntax-only" "-disable-free" 
"-disable-llvm-verifier" "-discard-value-names" "-main-file-name" 
"android-no-installed-libcxx.cpp" "-mrelocation-model" "pic" "-pic-level" "2" 
"-pic-is-pie" "-mthread-model" "posix" "-mframe-pointer=all" 
"-fno-rounding-math" "-masm-verbose" "-mconstructor-aliases" "-fuse-init-array" 
"-target-cpu" "generic" "-target-feature" "+neon" "-target-abi" "aapcs" 
"-mllvm" "-aarch64-fix-cortex-a53-835769=1" 
"-fallow-half-arguments-and-returns" "-dwarf-column-info" 
"-debugger-tuning=gdb" "-resource-dir" "/tmp/_update_lc/r/lib64/clang/10.0.0" 
"-internal-isystem" "/usr/include/c++/v1" "-internal-isystem" 
"/usr/local/include" "-internal-isystem" 
"/tmp/_update_lc/r/lib64/clang/10.0.0/include" "-internal-externc-isystem" 
"/include" "-internal-externc-isystem" "/usr/include" "-fdeprecated-macro" 
"-fdebug-compilation-dir" "/tmp/_update_lc/r/tools/clang/test/Driver" 
"-ferror-limit" "19" "-fmessage-length" "0" "-fno-signed-char" 
"-fgnuc-version=4.2.1" "-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions" 
"-fdiagnostics-show-option" "-x" "c++" 
"/home/dave/s/lp/clang/test/Driver/android-no-installed-libcxx.cpp"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71154



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

[PATCH] D70157: Align branches within 32-Byte boundary

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D70157#1772227 , @annita.zhang 
wrote:

> > 
> > 
> >>> Third, I have not see a justification for why complexity for instruction 
> >>> prefix padding is necessary.  All the effected CPUs support multi-byte 
> >>> nops, so we're talking about a *single micro op* difference between the 
> >>> nop form and prefix form.  Can anyone point to a performance delta due to 
> >>> this?  If not, I'd suggest we should start with the nop form, and then 
> >>> build the prefix form in a generic manner for all alignment varieties.
> >> 
> >> +1.
> > 
> > +1. Starting from just NOP padding sounds a simple and good first step. We 
> > can explore segment override prefixes in the future.
>
> I think it's a good suggestion to start with NOP padding as the first step. 
> In our previous experiment, we saw that the prefix padding was slight better 
> than NOP padding, but not much. We will retest the NOP padding and go back to 
> you.


For whatever it may be worth: Agnor Fog's empirical research on x86 pipelines 
and his review of manufacturer optimization guidelines also concludes that 
prefixes are often preferable to NOPs on modern x86 processors. (See: 
https://www.agner.org/optimize/microarchitecture.pdf) This arguably isn't 
surprising given that the decoder needs to be good at finding instruction 
boundaries but the decoder isn't responsible for interpreting instructions, 
therefore NOPs of any size dilute decode bandwidth.


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

https://reviews.llvm.org/D70157



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

[PATCH] D70157: Align branches within 32-Byte boundary

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D70157#1747640 , @jyknight wrote:

> In D70157#1747551 , @davezarzycki 
> wrote:
>
> > In D70157#1747510 , @xbolva00 
> > wrote:
> >
> > > > Even though core2 isn't affected by the erratum, core2 code can run on 
> > > > CPUs that do have the bug (and core2 is a popular target for code that 
> > > > needs to run "everywhere"), therefore all target CPUs that predate a 
> > > > hardware fix really
> > >
> > > So perf of all code/generic codegen will go down. This is not very 
> > > acceptable. -1 for making this enabled by default for generic codegen.
> >
> >
> > I'm okay with this not being the default if we document somewhere that LLVM 
> > assumes that machines have up to date microcode installed.
>
>
> So, my understanding is:
>
> 1. There is a CPU bug, that in very rare but unspecified circumstances, can 
> cause branches of all kinds (conditional-jump, fused-conditional-jump, 
> unconditional jump, call, return, indirect jumps and calls?) to go to the 
> wrong place, if the instruction crosses a 64-byte cacheline boundary.
> 2. In order to fix that bug, the new CPU firmware disables the faster 
> decoded-icache mechanism, falling back to the legacy decoder for any 32-byte 
> block of code which ends with one of those jumps (because it works in 32-byte 
> blocks, not 64-byte blocks). Falling back to the legacy decoder can have a 
> sometimes-significant performance cost. Of course, this is not the _only_ 
> reason that the CPU falls back to the legacy decoder, but it's a significant 
> new one.
>
>   This patch, then, spends some memory and icache space (and potentially 
> decode-time) in order to try to get back the performance lost by the above 
> fix. This can be worthwhile because if you can cause there not to be any 
> 32-byte code sections that have a branch at the end, then the fallback to the 
> legacy decoder won't trigger, and the performance will hopefully return to 
> something comparable to the initial state. Unfortunately, while this ought to 
> increase performance impact on all of the affected processors, it will have 
> only negative effects on unaffected processors, since then you're spending 
> memory and icache space, and not getting anything back in return.
>
>   Similarly, if you're doing this extra alignment on code that isn't executed 
> repeatedly out of the icache, it's also going to be useless.
>
>   So, I'd say it's _not at all_ clear that it should be enabled by default.
>
>   I'm also a bit confused as to why the default is set as it is. Why is the 
> default only fused+jcc+jmp, not all branch types?


Strictly speaking, Intel doesn't say what happens if this bug occurs, nor do 
they say that branches themselves are the problem, just "branch instruction 
bytes" and that "unpredictable system behavior may occur". Compare and contrast 
with the subsequent erratum where they explicitly say that x86, AVX, and 
integer divide instructions (not instruction bytes) can have unpredictable 
behavior. See SKX102 and SKX103: 
https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scalable-spec-update.html

But we're digressing. I think the default policy discussion might be better had 
on llvm-dev than a Phab review.


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

https://reviews.llvm.org/D70157



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

[PATCH] D70157: Align branches within 32-Byte boundary

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D70157#1746793 , @MaskRay wrote:

> On x86, the preferred function alignment is 16 
> (https://github.com/llvm/llvm-project/blob/arcpatch-D70157/llvm/lib/Target/X86/X86ISelLowering.cpp#L1893),
>  which is the default function alignment in text sections. If the 
> cross-boundary decision is made with alignment=32 
> (--x86-align-branch-boundary=32) in mind, and the section alignment is still 
> 16 (not increased to 32 or higher), the linker may place the section at an 
> address which equals 16 modulo 32, the section contents will thus shift by 
> 16. The instructions that do not cross the boundary in the object files may 
> cross the boundary in the linker output. Have you considered increasing the 
> section alignment to 32?
>
> Shall we default to -mbranches-within-32B-boundaries if the specified -march= 
> or -mtune= may be affected by the erratum?


That isn't good enough. Even though core2 isn't affected by the erratum, core2 
code can run on CPUs that do have the bug (and core2 is a popular target for 
code that needs to run "everywhere"), therefore all target CPUs that predate a 
hardware fix really ought to have -mbranches-within-32B-boundaries by default.


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

https://reviews.llvm.org/D70157



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

[PATCH] D70157: Align branches within 32-Byte boundary

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D70157#1747510 , @xbolva00 wrote:

> > Even though core2 isn't affected by the erratum, core2 code can run on CPUs 
> > that do have the bug (and core2 is a popular target for code that needs to 
> > run "everywhere"), therefore all target CPUs that predate a hardware fix 
> > really
>
> So perf of all code/generic codegen will go down. This is not very 
> acceptable. -1 for making this enabled by default for generic codegen.


I'm okay with this not being the default if we document somewhere that LLVM 
assumes that machines have up to date microcode installed.


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

https://reviews.llvm.org/D70157



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

[PATCH] D69292: Proposal to add -Wtautological-compare to -Wall

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Let's just fix the bug: 1d55c9e59ebf3f3ff572d42da433b2f72f1ce900 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69292



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

[PATCH] D69292: Proposal to add -Wtautological-compare to -Wall

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added subscribers: libcxx-commits, davezarzycki.
davezarzycki added a comment.

This broke the libcxx test suite:

  FAIL: libc++ :: 
libcxx/debug/containers/db_sequence_container_iterators.multithread.pass.cpp 
(50769 of 59296)
   TEST 'libc++ :: 
libcxx/debug/containers/db_sequence_container_iterators.multithread.pass.cpp' 
FAILED 
  Command: ['/p/tllvm/bin/clang++', '-o', 
'/tmp/_update_lc/t/projects/libcxx/test/libcxx/debug/containers/Output/db_sequence_container_iterators.multithread.pass.cpp.o',
 '-x', 'c++', 
'/home/dave/s/lp/libcxx/test/libcxx/debug/containers/db_sequence_container_iterators.multithread.pass.cpp',
 '-c', '-v', '-ftemplate-depth=270', '-Werror=thread-safety', '-std=c++2a', 
'-include', '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', 
'-nostdinc++', '-I/home/dave/s/lp/libcxx/include', 
'-I/tmp/_update_lc/t/projects/libcxx/include/c++build', 
'-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', '-D__STDC_CONSTANT_MACROS', 
'-I/home/dave/s/lp/libcxx/test/support', 
'-DLIBCXX_FILESYSTEM_STATIC_TEST_ROOT="/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env"',
 
'-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT="/tmp/_update_lc/t/projects/libcxx/test/filesystem/Output/dynamic_env"',
 '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER="/usr/bin/python 
/home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py"', 
'-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', '-Wextra', '-Werror', 
'-Wuser-defined-warnings', '-Wshadow', '-Wno-unused-command-line-argument', 
'-Wno-attributes', '-Wno-constant-evaluated', '-Wno-pessimizing-move', 
'-Wno-c++11-extensions', '-Wno-user-defined-literals', '-Wno-noexcept-type', 
'-Wsign-compare', '-Wunused-variable', '-Wunused-parameter', 
'-Wunreachable-code', '-c']
  Exit Code: 1
  Standard Error:
  --
  clang version 10.0.0 (https://github.com/llvm/llvm-project.git 
d8b6b1114307558a5245de3806bb70f53f6f3efe)
  Target: x86_64-unknown-linux-gnu
  Thread model: posix
  InstalledDir: /p/tllvm/bin
  Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
  Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
  Candidate multilib: .;@m64
  Candidate multilib: 32;@m32
  Selected multilib: .;@m64
   "/p/tllvm/bin/clang-10" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj 
-mrelax-all -disable-free -disable-llvm-verifier -discard-value-names 
-main-file-name db_sequence_container_iterators.multithread.pass.cpp 
-mrelocation-model static -mthread-model posix -mframe-pointer=all -fmath-errno 
-fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables 
-fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v 
-nostdinc++ -resource-dir /p/tllvm/lib64/clang/10.0.0 -include 
/home/dave/s/lp/libcxx/test/support/nasty_macros.h -I 
/home/dave/s/lp/libcxx/include -I 
/tmp/_update_lc/t/projects/libcxx/include/c++build -D __STDC_FORMAT_MACROS -D 
__STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I 
/home/dave/s/lp/libcxx/test/support -D 
"LIBCXX_FILESYSTEM_STATIC_TEST_ROOT=\"/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env\""
 -D 
"LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT=\"/tmp/_update_lc/t/projects/libcxx/test/filesystem/Output/dynamic_env\""
 -D "LIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER=\"/usr/bin/python 
/home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py\"" -D 
_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem /usr/local/include 
-internal-isystem /p/tllvm/lib64/clang/10.0.0/include -internal-externc-isystem 
/include -internal-externc-isystem /usr/include -Werror=thread-safety -Wall 
-Wextra -Werror -Wuser-defined-warnings -Wshadow 
-Wno-unused-command-line-argument -Wno-attributes -Wno-constant-evaluated 
-Wno-pessimizing-move -Wno-c++11-extensions -Wno-user-defined-literals 
-Wno-noexcept-type -Wsign-compare -Wunused-variable -Wunused-parameter 
-Wunreachable-code -std=c++2a -fdeprecated-macro -fdebug-compilation-dir 
/tmp/_update_lc/t/projects/libcxx/test/libcxx/debug/containers -ftemplate-depth 
270 -ferror-limit 19 -fmessage-length 0 -fgnuc-version=4.2.1 
-fno-implicit-modules -fobjc-runtime=gcc -fcxx-exceptions -fexceptions 
-fdiagnostics-show-option -faddrsig -o 
/tmp/_update_lc/t/projects/libcxx/test/libcxx/debug/containers/Output/db_sequence_container_iterators.multithread.pass.cpp.o
 -x c++ 
/home/dave/s/lp/libcxx/test/libcxx/debug/containers/db_sequence_container_iterators.multithread.pass.cpp
  clang -cc1 version 10.0.0 based upon LLVM 10.0.0git default target 
x86_64-unknown-linux-gnu
  ignoring nonexistent directory "/include"
  #include "..." search starts here:
  #include <...> search starts here:
   /home/dave/s/lp/libcxx/include
   /tmp/_update_lc/t/projects/libcxx/include/c++build
   /home/dave/s/lp/libcxx/test/support
   /usr/local/include
   /p/tllvm/lib64/clang/10.0.0/include
   /usr/include
  End of search list.
  In file included from 
/home/dave/s/lp/libcxx/test/libcxx/debug/cont

[PATCH] D69841: Target Ivy bridge on macOS Mojave and later

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki abandoned this revision.
davezarzycki added a comment.

Okay. I'm going to abandon this patch on the assumption that Apple has an 
internal bug tracking this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69841



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

[PATCH] D69841: Target Ivy bridge on macOS Mojave and later

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

@bob.wilson – Ping. While Ivy Bridge (or really, Sandy Bridge) has AVX1, which 
enables faster memcpy, memset, and even memcmp (for common scenarios). If there 
is something I'm missing? If you can't explain why, that's okay. :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69841



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

[PATCH] D69841: Target Ivy bridge on macOS Mojave and later

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hi @bob.wilson – Am I missing something here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69841



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

[PATCH] D69841: Target Ivy bridge on macOS Mojave and later

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki created this revision.
davezarzycki added a reviewer: bob.wilson.
davezarzycki added a project: clang.

Ivy Bridge is required by macOS 10.14 (Mojave) and later.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69841

Files:
  clang/lib/Driver/ToolChains/Arch/X86.cpp


Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -73,12 +73,15 @@
   if (Triple.isOSDarwin()) {
 if (Triple.getArchName() == "x86_64h")
   return "core-avx2";
-// macosx10.12 drops support for all pre-Penryn Macs.
-// Simulators can still run on 10.11 though, like Xcode.
-if (Triple.isMacOSX() && !Triple.isOSVersionLT(10, 12))
-  return "penryn";
 // The oldest x86_64 Macs have core2/Merom; the oldest x86 Macs have Yonah.
-return Is64Bit ? "core2" : "yonah";
+// The simulators (i.e. Darwin but not macOS) can still run on older Macs.
+// macosx10.12 requires Penryn.
+if (!Triple.isMacOSX() || Triple.isOSVersionLT(10, 12))
+  return Is64Bit ? "core2" : "yonah";
+// macosx10.14 requires Ivy Bridge.
+if (Triple.isOSVersionLT(10, 14))
+  return "penryn";
+return "ivybridge";
   }
 
   // Set up default CPU name for PS4 compilers.


Index: clang/lib/Driver/ToolChains/Arch/X86.cpp
===
--- clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -73,12 +73,15 @@
   if (Triple.isOSDarwin()) {
 if (Triple.getArchName() == "x86_64h")
   return "core-avx2";
-// macosx10.12 drops support for all pre-Penryn Macs.
-// Simulators can still run on 10.11 though, like Xcode.
-if (Triple.isMacOSX() && !Triple.isOSVersionLT(10, 12))
-  return "penryn";
 // The oldest x86_64 Macs have core2/Merom; the oldest x86 Macs have Yonah.
-return Is64Bit ? "core2" : "yonah";
+// The simulators (i.e. Darwin but not macOS) can still run on older Macs.
+// macosx10.12 requires Penryn.
+if (!Triple.isMacOSX() || Triple.isOSVersionLT(10, 12))
+  return Is64Bit ? "core2" : "yonah";
+// macosx10.14 requires Ivy Bridge.
+if (Triple.isOSVersionLT(10, 14))
+  return "penryn";
+return "ivybridge";
   }
 
   // Set up default CPU name for PS4 compilers.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69786: [X86] Add support for -mvzeroupper and -mno-vzeroupper to match gcc.

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Actually, wait, what does it mean for a CPU without AVX to have 
`FeatureInsertVZEROUPPER`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69786



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

[PATCH] D69786: [X86] Add support for -mvzeroupper and -mno-vzeroupper to match gcc.

[David Zarzycki via Phabricator via cfe-commits]

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

LGTM. Thanks! I'll close my differential proposal then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69786



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

[PATCH] D69518: [Diagnostics] Warn for std::is_constant_evaluated in constexpr mode

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hi @xbolva00 – Thanks. That does make the libcxx test suite pass.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69518



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

[PATCH] D69518: [Diagnostics] Warn for std::is_constant_evaluated in constexpr mode

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This broke two stage builds of libc++. Can we revert this until a fix is ready?

  FAIL: libc++ :: 
std/utilities/meta/meta.const.eval/is_constant_evaluated.fail.cpp (55845 of 
59103)
   TEST 'libc++ :: 
std/utilities/meta/meta.const.eval/is_constant_evaluated.fail.cpp' FAILED 

  Command: ['/p/tllvm/bin/clang++', '-o', '/dev/null', '-x', 'c++', 
'/home/dave/s/lp/libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.fail.cpp',
 '-c', '-v', '-ftemplate-depth=270', '-fsyntax-only', '-Xclang', '-verify', 
'-Xclang', '-verify-ignore-unexpected=note', '-ferror-limit=1024', 
'-Werror=thread-safety', '-std=c++2a', '-include', 
'/home/dave/s/lp/libcxx/test/support/nasty_macros.h', '-nostdinc++', 
'-I/home/dave/s/lp/libcxx/include', 
'-I/tmp/_update_lc/t/projects/libcxx/include/c++build', 
'-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', '-D__STDC_CONSTANT_MACROS', 
'-I/home/dave/s/lp/libcxx/test/support', 
'-DLIBCXX_FILESYSTEM_STATIC_TEST_ROOT="/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env"',
 
'-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT="/tmp/_update_lc/t/projects/libcxx/test/filesystem/Output/dynamic_env"',
 '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER="/usr/bin/python 
/home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py"', 
'-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', '-Wextra', '-Werror', 
'-Wuser-defined-warnings', '-Wshadow', '-Wno-unused-command-line-argument', 
'-Wno-attributes', '-Wno-pessimizing-move', '-Wno-c++11-extensions', 
'-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', 
'-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', 
'-Wno-error=user-defined-warnings', '-c']
  Exit Code: 1
  Standard Error:
  --
  clang version 10.0.0 (/home/dave/s/lp/clang 
7e1a3076419d4d453d71143a1e81409ea1db177c)
  Target: x86_64-unknown-linux-gnu
  Thread model: posix
  InstalledDir: /p/tllvm/bin
  Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
  Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
  Candidate multilib: .;@m64
  Candidate multilib: 32;@m32
  Selected multilib: .;@m64
   "/p/tllvm/bin/clang-10" -cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only 
-disable-free -disable-llvm-verifier -discard-value-names -main-file-name 
is_constant_evaluated.fail.cpp -mrelocation-model static -mthread-model posix 
-mframe-pointer=all -fmath-errno -masm-verbose -mconstructor-aliases 
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info 
-debugger-tuning=gdb -v -nostdinc++ -resource-dir /p/tllvm/lib64/clang/10.0.0 
-include /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I 
/home/dave/s/lp/libcxx/include -I 
/tmp/_update_lc/t/projects/libcxx/include/c++build -D __STDC_FORMAT_MACROS -D 
__STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I 
/home/dave/s/lp/libcxx/test/support -D 
"LIBCXX_FILESYSTEM_STATIC_TEST_ROOT=\"/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env\""
 -D 
"LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT=\"/tmp/_update_lc/t/projects/libcxx/test/filesystem/Output/dynamic_env\""
 -D "LIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER=\"/usr/bin/python 
/home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py\"" -D 
_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem /usr/local/include 
-internal-isystem /p/tllvm/lib64/clang/10.0.0/include -internal-externc-isystem 
/include -internal-externc-isystem /usr/include -Werror=thread-safety -Wall 
-Wextra -Werror -Wuser-defined-warnings -Wshadow 
-Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move 
-Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type 
-Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code 
-Wno-error=user-defined-warnings -std=c++2a -fdeprecated-macro 
-fdebug-compilation-dir /tmp/_update_lc/t -ftemplate-depth 270 -ferror-limit 
1024 -fmessage-length 0 -fgnuc-version=4.2.1 -fno-implicit-modules 
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option 
-verify -verify-ignore-unexpected=note -faddrsig -x c++ 
/home/dave/s/lp/libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.fail.cpp
  clang -cc1 version 10.0.0 based upon LLVM 10.0.0svn default target 
x86_64-unknown-linux-gnu
  ignoring nonexistent directory "/include"
  #include "..." search starts here:
  #include <...> search starts here:
   /home/dave/s/lp/libcxx/include
   /tmp/_update_lc/t/projects/libcxx/include/c++build
   /home/dave/s/lp/libcxx/test/support
   /usr/local/include
   /p/tllvm/lib64/clang/10.0.0/include
   /usr/include
  End of search list.
  error: 'error' diagnostics seen but not expected: 
File 
/home/dave/s/lp/libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.fail.cpp
 Line 26: 'std::is_constant_evaluated' will always evaluate to 'true' in a 
manifestly constant-evaluated expression
  1 error generated.
  --
  
  Expected compilatio

[PATCH] D66700: [Wdocumentation] improve wording of a warning message

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Works for me. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66700



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

[PATCH] D64696: Adds a warning when an inline Doxygen comment has no argument

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I don't think anybody is running doxygen over the Swift source right now, so 
I'll just escape the @ sign. That being said, can we improve this diagnostic? 
"command does not have an argument" is confusing when a given command does have 
an argument, just a malformed one. What do you think about "command must 
precede a word"? At least that gives a hint that the argument is not a "word" 
according to doxygen.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64696



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

[PATCH] D64696: Adds a warning when an inline Doxygen comment has no argument

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

From the Swift language source (http://github.com/apple/swift):

include/swift/AST/Attr.h:/// A limited variant of \c @objc that's used for 
classes with generic ancestry.
include/swift/AST/Decl.h:  /// \c @usableFromInline attribute are treated as 
public. This is normally
lib/Sema/LookupVisibleDecls.cpp:/// If \c baseType is \c @dynamicMemberLookup, 
this looks up any keypath


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64696



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

[PATCH] D62445: [test] Fix plugin tests

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

In D62445#1616218 , @davezarzycki 
wrote:

> Just FYI – Having LLVM_ENABLE_PLUGINS_default depend on LLVM_ENABLE_PIC is a 
> hack that should go away someday. Doing so requires that plugin dependencies 
> either always build PIC (and therefore ignore LLVM_ENABLE_PIC), or are linked 
> into the executables that load them and the plugin knows how to find them in 
> the executable. In the case of the latter and on Mach-O platforms, this 
> requires passing `-bundle_loader $PATH_TO_EXECUTABLE` to the linker when 
> creating the plugin (a.k.a. "bundle"), but on ELF platforms, I'm not sure 
> what needs to be done.


It just occurred to me: option 3 is to statically link the plugins if PIC is 
disabled.

These are all just tradeoffs of course, and the worst among them is what we 
have today: conflating "enable plugins" with the default PIC behavior for the 
project.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62445



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

[PATCH] D62445: [test] Fix plugin tests

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Just FYI – Having LLVM_ENABLE_PLUGINS_default depend on LLVM_ENABLE_PIC is a 
hack that should go away someday. Doing so requires that plugin dependencies 
either always build PIC (and therefore ignore LLVM_ENABLE_PIC), or are linked 
into the executables that load them and the plugin knows how to find them in 
the executable. In the case of the latter and on Mach-O platforms, this 
requires passing `-bundle_loader $PATH_TO_EXECUTABLE` to the linker when 
creating the plugin (a.k.a. "bundle"), but on ELF platforms, I'm not sure what 
needs to be done.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62445



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

[PATCH] D64696: Adds a warning when an inline Doxygen comment has no argument

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hello – This change seems to have exposed a bug in -Wdocumentation argument 
parsing. For example, this warns when it shouldn't(?):

  /// \c @foobar


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64696



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

[PATCH] D62445: [test] Fix plugin tests

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This broke non-PIC builds. Fixed: r362399


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62445



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

[PATCH] D62174: [Analysis] Link library dependencies to Analysis plugins

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Fixed: r361399


Repository:
  rC Clang

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

https://reviews.llvm.org/D62174



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

[PATCH] D62174: [Analysis] Link library dependencies to Analysis plugins

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This breaks non-PIC builds. Was this planned or expected? Can we revert this 
until a fix is found?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62174



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

[PATCH] D58216: Support attribute used in member funcs of class templates II

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

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


Repository:
  rC Clang

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

https://reviews.llvm.org/D58216



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

[PATCH] D58216: Support attribute used in member funcs of class templates II

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I've got a patch pending for Swift. That being said, the clang diagnostics 
leave something to be desired. If `__attribute__((used))` on definitions is 
sloppy at best or wrong at worst, then that should have a warning/error. Want a 
bug report? Or does one exist already?


Repository:
  rC Clang

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

https://reviews.llvm.org/D58216



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

[PATCH] D58216: Support attribute used in member funcs of class templates II

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a subscriber: bob.wilson.
davezarzycki added a comment.

I can't get Swift top-of-tree to build with gcc (8.3.1 20190223 (Red Hat 
8.3.1-2)), and I doubt that it is supported, but I could be wrong.

In any case, the requested change to the Swift compiler source sounds 
reasonable to me.

CC: @bob.wilson – Just FYI, top-of-tree clang will probably force a subtle 
change to the "master" and "upstream-with-swift" branches of Swift.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58216



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

[PATCH] D58418: [clang][DirectoryWatcher] Upstream DirectoryWatcher

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Can we please revert this code? One cannot use dynamic_cast on a char *. Did 
you mean reinterpret_cast?


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

https://reviews.llvm.org/D58418



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

[PATCH] D58107: [MinGW] Add the profiling library when necessary

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This change breaks building/testing the compiler with `CLANG_DEFAULT_LINKER` 
set to `lld`. Was this intentional? What should people do if they want to use 
`CLANG_DEFAULT_LINKER` and run the test suite?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58107



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

[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hot fix: r352996


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57592



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

[PATCH] D56928: Support attribute used in member funcs of class templates

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

This change broke building Swift on my Linux box. The compiler confusingly 
complains about the *same* template being both explicitly specialized and 
implicitly instantiated:

  /home/dave/s/u/swift/stdlib/public/runtime/ProtocolConformance.cpp:34:38: 
error: explicit specialization of 'dump' after instantiation
  template <> void ProtocolDescriptor::dump() const {
   ^
  /home/dave/s/u/swift/stdlib/public/runtime/ProtocolConformance.cpp:34:18: 
note: implicit instantiation first required here
  template <> void ProtocolDescriptor::dump() const {
   ^

Is this expected?


Repository:
  rC Clang

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

https://reviews.llvm.org/D56928



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

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

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hello @aprantl,

This change broke the test suite when building in /tmp (tmpfs) on Linux:

FAIL: Clang :: CodeGen/debug-info-abspath.c (5676 of 44360)

- TEST 'Clang :: CodeGen/debug-info-abspath.c' FAILED 

Script:
---

: 'RUN: at line 1';   /tmp/_t/bin/clang -cc1 -internal-isystem 
/tmp/_t/lib/clang/8.0.0/include -nostdsysteminc -debug-info-kind=limited 
-triple x86_64-unknown-linux-gnu
/home/dave/s/lc/clang/test/CodeGen/debug-info-abspath.c -emit-llvm -o - | 
/tmp/_t/bin/FileCheck /home/dave/s/lc/clang/test/CodeGen/debug-info-abspath.c
: 'RUN: at line 4';   cp 
/home/dave/s/lc/clang/test/CodeGen/debug-info-abspath.c 
/tmp/_t/tools/clang/test/CodeGen/Output/debug-info-abspath.c.tmp.c

: 'RUN: at line 5';   /tmp/_t/bin/clang -cc1 -internal-isystem 
/tmp/_t/lib/clang/8.0.0/include -nostdsysteminc -debug-info-kind=limited 
-triple x86_64-unknown-linux-gnu
/tmp/_t/tools/clang/test/CodeGen/Output/debug-info-abspath.c.tmp.c -emit-llvm 
-o - | /tmp/_t/bin/FileCheck 
/home/dave/s/lc/clang/test/CodeGen/debug-info-abspath.c --check-prefix=INTREE


Exit Code: 1

Command Output (stderr):


/home/dave/s/lc/clang/test/CodeGen/debug-info-abspath.c:13:16: error: 
CHECK-SAME: expected string not found in input
// CHECK-SAME: directory: "{{.+}}")

  ^

:25:81: note: scanning from here
!7 = !DIFile(filename: 
"/home/dave/s/lc/clang/test/CodeGen/debug-info-abspath.c", directory: "")

  ^

:25:83: note: possible intended match here
!7 = !DIFile(filename: 
"/home/dave/s/lc/clang/test/CodeGen/debug-info-abspath.c", directory: "")

^


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

https://reviews.llvm.org/D55085



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

[PATCH] D53219: Update hexagon driver tests

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Tested and verified with `-DCLANG_DEFAULT_LINKER=lld`


Repository:
  rC Clang

https://reviews.llvm.org/D53219



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

[PATCH] D53038: [Hexagon] Use GetLinkerPath method instead of hard-coded linker name.

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

A bisect revealed this change as the source of test failures on my Red Hat 
Fedora 28 Linux box. How was/is this tested?

Command Output (stderr):


/home/dave/s/lc/tools/clang/test/Driver/linux-ld.c:882:19: error: 
CHECK-HEXAGON: expected string not found in input
// CHECK-HEXAGON: "{{.*}}hexagon-link{{(.exe)?}}"

  ^

:1:1: note: scanning from here
clang version 8.0.0 (https://git.llvm.org/git/clang.git 
efe41bf98e6011bb413a5056f0025a4509de860d) (https://git.llvm.org/git/llvm.git 
638941f488dd9d1b1b9d49913240fdc2beec56a0)
^
:2:3: note: possible intended match here
Target: hexagon-unknown-linux-gnu

  ^

-



Testing Time: 43.34s



Failing Tests (2):

Clang :: Driver/hexagon-toolchain-elf.c
Clang :: Driver/linux-ld.c
  
  Expected Passes: 34506
  Expected Failures  : 82
  Unsupported Tests  : 8838
  Unexpected Failures: 2

FAILED: CMakeFiles/check-all


Repository:
  rC Clang

https://reviews.llvm.org/D53038



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

[PATCH] D49457: DR330: when determining whether a cast casts away constness, consider qualifiers from all levels matching a multidimensional array

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hi @rsmith – I've verified this patch fixes the original issue. Thanks for the 
quick fix!


Repository:
  rC Clang

https://reviews.llvm.org/D49457



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

[PATCH] D45777: [UnitTests] NFC/build-perf: Break up nontrivial compile jobs

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki closed this revision.
davezarzycki added a comment.

Thanks @thakis!

Committed as r330353


Repository:
  rC Clang

https://reviews.llvm.org/D45777



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

[PATCH] D45777: [UnitTests] NFC/build-perf: Break up nontrivial compile jobs

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Ping. Any review feedback would be appreciated. Thanks!


Repository:
  rC Clang

https://reviews.llvm.org/D45777



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

[PATCH] D45777: [UnitTests] NFC/build-perf: Break up nontrivial compile jobs

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki created this revision.
davezarzycki added reviewers: arphaman, sberg, delesley, james.dennett, 
jdennett, klimek.
Herald added a subscriber: mgorny.

RecursiveASTVisitorTest.cpp is one of the longest compile jobs and a build 
bottleneck on many-core machines. This patch breaks that file and some peer 
files up into smaller files to increase build concurrency and overall rebuild 
performance.


Repository:
  rC Clang

https://reviews.llvm.org/D45777

Files:
  Tooling/CMakeLists.txt
  Tooling/RecursiveASTVisitorTest.cpp
  Tooling/RecursiveASTVisitorTestExprVisitor.cpp
  Tooling/RecursiveASTVisitorTests/Attr.cpp
  Tooling/RecursiveASTVisitorTests/CXXBoolLiteralExpr.cpp
  Tooling/RecursiveASTVisitorTests/CXXOperatorCallExprTraverser.cpp
  Tooling/RecursiveASTVisitorTests/Class.cpp
  Tooling/RecursiveASTVisitorTests/ConstructExpr.cpp
  Tooling/RecursiveASTVisitorTests/DeclRefExpr.cpp
  Tooling/RecursiveASTVisitorTests/ImplicitCtor.cpp
  Tooling/RecursiveASTVisitorTests/InitListExprPostOrder.cpp
  Tooling/RecursiveASTVisitorTests/InitListExprPostOrderNoQueue.cpp
  Tooling/RecursiveASTVisitorTests/InitListExprPreOrder.cpp
  Tooling/RecursiveASTVisitorTests/InitListExprPreOrderNoQueue.cpp
  Tooling/RecursiveASTVisitorTests/IntegerLiteral.cpp
  Tooling/RecursiveASTVisitorTests/LambdaDefaultCapture.cpp
  Tooling/RecursiveASTVisitorTests/LambdaExpr.cpp
  Tooling/RecursiveASTVisitorTests/NestedNameSpecifiers.cpp
  Tooling/RecursiveASTVisitorTests/ParenExpr.cpp
  Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
  unittests/Tooling/RecursiveASTVisitorTestCallVisitor.cpp
  unittests/Tooling/RecursiveASTVisitorTests/CXXMemberCall.cpp

Index: Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
===
--- /dev/null
+++ Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
@@ -0,0 +1,40 @@
+//===- unittest/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "TestVisitor.h"
+
+using namespace clang;
+
+namespace {
+
+class TemplateArgumentLocTraverser
+  : public ExpectedLocationVisitor {
+public:
+  bool TraverseTemplateArgumentLoc(const TemplateArgumentLoc &ArgLoc) {
+std::string ArgStr;
+llvm::raw_string_ostream Stream(ArgStr);
+const TemplateArgument &Arg = ArgLoc.getArgument();
+
+Arg.print(Context->getPrintingPolicy(), Stream);
+Match(Stream.str(), ArgLoc.getLocation());
+return ExpectedLocationVisitor::
+  TraverseTemplateArgumentLoc(ArgLoc);
+  }
+};
+
+TEST(RecursiveASTVisitor, VisitsClassTemplateTemplateParmDefaultArgument) {
+  TemplateArgumentLocTraverser Visitor;
+  Visitor.ExpectMatch("X", 2, 40);
+  EXPECT_TRUE(Visitor.runOver(
+"template class X;\n"
+"template class T = X> class Y;\n"
+"template class T> class Y {};\n"));
+}
+
+} // end anonymous namespace
Index: Tooling/RecursiveASTVisitorTests/ParenExpr.cpp
===
--- /dev/null
+++ Tooling/RecursiveASTVisitorTests/ParenExpr.cpp
@@ -0,0 +1,30 @@
+//===- unittest/Tooling/RecursiveASTVisitorTests/ParenExpr.cpp ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "TestVisitor.h"
+
+using namespace clang;
+
+namespace {
+
+class ParenExprVisitor : public ExpectedLocationVisitor {
+public:
+  bool VisitParenExpr(ParenExpr *Parens) {
+Match("", Parens->getExprLoc());
+return true;
+  }
+};
+
+TEST(RecursiveASTVisitor, VisitsParensDuringDataRecursion) {
+  ParenExprVisitor Visitor;
+  Visitor.ExpectMatch("", 1, 9);
+  EXPECT_TRUE(Visitor.runOver("int k = (4) + 9;\n"));
+}
+
+} // end anonymous namespace
Index: Tooling/RecursiveASTVisitorTests/NestedNameSpecifiers.cpp
===
--- /dev/null
+++ Tooling/RecursiveASTVisitorTests/NestedNameSpecifiers.cpp
@@ -0,0 +1,74 @@
+//===- unittest/Tooling/RecursiveASTVisitorTests/NestedNameSpecifiers.cpp -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "TestVisitor.h"
+
+using namespace clang;
+
+namespace {
+
+// Check to ensure that nested name specifiers are visited.
+class NestedNameSpecifiersVisitor
+: public ExpectedLocationVisitor {
+public:
+  bool VisitRecordTypeLoc(Recor

[PATCH] D43578: -ftime-report switch support in Clang

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

It wasn't my suggestion. @thakis wrote: "We probably should have a separate 
bool in clang and key this off that and make -ftime-report set both."


https://reviews.llvm.org/D43578



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

[PATCH] D43578: -ftime-report switch support in Clang

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Hi @efriedma – Sorry about that. I haven't directly used `svn` in years thanks 
to the `git svn` bridge.


Repository:
  rL LLVM

https://reviews.llvm.org/D43578



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

[PATCH] D43578: -ftime-report switch support in Clang

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

A revert in practice just means undoing the changes. For example, while both 
`git` and `svn` have `revert` subcommands, you can also just take the original 
diff/patch, pipe it into `patch -R`, and if there are no conflicts, commit the 
result.


Repository:
  rL LLVM

https://reviews.llvm.org/D43578



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

[PATCH] D45488: [X86] Disable SGX for Skylake Server - CPP test

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I don't think this change is correct. To the best of my knowledge, SKL does 
support SGX but SKX does not.


Repository:
  rC Clang

https://reviews.llvm.org/D45488



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

[PATCH] D45058: [X86] Disable SGX for Skylake Server

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I think this change is incomplete. The following clang test fails on my SKX 
machine: `Preprocessor/predefined-arch-macros.c`

Line 895: `// CHECK_SKX_M32: #define __SGX__ 1`


Repository:
  rL LLVM

https://reviews.llvm.org/D45058



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

[PATCH] D45485: [CMake] Unbreak BUILD_SHARED_LIBS workflow

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Great! I'll revisit this patch in a week and see if it is still needed. 
Hopefully the author of https://reviews.llvm.org/D43578 will make this patch 
unnecessary by then.


Repository:
  rC Clang

https://reviews.llvm.org/D45485



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

[PATCH] D45485: [CMake] Unbreak BUILD_SHARED_LIBS workflow

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

I haven't proven that r329684 is the source of the regression, but it is the 
only timer related change in the last 24 hours as far as I can tell.


Repository:
  rC Clang

https://reviews.llvm.org/D45485



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

[PATCH] D45485: [CMake] Unbreak BUILD_SHARED_LIBS workflow

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki created this revision.
davezarzycki added reviewers: mspertus, beanz, gottesmm.
Herald added a subscriber: mgorny.

Due to recent timer changes, we need to add LLVM's `Core` library to avoid 
undefined symbol errors at link time (`llvm::TimePassesIsEnabled`) when using 
LLVM's BUILD_SHARED_LIBS workflow.


Repository:
  rC Clang

https://reviews.llvm.org/D45485

Files:
  lib/Frontend/CMakeLists.txt
  lib/Lex/CMakeLists.txt
  lib/Parse/CMakeLists.txt
  lib/Sema/CMakeLists.txt


Index: lib/Sema/CMakeLists.txt
===
--- lib/Sema/CMakeLists.txt
+++ lib/Sema/CMakeLists.txt
@@ -1,4 +1,5 @@
 set(LLVM_LINK_COMPONENTS
+  Core
   Support
   )
 
Index: lib/Parse/CMakeLists.txt
===
--- lib/Parse/CMakeLists.txt
+++ lib/Parse/CMakeLists.txt
@@ -1,4 +1,5 @@
 set(LLVM_LINK_COMPONENTS
+  Core
   MC
   MCParser
   Support
Index: lib/Lex/CMakeLists.txt
===
--- lib/Lex/CMakeLists.txt
+++ lib/Lex/CMakeLists.txt
@@ -1,6 +1,9 @@
 # TODO: Add -maltivec when ARCH is PowerPC.
 
-set(LLVM_LINK_COMPONENTS support)
+set(LLVM_LINK_COMPONENTS
+  Core
+  support
+  )
 
 add_clang_library(clangLex
   HeaderMap.cpp
Index: lib/Frontend/CMakeLists.txt
===
--- lib/Frontend/CMakeLists.txt
+++ lib/Frontend/CMakeLists.txt
@@ -1,6 +1,7 @@
 add_subdirectory(Rewrite)
 
 set(LLVM_LINK_COMPONENTS
+  Core
   BitReader
   Option
   ProfileData


Index: lib/Sema/CMakeLists.txt
===
--- lib/Sema/CMakeLists.txt
+++ lib/Sema/CMakeLists.txt
@@ -1,4 +1,5 @@
 set(LLVM_LINK_COMPONENTS
+  Core
   Support
   )
 
Index: lib/Parse/CMakeLists.txt
===
--- lib/Parse/CMakeLists.txt
+++ lib/Parse/CMakeLists.txt
@@ -1,4 +1,5 @@
 set(LLVM_LINK_COMPONENTS
+  Core
   MC
   MCParser
   Support
Index: lib/Lex/CMakeLists.txt
===
--- lib/Lex/CMakeLists.txt
+++ lib/Lex/CMakeLists.txt
@@ -1,6 +1,9 @@
 # TODO: Add -maltivec when ARCH is PowerPC.
 
-set(LLVM_LINK_COMPONENTS support)
+set(LLVM_LINK_COMPONENTS
+  Core
+  support
+  )
 
 add_clang_library(clangLex
   HeaderMap.cpp
Index: lib/Frontend/CMakeLists.txt
===
--- lib/Frontend/CMakeLists.txt
+++ lib/Frontend/CMakeLists.txt
@@ -1,6 +1,7 @@
 add_subdirectory(Rewrite)
 
 set(LLVM_LINK_COMPONENTS
+  Core
   BitReader
   Option
   ProfileData
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits