From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16684 invoked by alias); 4 Aug 2003 17:38:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16667 invoked from network); 4 Aug 2003 17:38:42 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 4 Aug 2003 17:38:42 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 0483DF2D7C; Mon, 4 Aug 2003 13:38:41 -0400 (EDT) To: dewar@gnat.com, jbuck@synopsys.com Subject: Re: On inlining in C++ Cc: gcc@gcc.gnu.org, gdr@integrable-solutions.net Message-Id: <20030804173841.0483DF2D7C@nile.gnat.com> Date: Mon, 04 Aug 2003 17:41:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-08/txt/msg00166.txt.bz2 > > Option 1: a version of GNU C++ that > > * honors the "inline" keyword in all situations where the compiler is > capable of inlining the call > * does the same for functions defined in the class body > * when -Winline is given, issues a warning and explanation about why > a call is not inlined > * avoids computing any metrics related to inlining decisions (unless -O3) > > Option 2: a version of GNU C++ that uses the smartest heuristics that the > "ignore inline" advocates can come up with. Indeed, this is exactly the experiment that is required, and I suspect the best resolution is to have this controllable by a switch. The issue of what the best setting for the switch is is another discussion, and for example depends on how well gdb handles inlining.