From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47010 invoked by alias); 12 Aug 2019 23:47:26 -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 46952 invoked by uid 89); 12 Aug 2019 23:47:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=accident 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; Mon, 12 Aug 2019 23:47:24 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F105C8E58C; Mon, 12 Aug 2019 23:47:22 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-27.rdu2.redhat.com [10.10.112.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id D95C27D4D4; Mon, 12 Aug 2019 23:47:21 +0000 (UTC) Subject: Re: [PATCH] fold more string comparison with known result (PR 90879) To: Martin Sebor , Jakub Jelinek Cc: gcc-patches References: <223e6275-98b9-f46d-a5c0-4ea802a68aaf@gmail.com> <20190809162257.GB2726@tucnak> <80cf0a28-35c9-d57f-729a-d1cf58bd21d1@gmail.com> <20190809165803.GC2726@tucnak> <0e9e9034-3357-6d8e-d38d-35c38bdb2882@gmail.com> <2d95fa01-9e69-26e5-4634-b9906976d8f4@gmail.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: Date: Tue, 13 Aug 2019 02:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <2d95fa01-9e69-26e5-4634-b9906976d8f4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00789.txt.bz2 On 8/12/19 4:17 PM, Martin Sebor wrote: > On 8/12/19 2:04 PM, Jeff Law wrote: >> On 8/9/19 4:14 PM, Martin Sebor wrote: >>> On 8/9/19 10:58 AM, Jakub Jelinek wrote: >>>> On Fri, Aug 09, 2019 at 10:51:09AM -0600, Martin Sebor wrote: >>>>> That said, we should change this code one way or the other. >>>>> There is even less of a guarantee that other compilers support >>>>> writing past the end of arrays that have non-zero size than >>>>> that they recognize the documented zero-length extension. >>>> >>>> We use that everywhere forever, so no. >>> >>> Just because some invalid code has been in place "forever" doesn't >>> mean it cannot be changed.  Relying on undocumented "extensions" >>> because they just happen to work with the compilers they have been >>> exposed to is exactly how naive users get in trouble.  Our answer >>> to reports of "bugs" when the behavior changes is typically: fix >>> your code.  There's little reason to expect other compiler writers >>> to be any more accommodating. >>> >>>> See e.g. rtx u.fld and u.hwint arrays, tree_exp operands array, >>>> gimple_statement_with_ops op array just to name a few that are >>>> everywhere.  Coverity is indeed unhappy about >>>> that, but it would be with [0] certainly too.  Another option is >>>> to use maximum possible size where we know it (which is the case of >>>> rtxes and most tree expressions and gimple stmts, but not e.g. >>>> CALL_EXPR or GIMPLE_CALL where there is no easy upper bound. >>> >>> The solution introduced in C99 is a flexible array.  C++ >>> compilers usually support it as well.  Those that don't are >>> likely to support the zero-length array (even Visual C++ does). >>> If there's a chance that some don't support either do you really >>> think it's safe to assume they will do something sane with >>> the [1] hack?  If you're concerned that the flexible array syntax >>> or the zero length array won't compile, add a configure test to >>> see if it does and use whatever alternative is most appropriate. >> Given that we require a C++03 compiler to build GCC, I think we can >> revisit how we represent the trailing array.  But that seems independent >> of the bulk of this patch. >> >> Can we separate this issue from the rest of the patch? > > The updated patch I posted is independent of the trailing > [1] array hack: > >   https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html I must have dropped this from my queue by accident. I'll go find it and give it a looksie as well. jeff