From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 8C0D33858C54 for ; Wed, 24 May 2023 13:11:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8C0D33858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4f24d8440c9so906853e87.1 for ; Wed, 24 May 2023 06:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684933898; x=1687525898; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=P5muqfOBWXv4C6K58WnB7vUwe1WkYmoOYrDhtVFg//I=; b=jQBL2jpeE5x9uREgHK0sX72DXjiY8yMo4KCSG4fqde1QWyB4G6A3OrnjyA0MI4hXC9 IAbdrHUdmGRVNgexy8p0qzF24jAfXjCNsv/8NODmOHCCZ++eClAEniHOSZqPYXsuFQSq h6gMaJ4aPcDBVveVqPBxZPzaE0FDazacigi7Ngm8wSQaSZ1cdJXr8yv5jY0SrublVneu QmgUCudk+eZrL6cTAXzgp/iP8WSUbbc7l8fCU54GpSdYi9OQLJKd6j+3KLwfsaTqGT0K LKjaMx8yebpBwwhbWuSZALtq5GCz9Ue0xFx2uUi2wVPdN9lDoo84s9sg3PmsW9d5de2Y CI6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684933898; x=1687525898; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=P5muqfOBWXv4C6K58WnB7vUwe1WkYmoOYrDhtVFg//I=; b=YmIRd5xULB5FwenVaE54P9qTAmkfEkLac2M7Wo7hRIZKRtMpQaBniunS/EZD8oMsba zkYttNYw6FCl/H4OIv1mC97CYuSBZ6bp2cZfm6/F8gBh0vMd5wVZS2/JaFOPYOAS696N +L3CKlq2tSh0kcof+18G+P+5oC+Aih7ojPebGLKTtTjW/D2HEWv2UT2zLxg0SwwobLTd eAOHNLkvBzX80TD3z+GbnmT2F6b/0/R/8LMaUMIGJdjsqsNFWGvyGPhB8b/P72Mm3+VJ NUAg6vIL+2nhkLMe0ka3t/tSWxvtTC1egSQYN65l1XjrA/HI2TNhrtIjYL/VyAfnWEBL jMNQ== X-Gm-Message-State: AC+VfDxSstc30dgwdJSLFsFg03wxiiuG/5vlqNK224Gdvh+qnmWBFvP4 aNP5BshE4BUCkX4fuEGo+epQeFARiDh42pUuM6c= X-Google-Smtp-Source: ACHHUZ5/6gYpySFGThTkS/a/tGpkHO0Zq2UNJbyD1oH+SOg671B3X2idTTg+LYshXO8QPYq3At03WbTblN/z6a4xnf4= X-Received: by 2002:a05:6512:304b:b0:4eb:412f:9e0e with SMTP id b11-20020a056512304b00b004eb412f9e0emr6698693lfb.26.1684933897558; Wed, 24 May 2023 06:11:37 -0700 (PDT) MIME-Version: 1.0 References: <2883909.e9J7NaK4W3@fomalhaut> <8263171.NyiUUSuA9g@fomalhaut> In-Reply-To: <8263171.NyiUUSuA9g@fomalhaut> From: Richard Biener Date: Wed, 24 May 2023 15:09:31 +0200 Message-ID: Subject: Re: [PATCH] Fix artificial overflow during GENERIC folding To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: On Wed, May 24, 2023 at 2:39=E2=80=AFPM Eric Botcazou wrote: > > > 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 on= ly 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 a= nd > > 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 re= ally > > convinced the setting for the implementation defined behavior on conver= sion > > to unsigned is good). > > Yes, the Ada front-end relies on the TREE_OVERFLOW flag to detect overflo= ws at > compile time, so it cannot be removed, but it must be set correctly, whic= h 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 typ= e 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, an= d 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 intermediat= e > conversion trick is a kludge because we lack a proper method to selective= ly > disable undefined overflow at run time, but that's not the case at compil= e > 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. But nobody is going to understand why the INTEGER_CST case goes the other way. As you say we don't have a good way to say we're doing this to avoid undefined behavior, but then a view-convert back would be a good way to indicate that? I can't come up with a better name for a custom operator we could also use, (convert_without_overflow (negate (convert:utype @1)))) maybe? As said, if view_convert works I prefer that. Does it? Richard. > > -- > Eric Botcazou > >