public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: gcc-patches@gcc.gnu.org
Subject: Fix pass49-frag (mudflap support for varargs)
Date: Wed, 30 Mar 2011 21:30:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.1103302249580.19760@wotan.suse.de> (raw)

Hi,

for some reasons the FAIL of pass49-frag now annoyed me enough to look 
into it, where it didn't do so for the last 50 years it's failing (give or 
take a few).  mudflap has a mean to mark some expressions as not 
interesting to generate checks for, which is used to disable this for the 
indirect refs that are generated for the varargs accesses (naturally these 
can't be checked because nobody registers these stack slots).  That is 
done via build_va_arg_indirect_ref calling mf_mark on the generated 
indirect_ref.

Now, our gimplifier changes this indirect_ref into a mem_ref, making the 
marking (via a hash-table marked_trees in tree-mudflap.c) obsolete.  
Instead of amending the gimplifier to copy the mark whenever changing a 
marked tree, I chose to instead simply generate a memref right from the 
start, which isn't gimplified further, hence the mark stays okay.

Yes, that's somewhat fragile, but so is the whole mudflap code generation.  
And in the abstract it seems better to generate more natural gimple code 
to begin with (of course the operand still is gimplified when necessary, 
but that doesn't destroy the mark as it's done in place).

Why pass49-frag also failed before mem-ref I don't know.  I don't want to 
know.  I'd speculate that it's similar reasons.  Or maybe it wasn't 
failing and I confuse it with some other pass4x-frag that was failing for 
years where nobody cared.

In any case, patch fixes this mudflap testcase and for x86_64-linux that 
was the last failing one.  Regstrapping on x86_64-linux in progress.  Okay 
for trunk?


Ciao,
Michael.
PS: Btw, that varargs at least for x86_64 didn't work with mudflap makes 
me somewhat suspicious about the existence of people using -fmudflap.  
Perhaps we should just remove the whole mudflap code for 4.7.
-- 
	* builtins.c (build_va_arg_indirect_ref): Use
	build_simple_mem_ref_loc.

Index: builtins.c
===================================================================
--- builtins.c	(revision 171675)
+++ builtins.c	(working copy)
@@ -4748,7 +4748,7 @@ std_gimplify_va_arg_expr (tree valist, t
 tree
 build_va_arg_indirect_ref (tree addr)
 {
-  addr = build_fold_indirect_ref_loc (EXPR_LOCATION (addr), addr);
+  addr = build_simple_mem_ref_loc (EXPR_LOCATION (addr), addr);
 
   if (flag_mudflap) /* Don't instrument va_arg INDIRECT_REF.  */
     mf_mark (addr);

             reply	other threads:[~2011-03-30 21:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30 21:30 Michael Matz [this message]
2011-03-31  8:49 ` Richard Guenther

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=Pine.LNX.4.64.1103302249580.19760@wotan.suse.de \
    --to=matz@suse.de \
    --cc=gcc-patches@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: 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).