From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20056 invoked by alias); 22 Jan 2012 14:52:51 -0000 Received: (qmail 20040 invoked by uid 22791); 22 Jan 2012 14:52:50 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-out.m-online.net (HELO mail-out.m-online.net) (212.18.0.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 22 Jan 2012 14:52:36 +0000 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id E2C3C1C00B33; Sun, 22 Jan 2012 15:52:34 +0100 (CET) X-Auth-Info: nOZVm0JO9+e/u3jpQ3xYlH82GG1hOKazBwfSOiCJvEc= Received: from igel.home (ppp-93-104-157-111.dynamic.mnet-online.de [93.104.157.111]) by mail.mnet-online.de (Postfix) with ESMTPA id 628F21C001BE; Sun, 22 Jan 2012 15:52:34 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id 12628CA29E; Sun, 22 Jan 2012 15:52:34 +0100 (CET) From: Andreas Schwab To: gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org Cc: Joseph Myers Subject: Fix flag_trapping_math in java frontend X-Yow: .. I think I'd better go back to my DESK and toy with a few common MISAPPREHENSIONS... Date: Sun, 22 Jan 2012 14:52:00 -0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2012-q1/txt/msg00009.txt.bz2 The java frontend wants that floating point operations are assumed to never trap, thus clears flag_trapping_math in java_init_options_struct. But this is no longer effective after revision 165823, because set_fast_math_flags is now always called during option processing, overriding anything what the frontend did to flag_trapping_math. This is an amendment to revision 169930 which introduced frontend_set_flag_trapping_math, but didn't set it in java_init_options_struct. While this was found during examination of PR49847, this doesn't fix it, but only makes the bug dormant again in 4.6. Tested on powerpc-linux, ok for trunk and 4.6 branch? Andreas. 2012-01-22 Andreas Schwab * lang.c (java_init_options_struct): Set frontend_set_flag_trapping_math. diff --git a/gcc/java/lang.c b/gcc/java/lang.c index ccab48c..da7dd05 100644 --- a/gcc/java/lang.c +++ b/gcc/java/lang.c @@ -1,6 +1,6 @@ /* Java(TM) language-specific utility routines. Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, - 2005, 2006, 2007, 2008, 2010 Free Software Foundation, Inc. + 2005, 2006, 2007, 2008, 2010, 2012 Free Software Foundation, Inc. This file is part of GCC. @@ -550,6 +550,7 @@ java_init_options_struct (struct gcc_options *opts) /* In Java floating point operations never trap. */ opts->x_flag_trapping_math = 0; + opts->frontend_set_flag_trapping_math = true; /* In Java arithmetic overflow always wraps around. */ opts->x_flag_wrapv = 1; -- 1.7.8.4 -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."