From owner-freebsd-java@FreeBSD.ORG Sun Aug 19 03:01:32 2007 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44DF016A417; Sun, 19 Aug 2007 03:01:32 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from ns.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id DBD5213C459; Sun, 19 Aug 2007 03:01:24 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by ns.tydfam.jp (8.14.1/8.14.1) with ESMTP id l7J3058n015377; Sun, 19 Aug 2007 12:00:05 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sun, 19 Aug 2007 12:01:36 +0900 (JST) Message-Id: <20070819.120136.41629169.ken@tydfam.jp> To: anrays@gmail.com From: Ken Yamada In-Reply-To: <864piweemc.fsf@santinel.home.ua> References: <20070815144804.GC5151@misty.eyesbeyond.com> <20070818.213208.74754361.ken@tydfam.jp> <864piweemc.fsf@santinel.home.ua> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91/3991/Sun Aug 19 09:31:39 2007 on ns.tydfam.jp X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ns.tydfam.jp Cc: lists_freebsd_org@07.antispam.web-wahnsinn.de, freebsd-current@freebsd.org, freebsd-java@freebsd.org Subject: Re: Gcc bugs break java/jdk15 build? [Workaround] X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2007 03:01:32 -0000 Does this mean that GCC 4.2.1 does not solve "loop optimization bug" pointed out by Andrey Chernov (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=282888+0+archive/2007/freebsd-current/20070701.freebsd-current) on 4.2.0? Is it a good idea of adding -fno-tree-vrp to CFLAGS in /etc/make.conf to avoid this optimization bug for all compilation? (BTW, I leave -O3 of CFLAGS as is in make.conf and just added -fno-tree-vrp to the end of the line.)