public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: rth@redhat.com, aoliva@redhat.com
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] Fix tree inlining ICE
Date: Tue, 23 Oct 2001 05:51:00 -0000	[thread overview]
Message-ID: <20011023145503.D11778@sunsite.ms.mff.cuni.cz> (raw)

Hi!

The following testcase ICEs with -O3 (but goes away when the auto nested
function prototype is removed; but it cannot be removed because otherwise
-Wmissing-prototypes warns about it). The problem is we end up
with two different DECL_STMTs with the same DECL_STMT_EXPR (baz) and tree
inliner is very confused about it. This patch makes sure DECL_STMT is added
for the actual nested fn definition only.
What was broken before and keeps being broken is:
void bar (void) { auto void baz (void); baz ();  }
which IMHO should generate error, the question is where exactly the error
should be diagnosed.
Ok to commit if it bootstraps and creates no regressions?

BTW: I have another issue with C tree inlining. The default
-finline-limit=600 is too low for glibc and causes glibc ld.so not to work
at all (glibc in one place relies on some nested static inline functions
beeing inlined). Experimentation showed that -finline-limit=1500 works (both
elf_get_dynamic_info and elf_do_machine_rel get inlined).
Now, what do you think is a good solution for this? Hardcoding
-finline-limit=1500 into glibc CFLAGS is IMHO not the right solution, since
the meaning of this switch keeps changing (was number of RTL insns, now
something completely else, etc.). Either -finline-limit could have different
defaults for each language, or the lang hook which is used currently for not
honouring inline-limit in some cases at all could be changed, so that it
could return a new limit computed from the -finline-limit parameter and
properties of function being inlined. I think it makes sense to say that
functions marked by user with inline keyword should be attempted to inline
harder than just some arbitrary short function at -O3, and C nested
inline functions should be attempted even harder (e.g. due to all the
bookkeeping needed for nested function calls if they are not inlined).

2001-10-23  Jakub Jelinek  <jakub@redhat.com>

	* c-decl.c (finish_decl): Don't add DECL_STMTs for nested function
	prototypes.

	* gcc.c-torture/compile/20011023-1.c: New test.

--- gcc/c-decl.c.jj	Mon Oct 22 11:06:59 2001
+++ gcc/c-decl.c	Tue Oct 23 14:27:45 2001
@@ -3731,7 +3731,8 @@ finish_decl (decl, init, asmspec_tree)
 		SET_DECL_ASSEMBLER_NAME (decl, get_identifier (asmspec));
 	    }
 
-	  add_decl_stmt (decl);
+	  if (TREE_CODE (decl) != FUNCTION_DECL)
+	    add_decl_stmt (decl);
 	}
 
       if (DECL_CONTEXT (decl) != 0)
--- gcc/testsuite/gcc.c-torture/compile/20011023-1.c.jj	Tue Oct 23 13:58:40 2001
+++ gcc/testsuite/gcc.c-torture/compile/20011023-1.c	Tue Oct 23 14:38:38 2001
@@ -0,0 +1,12 @@
+extern void foo (char *x);
+void bar (void);
+void bar (void)
+{
+  auto void baz (void);
+  void baz (void)
+    {
+      char tmp[2];
+      foo (tmp);
+    }
+  baz ();
+}

	Jakub

             reply	other threads:[~2001-10-23  5:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-23  5:51 Jakub Jelinek [this message]
2001-10-23 11:04 ` Richard Henderson
2001-10-23 11:05 ` Richard Henderson
2001-10-23 11:11 ` Neil Booth
2001-10-24  0:43 ` Gerald Pfeifer
2001-11-13 15:03 Jakub Jelinek

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=20011023145503.D11778@sunsite.ms.mff.cuni.cz \
    --to=jakub@redhat.com \
    --cc=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rth@redhat.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).