On Tue, Jun 16, 2020 at 7:17 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Tue, Jun 09, 2020 at 09:34:01AM -0700, H.J. Lu via Gcc-patches wrote: > > > > * gcc.target/i386/pr93492-3.c: Likewise. > > > > * gcc.target/i386/pr93492-5.c: Likewise. > > These tests FAIL on i686-linux. > E.g. in the first one I see > .file "pr93492-3.c" > .text > .globl f10_endbr > .type f10_endbr, @function > f10_endbr: > .LFB0: > .cfi_startproc > endbr32 > .section __patchable_function_entries,"aw",@progbits > .align 4 > .long .LPFE1 > .text > .LPFE1: > nop > 1: call __fentry__ > pushl %ebp > .cfi_def_cfa_offset 8 > .cfi_offset 5, -8 > movl %esp, %ebp > .cfi_def_cfa_register 5 > popl %ebp > .cfi_restore 5 > .cfi_def_cfa 4, 4 > ret > .cfi_endproc > .LFE0: > .size f10_endbr, .-f10_endbr > so it doesn't match the scan regexp, because > call __fentry__ > is not immediately followed by > ret > As -pg is incompatible with -fomit-frame-pointer, I don't see anything wrong > on that.
Can you take a look at https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547992.html It should fix it. > Another thing in the test is that I don't think you can rely on > .cfi_startproc actually being printed, you should add an effective target > that will either check __GCC_HAVE_DWARF2_CFI_ASM macro definition, or check > for presence of .cfi_startproc on some trivial function compiled with > -fasynchronous-unwind-tables. > -mfentry and -fpatchable-function-entry= don't work on all targets. Should I limit these tests to Linux? -- H.J.
