1. Mar 22, 2024
    • Simon Pilgrim's avatar
      32185706
    • Daniel Chen's avatar
      [Flang] Support for NULL() and procedure in structure constructor for... · e84a985c
      Daniel Chen authored
      [Flang] Support for NULL() and procedure in structure constructor for procedure pointer component. (#85991)
      
      This PR fixes a subset of procedure pointer component initialization in
      structure constructor.
      It covers
        1. NULL()
        2. procedure
        
       For example:
       ```
         MODULE M
          TYPE :: DT
            !PROCEDURE(Fun), POINTER, NOPASS :: pp1
            PROCEDURE(Fun), POINTER :: pp1
          END TYPE
      
          CONTAINS
      
          INTEGER FUNCTION Fun(Arg)
           class(dt) :: arg
          END FUNCTION
      
        END MODULE
      
        PROGRAM MAIN
        USE M
        IMPLICIT NONE
        TYPE (DT), PARAMETER :: v1 = DT(NULL())
        TYPE (DT) :: v2
        v2 = DT(fun)
        END
        ```
        
      Passing a procedure pointer itself or reference to a function that
      returns a procedure pointer is TODO.
      e84a985c
    • LLVM GN Syncbot's avatar
      [gn build] Port 797336b1 · aa571a1e
      LLVM GN Syncbot authored
      aa571a1e
    • T-Gruber's avatar
      Adapted MemRegion::getDescriptiveName to handle ElementRegions (#85104) · 86d479fd
      T-Gruber authored
      Fixes https://github.com/llvm/llvm-project/issues/84463
      
      
      
      Changes:
      - Adapted MemRegion::getDescriptiveName
      - Added unittest to check name for a given clang::ento::ElementRegion
      - Some format changes due to clang-format
      
      ---------
      
      Co-authored-by: default avatarAndreas Steinhausen <andreas.steinhausen@concenrio.io>
      Co-authored-by: default avatarBalazs Benics <benicsbalazs@gmail.com>
      86d479fd
    • Balazs Benics's avatar
      [analyzer] Wrap SymbolicRegions by ElementRegions before getting a FieldRegion (#85211) · c8772940
      Balazs Benics authored
      Inside the ExprEngine when we process the initializers, we create a
      PostInitializer program-point, which will refer to the field being
      initialized, see `FieldLoc` inside `ExprEngine::ProcessInitializer`.
      
      When a constructor (of which we evaluate the initializer-list) is
      analyzed in top-level context, then the `this` pointer will be
      represented by a `SymbolicRegion`, (as it should be).
      
      This means that we will form a `FieldRegion{SymbolicRegion{.}}` as the
      initialized region.
      
      ```c++
      class Bear {
      public:
        void brum() const;
      };
      class Door {
      public:
        // PostInitializer would refer to "FieldRegion{SymRegion{this}}"
        // whereas in the store and everywhere else it would be:
        // "FieldRegion{ELementRegion{SymRegion{Ty*, this}, 0, Ty}".
        Door() : ptr(nullptr) {
          ptr->brum(); // Bug
        }
      private:
        Bear* ptr;
      };
      ```
      
      We (as CSA folks) decided to avoid the creation of FieldRegions directly
      of symbolic regions in the past:
      
      https://github.com/llvm/llvm-project/commit/f8643a9b31c4029942f67d4534c9139b45173504
      
      ---
      
      In this patch, I propose to also canonicalize it as in the mentioned
      patch, into this: `FieldRegion{ElementRegion{SymbolicRegion{Ty*, .}, 0,
      Ty}`
      
      This would mean that FieldRegions will/should never simply wrap a
      SymbolicRegion directly, but rather an ElementRegion that is sitting in
      between.
      
      This patch should have practically no observable effects, as the store
      (due to the mentioned patch) was made resilient to this issue, but we
      use `PostInitializer::getLocationValue()` for an alternative reporting,
      where we faced this issue.
      
      Note that in really rare cases it suppresses now dereference bugs, as
      demonstrated in the test. It is because in the past we failed to follow
      the region of the PostInitializer inside the StoreSiteFinder visitor -
      because it was using this code:
      ```c++
      // If this is a post initializer expression, initializing the region, we
      // should track the initializer expression.
      if (std::optional<PostInitializer> PIP =
              Pred->getLocationAs<PostInitializer>()) {
        const MemRegion *FieldReg = (const MemRegion *)PIP->getLocationValue();
        if (FieldReg == R) {
          StoreSite = Pred;
          InitE = PIP->getInitializer()->getInit();
        }
      }
      ```
      Notice that the equality check didn't pass for the regions I'm
      canonicalizing in this patch.
      
      Given the nature of this change, we would rather upstream this patch.
      
      CPP-4954
      c8772940
    • Janek van Oirschot's avatar
      Revert "[AMDGPU] MCExpr-ify MC layer kernel descriptor" (#86151) · 797336b1
      Janek van Oirschot authored
      Reverts llvm/llvm-project#80855
      797336b1
    • Ilya Biryukov's avatar
      [libc++] Remove macros for keeping std::allocator members and void... · 4bf8dc1a
      Ilya Biryukov authored
      [libc++] Remove macros for keeping std::allocator members and void specialization after C++20 (#85806)
      
      Fixes #75975.
      
      Remove `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` for the LLVM 19
      release, it was previously marked as deprecated in LLVM 18.
      
      I believe that
      `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` was only
      used by Google in conjunction with
      `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`.
      
      Removing both macros together should not cause any issues in practice,
      even though we did not announce the removal of
      `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` before.
      4bf8dc1a
    • Simon Pilgrim's avatar
      [DAG] combineConcatVectorOfScalars - stop always creating UNDEF nodes. NFC. · 69429276
      Simon Pilgrim authored
      Noticed in debug logs - most calls to visitVECTOR_SHUFFLE resulted into wasteful UNDEF node creations, despite almost never being used.
      69429276
    • Nick Desaulniers's avatar
      [libc][stdio] implement rename via SYS_renameat2 (#86140) · 6eff53b4
      Nick Desaulniers authored
      SYS_rename may be unavailable on architectures such as aarch64 and
      riscv.
      rename can be implemented in terms of SYS_rename, SYS_renameat, or
      SYS_renameat2. I don't have a full picture of the history here, but it
      seems
      that SYS_renameat might also be unavailable on some platforms.
      
      `man 2 rename` mentions that SYS_renameat2 was added in Linux 3.15. We
      don't
      need to support such ancient kernel versions prior.
      
      Link: #84980
      Link: #85068
      6eff53b4
    • OverMighty's avatar
      [clang] Implement __builtin_{clzg,ctzg} (#83431) · c1c2551a
      OverMighty authored
      
      Fixes #83075, fixes #83076.
      c1c2551a
    • Guillaume Chatelet's avatar
      [libc] Add `is_constant_evaluated` type_traits (#86139) · 9a87d4d5
      Guillaume Chatelet authored
      This will replace `__builtin_is_constant_evaluated` in math_extras.h.
      9a87d4d5
    • Craig Topper's avatar
      [ConstantRange] Fix off by 1 bugs in UIToFP and SIToFP handling. (#86041) · 12836467
      Craig Topper authored
      We were passing the min and max values of the range to the ConstantRange
      constructor, but the constructor expects the upper bound to 1 more than
      the max value so we need to add 1.
      
      We also need to use getNonEmpty so that passing 0, 0 to the constructor
      creates a full range rather than an empty range. And passing smin,
      smax+1 doesn't cause an assertion.
      
      I believe this fixes at least some of the reason #79158 was reverted.
      12836467
    • Tarun Prabhu's avatar
      [flang][NFC] Fix header guards · d9f0d9a1
      Tarun Prabhu authored
      Some header guards conflicted with clang. Fix a few others to follow the
      convention in the rest of the headers in flang.
      d9f0d9a1
    • Matt Arsenault's avatar
    • Jonas Devlieghere's avatar
      81bd7998
  2. Mar 21, 2024