Falsely identified functions within function

Version 4.2.6455-stable
OS: Windows 10 (22H2)
CPU Architecture: x64

I am de-compiling an .exe built with Borland C++.

One function was misidentified as 4 functions.

the linear disassembly looks like this:

int32_t function1(....)
push ebp
mov ebp, esp
...
jmp functionCleanup
int32_t function2(....)
jmp function4
{continuation of function function1}
and ebx, 0xfffff
sar ebx, 01
...
jmp functionCleanup
int32_t function3(....)
mov word[ebp-0x28], 0xc
jmp function4
{continuation of function function1}
mov word [ebp-0x28], 0x6c
...
jmp functionCleanup
int32_t function4(....)
mov word [ebp-0x28], 0x90
...
jmp functionCleanup
66 c7 ... 00 (11 bytes: a mov and a call instruction that are shown as hex instead of disassembly)
int32_t functionCleanup(....)
pop edi
...
retn

I believe function2, function3, function4, functionCleanup are not really functions, since they don't start with "push ebp". Also at the end of supposed function 4, two instructions were shown as hex instead of assembly.

the line that contains "sar ebx, 01" has two tags:
-Could not generate flag IL: IL for flag c in Lifted IL instruction asr.d{*}(ebx,1) could not be generated
-Unimplemented instruction (LLIL): opcode “sar” is partially unimplemented (LLIL)

I wanted to demote the falsely identified functions to labels instead.
When I select "Undefine current function", on the functions that were not really functions,
the functions are shown as hex, instead of the assembly.

Reproduce the report with the Borland C++ executable described and inspect the linear disassembly around function1 through functionCleanup, including the partially unimplemented sar instruction and the bytes rendered as hex. Determine why the additional entry points are identified as functions; done means valid code is disassembled correctly and false functions can be replaced by labels without turning the code into hex.