RFC for improvement: (1) add support for GCC compilation. (2) This may be a red herring, but we may want to eliminate lines from the end, NOT fromt he begining.

[zephyrus00jp]

I am a complete newbie to c-vise, but I used c-vise more or less successfully against a very large mozilla source code.
The preprocessed file at one point was like 160K lines of code.
It took me four days on 7 cores to reduce it.
See the problem originally reported at mozilla bugzilla,
https://bugzilla.mozilla.org/show_bug.cgi?id=1825516
and at GCC bugzilla for the reduced file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109480

I said "more or less successfully" because I could not get the semantic analyzer of c-vise to work initially until the code was reduced to approximately 65K lines of code.
I am NOT sure if this is due to the sheer size of the code, OR if c-vise does not invoke clang program by specifying g++ extension.
The preprocessed source code was originally meant for GNU G++ compiler. So it contained a few builtin functions specific to g++.
That is, I wonder if adding "g++98, g++11, g++14, g++17" and maybe "g++20" to the set of options when cvise uses one at a time to invoke clang analysis tool would help. Maybe with these added options, my reduction could use semantic information at an earlier phase.
The error I noticed returned by cvise_delta while using cvise was (-11). This was under Debian GNU/linux.
It seems to be EAGAIN. Can that mean the memory issue or something? I have enough swap space, though.

(2) Start Elimination of lines during LinesPass::0 from the END of the file (or for that matter even for ClangBinarySearchPass::replace-function-def-with-decl, ClangBinarySearchPass::remove-unused-function, ClangPass::remove-unused-function, etc.)

Since the reduction of 160K lines of code when the semanatic analysis does not work was so slow,
I added --print-diff to see what kind of progress, if any, was being made.

I noticed that LinesPass:0 eventually degrades into eliminating a few lines at a time consecutively but it starts from the beginning of the file.
Well, that is natural. We count form 0, 1, ....
However, for eliminating a small number of consecutive lines from a C source file, and to a lesser dgree from a C++ source file,
I think start eliminating the lines at the end is more productive. That is my gut feeling.
The reason is quite simple.
If you eliminate lines from the beginning you are likely to remove typedefs, variable declarations and such that are quite likely to cause compilation errors later in the file.
On the other hand, starting the elimination from the end of the file is likely to cause less compilation errors, and is likely to help us remove the declarations that are no longer referenced by the later eliminated code.
That is the guess.

It may not matter when the semantic analysis works like a charm, but for my 160K lines of code, not having the semantic help and
looking at the repetition of elimination from the start of the file caused me to think very hard how I could make the process even an iota faster, and I concluded the elimination from the end of the file would be a win.

These two points are just a thought after my struggle with 160K lines of code to reduce it.

Thank you for sharing the great software with the wide developer community.

EDIT: I wrote 65 lines of code, which should read 65K lines of code. Minor fixes for expressions, etc.

[marxin]

Hey! First, thank you very much for your issue and the GCC bug report.

It took me four days on 7 cores to reduce it. See the problem originally reported at mozilla bugzilla, https://bugzilla.mozilla.org/show_bug.cgi?id=1825516 and at GCC bugzilla for the reduced file. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109480

Well, taking 4 days is too much on a reasonably fast machine, my experience is that it should finish within a couple of hours. Anyway, please attach here the original test-case and the interestingness test, please.

I said "more or less successfully" because I could not get the semantic analyzer of c-vise to work initially until the code was reduced to approximately 65K lines of code. I am NOT sure if this is due to the sheer size of the code, OR if c-vise does not invoke clang program by specifying g++ extension. The preprocessed source code was originally meant for GNU G++ compiler. So it contained a few builtin functions specific to g++. That is, I wonder if adding "g++98, g++11, g++14, g++17" and maybe "g++20" to the set of options when cvise uses one at a time to invoke clang analysis tool would help. Maybe with these added options, my reduction could use semantic information at an earlier phase. The error I noticed returned by cvise_delta while using cvise was (-11). This was under Debian GNU/linux. It seems to be EAGAIN. Can that mean the memory issue or something? I have enough swap space, though.

Speaking about the fastest reduction (at the beginning): ClangBinarySearchPass::replace-function-def-with-decl and ClangBinarySearchPass::remove-unused-function should make the hardest work. Note these passes use clang_delta and can detect the most beneficial C++ standard. It works reasonably well even if you have a compilation error, that's fine. It used to happen that clang_delta crashed for more complex test-cases, but it improved with LLVM 16 release rapidly. Plus, recently, I improved the reduction algorithm to jump between these 2 passes after N successful transformations (8b25bd7).

(2) Start Elimination of lines during LinesPass::0 from the END of the file (or for that matter even for ClangBinarySearchPass::replace-function-def-with-decl, ClangBinarySearchPass::remove-unused-function, ClangPass::remove-unused-function, etc.)

This is a nice hint, but it's not typically necessary as the binary passes begin with bigger optimization chunks that is later on reduced to a smaller one.

[zephyrus00jp]

Hey! First, thank you very much for your issue and the GCC bug report.

You are very welcome, and thank you for sharing and improving this useful code.
I am impressed with what it can.

It took me four days on 7 cores to reduce it. See the problem originally reported at mozilla bugzilla, https://bugzilla.mozilla.org/show_bug.cgi?id=1825516 and at GCC bugzilla for the reduced file. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109480

Well, taking 4 days is too much on a reasonably fast machine, my experience is that it should finish within a couple of hours. Anyway, please attach here the original test-case and the interestingness test, please.

Yes, four days was a bit tough on a PC that is shared between work/hobby.

Original preprocessed file:
The original preprocessed code (for GCC) is available at https://gist.github.com/nmlapre/4f979a17f28fe97c04cfe1db05ce01b1
It was prepared by the original bug reporter who experienced the G++ issue before I did.
( https://bugzilla.mozilla.org/show_bug.cgi?id=1825516)

I copied the file to a local file named "target.cpp".

My interestingness test script:
reduce-test.zip

Using this I tried cvise with my check shell script like this.

cvise --debug --print-diff THE-CURRENT-DIRECTORY/reduce-test.sh target.cpp

If you can figure the obvious issues from my interestingness test, I would love to hear them.

Actually, for the initial three days, I interrupt the cvise session and occasionally tinkered with invoking some pass by "--start-with-pass" option several times because of the slowness.

I said "more or less successfully" because I could not get the semantic analyzer of c-vise to work initially until the code was reduced to approximately 65K lines of code. I am NOT sure if this is due to the sheer size of the code, OR if c-vise does not invoke clang program by specifying g++ extension. The preprocessed source code was originally meant for GNU G++ compiler. So it contained a few builtin functions specific to g++. That is, I wonder if adding "g++98, g++11, g++14, g++17" and maybe "g++20" to the set of options when cvise uses one at a time to invoke clang analysis tool would help. Maybe with these added options, my reduction could use semantic information at an earlier phase. The error I noticed returned by cvise_delta while using cvise was (-11). This was under Debian GNU/linux. It seems to be EAGAIN. Can that mean the memory issue or something? I have enough swap space, though.

Speaking about the fastest reduction (at the beginning): ClangBinarySearchPass::replace-function-def-with-decl and ClangBinarySearchPass::remove-unused-function should make the hardest work. Note these passes use clang_delta and can detect the most beneficial C++ standard. It works reasonably well even if you have a compilation error, that's fine. It used to happen that clang_delta crashed for more complex test-cases, but it improved with LLVM 16 release rapidly. Plus, recently, I improved the reduction algorithm to jump between these 2 passes after N successful transformations (8b25bd7).

Maybe then I will benefit from the later c-vise that uses llvm-16.
Debian GNU/Linux does not seem to have llvm-16 as of now as part of its standard packages.

(2) Start Elimination of lines during LinesPass::0 from the END of the file (or for that matter even for ClangBinarySearchPass::replace-function-def-with-decl, ClangBinarySearchPass::remove-unused-function, ClangPass::remove-unused-function, etc.)

This is a nice hint, but it's not typically necessary as the binary passes begin with bigger optimization chunks that is later on reduced to a smaller one.

Right, for binary passes with linked list of information, it may be not that important.

However, for LinesPass::0 and friends without any guidance from the semantic information (aside from the compilation status from interestingness test), the elimination from the end of the file is a poor man's educated guess of what would be more likely to be removed without an issue and later will benefit us so that we can remove the earlier declarations which are no longer referenced by the now eliminated later lines.
Looking at the elimination of two lines of code from a file of 100K lines of more makes me such a slight improvement may be worth for LinesPass::0 and friends.

Thank you again for sharing this great package.

[marxin]

If you can figure the obvious issues from my interestingness test, I would love to hear them.

Well, you can easily run it with:

cvise -c 'timeout 10 g++-13 RemoteAccessibleBase.ii  -c -w -fsyntax-only -fno-checking -fmax-errors=10 2>&1 | grep "static void nsFrameList::operator delete.*is private within this context"' RemoteAccessibleBase.ii
00:00:00 INFO Using temporary interestingness test: /tmp/tmp_8pxm65_.sh
00:00:05 INFO ===< 9816 >===
00:00:05 INFO running 16 interestingness tests in parallel
00:00:05 INFO INITIAL PASSES
00:00:05 INFO ===< IncludesPass >===
00:00:05 INFO ===< UnIfDefPass >===
00:00:05 INFO ===< CommentsPass >===
00:00:06 INFO ===< IfPass >===
00:00:06 INFO ===< LineMarkersPass >===
00:00:06 INFO ===< BlankPass >===
00:00:12 INFO (0.1%, 13267021 bytes, 305221 lines)
00:00:17 INFO (0.4%, 13227160 bytes, 303971 lines)
00:00:17 INFO ===< ClangBinarySearchPass::replace-function-def-with-decl (30 transforms) >===
00:00:36 INFO using C++ standard: c++2b with 33820 transformation opportunities
00:00:51 INFO (5.9%, 12495723 bytes, 291944 lines)
00:01:01 INFO (5.9%, 12494691 bytes, 291910 lines)
00:01:11 INFO (10.5%, 11885054 bytes, 288357 lines)
00:01:21 INFO (10.5%, 11884169 bytes, 288344 lines)
00:01:31 INFO (11.5%, 11755328 bytes, 284683 lines)
00:01:41 INFO (12.0%, 11681647 bytes, 282402 lines)
00:01:50 INFO (12.0%, 11680465 bytes, 282381 lines)
00:02:00 INFO (12.7%, 11588350 bytes, 279681 lines)
00:02:10 INFO (13.7%, 11451711 bytes, 275983 lines)
00:02:19 INFO (14.0%, 11417096 bytes, 275492 lines)
00:02:29 INFO (15.0%, 11280815 bytes, 274483 lines)
00:02:38 INFO (15.4%, 11231223 bytes, 273446 lines)
00:02:48 INFO (15.7%, 11187037 bytes, 272810 lines)
00:03:03 INFO (16.3%, 11115640 bytes, 270931 lines)
00:03:12 INFO (16.6%, 11077475 bytes, 269834 lines)
00:03:21 INFO (16.8%, 11051916 bytes, 269194 lines)
00:03:29 INFO (16.9%, 11028557 bytes, 268680 lines)
00:03:38 INFO (17.3%, 10979824 bytes, 267165 lines)
00:03:47 INFO (17.5%, 10955726 bytes, 266360 lines)
00:03:56 INFO (17.6%, 10934576 bytes, 265849 lines)
00:04:05 INFO (18.1%, 10877181 bytes, 264238 lines)
00:04:14 INFO (18.4%, 10832602 bytes, 262925 lines)
00:04:22 INFO (18.6%, 10812213 bytes, 262329 lines)
00:04:31 INFO (18.7%, 10795192 bytes, 261810 lines)
00:04:40 INFO (18.9%, 10773302 bytes, 261147 lines)
00:04:48 INFO (19.6%, 10674463 bytes, 261051 lines)
00:04:57 INFO (20.1%, 10612394 bytes, 259795 lines)
00:05:05 INFO (20.3%, 10580629 bytes, 258819 lines)
00:05:14 INFO (20.5%, 10560223 bytes, 258259 lines)
00:05:22 INFO (20.8%, 10514013 bytes, 257011 lines)
00:05:22 INFO skipping after 30 successful transformations
00:05:22 INFO ===< ClangBinarySearchPass::remove-unused-function (30 transforms) >===
00:05:37 INFO using C++ standard: c++11 with 52583 transformation opportunities
00:05:48 INFO (20.8%, 10513997 bytes, 257010 lines)
00:05:56 INFO (20.8%, 10513945 bytes, 257008 lines)
00:06:05 INFO (24.4%, 10043380 bytes, 249506 lines)
00:06:13 INFO (24.4%, 10043253 bytes, 249502 lines)
00:06:22 INFO (24.4%, 10042807 bytes, 249491 lines)
00:06:31 INFO (26.1%, 9805234 bytes, 243462 lines)
00:06:44 INFO (27.1%, 9680230 bytes, 239683 lines)
00:06:52 INFO (27.1%, 9680201 bytes, 239682 lines)
00:07:01 INFO (27.1%, 9678398 bytes, 239621 lines)
00:07:09 INFO (27.5%, 9621115 bytes, 239604 lines)
00:07:22 INFO (28.2%, 9528852 bytes, 235943 lines)
00:07:31 INFO (29.1%, 9414673 bytes, 231665 lines)
00:07:39 INFO (29.2%, 9405878 bytes, 231389 lines)
00:07:47 INFO (29.2%, 9400548 bytes, 231163 lines)
00:07:55 INFO (29.2%, 9400490 bytes, 231161 lines)
00:08:03 INFO (29.2%, 9400360 bytes, 231157 lines)
00:08:11 INFO (29.4%, 9367962 bytes, 230243 lines)
00:08:23 INFO (29.7%, 9337189 bytes, 230116 lines)
00:08:31 INFO (29.8%, 9314087 bytes, 229666 lines)
00:08:39 INFO (30.0%, 9292996 bytes, 229240 lines)
00:08:47 INFO (30.5%, 9233119 bytes, 228722 lines)
00:08:55 INFO (30.7%, 9198317 bytes, 228127 lines)
00:09:03 INFO (31.0%, 9157891 bytes, 227284 lines)
00:09:10 INFO (32.4%, 8971671 bytes, 227019 lines)
00:09:18 INFO (32.8%, 8925524 bytes, 225392 lines)
00:09:26 INFO (33.1%, 8882654 bytes, 223799 lines)

I would recommend using a reasonable timeout as the compiler might be stuck sometimes. Plus, as you can see, ClangBinarySearchPass works fine and makes the biggest portion of reduction, in my case 1/3 of the test-case is reduced in first 10 minutes.

[marxin]

Debian GNU/Linux does not seem to have llvm-16 as of now as part of its standard packages.

Then, I would recommend switching to openSUSE Tumbleweed, where I push to the official package the latest cvise master branch.

[marxin]

However, for LinesPass::0 and friends without any guidance from the semantic information (aside from the compilation status from interestingness test), the elimination from the end of the file is a poor man's educated guess of what would be more likely to be removed without an issue and later will benefit us so that we can remove the earlier declarations which are no longer referenced by the now eliminated later lines.

It might help, but as already explained, the pass first starts with the biggest chunks (entire file, first half, second half, first quarter and so forth) and that works very quickly for a reasonable number of lines of code.

[zephyrus00jp]

If you can figure the obvious issues from my interestingness test, I would love to hear them.

Well, you can easily run it with:

cvise -c 'timeout 10 g++-13 RemoteAccessibleBase.ii  -c -w -fsyntax-only -fno-checking -fmax-errors=10 2>&1 | grep "static void nsFrameList::operator delete.*is private within this context"' RemoteAccessibleBase.ii
00:00:00 INFO Using temporary interestingness test: /tmp/tmp_8pxm65_.sh
00:00:05 INFO ===< 9816 >===
00:00:05 INFO running 16 interestingness tests in parallel
00:00:05 INFO INITIAL PASSES
00:00:05 INFO ===< IncludesPass >===
00:00:05 INFO ===< UnIfDefPass >===
00:00:05 INFO ===< CommentsPass >===
00:00:06 INFO ===< IfPass >===
00:00:06 INFO ===< LineMarkersPass >===
00:00:06 INFO ===< BlankPass >===
00:00:12 INFO (0.1%, 13267021 bytes, 305221 lines)
00:00:17 INFO (0.4%, 13227160 bytes, 303971 lines)
00:00:17 INFO ===< ClangBinarySearchPass::replace-function-def-with-decl (30 transforms) >===
00:00:36 INFO using C++ standard: c++2b with 33820 transformation opportunities
00:00:51 INFO (5.9%, 12495723 bytes, 291944 lines)
00:01:01 INFO (5.9%, 12494691 bytes, 291910 lines)
00:01:11 INFO (10.5%, 11885054 bytes, 288357 lines)
00:01:21 INFO (10.5%, 11884169 bytes, 288344 lines)
00:01:31 INFO (11.5%, 11755328 bytes, 284683 lines)
00:01:41 INFO (12.0%, 11681647 bytes, 282402 lines)
00:01:50 INFO (12.0%, 11680465 bytes, 282381 lines)
00:02:00 INFO (12.7%, 11588350 bytes, 279681 lines)
00:02:10 INFO (13.7%, 11451711 bytes, 275983 lines)
00:02:19 INFO (14.0%, 11417096 bytes, 275492 lines)
00:02:29 INFO (15.0%, 11280815 bytes, 274483 lines)
00:02:38 INFO (15.4%, 11231223 bytes, 273446 lines)
00:02:48 INFO (15.7%, 11187037 bytes, 272810 lines)
00:03:03 INFO (16.3%, 11115640 bytes, 270931 lines)
00:03:12 INFO (16.6%, 11077475 bytes, 269834 lines)
00:03:21 INFO (16.8%, 11051916 bytes, 269194 lines)
00:03:29 INFO (16.9%, 11028557 bytes, 268680 lines)
00:03:38 INFO (17.3%, 10979824 bytes, 267165 lines)
00:03:47 INFO (17.5%, 10955726 bytes, 266360 lines)
00:03:56 INFO (17.6%, 10934576 bytes, 265849 lines)
00:04:05 INFO (18.1%, 10877181 bytes, 264238 lines)
00:04:14 INFO (18.4%, 10832602 bytes, 262925 lines)
00:04:22 INFO (18.6%, 10812213 bytes, 262329 lines)
00:04:31 INFO (18.7%, 10795192 bytes, 261810 lines)
00:04:40 INFO (18.9%, 10773302 bytes, 261147 lines)
00:04:48 INFO (19.6%, 10674463 bytes, 261051 lines)
00:04:57 INFO (20.1%, 10612394 bytes, 259795 lines)
00:05:05 INFO (20.3%, 10580629 bytes, 258819 lines)
00:05:14 INFO (20.5%, 10560223 bytes, 258259 lines)
00:05:22 INFO (20.8%, 10514013 bytes, 257011 lines)
00:05:22 INFO skipping after 30 successful transformations
00:05:22 INFO ===< ClangBinarySearchPass::remove-unused-function (30 transforms) >===
00:05:37 INFO using C++ standard: c++11 with 52583 transformation opportunities
00:05:48 INFO (20.8%, 10513997 bytes, 257010 lines)
00:05:56 INFO (20.8%, 10513945 bytes, 257008 lines)
00:06:05 INFO (24.4%, 10043380 bytes, 249506 lines)
00:06:13 INFO (24.4%, 10043253 bytes, 249502 lines)
00:06:22 INFO (24.4%, 10042807 bytes, 249491 lines)
00:06:31 INFO (26.1%, 9805234 bytes, 243462 lines)
00:06:44 INFO (27.1%, 9680230 bytes, 239683 lines)
00:06:52 INFO (27.1%, 9680201 bytes, 239682 lines)
00:07:01 INFO (27.1%, 9678398 bytes, 239621 lines)
00:07:09 INFO (27.5%, 9621115 bytes, 239604 lines)
00:07:22 INFO (28.2%, 9528852 bytes, 235943 lines)
00:07:31 INFO (29.1%, 9414673 bytes, 231665 lines)
00:07:39 INFO (29.2%, 9405878 bytes, 231389 lines)
00:07:47 INFO (29.2%, 9400548 bytes, 231163 lines)
00:07:55 INFO (29.2%, 9400490 bytes, 231161 lines)
00:08:03 INFO (29.2%, 9400360 bytes, 231157 lines)
00:08:11 INFO (29.4%, 9367962 bytes, 230243 lines)
00:08:23 INFO (29.7%, 9337189 bytes, 230116 lines)
00:08:31 INFO (29.8%, 9314087 bytes, 229666 lines)
00:08:39 INFO (30.0%, 9292996 bytes, 229240 lines)
00:08:47 INFO (30.5%, 9233119 bytes, 228722 lines)
00:08:55 INFO (30.7%, 9198317 bytes, 228127 lines)
00:09:03 INFO (31.0%, 9157891 bytes, 227284 lines)
00:09:10 INFO (32.4%, 8971671 bytes, 227019 lines)
00:09:18 INFO (32.8%, 8925524 bytes, 225392 lines)
00:09:26 INFO (33.1%, 8882654 bytes, 223799 lines)

I would recommend using a reasonable timeout as the compiler might be stuck sometimes. Plus, as you can see, ClangBinarySearchPass works fine and makes the biggest portion of reduction, in my case 1/3 of the test-case is reduced in first 10 minutes.

I think I better wait for llvm-16 and g++-13 to hit Debian repositories because as of now if I invoke g++-12 (and llvm-15 instaleld), I get the following error and that is why I was talking about the possible speedup due to the backward elimination direction.

... prompt ... $ cvise -c 'timeout 10 g++-12 target.cpp  -c -w -fsyntax-only -fno-checking -fmax-errors=10 2>&1 | grep "static void nsFrameList::operator delete.*is private within this context"' target.cpp
00:00:00 INFO Using temporary interestingness test: /mnt/mytmpfs/tmp4m_0j4xk.sh
00:00:10 INFO ===< 3358734 >===
00:00:10 INFO running 7 interestingness tests in parallel
00:00:10 INFO INITIAL PASSES
00:00:10 INFO ===< IncludesPass >===
00:00:10 INFO ===< UnIfDefPass >===
00:00:10 INFO ===< CommentsPass >===
00:00:11 INFO ===< IfPass >===
00:00:11 INFO ===< LineMarkersPass >===
00:00:11 INFO ===< BlankPass >===
00:00:12 INFO ===< ClangBinarySearchPass::replace-function-def-with-decl >===
00:00:14 WARNING clang_delta --query-instances failed with exit code -11: 
00:00:15 WARNING clang_delta --query-instances failed with exit code -11: 
00:00:18 WARNING clang_delta --query-instances failed with exit code -11: 
00:00:20 WARNING clang_delta --query-instances failed with exit code -11: 
00:00:22 WARNING clang_delta --query-instances failed with exit code -11: 
00:00:25 WARNING clang_delta --query-instances failed with exit code -11: 
00:00:25 INFO using C++ standard: c++2b with 0 transformation opportunities
00:00:27 WARNING clang_delta --query-instances failed with exit code -11: 
00:00:27 INFO ===< ClangBinarySearchPass::remove-unused-function >===
00:00:29 WARNING clang_delta --query-instances failed with exit code -11: 
00:00:29 INFO Exiting now ...
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ apt-cache search g++-13

The error is inside libclang.a.
$I have recompiled/rebuilt c-vise locally in the hope of catching the root cause of my failure.
But the failure is in the system-supplied libclang-cpp.so.

.

.. prompt ... $ gdb /usr/local/libexec/cvise/clang_delta 
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/libexec/cvise/clang_delta...
(No debugging symbols found in /usr/local/libexec/cvise/clang_delta)
(gdb) run --query-instances=replace-function-def-with-decl --std=c++98 /home/ishikawa/Dropbox/TB-DIR/WALL-PATCH-DIR/target.cpp
Starting program: /usr/local/libexec/cvise/clang_delta --query-instances=replace-function-def-with-decl --std=c++98 /home/ishikawa/Dropbox/TB-DIR/WALL-PATCH-DIR/target.cpp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5cd71b4 in clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&, bool) ()
   from /usr/lib/llvm-15/lib/libclang-cpp.so.15
(gdb) where
#0  0x00007ffff5cd71b4 in clang::Sema::FindInstantiatedDecl(clang::SourceLocation, clang::NamedDecl*, clang::MultiLevelTemplateArgumentList const&, bool) ()
   from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#1  0x00007ffff5ca9f5e in ?? () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#2  0x00007ffff5cbb899 in ?? () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#3  0x00007ffff5cb3830 in ?? () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#4  0x00007ffff5cae375 in ?? () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#5  0x00007ffff5caa89a in ?? () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#6  0x00007ffff5ca7ca0 in ?? () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#7  0x00007ffff5cca9a5 in ?? () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#8  0x00007ffff5cbe656 in ?? () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#9  0x00007ffff5ca686c in clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#10 0x00007ffff5ce78b0 in clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool, bool) ()
   from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#11 0x00007ffff5ce9dad in clang::Sema::PerformPendingInstantiations(bool) ()
   from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#12 0x00007ffff55e9c3b in clang::Sema::ActOnEndOfTranslationUnitFragment(clang::Sema::TUFragmentKind) () from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#13 0x00007ffff55ea292 in clang::Sema::ActOnEndOfTranslationUnit() ()
   from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#14 0x00007ffff4f7f20f in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) ()
   from /usr/lib/llvm-15/lib/libclang-cpp.so.15
#15 0x00007ffff4ebd9ae in clang::ParseAST(clang::Sema&, bool, bool) ()
   from /usr/lib/llvm-15/lib/libclang-cpp.so.15
--Type <RET> for more, q to quit, c to continue without paging--

It is possible that I may not have enough RAM to create the large AST for the input file. But I doubt it.
I assign 16GB to this linux guest inside VirtualBox.

Thank you again for your detailed comments.

[marxin]

But the failure is in the system-supplied libclang-cpp.so.

Yep, that's exactly the error I faced a multiple-time in the past with LLVM 15 and older. 16G is plenty of RAM, so for now, I would recommend using Podman with openSUSE container:
https://github.com/marxin/cvise/blob/master/INSTALL.md#using-docker-or-podman

[zephyrus00jp]

But the failure is in the system-supplied libclang-cpp.so.

Yep, that's exactly the error I faced a multiple-time in the past with LLVM 15 and older. 16G is plenty of RAM, so for now, I would recommend using Podman with openSUSE container: https://github.com/marxin/cvise/blob/master/INSTALL.md#using-docker-or-podman

I see. Thank you.