From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id C0C8D3858CDB for ; Wed, 24 May 2023 12:39:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C0C8D3858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-3f42d937d2eso7526065e9.2 for ; Wed, 24 May 2023 05:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1684931955; x=1687523955; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=NNMSHIdybkmQDHPyS4ZgBu2O2/fut1mscn+eqa3ui84=; b=JI2V3Y1C56dbbYzHvtO2XKRODkD6dU1Utuo2Lgkhc1OgKU96xFBZU4gtRKSNXHTxeX 8Feh/DpiVMbeAvwHAOCFzMgmtqcmrzCYmkhM/ICkOU41u3EBUTxHMrH2HFpvFYigLZH3 i6OIlTWOwIhYd1kB0pT91rrNE85hnZ5IH3jg20RVsi4QrzvNsbdVJdnHqsWKx6I/0w8f 7tfEjyWdd3QHf/Jrj6LJF+ZyEm58ZK65X732Fs66Jm1q8SU+AkdWGGPL9fPera8QUnKj MVI44kIaL223KGPxbhSveBqSVfikM4tdfApGLbPJWU36YIEXDG7w6ebbTg+Ca6K+EHsg lF/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684931955; x=1687523955; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NNMSHIdybkmQDHPyS4ZgBu2O2/fut1mscn+eqa3ui84=; b=gHVgLTE3nAe8ewEjPHSSfxTXr8VHJf03HN2jdx94Q8xNi38sC/pqakrpfOn4Ye9LGk zrnZncfgvGk6LI6jrM1UQQ0gf9clOGJUzch1U9P92E7zx+xftK0d4FB/jZe9k3cMj3L0 zLwhwuYh7V12pxoA/g1L8B8epSx/gSrxeAS10uqeqTJDfeq1B7+SxlFWWbj1dm62Uter wdDaErqgjGiUlWkfhwdgfK7SspEkt9Y3v+wrWNsi+TeCpAiCD9UavFtIT6RN+7PLEXR/ CGTxsxnRAegq696zgK+3obdlNhQoth5rXOAD3gAy11QXBQsEz2bY02TCC++1ogF0E555 lXGw== X-Gm-Message-State: AC+VfDyfjHlve/uW31CZrh8Bfv3Iw30zOIxjANPJvX/npgwvSwTp1Xm8 PwK8ejb/u7DaZcWlV+OUCA7KadqmopYKWFe/lDNADg== X-Google-Smtp-Source: ACHHUZ4Vcuw6iXP3EMTmFDIHrXobG2kR0R+UwPvvtTGd4EjGZqcKZPKsYO2DKq7s1u1ykvCMuOQhvA== X-Received: by 2002:a7b:c4d3:0:b0:3f6:e73:ef1d with SMTP id g19-20020a7bc4d3000000b003f60e73ef1dmr3252206wmk.18.1684931955402; Wed, 24 May 2023 05:39:15 -0700 (PDT) Received: from fomalhaut.localnet ([2a01:e0a:8d5:d990:e654:e8ff:fe8f:2ce6]) by smtp.gmail.com with ESMTPSA id a2-20020a5d53c2000000b002ffbf2213d4sm14534257wrw.75.2023.05.24.05.39.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 05:39:15 -0700 (PDT) From: Eric Botcazou X-Google-Original-From: Eric Botcazou To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix artificial overflow during GENERIC folding Date: Wed, 24 May 2023 14:39:14 +0200 Message-ID: <8263171.NyiUUSuA9g@fomalhaut> In-Reply-To: References: <2883909.e9J7NaK4W3@fomalhaut> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: > I don't like littering the patterns with this and it's likely far from the > only cases we have? Maybe, but that's the only problematic case we have in Ada. It occurs only on mainline because we have streamlined address calculations there, from out-of- line to inline expansion, i.e. from run time to compile time. > Since we did move some of the patterns from fold-const.cc to match.pd and > the frontends might be interested in TREE_OVERFLOW (otherwise we'd just > scrap that!) I'm not sure removing the flag is good (and I never was really > convinced the setting for the implementation defined behavior on conversion > to unsigned is good). Yes, the Ada front-end relies on the TREE_OVERFLOW flag to detect overflows at compile time, so it cannot be removed, but it must be set correctly, which is not the case here: (T)p - (T) (p + 4) where T is signed should just yield -4. > Am I correct that the user writing such a conversion in Ada _should_ > get a constraint violation? So it's just the middle-end introducing it > to avoid undefined signed overflow that's on error? Yes, it's a Constraint_Error in Ada to convert a value of an unsigned type to a signed type if it does not fit in the signed type. > I'll also note that fold_convert_const_int_from_int shouldn't set > TREE_OVERFLOW on unsigned destination types? So it's the > outer conversion back to signed that generates the TREE_OVERFLOW? Yes, 4 is converted to unsigned, then negated, yielding a huge number, and the final conversion back to signed yields -4 with TREE_OVERFLOW set. > Would it help to use a (view_convert ...) here? For non-constants that > should be folded back to a sign changing (convert ...) but the constant > folding should hopefully happen earlier? But it's again implementation > defined behavior we have here, so not sure we need TREE_OVERFLOW at all. I'm not sure we need to jump through too many hoops here: the intermediate conversion trick is a kludge because we lack a proper method to selectively disable undefined overflow at run time, but that's not the case at compile time where we have a finer-grained control (and even different rules) so I don't really see a problem with handling the two cases differently. -- Eric Botcazou