Summary: | Functions must be DECLARED __forcedinline. | ||
---|---|---|---|
Product: | Eigen | Reporter: | panda-34 <anikin> |
Component: | General | Assignee: | Nobody <eigen.nobody> |
Status: | CONFIRMED --- | ||
Severity: | Unknown | CC: | gael.guennebaud, jacob.benoit.1 |
Priority: | Normal | ||
Version: | 3.2 | ||
Hardware: | x86 - 32-bit | ||
OS: | Windows | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 1608 |
Description
panda-34
2013-10-01 16:04:32 UTC
Sorry for not looking at this issue earlier. ICC is indeed that stupid, and pretty bad at inlining in general. I have examples where it fails to inline the trivial copy-constructor that it generated itself. For instance for CwiseUnaryOp, it introduces calls to functions with a body as trivial as: movq (%rsi), %rax movq %rax, (%rdi) movq 8(%rsi), %rdx movq %rdx, 8(%rdi) ret I'll try to fix as many of them as possible, but I guess that we should also recommend users to compile with -inline-forceinline (or use gcc or clang ;). Regarding the discrepancies between declarations and definitions, since there are more than 2000 occurences of EIGEN_STRONG_INLINE we would need an automatic way to detect them... any ideas? Here is a first bunch of fixes limiting the damages: https://bitbucket.org/eigen/eigen/commits/dc19770fa4b0/ I haven't included the explicit copy-ctor because I'd prefer to find another workaround, hopefully... -- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/667. |