Assertion failed: ((CGF.CurFuncDecl == nullptr || CGF.Builder.getIsFPConstrained() || isa<CXXConstructorDecl>(CGF.CurFuncDecl) || isa<CXXDestructorDecl>(CGF.CurFuncDecl) || (NewExceptionBehavior == llvm::fp::ebIgnore && NewRoundingBehavior == llvm::RoundingMode::NearestTiesToEven)) && "FPConstrained should be enabled on entire function"), function ConstructorHelper, file /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp, line 165.

[pkubaj]

FreeBSD 14.0-CURRENT LLVM 16.0.6 powerpc64le, powerpc64, powerpc64

Reproducer:

template <class Compare> void stable_sort(int last, Compare) {
  stable_sort(last, int());
}
#pragma STDC FENV_ACCESS ON
struct cluster_result {
  int operator[](int);
};
template <int> void generate_SciPy_dendrogram() {
  cluster_result Z2;
  int trans_tmp_1(0);
  int trans_tmp_2 = Z2[1];
  stable_sort(trans_tmp_1, trans_tmp_2);
}
void linkage_wrap() { generate_SciPy_dendrogram<false>; }

Build with:

/usr/bin/c++ -cc1 -triple powerpc-unknown-freebsd14.0 -emit-obj fastcluster_python-684654.cpp

Output:

Assertion failed: ((CGF.CurFuncDecl == nullptr || CGF.Builder.getIsFPConstrained() || isa<CXXConstructorDecl>(CGF.CurFuncDecl) || isa<CXXDestructorDecl>(CGF.CurFuncDecl) || (NewExceptionBehavior == llvm::fp::ebIgnore && NewRoundingBehavior == llvm::RoundingMode::NearestTiesToEven)) && "FPConstrained should be enabled on entire function"), function ConstructorHelper, file /usr/src/contrib/llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp, line 165.

[VoxSciurorum]

I confirmed this behavior with the system compiler on FreeBSD 14.0-CURRENT on amd64 and aarch64 as well. The ports build of llvm16 does not crash, despite being based on a very similar version of llvm.

[pkubaj]

LLVM in ports has assertions disabled, which is probably the reason.

[VoxSciurorum]

LLVM in ports has assertions disabled, which is probably the reason.

I think you are right about that. I also reproduced the crash on amd64 Linux using a build with assertions enabled.

[DimitryAndric]

This regressed with 65cf77d218cf8b6aee2dbe252f5512cccc0311c8 by @spavloff (cc @rjmccall).

[spavloff]

The reproducer provided here is not related to 65cf77d, because it causes compiler crash with that commit reverted.

The problem reported here is fixed by the patch https://reviews.llvm.org/D154359.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[pkubaj]

Would it be possible to merge it to 16?

[pkubaj]

@DimitryAndric Also, a backport to FreeBSD would be well appreciated :)

[DimitryAndric]

I think clang 17 is going to be branched soon, so 16 is a bit "old" already... In any case I have merged it into FreeBSD in freebsd/freebsd-src@1cd9788408aa9ea4fd0fbc3e06bd9a4eaf8d8d22.

[hubert-reinterpretcast]

The bad codegen reported in https://github.com/llvm/llvm-project/issues/63063#issuecomment-1572726311 still occurs with this fix.

[hubert-reinterpretcast]

@spavloff, I have opened a regression defect against the fix: https://github.com/llvm/llvm-project/issues/64605 @DimitryAndric, fyi, in case you want to revert this out of FreeBSD.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[spavloff]

As I commented in https://github.com/llvm/llvm-project/issues/64605, this problem is not caused by https://github.com/llvm/llvm-project/commit/fde5924dcc69fe814085482df259b8cfee236f2c, and revert of this commit does not fix the issue.

[hubert-reinterpretcast]

I opened https://github.com/llvm/llvm-project/issues/64823 for a different case that hits the same assertion.