Skip to content

branch-4.1: [Fix](thirdparty) Unify arrow cpp standard with be #64390#64805

Open
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-64390-branch-4.1
Open

branch-4.1: [Fix](thirdparty) Unify arrow cpp standard with be #64390#64805
github-actions[bot] wants to merge 1 commit into
branch-4.1from
auto-pick-64390-branch-4.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #64390

Related PR: #63191

Problem Summary:

Arrow 17 defaults to `C++17` when CMAKE_CXX_STANDARD is not specified,
while Doris BE is built with `C++20`. This can make header-defined
inline/template code from Arrow Flight and its dependencies be compiled
under different C++ standard modes in the same final binary.

In particular, Arrow Status-related inline paths may generate different
implementations across C++17 and C++20, such as different initialization
strategies for function-local static std::string objects:

code:
```cpp
const std::string& get_empty_string() {
    static const std::string s = "";
    return s;
} 
```

cpp17 lazy initialization:
```asm
get_empty_string[abi:cxx11]():
        push    rbp
        mov     rbp, rsp
        sub     rsp, 64
        cmp     byte ptr [rip + guard variable for get_empty_string[abi:cxx11]()::s[abi:cxx11]], 0
        jne     .LBB0_4
        lea     rdi, [rip + guard variable for get_empty_string[abi:cxx11]()::s[abi:cxx11]]
        call    __cxa_guard_acquire@PLT
        cmp     eax, 0
        je      .LBB0_4
        lea     rdx, [rbp - 33]
        mov     qword ptr [rbp - 32], rdx
        mov     rax, qword ptr [rbp - 32]
        mov     qword ptr [rbp - 8], rax
        lea     rdi, [rip + get_empty_string[abi:cxx11]()::s[abi:cxx11]]
        lea     rsi, [rip + .L.str]
        call    std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::basic_string<std::allocator<char>>(char const*, std::allocator<char> const&)
        jmp     .LBB0_3
.LBB0_3:
        lea     rax, [rbp - 33]
        mov     qword ptr [rbp - 24], rax
        mov     rdi, qword ptr [rbp - 24]
        call    std::__new_allocator<char>::~__new_allocator() [base object destructor]
        lea     rdi, [rip + std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>::~basic_string() [base object destructor]]
        lea     rsi, [rip + get_empty_string[abi:cxx11]()::s[abi:cxx11]]
        lea     rdx, [rip + __dso_handle]
        call    __cxa_atexit@PLT
        lea     rdi, [rip + guard variable for get_empty_string[abi:cxx11]()::s[abi:cxx11]]
        call    __cxa_guard_release@PLT
```

cpp20 constant initialization: 
```asm
get_empty_string[abi:cxx11]():
        push    rbp
        mov     rbp, rsp
        lea     rax, [rip + get_empty_string[abi:cxx11]()::s[abi:cxx11]]
        pop     rbp
        ret

get_empty_string[abi:cxx11]()::s[abi:cxx11]:
        .quad   get_empty_string[abi:cxx11]()::s[abi:cxx11]+16
        .quad   0
        .zero   16
```

Mixing those definitions through `weak/COMDAT` symbols is not a
supported build model and can surface as runtime crashes in Flight
error/status handling paths.
@github-actions github-actions Bot requested a review from yiguolei as a code owner June 25, 2026 01:59
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

BE UT Coverage Report

Increment line coverage 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 54.04% (20633/38180)
Line Coverage 37.64% (196394/521706)
Region Coverage 33.97% (153335/451402)
Branch Coverage 34.94% (66911/191502)

@hello-stephen

Copy link
Copy Markdown
Contributor

BE Regression && UT Coverage Report

Increment line coverage 100% (0/0) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 73.60% (27457/37306)
Line Coverage 57.29% (297453/519196)
Region Coverage 54.83% (249202/454508)
Branch Coverage 56.23% (107854/191799)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants