From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11286 invoked by alias); 25 Mar 2010 17:38:02 -0000 Received: (qmail 11173 invoked by uid 48); 25 Mar 2010 17:37:51 -0000 Date: Thu, 25 Mar 2010 17:38:00 -0000 Message-ID: <20100325173751.11172.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/40106] [4.4 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hubicka at gcc dot gnu dot org" 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: 2010-03/txt/msg02571.txt.bz2 ------- Comment #59 from hubicka at gcc dot gnu dot org 2010-03-25 17:37 ------- Hi, concerning the optimize_*_for_size and maybe_hot_*_p predicates, the idea is that maybe_hot/probably_cold care about the profile alone. So when optimizing for size, parts of program still can be considered hot and this can be used by optimizers if doing so does not increase code size (i.e. one can trade copy in hot block for copy in cold block even at -Os). optimize_*_for_size should be aware of the defaults - with -Os everything is by default optimized for size unless user asks otherwise and with ohter levels only probably cold sutuff (that is negation of maybe_hot) is optimized for size. Let me check if there are some problems, but I guess this is just problem with too many nested loops leading to too large frequency differences. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106