Why does link-time optimization cause a segmentation fault?

Question

I am using Mingw-w64 v7 and g++ 10.2 on Windows built with the arguments --mode=gcc-10.2.0 --arch=x86_64 --buildroot=/c/mingw-builds/BuildRoot --update-sources --exceptions=seh --threads=posix --enable-languages=c++ --jobs=48 --rt-version=v7. I have downloaded and unpacked bzip2 1.0.6 from here: https://sourceforge.net/projects/bzip2/. Now I build boost 1.76.0 like this in a MSys2 console:

./bootstrap.sh --with-libraries=iostreams --prefix=c:/Libraries/boost_1_76_0/InstallRelease
./b2 --layout=system variant=release link=shared address-model=64 threading=multi optimization=speed runtime-link=shared -s BZIP2_SOURCE=C:/Libraries/bzip2-1.0.6 install

I would like use Boost.Iostreams to compress some streams with bzip2. Therefore I create a test file main.cpp with this content:

#include <iostream>
#include <fstream>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/filter/bzip2.hpp>

int main() 
{
    {
        std::ofstream file("hello.z", std::ios_base::out | std::ios_base::binary);
        boost::iostreams::filtering_ostream out;
        out.push(boost::iostreams::bzip2_compressor());
        out.push(file);
        
        out << "Hello World!" << std::endl;
    }

    {
        std::ifstream file_in("hello.z", std::ios_base::in | std::ios_base::binary);
        boost::iostreams::filtering_istream in;
        in.push(boost::iostreams::bzip2_decompressor());
        in.push(file_in);
        
        std::string content(std::istreambuf_iterator<char>(in), {});
        std::cout << content << std::endl;
    }
    
    return 0;
}

If I compile it with

 g++ main.cpp -o main.exe --std=c++11  -lboost_iostreams -I/c/libraries/boost_1_76_0/InstallRelease/include -L/c/libraries/boost_1_76_0/InstallRelease/lib

set the path on an Msys2 console with

export PATH=/c/Libraries/boost_1_76_0/InstallRelease/lib:/c/mingw-w64-10.2/mingw64/bin

and run it, I get

$ ./main.exe
Hello World!

Now if I delete the directories bin.v2 and InstallRelease from the boost_1_76_0 directory and build boost again, but this time with cflags=-flto like this:

./b2 --layout=system variant=release link=shared address-model=64 threading=multi optimization=speed runtime-link=shared cflags="-flto" -s BZIP2_SOURCE=C:/Libraries/bzip2-1.0.6 install

and run main.exe again, I get:

$ ./main.exe
Segmentation fault

This is not the case, if I use boost::iostreams::zlib_(de)compressor instead. If I build boost with debug information like this:

./b2 --layout=system variant=debug link=shared address-model=64 runtime-link=shared cflags="-flto" -s BZIP2_SOURCE=C:/Libraries/bzip2-1.0.6 install

and run main.exe within gdb, the output is like this:

Starting program: C:\...\main.exe #
[New Thread 7460.0x1dec]
[New Thread 7460.0x2508]
[New Thread 7460.0x2cb4]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb)

Trying to print a backtrace is not successful, even if main.exe has been compiled with the arguments -O0 -g:

(gdb) bt
#0  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

What does that mean? Is link-time optimization not as harmful as I had thought? Where is the bug? In the compiler? In Boost.Iostreams? Have I made an error? Which one? Or how can I figure out what actually has caused the segmentation fault?