From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B409C3858D1E for ; Wed, 25 Oct 2023 13:58:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B409C3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B409C3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698242338; cv=none; b=oMl0I3Jsy2De7FqiK84nzz4Oiq5QEstc6qE4LxzLUyIgpURpuTbafdBKMIiXJhRorn0L5uc8NBTXB+GWvnUPRLFwp+YVLBwwkQN391v0mcTYpBHT7B2AyWMNlMKP5NBpKwj2IoKeJS9/hdfdwIjzPBRH5TGcYOiYnbMsCkaOB8w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698242338; c=relaxed/simple; bh=EBVWYUKwY218TMut/JUbat6LCRAbslMv0bRZFRC9eII=; h=DKIM-Signature:From:Date:To:Subject:Message-ID:MIME-Version; b=lOs3tknGq5ILxcFED83CCUXrVbiya6M/4Qw+xBtgEwjWf1XyJFxpdKtYGyedTBwIvDHjEcyH64qjG7E4cHpAT9uRe/Fm0+Pe8cdqor0RidpfHHXmDhe5vJw2vZxOHtWghKDjeWVs32PMcbNXAEiDvvfbzGy3U2ALVp2YvuDW1cU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698242336; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oCGGqVUH+JkvY+OI4b8WkEKMb2JwFm7vwwEbdZc+Kq0=; b=Wv91gVhjsC+rTJzEg4E2rvfH19RFLkJYAGRMS2XPGQX8zea40Q4AxWv7xaG/A+NrFhke8c w5tNSOjrjvCPL6OCKECs9nU+Y6ezwOCC8IOJ2AjV9fEiKX2TpRhrLWdZFojz4OQqXjeneA u0MIILxh1q15DrP9tcPySR3amBQ4rcQ= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-407-j8kyzgTdPaSTXDG21HmEQQ-1; Wed, 25 Oct 2023 09:58:53 -0400 X-MC-Unique: j8kyzgTdPaSTXDG21HmEQQ-1 Received: by mail-ua1-f69.google.com with SMTP id a1e0cc1a2514c-7b6c916cdd5so2930499241.3 for ; Wed, 25 Oct 2023 06:58:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698242333; x=1698847133; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dGmKgN80pCou2ioLSDcqDIv/wbYYWDi44brHU1ojnAY=; b=CXKu0Xfytg9ArbSfFYnapMJssSCVaOYkOohJdlhBmbweOVZsb1lMP5QJN4hWz2tbPz DnvLIqViMugUizn42nsD+mnWbruslUwOsQVM8LXPieyZEY3KVVg/o92z9XVQ6kzHEDiz c0dl9SHq5WKH8Z19WyymNMV3o0K98G3kBgy3S6ODlLrz5yDpl6rhXzYKPjLhlAPfBy97 ZTO+/xeiRhg3csrRy2i+qDM3LaRDruP0wwyj6ABnAjieTJMByuRqr0JErkL2wy7c94Od uP/plMtUCfrxCi52A1pO/9uBkw8tJigZxWqVRL9Lm4y1M4nYlmjh2L0UdImkSIjSmlj8 N9ZQ== X-Gm-Message-State: AOJu0YwfeBxUkzqbz0BuMwC1MCiAzHadOZ5WBhCz8UgLmu/2NUYoxE64 4B/Wq4e3dimrv3dF2Ruhp+zPeGjoHleBZLIDluhD8ycmxmbqv77FDICrRqvmoErDlhQCW9rrFOF lzIiEDvXay4+6Zm7qrg== X-Received: by 2002:a67:b242:0:b0:458:11dd:87aa with SMTP id s2-20020a67b242000000b0045811dd87aamr14880339vsh.22.1698242333333; Wed, 25 Oct 2023 06:58:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHsYHsv/SOPUW1gzN397HPAusoYtkk1gXzKaZL9dvRHIcg5tI9CKYHRR/qa2g3Zv+DHPj8cvg== X-Received: by 2002:a67:b242:0:b0:458:11dd:87aa with SMTP id s2-20020a67b242000000b0045811dd87aamr14880329vsh.22.1698242333053; Wed, 25 Oct 2023 06:58:53 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id dc6-20020a056214174600b006590d020260sm4429899qvb.98.2023.10.25.06.58.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Oct 2023 06:58:52 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Wed, 25 Oct 2023 09:58:51 -0400 (EDT) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: build_new_1 and non-dep array size [PR111929] In-Reply-To: Message-ID: References: <20231024170316.3919946-1-ppalka@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="8323329-1835901161-1698242332=:986507" X-Spam-Status: No, score=-13.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1835901161-1698242332=:986507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 24 Oct 2023, Jason Merrill wrote: > On 10/24/23 13:03, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > like the right approach? > > > > -- >8 -- > > > > This PR is another instance of NON_DEPENDENT_EXPR having acted as an > > "analysis barrier" for middle-end routines, and now that it's gone we > > may end up passing weird templated trees (that have a generic tree code) > > to the middle-end which leads to an ICE. In the testcase below the > > non-dependent array size 'var + 42' is expressed as an ordinary > > PLUS_EXPR, but whose operand types have different precisions -- long and > > int respectively -- naturally because templated trees encode only the > > syntactic form of an expression devoid of e.g. implicit conversions > > (typically). This type incoherency triggers a wide_int assert during > > the call to size_binop in build_new_1 which requires the operand types > > have the same precision. > > > > This patch fixes this by replacing our incremental folding of 'size' > > within build_new_1 with a single call to cp_fully_fold (which is a no-op > > in template context) once 'size' is fully built. > > This is OK, but we could probably also entirely skip a lot of the calculation > in a template, since we don't care about any values. Can we skip the entire > if (array_p) block? That seems to be safe correctness-wise, but QOI-wise it'd mean we'd no longer diagnose a too large array size ahead of time: template void f() { new int[__SIZE_MAX__ / sizeof(int)]; } : In function ‘void f()’: :3:37: error: size ‘(((sizetype)(18446744073709551615 / sizeof (int))) * 4)’ of array exceeds maximum object size ‘9223372036854775807’ (That we diagnose this ahead of time is thanks to the NON_DEPENDENT_EXPR removal; previously 'nelts' was wrapped in NON_DEPENDENT_EXPR which ironically prevented fold_non_dependent_expr from folding it to a constant...) > > > PR c++/111929 > > > > gcc/cp/ChangeLog: > > > > * init.cc (build_new_1): Use convert, build2, build3 instead of > > fold_convert, size_binop and fold_build3 when building 'size'. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/template/non-dependent28.C: New test. > > --- > > gcc/cp/init.cc | 9 +++++---- > > gcc/testsuite/g++.dg/template/non-dependent28.C | 6 ++++++ > > 2 files changed, 11 insertions(+), 4 deletions(-) > > create mode 100644 gcc/testsuite/g++.dg/template/non-dependent28.C > > > > diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc > > index d48bb16c7c5..56c1b5e9f5e 100644 > > --- a/gcc/cp/init.cc > > +++ b/gcc/cp/init.cc > > @@ -3261,7 +3261,7 @@ build_new_1 (vec **placement, tree type, > > tree nelts, > > max_outer_nelts = wi::udiv_trunc (max_size, inner_size); > > max_outer_nelts_tree = wide_int_to_tree (sizetype, max_outer_nelts); > > - size = size_binop (MULT_EXPR, size, fold_convert (sizetype, > > nelts)); > > + size = build2 (MULT_EXPR, sizetype, size, convert (sizetype, nelts)); > > if (TREE_CODE (cst_outer_nelts) == INTEGER_CST) > > { > > @@ -3344,7 +3344,7 @@ build_new_1 (vec **placement, tree type, > > tree nelts, > > /* Use a class-specific operator new. */ > > /* If a cookie is required, add some extra space. */ > > if (array_p && TYPE_VEC_NEW_USES_COOKIE (elt_type)) > > - size = size_binop (PLUS_EXPR, size, cookie_size); > > + size = build2 (PLUS_EXPR, sizetype, size, cookie_size); > > else > > { > > cookie_size = NULL_TREE; > > @@ -3358,8 +3358,8 @@ build_new_1 (vec **placement, tree type, > > tree nelts, > > if (cxx_dialect >= cxx11 && flag_exceptions) > > errval = throw_bad_array_new_length (); > > if (outer_nelts_check != NULL_TREE) > > - size = fold_build3 (COND_EXPR, sizetype, outer_nelts_check, > > - size, errval); > > + size = build3 (COND_EXPR, sizetype, outer_nelts_check, size, errval); > > + size = cp_fully_fold (size); > > /* Create the argument list. */ > > vec_safe_insert (*placement, 0, size); > > /* Do name-lookup to find the appropriate operator. */ > > @@ -3418,6 +3418,7 @@ build_new_1 (vec **placement, tree type, > > tree nelts, > > /* If size is zero e.g. due to type having zero size, try to > > preserve outer_nelts for constant expression evaluation > > purposes. */ > > + size = cp_fully_fold (size); > > if (integer_zerop (size) && outer_nelts) > > size = build2 (MULT_EXPR, TREE_TYPE (size), size, outer_nelts); > > diff --git a/gcc/testsuite/g++.dg/template/non-dependent28.C > > b/gcc/testsuite/g++.dg/template/non-dependent28.C > > new file mode 100644 > > index 00000000000..3e45154f61d > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/template/non-dependent28.C > > @@ -0,0 +1,6 @@ > > +// PR c++/111929 > > + > > +template > > +void f(long var) { > > + new int[var + 42]; > > +} > > --8323329-1835901161-1698242332=:986507--