1. 10 May, 2019 4 commits
  2. 08 May, 2019 2 commits
    • Jö Fahlke's avatar
      [!666] Test className() even without demangling · 1cc5fecb
      Jö Fahlke authored
      Merge branch 'classnametest-no-demngling-fallback' into 'master'
      
      ref:core/dune-common Run the classnametest is now run two times:
      
      -   classnametest-demangled: skipped if __cxa_demangle() is missing
      -   classnametest-fallback: an exit-status of 1 (resulting from failed checks
          expecting demangling) is still considered successfull, though anything
          else (e.g. segfault) will fail the test.
      
      Closes: [#160]
      
      See merge request [!666]
      
        [#160]: gitlab.dune-project.org/NoneNone/issues/160
        [!666]: gitlab.dune-project.org/core/dune-common/merge_requests/666
      
      
      Closes #160
      1cc5fecb
    • Jö Fahlke's avatar
      Test className() even without demangling · 561095cf
      Jö Fahlke authored
      Run the classnametest is now run two times:
      - `classnametest-demangled`: skipped if `__cxa_demangle()` is missing
      - `classnametest-fallback`: an exit-status of 1 (resulting from failed checks
        expecting demangling) is still considered successfull, though anything
        else (e.g. segfault) will fail the test.
      561095cf
  3. 07 May, 2019 3 commits
    • Jö Fahlke's avatar
      [!659] Make `className(expr)` return dynamic type · 1594c1a7
      Jö Fahlke authored
      Merge branch 'dynamic-classname' into 'master'
      
      ref:core/dune-common In addition, allow rvalue expr.
      
      Closes: [#158]
      
      WIP:
      
      -   [x] This is somewhat of an interface change. Wait at least until
          2019-05-07 for comments
      -   [x] Test for rvalue expr
      
      See merge request [!659]
      
        [#158]: gitlab.dune-project.org/NoneNone/issues/158
        [!659]: gitlab.dune-project.org/core/dune-common/merge_requests/659
      
      
      Closes #158
      1594c1a7
    • Oliver Sander's avatar
      [!663] add default initialization of reserved vector · bd44c3ab
      Oliver Sander authored
      Merge branch 'issue/non_initialized_reservedvector' into 'master'
      
      ref:core/dune-common
      
      ### Summary
      
      Fixes a warning of maybe not initialized member of ReservedVector
      
      ### Details
      
      A default initialization of a ReservedVector, i.e.
      
          ReservedVector<double,3> vec;
          vec.push_back(1.0);
          vec.back() = 2.0;
      
      might result in a compiler warning about possible use of uninitialized members
      vec.data[0]. This can be fixed with a default constructor and default member
      initializers.
      
      See merge request [!663]
      
        [!663]: gitlab.dune-project.org/core/dune-common/merge_requests/663
      bd44c3ab
    • Carsten Gräser's avatar
      [!664] Allow returning references in Std::visit() · 34304c3e
      Carsten Gräser authored
      Merge branch 'introduce-lfe-variant' into 'master'
      
      ref:core/dune-common Our own fallback implementation of Std::visit is
      currently not compatible with visitors returning lvalues. This is needed for
      the LocalFiniteElementVariant MR in dune-localfunctions. Notice that this also
      avoids an allocation that was used in Std::visit before.
      
      For the record: A further cleanup could optimize Hybrid::switchCase to use a
      real c switch statement, because there's rumors that compiler can optimize
      this much better than an `if ... else {} if...` sequence (current
      implementation) or an array of fuction pointers (another possible visit
      implementation).
      
      See merge request [!664]
      
        [!664]: gitlab.dune-project.org/core/dune-common/merge_requests/664
      34304c3e
  4. 06 May, 2019 8 commits
    • Christoph Grüninger's avatar
      [!657] Deprecate old versions of METIS and ParMETIS · 9c8ff584
      Christoph Grüninger authored
      Merge branch 'feature/deprecate-old-metis-parmetis' into 'master'
      
      See merge request [!657]
      
        [!657]: Nonecore/dune-common/merge_requests/657
      9c8ff584
    • Christoph Grüninger's avatar
      3d05cd41
    • Carsten Gräser's avatar
      [!665] [bugfix] Fix Dune::Hybrid::Impl::Id · 8d8ab5ab
      Carsten Gräser authored
      Merge branch 'bugfix/fix-id' into 'master'
      
      ref:core/dune-common There's a bug in the current implementation of
      Dune::Hybrid::Impl::Id. Trying to do 'perfect forwarding' using
      
            template<class T>
            constexpr decltype(auto) foo()(T&& x) {
              return std::forward<T>(x);
            }
      
      leads to undefined behaviour if you pass an r-value to the function. Then
      decltype(auto) would be deduced to be an r-value reference such that in
      
            auto&& bar = foo(expression());
      
      bar would be bound to a temporary which is no longer alive because there's no
      lifetime prolongation. The correct version is
      
            template<class T>
            constexpr T foo()(T&& x) {
              return std::forward<T>(x);
            }
      
      When passed an r-value of the raw type E then T is deduced to be E such that
      we move the temporary into the new value bar. If we pass an l-value of the raw
      type E, then T is deduced to be either T& or `const T&` such that we properly
      return the reference.
      
      See merge request [!665]
      
        [!665]: gitlab.dune-project.org/core/dune-common/merge_requests/665
      8d8ab5ab
    • Carsten Gräser's avatar
      [bugfix] Fix Dune::Hybrid::Impl::Id · f90c50ee
      Carsten Gräser authored
      There's a bug in the current implementation of `Dune::Hybrid::Impl::Id`.
      Trying to do 'perfect forwarding' using
      
        template<class T>
        constexpr decltype(auto) foo()(T&& x) {
          return std::forward<T>(x);
        }
      
      leads to undefined behaviour if you pass an r-value
      to the function. Then `decltype(auto)` would be
      deduced to be an r-value reference such that in
      
        auto&& bar = foo(expression());
      
      `bar` would be bound to a temporary which is no longer
      alive because there's no lifetime prolongation. The correct
      version is
      
        template<class T>
        constexpr T foo()(T&& x) {
          return std::forward<T>(x);
        }
      
      When passed an r-value of the raw type `E` then `T` is
      deduced to be `E` such that we move the temporary into
      the new value `bar`. If we pass an l-value of the raw
      type `E`, then `T` is deduced to be either `T&` or
      `const T&` such that we properly return the reference.
      f90c50ee
    • Carsten Gräser's avatar
      1ab4d91f
    • Simon Praetorius's avatar
      35197ef0
    • Jö Fahlke's avatar
      [!662] [Simd] Ignore value-initialization issues in vectorclass. · 80aa79bb
      Jö Fahlke authored
      Merge branch 'simd-ignore-vectorclass-value-initialization-issues' into 'master'
      
      ref:core/dune-common Value-initialized Vectorclass simd types are not always
      initialized. The reason is that vectorclass defines default-constructors for
      its Simd types with empty body and no member initializers.
      Value-initialization will see those constructors and invoke
      default-initialization. As the mask types sometimes just contain an
      `unsigned short` or similar fundamental data type, default-initializing that
      does nothing and leaves it inintialized.
      
      To make value-initialization work reliably, vectorclass would need to do one
      of two things:
      
      -   Make sure the default-constructor is implicitly or explicitly defaulted.
          That would mean value-initialization would invoke zero-initialization
          before default-inizialization, which would clear the member
      -   Provide a default initializer when declaring the member, which would then
          be used when the class does not define an initializer for the member in
          the default-constructor's member-initializer-list.
      
      Since I can't really fix vectorclass, work around this issue by using
      direct-initialization with an initializer (Simd::Scalar<V>(0)) to initialize
      simd types.
      
      Closes: [extensions/dune-vectorclass#9]
      
      See merge request [!662]
      
        [extensions/dune-vectorclass#9]: gitlab.dune-project.org/extensions/dune-vectorclass/issues/9
        [!662]: gitlab.dune-project.org/core/dune-common/merge_requests/662
      
      
      Closes extensions/dune-vectorclass#9
      80aa79bb
    • Jö Fahlke's avatar
      [Simd] Ignore value-initialization issues in vectorclass. · d676c3cb
      Jö Fahlke authored
      Value-initialized Vectorclass simd types are not always initialized.  The
      reason is that vectorclass defines default-constructors for its Simd types
      with empty body and no member initializers.  Value-initialization will see
      those constructors and invoke default-initialization.  As the mask types
      sometimes just contain an `unsigned short` or similar fundamental data type,
      default-initializing that does nothing and leaves it inintialized.
      
      To make value-initialization work reliably, vectorclass would need to do one
      of two things:
      - Make sure the default-constructor is implicitly or explicitly defaulted.
        That would mean value-initialization would invoke zero-initialization before
        default-inizialization, which would clear the member
      - Provide a default initializer when declaring the member, which would then be
        used when the class does not define an initializer for the member in the
        default-constructor's member-initializer-list.
      
      Since I can't really fix vectorclass, work around this issue by using
      direct-initialization with an initializer `(Simd::Scalar<V>(0))` to
      initialize simd types.
      
      Closes: extensions/dune-vectorclass#9
      d676c3cb
  5. 28 Apr, 2019 2 commits
  6. 24 Apr, 2019 3 commits
  7. 23 Apr, 2019 4 commits
  8. 18 Apr, 2019 2 commits
  9. 16 Apr, 2019 1 commit
    • Oliver Sander's avatar
      [!656] Implement ScalarMatrixView · 73a4ff68
      Oliver Sander authored
      Merge branch 'feature/implement-scalarmatrixview' into 'master'
      
      ref:core/dune-common This wrapper around a pointer to a number makes the
      number look like a 1x1 matrix. The asMatrix() helper functions get a
      matrix-like object form either a matrix or a number:
      
      -   If the object is a number, it's wrapped into the ScalarMatrixView proxy
          matrix.
      -   Otherwise it is asumed that the object already is a matrix which is simply
          forwarded.
      
      In order to use this you have to use proxy-aware universal references
      
          auto&& matrix = Impl::asMatrix(matrixOrNumber);
      
      All functionality (despite traits class spezializations) are contained in the
      namespace Impl::
      
      See merge request [!656]
      
        [!656]: gitlab.dune-project.org/core/dune-common/merge_requests/656
      73a4ff68
  10. 10 Apr, 2019 3 commits
    • Carsten Gräser's avatar
      Make DenseMatrix robust wrt to proxy matrices · e7d28a28
      Carsten Gräser authored
      For a proxy-matrix you cannot simply copy the derived type `MAT`
      to get a self-contained copy. This will just copy the proxy and
      the new proxy will point to the same value. To solve such issues
      we have the `AutonomousValue` mechanism which provides (by
      spezialization) a type which allows to store a self-contained copy.
      
      To make this work we need to call `luDecomposition` of
      `DenseMatrix<AutonomousValue<MAT>>` instead of `DenseMatrix<MAT>`.
      It turnes out that, surprisingly, this method is non-static which
      is also fixed by this commit.
      e7d28a28
    • Carsten Gräser's avatar
      Allow assignment of Scalar*View from other template instantiation · 68956c93
      Carsten Gräser authored
      This especially allow to assign a
      `Scalar*View<K>` from a `Scalar*View<const K>`.
      Additionally this introduces a specialization of `AutonomousValueType`
      for `Scalar*View`.
      68956c93
    • Carsten Gräser's avatar
      Implement ScalarMatrixView · 698a28d6
      Carsten Gräser authored
      This wrapper around a pointer to a number makes the number
      look like a 1x1 matrix. The `asMatrix()` helper functions
      get a matrix-like object form either a matrix or a number:
      * If the object is a number, it's wrapped into the `ScalarMatrixView`
        proxy matrix.
      * Otherwise it is asumed that the object already is a matrix
        which is simply forwarded.
      In order to use this you have to use proxy-aware universal references
      ```
      auto&& matrix = Impl::asMatrix(matrixOrNumber);
      ```
      
      All functionality (despite traits class spezializations)
      are contained in the namespace `Impl::`
      698a28d6
  11. 09 Apr, 2019 1 commit
    • Oliver Sander's avatar
      [!650] Feature/generalize densematrix multiplication scalarvector view · 9ad168ff
      Oliver Sander authored
      Merge branch 'feature/generalize-densematrix-multiplication-scalarvector-view' into 'master'
      
      ref:core/dune-common That's an alternative version of [!648] based on [!649].
      The implementation is simplified (IMHO) using ScalarVectorWrapper and
      asVector(). Notice that this incorporates [!649] already.
      
      See merge request [!650]
      
        [!648]: gitlab.dune-project.org/NoneNone/merge_requests/648
        [!649]: gitlab.dune-project.org/NoneNone/merge_requests/649
        [!650]: gitlab.dune-project.org/core/dune-common/merge_requests/650
      9ad168ff
  12. 08 Apr, 2019 7 commits