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 BC74B385782B for ; Mon, 6 Nov 2023 10:44:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BC74B385782B 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 BC74B385782B 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=1699267499; cv=none; b=msiAv6tHxec8jbLjNWQMJLin8OJ+5bnHOTS3py6KsJytyVsJ49J6pxmTVrqCj/GuJ38bCiYU+NsMF7+ExTAKe+4EZYfQL80hVVc2veiRDTNOhp4f7J6X4W/fNz/XMlWR9CPJlEk7ktwedaspiPhVxstA4IjUYjEQ3D7cv03Hgtg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699267499; c=relaxed/simple; bh=eyc2n5tZ4OH+7nd2QxbbRwpLU8J1dZxNnpo66CM8TBg=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=thW5RLLJ6R8XFTx95jwPV63Rjcp8g1c5zX62Eo3rg7tFdP2gjcgq+ZzHmte/CwYUgXR96RGyMkTfdDjkwCMuW8HucxZee90ttcsUwh+pLbY1K/2nuuAje2x/eTZbE8UZEQTDG/rY/+F7MAyZzLagNtI+EeW1OEiZMWk0n/Y4tLo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699267497; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2QNdkUhcn4+j+7wu+g9oVymanz0+E9YvWyxPBAT84IM=; b=hRley31ZE6jJ/tKHgHoLPWVLflAhUPrw88JbMyWpUZhsLmf/sHHBuXtDbv+sBPB8iBXuqN DGeWpNwUKB2QROEK5K3dmS0bfqT9/26PwiEiJT4wo11Hfn2ibxfLdKTnUyEYtU31RTX+m7 x9vuRqiMFRIF2eW4XVgbTk5oDBX/JM0= Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-643-eb0-i6-WMLS7Gs7E3C6LzQ-1; Mon, 06 Nov 2023 05:44:55 -0500 X-MC-Unique: eb0-i6-WMLS7Gs7E3C6LzQ-1 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-5b0c27d504fso29733387b3.1 for ; Mon, 06 Nov 2023 02:44:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699267495; x=1699872295; 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=2QNdkUhcn4+j+7wu+g9oVymanz0+E9YvWyxPBAT84IM=; b=ljKlxvTpNyIN+K5RQ6ZjA009ALvYLLyuFQuNIsYT6MQG6OmTw/5Ifdx5O/ssZH6p37 xLaowbnygLZKdat9TBhUnIVQlAX4SUY8NTNlVGrjcUMCGvmZIEUVcSnVNwVLNI+vp0K+ cp4TcPcdKly1cbDfWmctsGZKV8rroUGI+UtCl/7aIvfPXiSonaPpTHY3oVTsGNy6+HF8 SpNPrE30Ssumjg4OOwhk3PsAFKO8/cz8wukIn5yTbNpZFaCPzm4rgSiqhcL4RwabJHYY 4lr3GQqR459iDK9XmZspAaaMceIUjrVKIPMPgdX1wQvrqX3AKGYLkBYDy1tRe8JZHA9G 1Dsw== X-Gm-Message-State: AOJu0YxKE+qDMaWQBHPrhEM/IhxmZGthNiKlLGpYTMN97xD3/HiSyOdu 0DwUqH1dPpzyhYxmP0vBEXILpIj3O2F2llAp1Fc/tzoonzmX6u1eazfVK4wxJE2ddh39u01/rit tvBcYpcdvd1urlkyN1gHGwVHrIH/R0vW6HA== X-Received: by 2002:a0d:cb11:0:b0:5a7:d4d7:aaa1 with SMTP id n17-20020a0dcb11000000b005a7d4d7aaa1mr7019535ywd.16.1699267495327; Mon, 06 Nov 2023 02:44:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IFV4SW1P7GYlqKBpUSRRvXnYbJ5UbyROjoaJ5b6AyWPJcGRjRuY/zI3GoUyJlcxKrWYr4qSnjhZlUg0G5Yh43M= X-Received: by 2002:a0d:cb11:0:b0:5a7:d4d7:aaa1 with SMTP id n17-20020a0dcb11000000b005a7d4d7aaa1mr7019525ywd.16.1699267495085; Mon, 06 Nov 2023 02:44:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Mon, 6 Nov 2023 10:44:44 +0000 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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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: On Fri, 3 Nov 2023 at 17:47, Weslley da Silva Pereira wrote: > > Hi Jonathan, > > I am sorry for the delay. The mailing lists libstdc++@gcc.gnu.org and gcc= -patches@gcc.gnu.org have just too many emails, so your email got lost. I h= ope my changes still make sense to be included in GCC. Please, find my comm= ents below. Hi, Thanks for the updated patch, test etc. Yes, I think this still makes sense and I'll take care of committing it. > > On Thu, May 11, 2023 at 3:57=E2=80=AFPM Jonathan Wakely wrote: >> >> >> >> On Mon, 27 Mar 2023 at 22:25, Weslley da Silva Pereira via Libstdc++ wrote: >>> >>> Dear all, >>> >>> Here follows a patch that removes implicit type casts in std::complex. >>> >>> *Description:* The current implementation of `complex<_Tp>` assumes tha= t >>> `int, double, long double` are explicitly convertible to `_Tp`. Moreove= r, >>> 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 usin= g >>> `const _Tp __pi_2 =3D 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. O= ne >>> example is the type `Eigen::Half` from >>> https://eigen.tuxfamily.org/dox-devel/Half_8h_source.html which does no= t >>> 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. > > > I agree with your proposal for the changelog. > >> >> 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 htt= ps://gcc.gnu.org/contribute.html#legal and https://gcc.gnu.org/dco.html for= more details. > > > Here is my DCO sign-off: > > Copyright: > Signed-off-by: Weslley da Silva Pereira > >> >> >>> >>> >>> *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 standar= d btw, only the floating-point types are required to work, but we can suppo= rt others as an extension). Without tests, we don't know if that goal has b= een met, and we don't know if the goal continues to be met in future versio= ns. A test would ensure that we don't accidentally re-introduce code requir= ing implicit conversions. >> >> With a suitable test, I think this patch will be OK for GCC 14. >> >> Thanks again for contributing. >> >> > > Tests: > See the attached file `test_complex_eigenhalf.cpp` > > Test results: > - When using x86-64 GCC (trunk), I obtained compilation errors as shown i= n the attached text file. Live example at: https://godbolt.org/z/oa9M34h8P. > - I observed no errors after applying the suggested patch on my machine. > - I tried it with the flag `-Wall`. No warnings were shown. > - My machine configuration and my GCC build information are displayed in = the file `config.log` generated by the configuration step of GCC. > > Let me know if I need to do anything else. > > Thanks, > Weslley > > -- > Weslley S. Pereira