From patchwork Wed Jan 1 23:08:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 305988 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 770C42C00A3 for ; Thu, 2 Jan 2014 10:09:23 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=WEx499pUbmt6b9k+Z 4kSf4exmLxfOint+Tn/7JwLOyMlAfdL8fsOgFlrQ/ZXDkvrv4Wo2bQg2sUeCREXx CyO046U7vqGjniUtqJThWjOQXpn4DtpUMQW0BDRhkEXHa4YtLsH1OR7rfwlgaoQz Edsb9LmpaRVzC9NeaXBCqIBCvA= 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:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=2/1CoNn96jMBUteqF7WsS73 BxxM=; b=h0LWGI/BKleDia14XL6pt4KF14qmrFcv3dvEMPKqbZhSyNxVl3djKJI 0kVJ79V8qtumWQoTml5NqkM3h8NiOoUoqspq2KLgcNP9icj8ZO/7mWsqQTMTUvUQ p8oxP5GARwQU5S6CgSyUqYZ1njAlgs/UIyuVjEt8dKaaApAGV63g= Received: (qmail 31942 invoked by alias); 1 Jan 2014 23:09:17 -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 31925 invoked by uid 89); 1 Jan 2014 23:09:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Jan 2014 23:09:13 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s01N9AqA029677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jan 2014 18:09:10 -0500 Received: from tucnak.zalov.cz (vpn1-4-241.ams2.redhat.com [10.36.4.241]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s01N99W9007275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jan 2014 18:09:10 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.7/8.14.7) with ESMTP id s01N981x009231; Thu, 2 Jan 2014 00:09:08 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.7/8.14.7/Submit) id s01N8ubp009230; Thu, 2 Jan 2014 00:08:56 +0100 Date: Thu, 2 Jan 2014 00:08:56 +0100 From: Jakub Jelinek To: Mike Stump , Richard Biener , Laurynas Biveinis , Richard Sandiford Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] pch bug fix (take 2, PR pch/59436) Message-ID: <20140101230856.GO892@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20140101074631.GL892@tucnak.redhat.com> <20140101185348.GN892@tucnak.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140101185348.GN892@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes On Wed, Jan 01, 2014 at 07:53:48PM +0100, Jakub Jelinek wrote: > Without any gengtype.c changes, I wonder if just following change wouldn't > do it, gengtype considers only char and unsigned char pointers as strings > with the special strlen handling, all other scalar types are treated > differently it seems, and signed char aliases everything too. > > Or s/signed char/void/ in the patch is perhaps even better. I've bootstrapped/regtested this on x86_64-linux and i686-linux, and hopefully verified the problem from the PR is gone, by running over 610 successful PCH write + PCH read cycles as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436#c14 , no failures with the patch, while on a tree from yesterday without the patch I could reproduce it 17 times, on average every 22 iterations (from 2 to 81). Ok for trunk (and after a while for 4.8)? 2014-01-01 Mike Stump Jakub Jelinek PR pch/59436 * tree-core.h (struct tree_optimization_option): Change optabs type from unsigned char * to void *. * optabs.c (init_tree_optimization_optabs): Adjust TREE_OPTIMIZATION_OPTABS initialization. Jakub --- gcc/tree-core.h.jj 2013-12-11 10:11:06.000000000 +0100 +++ gcc/tree-core.h 2014-01-01 19:42:15.319869786 +0100 @@ -1550,7 +1550,7 @@ struct GTY(()) tree_optimization_option /* Target optabs for this set of optimization options. This is of type `struct target_optabs *'. */ - unsigned char *GTY ((atomic)) optabs; + void *GTY ((atomic)) optabs; /* The value of this_target_optabs against which the optabs above were generated. */ --- gcc/optabs.c.jj 2013-12-10 12:43:21.000000000 +0100 +++ gcc/optabs.c 2014-01-01 19:43:04.093620067 +0100 @@ -6245,7 +6245,7 @@ init_tree_optimization_optabs (tree optn /* If the optabs changed, record it. */ if (memcmp (tmp_optabs, this_target_optabs, sizeof (struct target_optabs))) - TREE_OPTIMIZATION_OPTABS (optnode) = (unsigned char *) tmp_optabs; + TREE_OPTIMIZATION_OPTABS (optnode) = (void *) tmp_optabs; else { TREE_OPTIMIZATION_OPTABS (optnode) = NULL;