Skip to content
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

Open
wants to merge 9,176 commits into
base: LSNP_Current
Choose a base branch
from
Open

Upgrade to 3.3.9 #2

wants to merge 9,176 commits into from

Conversation

akleeman
Copy link

This rebases any swift specific changes on Eigen 3.3.9.

ggael and others added 30 commits November 23, 2016 16:05
…fix a few Real versus Scalar issues.

(grafted from 56e5ec0
)
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
)
…ng factor: (s*A).triangularView<UpperUnit>()*B

(grafted from 5deeb19
)
…t assertion is a static one and not a runtime one.

(grafted from f6be728
)
Adds missing EIGEN_STRONG_INLINE to support MSVC properly inlining small vector calculations
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
)
Flamefire and others added 21 commits September 30, 2020 00:55
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)
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 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 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)
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.
@woodfell
Copy link

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:

[100%] Building CXX object pvt_common/CMakeFiles/pvt-common.dir/src/coord_system.cc.obj
In file included from /home/matt/work/piksi_firmware_private/third_party/starling/pvt_common/include/pvt_common/eigen_custom.h:24:0,
                 from /home/matt/work/piksi_firmware_private/third_party/starling/pvt_common/include/pvt_common/coord_system.h:17,
                 from /home/matt/work/piksi_firmware_private/third_party/starling/pvt_common/src/coord_system.cc:13:
/home/matt/work/piksi_firmware_private/third_party/starling/pvt_common/include/pvt_common/newlib_workarounds.h:24:17: error: expected unqualified-id before 'int'
 #define int32_t int
                 ^
In file included from /home/matt/work/piksi_firmware_private/third_party/starling/pvt_common/include/pvt_common/eigen_custom.h:24:0,
                 from /home/matt/work/piksi_firmware_private/third_party/starling/pvt_common/include/pvt_common/covariance_checks.h:17,
                 from /home/matt/work/piksi_firmware_private/third_party/starling/pvt_common/src/covariance_checks.cc:13:
/home/matt/work/piksi_firmware_private/third_party/starling/pvt_common/include/pvt_common/newlib_workarounds.h:24:17: error: expected unqualified-id before 'int'
 #define int32_t int
                 ^
make[3]: *** [pvt_common/CMakeFiles/pvt-common.dir/build.make:63: pvt_common/CMakeFiles/pvt-common.dir/src/coord_system.cc.obj] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [pvt_common/CMakeFiles/pvt-common.dir/build.make:76: pvt_common/CMakeFiles/pvt-common.dir/src/covariance_checks.cc.obj] Error 1
make[2]: *** [CMakeFiles/Makefile2:1786: pvt_common/CMakeFiles/pvt-common.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:1798: pvt_common/CMakeFiles/pvt-common.dir/rule] Error 2

I don't know the history of this hack, but just removing it breaks other things

@akleeman
Copy link
Author

@woodfell I wonder if int32_t is being defined as a type elsewhere (perhaps within Eigen) and so the #define int32_t int statement is failing? Any reason why we aren't using typedef or using in newlib_workarounds.h?

I suspect the other failures are because our patch fixes a static allocation issue in Eigen.

@akleeman
Copy link
Author

@jbangelo perhaps you're familiar with the issue @woodfell encountered?

@jbangelo
Copy link

I'm not sure what would be causing that, I'd have to dig into things

@woodfell
Copy link

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

@akleeman
Copy link
Author

There's a suspicious change that was added to Eigen which does a typedef std::int32_t int32_t ... but it's also inside Eigen::numext namespace so probably not the issue? https://gitlab.com/libeigen/eigen/-/commit/4356a55a61c99faec681b20c5477b7e7012ca128#f7cc96c40d9c142c30ae1e5f0482ddada6fbacc6_643_657

@woodfell
Copy link

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

@akleeman
Copy link
Author

I haven't looked into the int32_t any further. Were you able to get PFWP compiling?

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!

@woodfell
Copy link

Only very minimally. By removing that #define thing it can be compiled, I've run it on piksi and it appears to be working ok. But this is only a few minutes of bench testing, nothing particularly extensive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.