-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to 3.3.9 #2
base: LSNP_Current
Are you sure you want to change the base?
Conversation
…fix a few Real versus Scalar issues. (grafted from 56e5ec0 )
(grafted from f12b368 )
(grafted from 8579195 )
Branch 3.3: Fixing missing inlines on device functions for newer CUDA cards
…all vector calculations When working with MSVC often small vector operations are not properly inlined. This behaviour is observed even on the most recent compiler versions.
(grafted from 31e0bda )
(grafted from f558ad2 )
(grafted from 12efc7d )
…ng factor: (s*A).triangularView<UpperUnit>()*B (grafted from 5deeb19 )
(grafted from d820ab9 )
…t assertion is a static one and not a runtime one. (grafted from f6be728 )
(grafted from f7d1768 )
Adds missing EIGEN_STRONG_INLINE to support MSVC properly inlining small vector calculations
(grafted from 524119d )
(grafted from 40b4bf3 )
…e::diagonal(i) (grafted from 8d0ffe3 )
(grafted from de7b0fd )
…at with underflow. (grafted from c5b56f1 )
…sized) (grafted from dd4cc6b )
Author: George Burgess IV <[email protected]> Date: Thu Mar 1 11:20:24 2018 -0800 Prefer `::operator new` to `new` The C++ standard allows compilers much flexibility with `new` expressions, including eliding them entirely (https://godbolt.org/g/yS6i91). However, calls to `operator new` are required to be treated like opaque function calls. Since we're calling `new` for side-effects other than allocating heap memory, we should prefer the less flexible version. Signed-off-by: George Burgess IV <[email protected]> (grafted from 8c7b515 )
…ranspositions().inverse()) (grafted from a129239 )
(grafted from 112c899 )
…riendly. (grafted from e116f68 )
When the type is PATH an absolute path is expected and user-defined values are converted into absolute paths relative to the current directory. Fixes #1990 (cherry picked from commit a967fad)
Fixes #1995 (cherry picked from commit 30960d4)
An OpenMP parallel section must have a single entry and a single point of exit. Leaving such a section by throwing an exception is undefined. This patch fixes this by catching possible exceptions on the parallel section and throwing right we left it.
EIGEN_USING_STD -> EIGEN_USING_STD_MATH
This fixes #2012.
This resolves a compilation error associated with Eigen::eigen_assert_exception. It also eliminates the counting of exceptions that may occur in the OpenMP parallel section. If an unhandled exception occurs in this section, the behavior is non-conforming according to the OpenMP specification.
(cherry picked from commit d199c17)
(cherry picked from commit 9022f5a)
(cherry picked from commit 572d626)
Having a test named "array" can clash with the standard library header "array". Fixes issue #2046
…compiles (and is guaranteed to call math functions) (cherry picked from commit ecb7bc9)
…andard copy-assign-operator from PermutationMatrix and Transpositions to allow malloc-less std::move. Added unit-test to rvalue_types (cherry picked from commit efd9867)
Note that HTTPS must be used against the MathJax CDN when hosted on `eigen.tuxfamily.org` (which uses HTTPS) in order to avoid `Mixed Content`-errors from browsers. Using HTTPS for MathJax also works if the Eigen docs are hosted on plain HTTP. (cherry picked from commit 280f4f2)
Manually cherry-picked from a7170f2
part of the class signature is lost due to a problem with forward declarations. The problem is probably caused by doxygen bug #7689. It is confirmed to be fixed in doxygen >= 1.8.19. (cherry picked from commit 68f6941)
(cherry picked from commit c5985c4)
This commit modifies constructors for dense storage with some size information at compile-time to avoid copying uninitialized elements.
I've been playing about with this branch today and it mostly works well as far as I can tell. I'm getting a strange build error when trying to use it in PFWP though:
I don't know the history of this hack, but just removing it breaks other things |
@woodfell I wonder if I suspect the other failures are because our patch fixes a static allocation issue in Eigen. |
I'm not sure what would be causing that, I'd have to dig into things |
Just noticed it's happening on the starling repo PR as well - https://jenkins.ci.swift-nav.com/blue/organizations/jenkins/swift-nav%2Fstarling/detail/PR-4961/1/pipeline |
There's a suspicious change that was added to Eigen which does a |
Is there any update on this issue? I'm looking at doing a combined drop of fixes to Excelfore this week and this is one of the ones that is holding them up |
I haven't looked into the We'll want to make sure this update works with all our repos which use Eigen as well which, to be perfectly honest, would probably end up being a little more work than I signed up for. But who knows perhaps it'll just work! |
Only very minimally. By removing that |
This rebases any swift specific changes on Eigen 3.3.9.