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 4CA2A3856968 for ; Thu, 11 May 2023 21:57:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CA2A3856968 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683842256; 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=T7BScoLN7/hXS9GFSKZYT7F09WloBX6udZ5vJt7xcn8=; b=ciR6570deTm219fCMxrN1S7LUqMZVmGtjoeESHrBFOGYum3LAIs5QALFpvI6RqcHKIRpuP vaZF4oKKs83Rvx3AbrzlQtvtFbaahhN752HSIfLPqKIuqFTR177VlLMU/MGvOD9XsdkJN8 jqUScPRmUFq13b6BCV2TCU4H8xaOoYE= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-657-X3JK7LfGPQ-mjGONEMCDpw-1; Thu, 11 May 2023 17:57:35 -0400 X-MC-Unique: X3JK7LfGPQ-mjGONEMCDpw-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2ac82617bc9so42197141fa.0 for ; Thu, 11 May 2023 14:57:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683842253; x=1686434253; h=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=T7BScoLN7/hXS9GFSKZYT7F09WloBX6udZ5vJt7xcn8=; b=S7+/VXbiFJJ4cpSqQMFFhPri8EOELmBkxXSy2i0e8aq6dfKaMdfpxFauO1D2ro3SJy 7tIeco8W3vKad9C5fn0gtmW9CxRIBZqpqJK+j8GfbUARyixur4BzxoUqJUeAeYaICqWJ sFfLe+/wWq1w2yAKzS1j2YW9Z8h2O1xNmLNHvbwW6hN2NfE64WVSNrtsbgZ4cWUu0QCl yr1nbTsFICZ6aKvEeMSzfh4OTMxmKp3fKdLq0qL4VNkTjHsV1PguwaDikFwhbb7pUgRg VjFEchwGQ4wCGdfrWoePxzLrt0A8giSl3PIUODjrgcmq3QlXk+j6ZBIPZXgUVgglqTOp ztIg== X-Gm-Message-State: AC+VfDy9GqXAldmEgBrWpwD9VL0jYjIRlIisrYsPV5uTJzFAIoBanrl+ b5fi5ufy1Bbkb+xo/ykS3xd3T7jo3u/B/zxcZJnMyfOwemWRSmjY8Ppu2jpnqZorYmeC2IAM2RD YiJnCLQCoDwMSciHBJpq6uLyox4R/18m5LA== X-Received: by 2002:a2e:9819:0:b0:2aa:41a1:cd70 with SMTP id a25-20020a2e9819000000b002aa41a1cd70mr3553860ljj.3.1683842253590; Thu, 11 May 2023 14:57:33 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5HsevgPUVkiqYN0NgRzOLzC516hr5N2pvjNZYu0SE+/d0uTa2Gp5TsR9QOkenzjO1162DL3GshOQbrWKMmyJM= X-Received: by 2002:a2e:9819:0:b0:2aa:41a1:cd70 with SMTP id a25-20020a2e9819000000b002aa41a1cd70mr3553856ljj.3.1683842253180; Thu, 11 May 2023 14:57:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Thu, 11 May 2023 22:57:21 +0100 Message-ID: Subject: Re: [PATCH] libstdc++/complex: Remove implicit type casts in complex To: Weslley da Silva Pereira Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="0000000000005befe605fb721387" X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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: --0000000000005befe605fb721387 Content-Type: text/plain; charset="UTF-8" On Mon, 27 Mar 2023 at 22:25, Weslley da Silva Pereira via Libstdc++ < libstdc++@gcc.gnu.org> wrote: > Dear all, > > Here follows a patch that removes implicit type casts in std::complex. > > *Description:* The current implementation of `complex<_Tp>` assumes that > `int, double, long double` are explicitly convertible to `_Tp`. Moreover, > it also assumes that: > > 1. `int` is implicitly convertible to `_Tp`, e.g., when using > `complex<_Tp>(1)`. > 2. `long double` can be attributed to a `_Tp` variable, e.g., when using > `const _Tp __pi_2 = 1.5707963267948966192313216916397514L`. > > This patch transforms the implicit casts (1) and (2) into explicit type > casts. As a result, `std::complex` is now able to support more types. One > example is the type `Eigen::Half` from > https://eigen.tuxfamily.org/dox-devel/Half_8h_source.html which does not > implement implicit type conversions. > > *ChangeLog:* > libstdc++-v3/ChangeLog: > > * include/std/complex: > Thank you for the patch. Now that we're in developement stage 1 for GCC 14, it's time to consider it. You're missing a proper changelog entry, I suggest: * include/std/complex (polar, __complex_sqrt) (__complex_pow_unsigned, pow, __complex_acos): Replace implicit conversions from int and long double to value_type. You're also missing either a copyright assignment on file with the FSF (unless you've completed that paperwork?), or a DCO sign-off. Please see https://gcc.gnu.org/contribute.html#legal and https://gcc.gnu.org/dco.html for more details. > > *Patch:* fix_complex.diff. (Also at > https://github.com/gcc-mirror/gcc/pull/84) > > *OBS:* I didn't find a good reason for adding new tests or test results > here since this is really a small upgrade (in my view) to std::complex. > I don't agree. The purpose of this is to support std::complex for a type Foo without implicit conversions (which isn't required by the standard btw, only the floating-point types are required to work, but we can support others as an extension). Without tests, we don't know if that goal has been met, and we don't know if the goal continues to be met in future versions. A test would ensure that we don't accidentally re-introduce code requiring implicit conversions. With a suitable test, I think this patch will be OK for GCC 14. Thanks again for contributing. --0000000000005befe605fb721387--