From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 778613858D37 for ; Tue, 23 May 2023 06:05:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 778613858D37 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-x132.google.com with SMTP id 2adb3069b0e04-4f3b5881734so3852721e87.0 for ; Mon, 22 May 2023 23:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684821913; x=1687413913; 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=c6bV8ECp2sFQJMW5twJD12YfINjYjt1o4RgEezcKFRc=; b=dHiUs/ZlT1eqGchlHdlsVAUfsC1GkGL7UBcs8LlQSdKYc4zvr1OIM/J8F4eE+vi7+O 1SkZzPJ47dUePgok0ZkmLXd2U13eaJL6QHwprf0tOnMKLyT00WdMpW96N9uhq3NfjcQP /MYl+tLaDmITxasBTyc7iTa6UBQxI+3A6GWH3p8zGQIywqKoEnYIGq9qj3865UOD74em qiYA0gG1clnGmeOhxevkQQaEup1jW3T8LcnnPeJO4ETbM37lFrpGJj1Pz9/zIYxmyce8 2jPWvd75JlvZvE0vI6x0/SqXHMTKjg7IXVyg8X6YD6oGLIiecriDh1lHVRgljbiaHDMA De8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684821913; x=1687413913; 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=c6bV8ECp2sFQJMW5twJD12YfINjYjt1o4RgEezcKFRc=; b=VPe2TxnKDVaSxd3XU1pcyGB1Kx3ZxY5JursCQE5PxJh7YFo9T8OuqWbsNYphkmLeoB gwNiQNfrMg9iDQX4Ix1/hQGpo1Z5dkh7pvflt1If/tfFvn148xWQvdhNobLUXflBxC36 qLo2JxUskB+xPopiGYBFkKTQTXMN0ouL4YkTIZKFUETsTYPl/3qi+piXP7PNQOjL1iWh EMxTl2IJIekFqOdqjrZBH1IRoImpKAZ2L2kYR0EPu9YqXKqbmyS0trHiU+dzm5aHZYjb mTR9aQ/LQXKHjUeDA63Q9KKQT8nHf2MvNFMMdsxf6nJcROxZvEJuIJ2tu9M9rqoEl6pS IAkA== X-Gm-Message-State: AC+VfDyg1HABmcr75W9AQNhygBCko1ENN/Ueqd/E5Jc3QO4OUy9joVc8 v9ZAfki6Mfk7orse0ox9SLi9K3QD7NNERXfvTuCAeGKH X-Google-Smtp-Source: ACHHUZ5B1iXGZLfdHyxASclIlWXc23hwmxy2mu8wVxQwgtmJcTD4XlNq2RqDz6nVtqw/g5H8L2YTjMkFzjg8X2+eT6k= X-Received: by 2002:a2e:8092:0:b0:2ac:7973:6751 with SMTP id i18-20020a2e8092000000b002ac79736751mr4938053ljg.32.1684821912641; Mon, 22 May 2023 23:05:12 -0700 (PDT) MIME-Version: 1.0 References: <20230518210331.11564-1-amonakov@ispras.ru> In-Reply-To: From: Richard Biener Date: Tue, 23 May 2023 08:05:00 +0200 Message-ID: Subject: Re: [PATCH] c-family: implement -ffp-contract=on To: Alexander Monakov Cc: Marek Polacek , Jason Merrill , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPAM_BODY,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, May 22, 2023 at 5:16=E2=80=AFPM Alexander Monakov wrote: > > > On Mon, 22 May 2023, Richard Biener wrote: > > > On Thu, May 18, 2023 at 11:04=E2=80=AFPM Alexander Monakov via Gcc-patc= hes > > wrote: > > > > > > Implement -ffp-contract=3Don for C and C++ without changing default > > > behavior (=3Doff for -std=3DcNN, =3Dfast for C++ and -std=3DgnuNN). > > > > The documentation changes mention the defaults are changed for > > standard modes, I suppose you want to remove that hunk. > > No, the current documentation is incomplete, and that hunk extends it > to match the current GCC behavior. Should I break it out to a separate > patch? I see this drive-by fix could look confusing =E2=80=94 sorry about= that. > > > it would be possible to do > > > > *expr_p =3D build_call_expr_internal (ifn, type, ops[0], ops[1]. ops[= 2]); > > return GS_OK; > > > > and not worry about temporary creation and gimplifying of the operands. > > That would in theory also leave the possibility to do this during > > genericization instead (and avoid the guard against late invocation of > > the hook). > > Ah, no, I deliberately decided against that, because that way we would go > via gimplify_arg, which would emit all side effects in *pre_p. That seems > wrong if arguments had side-effects that should go in *post_p. Ah, true - that warrants a comment though. Richard. > > Thanks. > Alexander > > > Otherwise it looks OK, but I'll let frontend maintainers have a chance = to look > > as well. > > > > Thanks for tackling this long-standing issue. > > Richard.