From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20645 invoked by alias); 20 Feb 2008 23:40:07 -0000 Received: (qmail 19987 invoked by alias); 20 Feb 2008 23:39:21 -0000 Date: Wed, 20 Feb 2008 23:40:00 -0000 Message-ID: <20080220233921.19986.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/35262] [4.4 Regression]: FAIL: abi_check In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hubicka at ucw dot cz" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-02/txt/msg02182.txt.bz2 ------- Comment #5 from hubicka at ucw dot cz 2008-02-20 23:39 ------- Subject: Re: [4.4 Regression]: FAIL: abi_check OK, if it really is just inlining decision difference then we are fine. I guess we can either update symbol list or mark always_inline > because of a changing inlining decision. My concern, however, is whether it's > ok not to inline such a tiny function (fyi, the function is defined in > basic_ios.h all the uses are in fstream.tcc). First blush, I don't think it's > ok... I can look into the reason why it is not getting inlined. It would help to have preprocessed testcase as I am travelling now :) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262