Andarwinux wrote: > It does add `-fno-exceptions` even on the first bootstrap build for me. See > e.g. > https://github.com/mstorsjo/llvm-mingw/actions/runs/12662020869/job/35286224252#step:3:23134: > > ``` > -- The C compiler identification is Clang 20.0.0 > -- The CXX compiler identification is Clang 20.0.0 > -- The ASM compiler identification is Clang with GNU-like command-line > -- Found assembler: > /home/runner/work/llvm-mingw/llvm-mingw/install/llvm-mingw/bin/i686-w64-mingw32-clang > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - failed > -- Detecting C compile features > -- Detecting C compile features - done > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - failed > -- Detecting CXX compile features > -- Detecting CXX compile features - done > [...] > -- Performing Test CXX_SUPPORTS_FUNWIND_TABLES_FLAG > -- Performing Test CXX_SUPPORTS_FUNWIND_TABLES_FLAG - Success > -- Performing Test CXX_SUPPORTS_FNO_EXCEPTIONS_FLAG > -- Performing Test CXX_SUPPORTS_FNO_EXCEPTIONS_FLAG - Success > ```
I'm sorry, but this was caused by my own mistake: my modified clang++ wrapper has a -lc++abi, which I forgot what it was previously introduced to solve. > > If you build MinGW LTO libunwind without `-fno-exceptions` or with > > -`fexceptions`, libunwind references `__gcc_personality_seh0`, which > > results in undefined symbols. > > Perhaps this is a symbol which we need to implicitly mark as needed in the > linker? Because before the LTO, I think it only sees a definition of this > symbol, but nothing referencing it, so the LTO logic thinks it doesn't need > to retain/expose this symbol - while after the LTO, the generated code does > add new references to it. > > I don't find any precedence for doing this for LTO so far, but we have a > couple cases of doing something similar for the regular GC in LLD. Should I open a new issue for this? Since it won't actually happen in reality unless libunwind does switch to `-fexceptions` one day to compile the whole library, I'm not sure what to do. https://github.com/llvm/llvm-project/pull/121819 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
