From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9828 invoked by alias); 13 Jan 2006 17:33:40 -0000 Received: (qmail 9737 invoked by uid 48); 13 Jan 2006 17:33:39 -0000 Date: Fri, 13 Jan 2006 17:33:00 -0000 Message-ID: <20060113173339.9736.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/25620] Missed optimization with power In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jv244 at cam dot ac dot uk" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-01/txt/msg01284.txt.bz2 List-Id: ------- Comment #4 from jv244 at cam dot ac dot uk 2006-01-13 17:33 ------- (In reply to comment #3) > This needs to be done by the frontend, as the folded 2/3 or 4/3 is not exactly > representable in the target FP format (and such cannot be checked for). Making > this a frontend bug, rather than just closing as WONTFIX ;) Without fully understanding the above in all details. some target FP format might still have that 2./3. == 2 * 1./3. ? Furthermore, I would think that under -ffast-math these kind of transformations should be allowed if these equalities hold 'at machine precision'. E.g. x**p is replaced by cuberoot(p) if p is the FP number that is closest to 1./3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620