From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71622 invoked by alias); 17 Apr 2015 15:32:36 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 71608 invoked by uid 89); 17 Apr 2015 15:32:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 17 Apr 2015 15:32:33 +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 t3HFWT0l013529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 Apr 2015 11:32:29 -0400 Received: from localhost.localdomain (ovpn-113-81.phx2.redhat.com [10.3.113.81]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3HFWStH009571; Fri, 17 Apr 2015 11:32:29 -0400 Message-ID: <5531278C.3030409@redhat.com> Date: Fri, 17 Apr 2015 15:32:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jakub Jelinek , Richard Biener , Eric Botcazou CC: gcc-patches@gcc.gnu.org Subject: Re: Patch ping References: <20150417075933.GJ1725@tucnak.redhat.com> In-Reply-To: <20150417075933.GJ1725@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00894.txt.bz2 On 04/17/2015 01:59 AM, Jakub Jelinek wrote: > Hi! > > I'd like to ping > > PR target/65689 - P2 - http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00358.html > > patch (perhaps with the code[?] == ' ' -> ISSPACE (code[?]) changes or > strstr, as discussed in the following thread). > At this point of course for trunk only, and perhaps after a while for 5.2. For the comment in compute_maybe_allows, "This should be conservative" could be interpreted as setting both bits or setting neither bit. The code clearly does the former and with the background from reading the patch thread I know why, but someone reading the code may not get it without having to either look in the archives or follow how it gets used. Consider updating the comment. I'd tend to prefer strstr; I don't think this is performance sensitive code. OK for the trunk with the comment fixed and your call on how to handle the whitespace issues. jeff