[all-commits] [llvm/llvm-project] 0e79a9: [Utils] Support class template specializations in ...

[Jessica Clarke via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0e79a94836d7127a87c36fdca43ffaf6a17d8964
      https://github.com/llvm/llvm-project/commit/0e79a94836d7127a87c36fdca43ffaf6a17d8964
  Author: Jessica Clarke <jrtc27 at jrtc27.com>
  Date:   2021-07-28 (Wed, 28 Jul 2021)

  Changed paths:
    A clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp
    A clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp.expected
    A clang/test/utils/update_cc_test_checks/explicit-template-instantiation.test
    M llvm/utils/update_cc_test_checks.py

  Log Message:
  -----------
  [Utils] Support class template specializations in update_cc_test_checks

ClassTemplateSpecializationDecl not within a ClassTemplateDecl
represents an explicit instatiation of a template and so should be
handled as if it were a normal CXXRecordDecl. Unfortunately, having an
equivalent for FunctionTemplateDecl remains a TODO in ASTDumper's
VisitFunctionTemplateDecl, with all the explicit instantiations just
being emitted inside the FunctionTemplateDecl along with all the other
specializations, meaning we can't easily support explicit function
instantiations in update_cc_test_checks.

Reviewed By: arichardson

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


  Commit: 40080e7e7f42857c8edac4a53e476a68563f1a98
      https://github.com/llvm/llvm-project/commit/40080e7e7f42857c8edac4a53e476a68563f1a98
  Author: Jessica Clarke <jrtc27 at jrtc27.com>
  Date:   2021-07-28 (Wed, 28 Jul 2021)

  Changed paths:
    M clang/lib/AST/Interp/ByteCodeEmitter.cpp
    M clang/lib/AST/Interp/Disasm.cpp
    M clang/lib/AST/Interp/Interp.h
    M clang/lib/AST/Interp/Program.cpp
    M clang/lib/AST/Interp/Program.h
    M clang/lib/AST/Interp/Source.h
    M clang/utils/TableGen/ClangOpcodesEmitter.cpp

  Log Message:
  -----------
  [Clang interpreter] Avoid storing pointers at unaligned locations

The Clang interpreter's bytecode uses a packed stream of bytes
representation, but also wants to have some opcodes take pointers as
arguments, which are currently embedded in the bytecode directly.

However, CHERI, and thus Arm's upcoming experimental Morello prototype,
provide spatial memory safety for C/C++ by implementing language-level
(and sub-language-level) pointers as capabilities, which track bounds,
permissions and validity in hardware. This uses tagged memory with a
single tag bit at every capability-aligned address, and so storing
pointers to unaligned addresses results in the tag being stripped,
leading to a tag fault when the pointer is ultimately dereferenced at a
later point.

In order to support a stricter C/C++ implementation like CHERI, we no
longer store pointers directly in the bytecode, instead storing them in
a table and embedding the index in the bytecode.

Reviewed By: nand

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


Compare: https://github.com/llvm/llvm-project/compare/8612417e5a54...40080e7e7f42