Compilation fails for `Intel 18` #13821

marcfehling · 2022-05-25T20:34:48Z

With the Intel 18.0.2 suite (compiler, MPI, MKL), we can not compile the current master branch. It succeeds with Intel 19.1.1 though.

The following error recurs:

In file included from /dealii/include/deal.II/grid/tria_description.h(27),
                 from /dealii/include/deal.II/grid/tria.h(29),
                 from /dealii/include/deal.II/distributed/tria_base.h(28),
                 from /dealii/include/deal.II/dofs/dof_handler.h(29),
                 from /dealii/include/deal.II/dofs/dof_accessor.h(22),
                 from /dealii/source/numerics/data_out.cc(18):
/dealii/include/deal.II/lac/la_parallel_vector.h(1938): internal error: assertion failed at: "shared/cfe/edgcpfe/class_decl.c", line 3591

                                    has_locally_owned_domain_indices<MatrixType>,
                                    ^

compilation aborted for /dealii/source/numerics/data_out.cc (code 4)
make[2]: *** [source/numerics/CMakeFiles/obj_numerics_release.dir/data_out.cc.o] Error 4
make[1]: *** [source/numerics/CMakeFiles/obj_numerics_release.dir/all] Error 2
make: *** [all] Error 2

The line is part of a std::enable_if construct:

dealii/include/deal.II/lac/la_parallel_vector.h

Lines 1935 to 1939 in 9dd448b

    
           template < 
        
             typename MatrixType, 
        
             typename std::enable_if<has_get_mpi_communicator<MatrixType> && 
        
                                       has_locally_owned_domain_indices<MatrixType>, 
        
                                     MatrixType>::type * = nullptr>

Seems to be a compiler bug. Any idea how to deal with this?

The text was updated successfully, but these errors were encountered:

marcfehling · 2022-05-25T20:46:53Z

Maybe reverting parts of #13291 and #13320 will allow compilation again.

bangerth · 2022-05-25T23:34:08Z

You could try and see whether it makes a difference if you create a local static constexpr variable above that function that holds the result of has_get_mpi_communicator<MatrixType> && has_locally_owned_domain_indices<MatrixType> , and then use that variable in the enable_if.

marcfehling · 2022-05-26T01:09:39Z

You could try and see whether it makes a difference if you create a local static constexpr variable above that function that holds the result of has_get_mpi_communicator<MatrixType> && has_locally_owned_domain_indices<MatrixType> , and then use that variable in the enable_if.

That does not work, unfortunately. I swapped positions of this and the following function, as the latter doesn't use the && operator. Still the same problem.

In file included from /dealii/include/deal.II/grid/tria_description.h(27),
                 from /dealii/include/deal.II/grid/tria.h(29),
                 from /dealii/include/deal.II/distributed/tria_base.h(28),
                 from /dealii/include/deal.II/dofs/dof_handler.h(29),
                 from /dealii/include/deal.II/dofs/dof_accessor.h(22),
                 from /dealii/source/numerics/data_out.cc(18):
/dealii/include/deal.II/lac/la_parallel_vector.h(1940): internal error: assertion failed at: "shared/cfe/edgcpfe/class_decl.c", line 3591

                  typename std::enable_if<has_initialize_dof_vector<MatrixType>,
                                          ^

compilation aborted for /dealii/source/numerics/data_out.cc (code 4)

I will try to revert the old PRs partially and then add some preprocessor conditional with respect to the Intel compiler version. This way we still have the new, elegant way, and the old, compatible implementation. Plus we can easily drop the legacy code when we decide to no longer support Intel 18 (or rather when the XSDK group decides it is time).

bangerth · 2022-05-26T02:56:50Z

I played with this a bit earlier and pretty much instantly got into hot water when trying to replace std::enable_if by std::enable_if_t. I think it is because in essence we are doing this:

// function overload 1
      template <typename MatrixType,
                      typename std::enable_if<cond1>::type * = nullptr>
      void
      foo(MatrixType &                                mat,
            LinearAlgebra::distributed::Vector<Number, MatrixType> &vec,
            bool /*omit_zeroing_entries*/);

// function overload 2
      template <typename MatrixType,
                      typename std::enable_if<cond2, MatrixType>::type * = nullptr>
      void
      foo(MatrixType &                                mat,
            LinearAlgebra::distributed::Vector<Number> &vec,
            bool /*omit_zeroing_entries*/);

These functions have the same signature, and if there are template arguments so that both cond1 and cond2 are both true, then the compiler complained that we end up with a redeclaration of a function, which is not allowed.

Could you try something like

// function overload 1
      template <typename MatrixType>
      void
      foo(MatrixType &                                mat,
            LinearAlgebra::distributed::Vector<Number> &vec,
            bool /*omit_zeroing_entries*/,
            typename std::enable_if<cond1>::type * = nullptr)

instead?

marcfehling · 2022-05-27T16:40:21Z

These functions have the same signature, and if there are template arguments so that both cond1 and cond2 are both true, then the compiler complained that we end up with a redeclaration of a function, which is not allowed.

I still get the same error if I get rid of the second overload entirely. Moving the enable_if statement into a function parameter also didn't work.

However, getting rid of the static constexpr variables and writing for example

std::enable_if<is_supported_operation<get_mpi_communicator_t, MatrixType>

instead of

std::enable_if<has_get_mpi_communicator<MatrixType>

worked!

Do you prefer getting rid of the static constexpr variables entirely, or shall I write a conditional as described in #13821 (comment)?

I will apply the changes and see if it's going to work for all cases.

marcfehling · 2022-05-27T16:52:53Z

This seems to work:
https://github.com/marcfehling/dealii/blob/1c589dd470598440bdbf59a0d3bb6b7cbe2bd610/include/deal.II/lac/la_parallel_vector.h#L1935-L1945

marcfehling · 2022-05-27T21:07:39Z

When compiling the examples, I am now facing linker problems:

../lib/libdeal_II.so.9.4.0-pre: error: undefined reference to 'void dealii::Utilities::MPI::internal::all_reduce<bool>(int const&, dealii::ArrayView<bool const, dealii::MemorySpace::Host> const&, int const&, dealii::ArrayView<bool, dealii::MemorySpace::Host> const&)'

tjhei · 2022-05-27T21:37:24Z

I am now facing linker problems:

This looks like #13794, which should have been fixed already.

marcfehling · 2022-05-27T21:47:54Z

This looks like #13794, which should have been fixed already.

Thank you for the hint! #13794 is already part of my feature branch, but it didn't fix the problem. ~~Interestingly, linking succeeds with Intel 19 - it's just Intel 18 that causes trouble.~~

I will double-check that my configuration is correct.

marcfehling · 2022-05-27T21:51:51Z

Actually, Intel 19 bails out with a different error message when building in release mode:

          ": internal error: ** The compiler has encountered an unexpected problem.
** Segmentation violation signal raised. **
Access violation or stack overflow. Please contact Intel Support for assistance.

icpc: error #10014: problem during multi-file optimization compilation (code 4)

marcfehling · 2022-05-27T22:40:20Z

I take everything back. My feature branch did not include #13794.

bangerth · 2022-05-30T17:13:42Z

What's left here? Did #13838 and #13841 fix this?

marcfehling · 2022-05-31T02:22:49Z

I encountered one more (and hopefully the last) linker error with both Intel 18 and Intel 19.

 /opt/apps/gcc/6.3.0/bin/ld.gold: error: ../lib/libdeal_II.g.so.9.4.0-pre: bad symbol name offset 947623309 at 0

But I have no idea how to figure out the cause for this one.

tjhei · 2022-05-31T02:44:52Z

Can you try without the gold linker? Also try deleting all intermediate files and build again, i think I had something like this before where one of the artifacts is garbage (from an earlier unsuccessful build).

marcfehling · 2022-05-31T05:09:29Z

Thanks for the hint @tjhei.

It indeed works when disabling gold by adding -D DEAL_II_COMPILER_HAS_FUSE_LD_GOLD=OFF to the cmake configuration, for both Intel 18 and Intel 19.

I guess we can close the issue now.

For completion, these are the errors I get:

Intel 18:

/opt/apps/gcc/6.3.0/bin/ld.gold: error: ../lib/libdeal_II.so.9.4.0-pre: bad symbol name offset 1196708948 at 0

Intel 19:

          ": internal error: ** The compiler has encountered an unexpected problem.
** Segmentation violation signal raised. **
Access violation or stack overflow. Please contact Intel Support for assistance.

icpc: error #10014: problem during multi-file optimization compilation (code 4)

marcfehling added the High Priority ⚠️ label May 25, 2022

marcfehling added this to the Release 9.4 milestone May 25, 2022

marcfehling changed the title ~~Compilation fails for Intel18~~ Compilation fails for Intel 18 May 25, 2022

marcfehling added the Compiler label May 25, 2022

This was referenced May 27, 2022

Intel 18: static constexpr bool #13838

Merged

Intel 18: more constexpr problems #13841

Merged

marcfehling closed this as completed May 31, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compilation fails for `Intel 18` #13821

Compilation fails for `Intel 18` #13821

marcfehling commented May 25, 2022 •

edited

marcfehling commented May 25, 2022

bangerth commented May 25, 2022

marcfehling commented May 26, 2022

bangerth commented May 26, 2022

marcfehling commented May 27, 2022 •

edited

marcfehling commented May 27, 2022

marcfehling commented May 27, 2022

tjhei commented May 27, 2022

marcfehling commented May 27, 2022 •

edited

marcfehling commented May 27, 2022

marcfehling commented May 27, 2022

bangerth commented May 30, 2022

marcfehling commented May 31, 2022

tjhei commented May 31, 2022 •

edited

marcfehling commented May 31, 2022

Compilation fails for Intel 18 #13821

Compilation fails for Intel 18 #13821

Comments

marcfehling commented May 25, 2022 • edited

marcfehling commented May 25, 2022

bangerth commented May 25, 2022

marcfehling commented May 26, 2022

bangerth commented May 26, 2022

marcfehling commented May 27, 2022 • edited

marcfehling commented May 27, 2022

marcfehling commented May 27, 2022

tjhei commented May 27, 2022

marcfehling commented May 27, 2022 • edited

marcfehling commented May 27, 2022

marcfehling commented May 27, 2022

bangerth commented May 30, 2022

marcfehling commented May 31, 2022

tjhei commented May 31, 2022 • edited

marcfehling commented May 31, 2022

Compilation fails for `Intel 18` #13821

Compilation fails for `Intel 18` #13821

marcfehling commented May 25, 2022 •

edited

marcfehling commented May 27, 2022 •

edited

marcfehling commented May 27, 2022 •

edited

tjhei commented May 31, 2022 •

edited