Test matrix_free/fe_q_iso_q1_01 segfaults with clang-16 when linked against libc++ in debug mode

[tamiko]

I have no idea what to make out of this segfault with clang-16 in debug mode:

#0  0x00007ffff5375faf in dealii::Polynomials::PiecewisePolynomial<double>::value (this=0x5555557d96d0, x=0.10566243270259355, n_derivatives=4, values=0x555555887730)
    at /srv/testsuite/dealii/source/base/polynomials_piecewise.cc:143
#1  0x00007fffefbcd32e in dealii::TensorProductPolynomials<2, dealii::Polynomials::PiecewisePolynomial<double> >::compute_derivative<1> (this=0x555555880a70, i=<optimized out>, p=...)
    at /srv/testsuite/dealii/include/deal.II/base/tensor_product_polynomials.h:558
#2  0x00007ffff3db48a4 in dealii::internal::MatrixFreeFunctions::ShapeInfo<dealii::VectorizedArray<double, 2ul> >::reinit<2, 2, 2> (this=0x55555587fac0, quad_in=..., fe_in=..., 
    base_element_number=<optimized out>) at /srv/testsuite/dealii/include/deal.II/matrix_free/shape_info.templates.h:701
#3  0x00007ffff3be68b5 in dealii::MatrixFree<2, double, dealii::VectorizedArray<double, 2ul> >::internal_reinit<double, 2> (this=0x7fffffffc870, mapping=..., dof_handler=..., 
    constraints=..., locally_owned_dofs=..., quad=..., additional_data=...) at /srv/testsuite/dealii/include/deal.II/matrix_free/matrix_free.templates.h:426
#4  0x000055555557e290 in dealii::MatrixFree<2, double, dealii::VectorizedArray<double, 2ul> >::reinit<dealii::QIterated<1>, double, dealii::MappingQ1<2, 2> > (
    this=this@entry=0x7fffffffc870, mapping=..., dof_handler=..., constraints_in=..., quad=..., additional_data=...) at /srv/testsuite/dealii/include/deal.II/matrix_free/matrix_free.h:3167
#5  0x000055555557b115 in test<2> (n_subdivisions=n_subdivisions@entry=2) at /srv/testsuite/dealii/tests/matrix_free/fe_q_iso_q1_01.cc:53
#6  0x000055555557a3f7 in main (argc=1, argv=0x7fffffffdc18) at /srv/testsuite/dealii/tests/matrix_free/fe_q_iso_q1_01.cc:91

The test passes for all other compilers and test configurations. Also, the corresponding release-variant passes on all configurations.

In reference to #15383

[bangerth]

For reference, the code is here (line 143):
https://github.com/dealii/dealii/blob/master/source/base/polynomials_piecewise.cc#L143
It's hard to believe what can go wrong in this place. x is a local function argument (passed by-value), offset a local variable, as is step. There aren't any pointer operations in this line.

I think you'll have to run this in a debugger and poke around the various variables to see what's happening here.

[kronbichler]

I investigated the problem and realized the following:

• The problem fails in the assembly instruction cmpnltpd %xmm3,%xmm2, which corresponds to the comparison x < offset, where x=0.10566243270259355 and offset = 0.0, with %xmm2 mapped to x and %xmm3 mapped to offset.
• When the violation occurs, I see the register content %xmm2 = v2_double = {0.10566243270259355, 0} and %xmm3 = v2_double = {0, -nan(0xfffffffffffff)}. This means that xmm3 contains a 0 in the lower part of the vector, which is correct, but a nan in the upper part of the 128-bit vector. It is the upper part that creates a floating point exception.
• I then went through the uses of the %xmm3 register in this function, and apparently it is only used in the instructions cvtsi2sd and mulsd before. These are lower-lane functions, so they do not touch the upper lane. In consequence, the origin must be somewhere else in the call stack.

I tend to believe that this must be a compiler bug, because the compiler cannot make assumptions on the prior content of %xmm3 upon entry of the function in terms of the content in the upper lane. In other words, the compiler should have chosen a cmpnltsd instruction instead of cmpnltpd. I do not see it for clang versions prior to 16.0 and I only see it with -Og and -O1 compile flags. I think it is time to file a bug report to clang/llvm. I try to extract a minimal test case.

[kronbichler]

Note that the result of the upper lane, which contains nan, will not be used later in the code, and is in fact an artificial leftover from some library call somewhere else. The investigation makes me sure this is not our bug.

[tamiko]

@kronbichler I will add the flag to the debug variant when compiling with clang.