From patchwork Mon Aug 15 05:06:13 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 109980 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 05AEEB6F8C for ; Mon, 15 Aug 2011 15:06:47 +1000 (EST) Received: (qmail 7915 invoked by alias); 15 Aug 2011 05:06:41 -0000 Received: (qmail 7907 invoked by uid 22791); 15 Aug 2011 05:06:38 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, TW_ZJ X-Spam-Check-By: sourceware.org Received: from anubis.se.axis.com (HELO anubis.se.axis.com) (195.60.68.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 05:06:19 +0000 Received: from localhost (localhost [127.0.0.1]) by anubis.se.axis.com (Postfix) with ESMTP id BD53619D79; Mon, 15 Aug 2011 07:06:15 +0200 (CEST) Received: from anubis.se.axis.com ([127.0.0.1]) by localhost (anubis.se.axis.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OHlJpI+FY+Zl; Mon, 15 Aug 2011 07:06:15 +0200 (CEST) Received: from thoth.se.axis.com (thoth.se.axis.com [10.0.2.173]) by anubis.se.axis.com (Postfix) with ESMTP id D0E4419D77; Mon, 15 Aug 2011 07:06:14 +0200 (CEST) Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.88.21.50]) by thoth.se.axis.com (Postfix) with ESMTP id 9B7C73406C; Mon, 15 Aug 2011 07:06:14 +0200 (CEST) Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id p7F56EF6031878; Mon, 15 Aug 2011 07:06:14 +0200 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id p7F56DV5031874; Mon, 15 Aug 2011 07:06:13 +0200 Date: Mon, 15 Aug 2011 07:06:13 +0200 Message-Id: <201108150506.p7F56DV5031874@ignucius.se.axis.com> From: Hans-Peter Nilsson To: gcc-patches@gcc.gnu.org CC: rguenther@suse.de, ubizjak@gmail.com In-reply-to: (message from Uros Bizjak on Thu, 11 Aug 2011 14:34:25 +0200) Subject: Fix spurious match testsuite regressions from "[PATCH, middle end]: Introduce BUILT_IN_I{CEIL_FLOOR_ROUND_RINT} FP-to-int conversion functions" MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org This patch: > 2011-08-11 Uros Bizjak > > * builtins.def (BUILT_IN_ICEIL{,F,L}, BUILT_IN_IFLOOR{,F,L}, > BUILT_IN_IRINT{,F,L}, BUILT_IN_IROUND{,F,L}: New builtin definitions. > * convert.c (convert_to_integer): Convert to BUILT_IN_ICEIL, > BUILT_IN_IFLOOR, BUILT_IN_IRINT or BUILT_INT_IROUND when converting > to integer_type_node. > * fold-const.c (tree_call_nonnegative_warnv_p): Handle BUILT_IN_ICEIL, > BUILT_IN_IFLOOR, BUILT_IN_IRINT and BUILT_INT_IROUND. > * builtins.c (expand_builtin_in): Ditto. > (mathfn_built_in_1): Ditto. > (expand_builtin_int_roundingfn): Handle BUILT_IN_ICEIL and > BUILT_IN_IFLOOR. > (expand_builtin_int_roundingfn_2): Handle BUILT_IN_IRINT and > BUILT_IN_IROUND. > (fold_fixed_mathfn): Canonicalize BUILT_IN_ICEIL, BUILTIN_IN_IFLOOR, > BUILT_IN_IRINT and BUILT_IN_IROUND to BUILT_IN_LCEIL, > BUILTIN_IN_LFLOOR, BUILT_IN_LRINT and BUILT_IN_LROUND on ILP32 targets. "caused" this regression for cris-elf: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ... ... FAIL: gcc.dg/tree-ssa/vrp61.c scan-tree-dump-not vrp1 "1234" Looking at vrp61.c only yields a big WTF, but when looking at the vrp61.c.067t.vrp1 dump file all is explained, because there, at the top is: ;; Function f (f, funcdef_no=0, decl_uid=1234, cgraph_uid=0) Hilarious. Probably not the instance intended to not-look for. Anyway, I decided not to try and do anything else but a brain-dead tweak, hoping that someone used to writing such test-cases would jump in with a better solution (like, not dumping the decl_uid unless the dump verbosity-level is higher)... doh! Anyhow, the following should fit nicely with 16-bitters and allow for another ten-fold of built-in functions... So, ok as is? If not, would you preapprove tree-dumping decl_uids only at a higher dump verbosity level? gcc/testsuite: * gcc.dg/tree-ssa/vrp61.c: Increase magic number from 1234 to 12345. brgds, H-P Index: gcc.dg/tree-ssa/vrp61.c =================================================================== --- gcc.dg/tree-ssa/vrp61.c (revision 177757) +++ gcc.dg/tree-ssa/vrp61.c (working copy) @@ -7,10 +7,10 @@ int f (int x, int y) { x = x ^ y; if (x < 0 || x > 1023) - return 1234; + return 12345; } return x; } -/* { dg-final { scan-tree-dump-not "1234" "vrp1" } } */ +/* { dg-final { scan-tree-dump-not "12345" "vrp1" } } */ /* { dg-final { cleanup-tree-dump "vrp1" } } */