test-cornerstoragerefwrap segfaults on AMD CPUs in job "debian:10 gcc-8-noassert-17" since gcc-8.2.0

@ansgar Are you aware of any issues with the dresden runner that could explain this?

mentioned in commit eb051c45

Pipeline https://gitlab.dune-project.org/core/dune-geometry/pipelines/12338 tries that job on different runners. The runner sky is down for performance tests at the moment, so that job may need to be restarted tomorrow

Hmm.

runner	CPU	status
shared-ci@tu-dresden.de	bulldozer	fail
dune-ci@epic.uni-muenster.de	zen	fail
hd-2c-8g-1h	haswell	pass
dune-ci@sky.uni-muenster.de	skylake-avx512	pass

Maby the generated code fails on AMD processors only? I.e. compiler bug? At least I don't see any -march=native passed to the compiler.

The last job where test-cornerstoragerefwrap succeeded in dresden was https://gitlab.dune-project.org/core/dune-geometry/-/jobs/52307, two weeks ago with g++ 8.1.0.

The failing jobs used g++ 8.2.0.

So thats probably it, then.

changed title from test-cornerstoragerefwrap segfaults on {-shared-ci@tu-dresden.de in job "debian:10 gcc-8-noassert-17"-} to test-cornerstoragerefwrap segfaults on AMD CPUs in job "debian:10 gcc-8-noassert-17" since gcc-8.2.0

As it turns out, there is the Vc library in that build, which does detection of the architecture at cmake time. It seems to detect these parameters:

-Wabi -fabi-version=0 -fabi-compat-version=0 -ffp-contract=fast -march=znver1 -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4a -mavx -mfma -mbmi2 -mavx2 -mno-xop -mno-fma4 -mno-avx512f -mno-avx512vl -mno-avx512pf -mno-avx512er -mno-avx512cd -mno-avx512dq -mno-avx512bw -mno-avx512ifma -mno-avx512vbmi -DENABLE_VC=1 -fext-numeric-literals

With all of the above parameters, the test segfaults.
With none of the above parameters, the test segfaults too.
With only -mavx (or -mavx2), the test passes.

If manually reduced the test to a call to Dune::ReferenceElements<double, 2>::cube() and am in the process of running a creduce. The interestingness test

compiles the preprocessed output with -mavx and requires it to exit with 0,
compiles the preprocessed output without -mavx and requires it to segfault.

Here is the creduce result for now, which is going to need further reduction: interestingness test, test-cornerstoragerefwrap.ii

This is now freestanding, i.e. there shouldn't be any dune parts needed to link against.

Unfortunately, as it turns out, the reduced testcase seems to be nondeterministic, so I'm redoing the reduction manually.

Manual reduction lead me to this today:

test.cc

#include <array>
#include <vector>

template<class T>
__attribute__((__noinline__)) T ID(T v)
{
  asm("");
  return v;
}

int main()
{
  std::vector< std::array< double, 2 > > origins( 2 );
  origins[ 0 ] = { 0.0, 0.0 };
  origins[ 1 ] = { 0.0, 0.0 };
  std::array< double, 1 > jacobianTransposeds[ 2 ];
  jacobianTransposeds[ 0 ] = { 0.0 };
  jacobianTransposeds[ 1 ] = { 0.0 };
  const unsigned int n = 2*ID(1);
  for( unsigned int i = 0; i < n; ++i )
    jacobianTransposeds[ i ][ 0 ] = origins[ i ][ 0 ];
}

Compiling like this (interesting):

/usr/bin/g++-8 -std=c++17 -O3 -mavx -o test-cornerstoragerefwrap-pass test.cc
/usr/bin/g++-8 -std=c++17 -O3 -o test-cornerstoragerefwrap-fail test.cc

I've tried your code on our AMD EPYC 7551P with GCC 8.2.0 and I get: pass= 10/10, fail= 10/10. I have repeated the compile-and-run test several times and always the same result.

Reduced through the standard library, got this:

test.ii

struct array2
{
  double _M_elems0;
  double _M_elems1;
};
struct array1
{
  double _M_elems[1];
};
constexpr double&
_S_ref(array1 &a) noexcept
{
  const auto &__t = a._M_elems;
  return const_cast<double&>(__t[0]);
}
int main(int argc, char **)
{
  array2* _M_start = new array2[2];
  _M_start[ 0 ]._M_elems0 = 0.0;
  _M_start[ 1 ]._M_elems0 = 0.0;
  array1 jacobianTransposeds[ 2 ];
  const unsigned int n = 2*argc;
  for( unsigned int i = 0; i < n; ++i )
    _S_ref(jacobianTransposeds[ i ]) = _M_start[ i ]._M_elems0;
  delete[] _M_start;
}

I'm pointing an accusing finger at the const_cast, which happened somewhere in the guts of std::array. From https://en.cppreference.com/w/cpp/language/const_cast#Notes:

const_cast makes it possible to form a reference or pointer to non-const type that is actually referring to a const object or a reference or pointer to non-volatile type that is actually referring to a volatile object. Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior.

Though I'm not 100% certain that this actually is undefined behavior, after all, the modified object is ultimately non-const.

Hmm, the C++17 standard (§10.1.7.1 The cv-qualifiers) actually has several examples showing that taking a pointer-to-const to a non-const object, then casting away the constness of that pointer and modifying the object through the result is well-defined.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288

The GCC bug is already present in 8.1.0, so I'm not sure whether a fix for the gcc bug will also fix this problem.

mentioned in merge request !110 (merged)

I can confirm that this bug seems to be fixed in the current gcc snapshot (gcc-9-20181118).

https://gcc.gnu.org/pub/gcc/snapshots/9-20181118/gcc-9-20181118.tar.xz
dune-common@a294e03d
a0d66736
opts
Dockerfile-8.2 (this is segfaulting)
Dockerfile (this passes)

For want of a better idea, I'm going to skip this test for gcc >=8.2 <9.0

(Edit: gcc >=8.2, not 8.0)

mentioned in commit c5ee6995

mentioned in merge request !114 (merged)

test-cornerstoragerefwrap segfaults on AMD CPUs in job "debian:10 gcc-8-noassert-17" since gcc-8.2.0

Designs

Child items 0

Activity