Trying to build devel/onetbb from the shar file included in PR 252648, clang fails. See details already reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252648#c13 The requested files are also attached to the same PR: - https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221792 - https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221793
Thans for the report. I'll have a look at that!
Hello Thierry, I could not reproduce the problem on 12.2-RELEASE using clang11 explicitly. I.e. with the following patch to Makefile: +# XXX Test +BUILD_DEPENDS+= ${LOCALBASE}/bin/clang11:devel/llvm11 +CPP= ${LOCALBASE}/bin/clang-cpp11 +CC= ${LOCALBASE}/bin/clang11 +CXX= ${LOCALBASE}/bin/clang++11 See: http://box.martymac.org/FreeBSD-Packages/data/FBSD122amd64-tbb-migr/2021-01-21_18h55m30s/logs/onetbb-2021.1.1.log Could that be related to -CURRENT itself ? Any hint ?
I'll set up a 13-STABLE and see if I can reproduce the problem, stay tuned.
I could reproduce the problem on 14-CURRENT with llvm11. Weird, I could not reproduce it on 12.2 with llvm11 from ports. Here are the logs I get : # /usr/bin/c++ -v -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/.. -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -Wall -Wextra -Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wno-parentheses -pthread -std=c++11 -MD -MT test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -MF test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o.d -o test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -c /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/conformance/conformance_blocked_rangeNd.cpp FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin (in-process) "/usr/bin/c++" -cc1 -triple x86_64-unknown-freebsd14.0 -emit-obj -disable-free -main-file-name conformance_blocked_rangeNd.cpp -mrelocation-model static -mframe-pointer=all -relaxed-aliasing -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /usr/lib/clang/11.0.1 -dependency-file test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o.d -MT test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -sys-header-deps -I /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/.. -I /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test -I /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include -internal-isystem /usr/include/c++/v1 -O2 -Wall -Wextra -Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wno-parentheses -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /usr/ports/devel/onetbb/work/.build -ferror-limit 19 -pthread -stack-protector 2 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -o test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -x c++ /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/conformance/conformance_blocked_rangeNd.cpp clang -cc1 version 11.0.1 based upon LLVM 11.0.1 default target x86_64-unknown-freebsd14.0 #include "..." search starts here: #include <...> search starts here: /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/.. /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include /usr/include/c++/v1 /usr/lib/clang/11.0.1/include /usr/include End of search list. Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Casting.h, line 269. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/bin/c++ -v -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/.. -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -Wall -Wextra -Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wno-parentheses -pthread -std=c++11 -MD -MT test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -MF test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o.d -o test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -c /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/conformance/conformance_blocked_rangeNd.cpp 1. /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:69:62: current parser token ':' 2. /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:34:1: parsing namespace 'tbb' 3. /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:35:1: parsing namespace 'tbb::detail' 4. /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:36:1: parsing namespace 'tbb::detail::d1' 5. /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:55:1: parsing struct/union/class body 'tbb::detail::d1::blocked_rangeNd_impl<Value, N, detail::index_sequence<Is...>>' #0 0x00000000041d56fe PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13 #1 0x00000000041d3955 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18 #2 0x0000000004172e3e HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:77:5 #3 0x0000000004172fc1 CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:0:51 #4 0x0000000805692e00 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/conformance_blocked_rangeNd-d553c8.cpp c++: note: diagnostic msg: /tmp/conformance_blocked_rangeNd-d553c8.sh c++: note: diagnostic msg: ********************
Created attachment 221913 [details] Diagnostic .cpp file (gzipped)
Created attachment 221914 [details] Diagnostic .sh file (gzipped)
Hello, Can someone from LLVM team have a look at that failure ? Thanks in advance, Ganael.
Not sure if it is a bug of LLVM itself, but it seems so: "c++: error: clang frontend command failed due to signal" Any idea?
On stable branches, and for LLVM ports, assertions are disabled so it will either continue happily (and maybe eat your data :), or it will encounter some other error like a segfault. On -CURRENT (aka 'head' or 'main') we do have LLVM assertions enabled, so you will more easily run into them. That said, I will have look at the reproduction files from bug 252892. Btw why are there two bugs for the same issue? Can one of them be closed as a dupe?
Hello Dimitry, > On stable branches, and for LLVM ports, assertions are disabled > [...] So that problem would be related to TBB code only, thanks for those precisions. > That said, I will have look at the reproduction files from bug 252892. Thanks ! > Btw why are there two bugs for the same issue? Can one of them be closed as a > dupe? PR #252648 is the master one for handling oneTBB switch. PR #252892 has then been opened for that specific build issue ; that second PR could be closed, but I think it's not so bad to have another one dedicated to that issue, to avoid polluting the master bug report. Best regards, Ganael.
>> On stable branches, and for LLVM ports, assertions are disabled >> [...] > > So that problem would be related to TBB code only, thanks for those precisions. Let me correct myself (sorry, I just got it :p): of course you mean assertions on *llvm side* so we are hitting a *llvm assertion*, triggered by oneTbb code...
(In reply to Ganael LAPLANCHE from comment #11) Yes indeed, exactly that. :) I already found an upstream fix for this particular assertion, and am testing it now. I will probably commit it later today, and set an MFC timeout of 3 days.
Good news, thanks :)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e63539f3059728ff58328ac0ecb2a7bf4e2f08e8 commit e63539f3059728ff58328ac0ecb2a7bf4e2f08e8 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2021-01-26 13:07:47 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2021-01-26 16:51:25 +0000 Fix clang assertion when compiling the devel/onetbb port Merge commit 740a164de from llvm git (by Richard Smith): PR46377: Fix dependence calculation for function types and typedef types. We previously did not treat a function type as dependent if it had a parameter pack with a non-dependent type -- such a function type depends on the arity of the pack so is dependent even though none of the parameter types is dependent. In order to properly handle this, we now treat pack expansion types as always being dependent types (depending on at least the pack arity), and always canonically being pack expansion types, even in the unusual case when the pattern is not a dependent type. This does mean that we can have canonical types that are pack expansions that contain no unexpanded packs, which is unfortunate but not inaccurate. We also previously did not treat a typedef type as instantiation-dependent if its canonical type was not instantiation-dependent. That's wrong because instantiation-dependence is a property of the type sugar, not of the type; an instantiation-dependent type can have a non-instantiation-dependent canonical type. Merge commit 9cf98d26e from llvm git (by Richard Smith): PR46637: Fix handling of placeholder types in trailing-return-types. Only permit a placeholder type in a trailing-return-type if it would also have been permitted in the decl-specifier sequence of a corresponding declaration with no trailing-return-type. The standard doesn't actually say this, but this is the only thing that makes sense. Also fix handling of an 'auto' in a trailing-return-type in a parameter of a generic lambda. We used to crash if we saw such a thing. Merge commit 234f51a65 from llvm git (by Richard Smith): Don't crash if we deserialize a pack expansion type whose pattern contains no packs. Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb. PR: 252892 Reported by: thierry MFC after: 3 days .../clang/include/clang/AST/ASTContext.h | 10 +- .../llvm-project/clang/include/clang/AST/Type.h | 13 +-- .../clang/include/clang/AST/TypeProperties.td | 3 +- .../clang/include/clang/Basic/TypeNodes.td | 2 +- .../clang/include/clang/Sema/DeclSpec.h | 9 ++ .../llvm-project/clang/include/clang/Sema/Sema.h | 2 + contrib/llvm-project/clang/lib/AST/ASTContext.cpp | 34 +++--- contrib/llvm-project/clang/lib/AST/ASTImporter.cpp | 3 +- contrib/llvm-project/clang/lib/AST/Type.cpp | 9 +- .../llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp | 1 - .../clang/lib/CodeGen/CodeGenFunction.cpp | 1 - contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp | 1 - contrib/llvm-project/clang/lib/Sema/SemaLambda.cpp | 3 +- .../clang/lib/Sema/SemaTemplateDeduction.cpp | 7 ++ .../clang/lib/Sema/SemaTemplateVariadic.cpp | 3 +- contrib/llvm-project/clang/lib/Sema/SemaType.cpp | 119 +++++++++++---------- 16 files changed, 121 insertions(+), 99 deletions(-)
Thanks a lot Dimitry !
Thanks Dimitry, this was quick! Could please also bump newvers, so that the ports can check $OSVERSION ?
(In reply to Thierry Thomas from comment #16) Sure, though I'll probably get some grumbling from people that have to rebuild world yet again. :-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2cf84258922f306a3f84866685d2f5346f67db58 commit 2cf84258922f306a3f84866685d2f5346f67db58 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2021-01-26 18:43:55 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2021-01-26 18:43:55 +0000 Bump __FreeBSD_version after e63539f3059728ff58328ac0ecb2a7bf4e2f08e8 This is to allow ports to detect the clang fix applied in the above commit. PR: 252892 MFC after: 3 days sys/sys/param.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=010196adcfaf2bb610725394d40691874b4ff2af commit 010196adcfaf2bb610725394d40691874b4ff2af Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2021-01-26 13:07:47 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2021-01-29 23:25:53 +0000 Fix clang assertion when compiling the devel/onetbb port Merge commit 740a164de from llvm git (by Richard Smith): PR46377: Fix dependence calculation for function types and typedef types. We previously did not treat a function type as dependent if it had a parameter pack with a non-dependent type -- such a function type depends on the arity of the pack so is dependent even though none of the parameter types is dependent. In order to properly handle this, we now treat pack expansion types as always being dependent types (depending on at least the pack arity), and always canonically being pack expansion types, even in the unusual case when the pattern is not a dependent type. This does mean that we can have canonical types that are pack expansions that contain no unexpanded packs, which is unfortunate but not inaccurate. We also previously did not treat a typedef type as instantiation-dependent if its canonical type was not instantiation-dependent. That's wrong because instantiation-dependence is a property of the type sugar, not of the type; an instantiation-dependent type can have a non-instantiation-dependent canonical type. Merge commit 9cf98d26e from llvm git (by Richard Smith): PR46637: Fix handling of placeholder types in trailing-return-types. Only permit a placeholder type in a trailing-return-type if it would also have been permitted in the decl-specifier sequence of a corresponding declaration with no trailing-return-type. The standard doesn't actually say this, but this is the only thing that makes sense. Also fix handling of an 'auto' in a trailing-return-type in a parameter of a generic lambda. We used to crash if we saw such a thing. Merge commit 234f51a65 from llvm git (by Richard Smith): Don't crash if we deserialize a pack expansion type whose pattern contains no packs. Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb. PR: 252892 Reported by: thierry (cherry picked from commit e63539f3059728ff58328ac0ecb2a7bf4e2f08e8) Bump __FreeBSD_version after e63539f3059728ff58328ac0ecb2a7bf4e2f08e8 This is to allow ports to detect the clang fix applied in the above commit. PR: 252892 (cherry picked from commit 2cf84258922f306a3f84866685d2f5346f67db58) .../clang/include/clang/AST/ASTContext.h | 10 +- .../llvm-project/clang/include/clang/AST/Type.h | 13 +-- .../clang/include/clang/AST/TypeProperties.td | 3 +- .../clang/include/clang/Basic/TypeNodes.td | 2 +- .../clang/include/clang/Sema/DeclSpec.h | 9 ++ .../llvm-project/clang/include/clang/Sema/Sema.h | 2 + contrib/llvm-project/clang/lib/AST/ASTContext.cpp | 34 +++--- contrib/llvm-project/clang/lib/AST/ASTImporter.cpp | 3 +- contrib/llvm-project/clang/lib/AST/Type.cpp | 9 +- .../llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp | 1 - .../clang/lib/CodeGen/CodeGenFunction.cpp | 1 - contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp | 1 - contrib/llvm-project/clang/lib/Sema/SemaLambda.cpp | 3 +- .../clang/lib/Sema/SemaTemplateDeduction.cpp | 7 ++ .../clang/lib/Sema/SemaTemplateVariadic.cpp | 3 +- contrib/llvm-project/clang/lib/Sema/SemaType.cpp | 119 +++++++++++---------- sys/sys/param.h | 2 +- 17 files changed, 122 insertions(+), 100 deletions(-)
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=aefe88f9e3006d2ed09e36c83342eea00807f38b commit aefe88f9e3006d2ed09e36c83342eea00807f38b Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2021-01-26 13:07:47 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2021-12-25 11:50:56 +0000 Fix clang assertion when compiling the devel/onetbb port Merge commit 740a164de from llvm git (by Richard Smith): PR46377: Fix dependence calculation for function types and typedef types. We previously did not treat a function type as dependent if it had a parameter pack with a non-dependent type -- such a function type depends on the arity of the pack so is dependent even though none of the parameter types is dependent. In order to properly handle this, we now treat pack expansion types as always being dependent types (depending on at least the pack arity), and always canonically being pack expansion types, even in the unusual case when the pattern is not a dependent type. This does mean that we can have canonical types that are pack expansions that contain no unexpanded packs, which is unfortunate but not inaccurate. We also previously did not treat a typedef type as instantiation-dependent if its canonical type was not instantiation-dependent. That's wrong because instantiation-dependence is a property of the type sugar, not of the type; an instantiation-dependent type can have a non-instantiation-dependent canonical type. Merge commit 9cf98d26e from llvm git (by Richard Smith): PR46637: Fix handling of placeholder types in trailing-return-types. Only permit a placeholder type in a trailing-return-type if it would also have been permitted in the decl-specifier sequence of a corresponding declaration with no trailing-return-type. The standard doesn't actually say this, but this is the only thing that makes sense. Also fix handling of an 'auto' in a trailing-return-type in a parameter of a generic lambda. We used to crash if we saw such a thing. Merge commit 234f51a65 from llvm git (by Richard Smith): Don't crash if we deserialize a pack expansion type whose pattern contains no packs. Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb. PR: 252892 Reported by: thierry MFC after: 3 days (cherry picked from commit e63539f3059728ff58328ac0ecb2a7bf4e2f08e8) .../clang/include/clang/AST/ASTContext.h | 10 +- .../llvm-project/clang/include/clang/AST/Type.h | 13 +-- .../clang/include/clang/AST/TypeProperties.td | 3 +- .../clang/include/clang/Basic/TypeNodes.td | 2 +- .../clang/include/clang/Sema/DeclSpec.h | 9 ++ .../llvm-project/clang/include/clang/Sema/Sema.h | 2 + contrib/llvm-project/clang/lib/AST/ASTContext.cpp | 34 +++--- contrib/llvm-project/clang/lib/AST/ASTImporter.cpp | 3 +- contrib/llvm-project/clang/lib/AST/Type.cpp | 9 +- .../llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp | 1 - .../clang/lib/CodeGen/CodeGenFunction.cpp | 1 - contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp | 1 - contrib/llvm-project/clang/lib/Sema/SemaLambda.cpp | 3 +- .../clang/lib/Sema/SemaTemplateDeduction.cpp | 7 ++ .../clang/lib/Sema/SemaTemplateVariadic.cpp | 3 +- contrib/llvm-project/clang/lib/Sema/SemaType.cpp | 119 +++++++++++---------- 16 files changed, 121 insertions(+), 99 deletions(-)