public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f Date: Sun, 20 Nov 2022 16:44:07 +0000 [thread overview] Message-ID: <bug-107183-4-N7PUerhu4v@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-107183-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107183 --- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:6b5c98c1c0003bd470a4428bede6c862637a94b8 commit r13-4175-g6b5c98c1c0003bd470a4428bede6c862637a94b8 Author: Jakub Jelinek <jakub@redhat.com> Date: Sun Nov 20 17:42:42 2022 +0100 reg-stack: Fix a -fcompare-debug bug in reg-stack [PR107183] As the following testcase shows, the swap_rtx_condition function in reg-stack can result in different code generation between -g and -g0. The function is doing the changes as it goes, so does analysis and changes together, which makes it harder to deal with DEBUG_INSNs, where normally analysis phase ignores them and the later phase doesn't. swap_rtx_condition walks instructions two different ways, one is using next_flags_user function which stops on non-call instructions that mention the flags register, and the other is a loop on fnstsw where it stops on instructions mentioning it and tries to find sahf instruction that uses it (in both cases calls stop it and so does end of basic block). Now both of these currently stop on DEBUG_INSNs that mention the flags register resp. the fnstsw result register. On success the function recurses on next flags user instruction if still live and if the recursion failed, reverts the changes it did too and fails. If it were just for the next_flags_user case, the fix could be just not doing INSN_CODE (insn) = -1; if (recog_memoized (insn) == -1) fail = 1; on DEBUG_INSNs (assuming all changes to those are fine), swap_rtx_condition_1 just changes one comparison to a different one. But due to the possibility of fnstsw result being used in theory before sahf in some DEBUG_INSNs, this patch takes a different approach. swap_rtx_condition has now a new argument and two modes. The first mode is when debug_seen is >= 0, in this case both next_flags_user and the loop for fnstsw -> sahf will ignore but note DEBUG_INSNs (that mention flags register or fnstsw result). If no such DEBUG_INSN is found during the whole call including recursive invocations (so e.g. for -g0 but probably most often for -g as well), it behaves as before, if it returns true all the changes are done and nothing further needs to be done later. If any DEBUG_INSNs are seen along the way, even when returning success all the changes are reverted, so it just reports that the function would be successful if DEBUG_INSNs were ignored. In this case, compare_for_stack_reg needs to call it again in debug_seen = -1 mode, which tells the function to update everything including DEBUG_INSNs. For the fnstsw -> sahf case which I hope will be very rare I just reset the DEBUG_INSNs, I don't really know how to express it easily otherwise. For the rest swap_rtx_condition_1 is done even on the DEBUG_INSNs. 2022-11-20 Jakub Jelinek <jakub@redhat.com> PR target/107183 * reg-stack.cc (next_flags_user): Add DEBUG_SEEN argument. If >= 0 and a DEBUG_INSN would be otherwise returned, set DEBUG_SEEN to 1 and ignore it. (swap_rtx_condition): Add DEBUG_SEEN argument. In >= 0 mode only set DEBUG_SEEN to 1 if problematic DEBUG_ISNSs were seen and revert all changes on success in that case. Don't try to recog_memoized DEBUG_INSNs. (compare_for_stack_reg): Adjust swap_rtx_condition caller. If it returns true and debug_seen is 1, call swap_rtx_condition again with debug_seen -1. * gcc.dg/ubsan/pr107183.c: New test.
next prev parent reply other threads:[~2022-11-20 16:44 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-07 18:14 [Bug debug/107183] New: -fcompare-debug failure (length) with -fsanitize=float-cast-overflow zsojka at seznam dot cz 2022-10-07 20:18 ` [Bug target/107183] [10/11/12/13 Regression] " pinskia at gcc dot gnu.org 2022-10-10 13:00 ` [Bug target/107183] [10/11/12/13 Regression] -fcompare-debug failure (length) with -fsanitize=float-cast-overflow since r7-5708-gcfd719e7769fd43f marxin at gcc dot gnu.org 2022-10-10 15:20 ` pinskia at gcc dot gnu.org 2022-10-18 8:33 ` rguenth at gcc dot gnu.org 2022-11-18 14:29 ` jakub at gcc dot gnu.org 2022-11-18 16:13 ` jakub at gcc dot gnu.org 2022-11-20 16:44 ` cvs-commit at gcc dot gnu.org [this message] 2022-11-20 23:11 ` cvs-commit at gcc dot gnu.org 2022-11-21 9:23 ` cvs-commit at gcc dot gnu.org 2022-11-21 9:31 ` [Bug target/107183] [10 " jakub at gcc dot gnu.org 2023-05-03 15:19 ` cvs-commit at gcc dot gnu.org 2023-05-04 7:20 ` jakub at gcc dot gnu.org
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-107183-4-N7PUerhu4v@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).