From: Eric Botcazou <ebotcazou@adacore.com>
To: Hans-Peter Nilsson <hp@bitrange.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFA:] fix PR55030, wrong code from __builtin_setjmp_receiver
Date: Mon, 12 Nov 2012 08:28:00 -0000 [thread overview]
Message-ID: <13011180.NBQR3vZSIa@polaris> (raw)
In-Reply-To: <alpine.BSF.2.02.1211112347180.73231@dair.pair.com>
> This is a target-specific blockage insn, but with the general form
> found in all targets defining it. The default blockage is an empty
> asm-volatile, which is what cse_insn recognized. The blockage insn is
> there to "prevent scheduling" of the critical insns and register
> values. It's almost obvious that an unspec_volatile should have that
> effect "too"; at least that's intended by the code in
> expand_builtin_setjmp_receiver. Luckily (or unluckily regarding the
> presence of the bug) *this* cse code is not run post-frame-layout
> (post-reload-cse does not use this code), or it seems people would
> soon notice register values used from the wrong side of the blockage,
> considering its critical use at the restore of the stack-pointer.
> As mentioned in the previous patch,
> <http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html>, clobbering
> the frame-pointer (and then using it) does not seem the logical
> alternative to the patch below; the blockage insn should just do its job.
Agreed.
> I updated comments and documentation so it's more apparent that
> register uses should also not be moved across the blockage; see the
> patched comments.
>
> Tested native x86_64-unknown-linux-gnu w./wo. -m32 and before/after
> 192677. Ok to commit?
>
> gcc:
> PR middle-end/55030
> * builtins.c (expand_builtin_setjmp_receiver): Update comment
> regarding purpose of blockage.
> * emit-rtl.c [!HAVE_blockage] (gen_blockage): Similarly for
> the head comment.
> * doc/md.texi (blockage): Update similarly. Change wording to
> require one of two forms, rather than implying a wider choice.
> * cse.c (cse_insn): Where checking for blocking insns, treat
> UNSPEC_VOLATILE as blocking, besides volatile ASM.
That's fine on principle, but there is a predicate for this (volatile_insn_p)
so I think we should use it here. Moreover, cselib_process_insn has the same
check so we should adjust it as well, which in turn means that dse.c:scan_insn
should probably be adjusted too. OK with these changes, thanks.
--
Eric Botcazou
next prev parent reply other threads:[~2012-11-12 8:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-12 4:49 Hans-Peter Nilsson
2012-11-12 8:28 ` Eric Botcazou [this message]
2012-11-19 3:54 ` Hans-Peter Nilsson
2012-11-19 9:35 ` Eric Botcazou
2012-11-26 3:30 ` Hans-Peter Nilsson
2012-11-27 11:44 ` Hans-Peter Nilsson
2012-11-27 12:04 ` Jakub Jelinek
2012-11-27 12:27 ` Hans-Peter Nilsson
2012-11-27 13:32 ` Jakub Jelinek
2012-11-27 17:39 ` Eric Botcazou
2012-11-27 18:20 ` Jakub Jelinek
2012-12-01 0:03 ` Eric Botcazou
2012-11-28 20:10 ` Richard Sandiford
2012-11-28 20:46 ` Richard Henderson
2012-11-28 13:44 ` Hans-Peter Nilsson
2012-11-28 13:56 ` Jakub Jelinek
2012-11-28 20:53 ` Richard Henderson
2012-11-27 19:30 Uros Bizjak
2012-11-28 9:50 ` Uros Bizjak
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=13011180.NBQR3vZSIa@polaris \
--to=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hp@bitrange.com \
/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: link
Be 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).