public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tomas.kalibera at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/103274] New: Remaining -freorder-blocks-and-partition/ glitch with Windows SEH Date: Tue, 16 Nov 2021 13:12:51 +0000 [thread overview] Message-ID: <bug-103274-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 Bug ID: 103274 Summary: Remaining -freorder-blocks-and-partition/ glitch with Windows SEH Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tomas.kalibera at gmail dot com Target Milestone: --- Created attachment 51809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51809&action=edit When compiled with -O3, dummy ends in a call (invalid unwind information). -freorder-blocks-and-partition sometimes causes a function to end right in a (non-returning) call, but SEH needs at least one more instruction on x86_64. Seen in GCC 10.3, 11.2 and git master. Maybe [1] did not cover all the cases? The attached compile-only example compiled with -O3 reproduces the problem. It is extracted from R, where this problem causes crashes (and where in wine, one gets an error "virtual_unwind exception data not found" and further instrumentation reveals it is because the address following the call instruction is already at the function boundary). The problem can be seen directly from the assembly: gcc -O3 -c -S ../main/a.c -o - produces dummy: [...] .L5: call myerrorcall .seh_endproc [...] dummy.cold: For reference, R is affected by this and has been disabling SEH as a workaround, but it has been reported that the workaround causes in turns crashes with CFG. This report is with substantial help from Martin Storsjo. ======= [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=15278fb2877184c75a6ee3a6def09efbb191968b;hp=9d3b9a3e70e634c7c48bb12bb35ec8219024f98b [2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386.c;h=1bca5a7eea6ab9accbbf6953f79e8a4da61859e2;hb=4212a6a3e44f870412d9025eeb323fd4f50a61da#l29076 [3] https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86AvoidTrailingCall.cpp [4] https://bugs.r-project.org/show_bug.cgi?id=18180
next reply other threads:[~2021-11-16 13:12 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-16 13:12 tomas.kalibera at gmail dot com [this message] 2021-11-16 14:55 ` [Bug target/103274] " ebotcazou at gcc dot gnu.org 2021-11-16 15:27 ` tomas.kalibera at gmail dot com 2021-11-16 16:02 ` martin at martin dot st 2021-11-16 16:07 ` martin at martin dot st 2021-11-16 17:11 ` [Bug target/103274] [10/11/12 regression] remaining " ebotcazou at gcc dot gnu.org 2021-11-16 17:34 ` ebotcazou at gcc dot gnu.org 2021-11-30 9:19 ` cvs-commit at gcc dot gnu.org 2021-11-30 9:21 ` cvs-commit at gcc dot gnu.org 2021-11-30 9:23 ` cvs-commit at gcc dot gnu.org 2021-11-30 9:24 ` ebotcazou at gcc dot gnu.org 2021-12-01 7:46 ` martin at martin dot st 2021-12-01 22:59 ` tomas.kalibera at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-103274-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).