From patchwork Tue Sep 6 12:01:55 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 113544 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 D9E98B6F7C for ; Tue, 6 Sep 2011 22:01:20 +1000 (EST) Received: (qmail 25227 invoked by alias); 6 Sep 2011 12:01:18 -0000 Received: (qmail 25219 invoked by uid 22791); 6 Sep 2011 12:01:18 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Sep 2011 12:01:04 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id DF7A2CB02DE for ; Tue, 6 Sep 2011 14:01:04 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMeJXy1iBGWo for ; Tue, 6 Sep 2011 14:00:54 +0200 (CEST) Received: from new-host-2.home (ADijon-552-1-41-2.w92-138.abo.wanadoo.fr [92.138.168.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 50FB7CB0353 for ; Tue, 6 Sep 2011 14:00:42 +0200 (CEST) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [c-family] Fix PR middle-end/50266 Date: Tue, 6 Sep 2011 14:01:55 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Message-Id: <201109061401.55969.ebotcazou@adacore.com> 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 Hi, this is a regression present on the mainline and 4.6 branch caused by the constructor uniquization patch. The tree_output_constant_def routine rejects offsetof-like computations that can be written in the C family of languages. While the C compiler folds most of them early, it doesn't if an intermediate folding step is required. The proposed fix is to make c_fully_fold also do the offsetof folding. Tested on x86_64-suse-linux, OK for mainline and 4.6 branch? 2011-09-06 Eric Botcazou PR middle-end/50266 * c-common.c (c_fully_fold_internal) : Fold offsetof-like computations. 2011-09-06 Eric Botcazou * gcc.dg/init-offsetof-1.c: New test. Index: c-common.c =================================================================== --- c-common.c (revision 178488) +++ c-common.c (working copy) @@ -1264,7 +1264,18 @@ c_fully_fold_internal (tree expr, bool i STRIP_TYPE_NOPS (op0); if (code != ADDR_EXPR && code != REALPART_EXPR && code != IMAGPART_EXPR) op0 = decl_constant_value_for_optimization (op0); - if (op0 != orig_op0 || in_init) + if (op0 != orig_op0 + && code == ADDR_EXPR + && (op1 = get_base_address (op0)) != NULL_TREE + && TREE_CODE (op1) == INDIRECT_REF + && TREE_CONSTANT (TREE_OPERAND (op1, 0))) + { + tree offset = fold_offsetof (op0, op1); + op1 + = fold_convert_loc (loc, TREE_TYPE (expr), TREE_OPERAND (op1, 0)); + ret = fold_build_pointer_plus_loc (loc, op1, offset); + } + else if (op0 != orig_op0 || in_init) ret = in_init ? fold_build1_initializer_loc (loc, code, TREE_TYPE (expr), op0) : fold_build1_loc (loc, code, TREE_TYPE (expr), op0);