From patchwork Wed Feb 27 19:44:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 1049122 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-497129-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="rBC0t6s3"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 448mNs2XN7z9s4Z for ; Thu, 28 Feb 2019 06:44:53 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type:mime-version; q=dns; s= default; b=AIQ0xeTh7maumqAXNHIKuQeTvAhKAgXTnc4gPpCYvZB2+bRNiWvRb NYzm/s25IFqy5mM4GylLak6uO5DNMz/n8NPfO0LHHY/XhlF8Lid1JWC6j2q9d1NP CACnIc6GWv+Kcu2DDpz6trBPS/nLMYe4Ot5AYKBBvwUVJ5UizT0cJg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type:mime-version; s= default; bh=SLSOiu0Nw3A5GbUeIYl5TDj1o+4=; b=rBC0t6s3W4IbP20qAmY7 VzG/ZYaJu6CR9UYHS+6IiMChTWZJcdBSVRs7J5pcz4LIjZ+Cx9t1Li7sA3NVpGAL Jp4hl172g6u/wHb9v6MzwHxdRIJjUUKKdnyy6Umb9MrZsf899JKXrOLgsNFtiIA9 Stt3nSBnPa7RwRfPggQf074= Received: (qmail 56209 invoked by alias); 27 Feb 2019 19:44:46 -0000 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 Received: (qmail 55928 invoked by uid 89); 27 Feb 2019 19:44:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, KAM_NUMSUBJECT, KAM_STOCKGEN, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=string_cst, STRING_CST, H*c:sk:HMHPRHH, const_rtx X-HELO: EUR02-HE1-obe.outbound.protection.outlook.com Received: from mail-oln040092068013.outbound.protection.outlook.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (40.92.68.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Feb 2019 19:44:43 +0000 Received: from VE1EUR02FT052.eop-EUR02.prod.protection.outlook.com (10.152.12.53) by VE1EUR02HT010.eop-EUR02.prod.protection.outlook.com (10.152.12.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10; Wed, 27 Feb 2019 19:44:40 +0000 Received: from AM6PR07MB4037.eurprd07.prod.outlook.com (10.152.12.55) by VE1EUR02FT052.mail.protection.outlook.com (10.152.13.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.21 via Frontend Transport; Wed, 27 Feb 2019 19:44:40 +0000 Received: from AM6PR07MB4037.eurprd07.prod.outlook.com ([fe80::2929:d3a3:182e:4219]) by AM6PR07MB4037.eurprd07.prod.outlook.com ([fe80::2929:d3a3:182e:4219%2]) with mapi id 15.20.1665.012; Wed, 27 Feb 2019 19:44:40 +0000 From: Bernd Edlinger To: "gcc-patches@gcc.gnu.org" , Jakub Jelinek , Richard Sandiford Subject: [PATCH] Fix PR rtl-optimization/89490 Date: Wed, 27 Feb 2019 19:44:40 +0000 Message-ID: x-microsoft-original-message-id: <52afe819-ac03-8270-b08c-429a0cebe3f6@hotmail.de> MIME-Version: 1.0 Hi! This patch fixes a P1 regression due to the recently introduced more aggressive constant string merging, which does not work correctly in object blocks consisting of STRING_CST w/o proper zero-termination. Fixed by avoiding creation of block objects for objects located in mergeable sections. Bootstrapped and reg-tested on x86_64-pc-linux-gnu, powerpc64le-linux, and powerpc64-linux (-m32/-m64) with help from Jakub. Is it OK for trunk? Thanks Bernd. 2019-02-27 Bernd Edlinger PR rtl-optimization/89490 * varasm.c (get_block_for_section): Bail out for mergeable sections. (default_use_anchors_for_symbol_p, output_object_block): Assert the block section is not mergeable. --- gcc/varasm.c.orig 2019-02-21 23:50:24.000000000 +0100 +++ gcc/varasm.c 2019-02-27 11:33:32.741967812 +0100 @@ -363,7 +363,11 @@ use_object_blocks_p (void) /* Return the object_block structure for section SECT. Create a new structure if we haven't created one already. Return null if SECT - itself is null. */ + itself is null. Return also null for mergeable sections since + section anchors can't be used in mergeable sections anyway, + because the linker might move objects around, and using the + object blocks infrastructure in that case is both a waste and a + maintenance burden. */ static struct object_block * get_block_for_section (section *sect) @@ -373,6 +377,9 @@ get_block_for_section (section *sect) if (sect == NULL) return NULL; + if (sect->common.flags & SECTION_MERGE) + return NULL; + object_block **slot = object_block_htab->find_slot_with_hash (sect, hash_section (sect), INSERT); @@ -7014,14 +7021,13 @@ default_asm_output_anchor (rtx symbol) bool default_use_anchors_for_symbol_p (const_rtx symbol) { - section *sect; tree decl; + section *sect = SYMBOL_REF_BLOCK (symbol)->sect; - /* Don't use anchors for mergeable sections. The linker might move - the objects around. */ - sect = SYMBOL_REF_BLOCK (symbol)->sect; - if (sect->common.flags & SECTION_MERGE) - return false; + /* This function should only be called with non-zero SYMBOL_REF_BLOCK, + furthermore get_block_for_section should not create object blocks + for mergeable sections. */ + gcc_checking_assert (sect && !(sect->common.flags & SECTION_MERGE)); /* Don't use anchors for small data sections. The small data register acts as an anchor for such sections. */ @@ -7630,6 +7636,7 @@ output_object_block (struct object_block else switch_to_section (block->sect); + gcc_checking_assert (!(block->sect->common.flags & SECTION_MERGE)); assemble_align (block->alignment); /* Define the values of all anchors relative to the current section