From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) by sourceware.org (Postfix) with ESMTPS id 871CB3951831; Mon, 5 Oct 2020 16:36:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 871CB3951831 Received: by mail-qk1-x743.google.com with SMTP id z6so4138954qkz.4; Mon, 05 Oct 2020 09:36:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1Lla5TaLRSyNuZLSwz7ZtOp5bZrb2ng7J99g++wBFHA=; b=unpP5O3Px5N63m8g6uzOGUhP+m/udv7gfeaUK27JZ+TL0ysvcZHemk1Wjk53UWUuzJ ZptRflr7UTNf6BR9lXOnMDjHM1aYbu+MeBU1wpocUCD88DjbHVNpGRE99C56gskCnt8q NlbArvkO30sszNrXyUeUO3B0YJDGhpVaFWM8b1AGLkmNgxCEHpWUI57OgRVEdUxsn/O/ IPzeus4zbcSuy8coQt5EnCPFjA081Xn96G5MtnsN+I2gWH69sYvEdkDfT00pXFvnxSZ2 g6CMI5RgCqazrVvpO9RRsREKqDiTJUawcwxOPYcwpjxR0iMjq0Au0HF+XXeaIN6ZZj0C js2A== X-Gm-Message-State: AOAM531u6rqlLcpq0McUL/aEMnzB0WfGnTSr8Zel5DqD7RWE1lWYYjEP gh0EuGgahIeYq+PjCN6b9+bm3S4ERtE= X-Google-Smtp-Source: ABdhPJxIfoTbJCoXCbnweoq6bONL45Yl1R2MD9TB3IbWMY2C5o+0UGZmCEe+0E2CqUGUNCzvApvhOA== X-Received: by 2002:a37:9c06:: with SMTP id f6mr820126qke.197.1601915780560; Mon, 05 Oct 2020 09:36:20 -0700 (PDT) Received: from [192.168.0.41] (97-118-127-189.hlrn.qwest.net. [97.118.127.189]) by smtp.gmail.com with ESMTPSA id x126sm380455qka.91.2020.10.05.09.36.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2020 09:36:19 -0700 (PDT) Subject: [PING][PATCH] make handling of zero-length arrays in C++ pretty printer more robust (PR 97201) From: Martin Sebor To: gcc-patches , Jason Merrill , libstdc++ References: <26ef4aff-92f2-2ec9-7074-c78413ab9777@gmail.com> Message-ID: <6124c361-8e4b-8a96-68f9-0603e20f8f5e@gmail.com> Date: Mon, 5 Oct 2020 10:36:18 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <26ef4aff-92f2-2ec9-7074-c78413ab9777@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 16:36:23 -0000 Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554893.html On 9/25/20 12:58 PM, Martin Sebor wrote: > The C and C++ representations of zero-length arrays are different: > C uses a null upper bound of the type's domain while C++ uses > SIZE_MAX.  This makes the middle end logic more complicated (and > prone to mistakes) because it has to be prepared for both.  A recent > change to -Warray-bounds has the middle end create a zero-length > array to print in a warning message.  I forgot about this gotcha > and, as a result, when the warning triggers under these conditions > in C++, it causes an ICE in the C++ pretty printer that in turn > isn't prepared for the C form of the domain. > > In my mind, the "right fix" is to make the representation the same > between the front ends, but I'm certain that such a change would > cause more problems before it solved them.  Another solution might > be to provide APIs for creating (and querying) arrays and have them > call language hooks in cases where the representation might differ. > But that would likely be quite intrusive as well.  So with that in > mind, for the time being, the attached patch just continues to deal > with the difference by teaching the C++ pretty printer to also > recognize the C form of the zero-length domain. > > While testing the one line fix I noticed that -Warray-bounds (and > therefore, I assume also all other warnings that detect out of bounds > accesses to allocated objects) triggers only for the ordinary form of > operator new and not for the nothrow overload, for instance.  That's > because the ordinary form is recognized as a built-in which has > the alloc_size attribute attached to it.  But because the other forms > are neither built-in nor declared in with the same attribute, > the warning doesn't trigger.  So the patch also adds the attribute > to the declarations of these overloads in .  In addition, it > adds attribute malloc to a couple of overloads of the operator that > it's missing from. > > Tested on x86_64-linux. > > Martin