From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) by sourceware.org (Postfix) with ESMTPS id B54493858D20; Sun, 26 Nov 2023 01:49:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B54493858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B54493858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::a33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700963386; cv=none; b=Ct7uklpFK7cT/pU+JSlLeP841RxD8RzxgNVloeH9KibJ3drNM3RixlKaipWEHBxh7fXSp3zXXnQvQK7fqFwC7s3saKtSnxuePEIUC0GR6y6f4lNeEyRxe54GLuG21Jivuuw/JDcR8dVaDlZHIvESbwpNVjj9XA2h33ZyOzuKEqA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700963386; c=relaxed/simple; bh=6oIRfYSdH0SEW2dNRujxoiM4ywh49+2OxJ64UI3gZAs=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=PO7fQVoMvl0tebBcwp8HBuPGbJIkO6wPEyf1+rzwn4t8Kptp96zMHwAmEkF6E4ZcvpNP8wrnRsVo7/dB0DYCFe0Bn6yHItyV2/+X6NrWgBo3cdMSolSF28OgA5e11t93U67ZlK67sR2WrTsVB/uGYnbkKpMnLe6QaOfGVSxzMbw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-4ac2e8911e4so169541e0c.0; Sat, 25 Nov 2023 17:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700963382; x=1701568182; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iwLZ/G/QKK4COBbdAArtPwoyhwNiConiylRwrlwfdwY=; b=aL1ntNicfqTgQgnrZHeM1AYeGQA4d8J5tcXY0b6imekeomF+OHboL7TdXLVjFGrLCl xsbJiC3XnEZwW/mNnxmL8yVdQacXRPVVFu2QJTaCLDTJJjxxJ3yR1Dj2oK2i33p3iad0 tbkA9/O4MWwQ7HSRrTXS1hziyboSmCncmYVGp3anXi8RmN6CePiitXGeIgjZi5fO/bdf X53jGbZMo0jd9o050ZGZZUgOb5pBtHgHenlQ6j1eo9SQEiSm04wOQksXH+ybWqPnyVMp RJ6qpvBRsl2VZvndutPCUktKGJsvA6aseIkmv7ki3HVPAvfdfVKxcRwjfCT6p9cYXf1B nOsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700963382; x=1701568182; 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=iwLZ/G/QKK4COBbdAArtPwoyhwNiConiylRwrlwfdwY=; b=LBphEdR5h5zZeMFhAb2vnhuK+vfh2R9mdxpINCUFv6q3uvqGRlAgfdDhauMaDgA1U4 S6+DbJve9KuemLj3WBJloWwzJExRwPMLvhvnfDGE5bgT4TukMvGvbbh8tPMWEj57MmLp Fts3wVetClCMjE2+KQBkOP+8rr0VwOe5J2AbDUDxMcyTqwrym3vJWu3kVVrwf1/214qW QpTTaBIxDeH5VOotqb7tzCc9VgQmOstc+TluW/OE9gItD+0gNw2tl+8C7oe79FPOjlvB ET6LledZ5CCr4cf5WHbRLdU5MQLGpGjuVjuWQ4GHwhzKeBo1jo4rRoFGJZ0/A57Y5uiR lhCg== X-Gm-Message-State: AOJu0YwQdJeIIjuPq46kefzNQ6AKJPTIn2JmxOeU95t/hMaEFDGZukbI SVn4RCjiQ+mbqT4C1fT8iVTyk27XkFa1WEbxR7k= X-Google-Smtp-Source: AGHT+IFlkCMgXYXyDku87BZL6ZcoDNrzUFNNJlqFG5N+3u9GEtDnMNXTesbLX4hNqHpjcmjtxYqzYsPUIHAXlf+gC3A= X-Received: by 2002:a05:6122:2207:b0:4b0:238e:e5d3 with SMTP id bb7-20020a056122220700b004b0238ee5d3mr6500146vkb.0.1700963381807; Sat, 25 Nov 2023 17:49:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Weslley da Silva Pereira Date: Sat, 25 Nov 2023 18:49:30 -0700 Message-ID: Subject: Re: [PATCH] libstdc++/complex: Remove implicit type casts in complex To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000260e3b060b0466f9" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,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: --000000000000260e3b060b0466f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan, Is there a way I can see my patch merged (when it gets merged)? Particularly, I want to have a link for the commit. I would like to add this as "impact on third party software" for the software https://github.com/tlapack/tlapack. Thanks, Weslley On Mon, Nov 6, 2023 at 3:44=E2=80=AFAM Jonathan Wakely = wrote: > 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 hope my changes still make sense to be included in GCC. Please, > find my comments 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++ < > 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 =3D 1.5707963267948966192313216916397514L`. > >>> > >>> This patch transforms the implicit casts (1) and (2) into explicit ty= pe > >>> 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. > > > > > > 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 > https://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 resul= ts > >>> here since this is really a small upgrade (in my view) to std::comple= x. > >> > >> > >> 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. > >> > >> > > > > Tests: > > See the attached file `test_complex_eigenhalf.cpp` > > > > Test results: > > - When using x86-64 GCC (trunk), I obtained compilation errors as shown > in 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 > > --=20 Weslley S. Pereira --000000000000260e3b060b0466f9--