From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 481403948446 for ; Thu, 12 Aug 2021 14:09:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 481403948446 Received: by mail-wm1-x333.google.com with SMTP id i10-20020a05600c354ab029025a0f317abfso7243617wmq.3 for ; Thu, 12 Aug 2021 07:09:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=XqlGlrdWfMyaGuSgqe65q5+3Wsmatd9DII+Ji4RuDXI=; b=kBe/7/lSWyclFqGRclhSey/Jb+vfztHGtKrgeHV5+Z/qIPx6NLhXsigBf2lKp/Oa5N ScISgdykvlOSrGfkC+EplB08spy3Vwtvm0ys45Vyfzn0NuKLsVw6UPLDOGObwxFajMJV f7RpBkRgLmq9l7coVUTitauQs37FvJcLw/O3e4pOaGduFCxuWYbmN4CzCGppbZaAtyr0 HdSRxhuvDD8kiNh2tKOSVU5SMGPO0cWO4hJK1Zgi7QLQjnVsucSVL7pMnOx1ncZZBb0B 5iTxAaUH4p2qIiM+igIuAzL4MXnqZoWf4f2z6Y7yoVzrrqiFq5sps13XDTg4CcIZs85o 6xWQ== X-Gm-Message-State: AOAM53018SRY0zOmRTBMq6l8AEy3B23rVY4/48u0QXsenfKq+bnosJk9 He1bHZgn/CdjbYLgEcl+AXJylyYPZPI= X-Google-Smtp-Source: ABdhPJzsEJoyaypVnG6ej8Jwo8S9+xB3XDGAL7WYh5OPBT2EEXa77A7dIW/6VPq8yGIIUTP/K+ucLg== X-Received: by 2002:a1c:4c06:: with SMTP id z6mr15367379wmf.53.1628777383124; Thu, 12 Aug 2021 07:09:43 -0700 (PDT) Received: from [192.168.42.144] (pop.92-184-100-0.mobile.abo.orange.fr. [92.184.100.0]) by smtp.googlemail.com with ESMTPSA id 19sm3164543wmj.23.2021.08.12.07.09.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Aug 2021 07:09:41 -0700 (PDT) Subject: Re: Unexpected greedy ops failure To: Jonathan Wakely Cc: "libstdc++@gcc.gnu.org" References: From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= Message-ID: Date: Thu, 12 Aug 2021 16:09:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 14:09:54 -0000 On 11/08/21 3:32 pm, Jonathan Wakely wrote: > On Wed, 11 Aug 2021 at 14:23, François Dumont via Libstdc++ > wrote: >> With the patch proposed in: >> https://gcc.gnu.org/pipermail/libstdc++/2021-August/053009.html to >> extend some _GLIBCXX_DEBUG checks in _GLIBCXX_ASSERTIONS I have 2 tests >> in failure: >> >> Running target unix/-D_GLIBCXX_DEBUG >> Running >> /home/fdt/dev/gcc/git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp >> ... >> FAIL: 23_containers/deque/types/1.cc (test for excess errors) >> FAIL: 23_containers/vector/types/1.cc (test for excess errors) >> >> The error is: >> >> /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/helper_functions.h:96: >> error: ambiguous overload for 'operator-' in '__rhs - __lhs' (operand >> types are 'std::move_iterator' and >> 'std::move_iterator') >> In file included from >> /home/fdt/dev/gcc/git/libstdc++-v3/testsuite/23_containers/vector/types/1.cc:24: >> /home/fdt/dev/gcc/git/libstdc++-v3/testsuite/util/testsuite_greedy_ops.h:48: >> note: candidate: 'greedy_ops::X greedy_ops::operator-(T, T) [with T = >> std::move_iterator]' >> In file included from >> /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:67, >> from >> /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/vector:60, >> from >> /home/fdt/dev/gcc/git/libstdc++-v3/testsuite/23_containers/vector/types/1.cc:23: >> /home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_iterator.h:1692: >> note: candidate: 'constexpr decltype ((__x.base() - __y.base())) >> std::operator-(const std::move_iterator<_IteratorL>&, const >> std::move_iterator<_IteratorR>&) [with _IteratorL = gree >> dy_ops::X*; _IteratorR = greedy_ops::X*; decltype ((__x.base() - >> __y.base())) = long int]' >> compiler exited with status 1 >> FAIL: 23_containers/vector/types/1.cc (test for excess errors) >> >> I really don"t understand the link between the failures and this patch. > The same tests fail with -std=gnu++20 since Jason made a fix to G++. I > haven't decided yet whether we should just disable those tests for > C++20, or do something else. Ok, so I rebuilt the compiler and I do not see this strange side effect anymore. My patch on the other thread is fully tested, in _GLIBCXX_DEBUG mode too. > > Basically, the "greedy" operators on those tests are bad, and nobody > should write code like that (C++20 concepts make it unnecessary to do > it anyway). > > >> But at the same time I am surprised that there is no definition for >> operator-(const move_iterator&, const move_iterator&) in the library >> (like in attached patch). With this change the failure vanishes. > See line 1689 in Yes, I saw this one but I meant the basic operator- with both operands of the same type like the one in the proposed patch. > >> Moreover is there a reason for having added several operators as normal >> std namespace operators rather than inline friend like in my patch ? I >> know we already talk about it but I don't remember if the reply was that >> we cannot do it or I simply forgot to propose the patch to do so. > The standard declares that operator- in namespace std, not as a > friend, see the synopsis in [iterator.synopsis]. That has observable > semantic effects, e.g. it's possible to call it with: > > struct X { > operator std::move_iterator() const; > }; > X x; > auto d = x - x; > > If the function is only defined as a friend, then it can only be found > by ADL, and this example won't compile. > > I suppose we could add the hidden friend *and* keep the generic > overload at namespace scope. That would meet the requirements of the > standard. I think we would still have the problem with greedy > operators for comparing related but not identical types, e.g. > move_iterator and move_iterator. Maybe we should cause it looks like it boosts a little bit the compilation time. Before I rebuilt the compiler the difference was noticeable from a human perspective (but I didn't measure it at that time). Now I measured it and with this testsuite_files: 23_containers/deque/types/1.cc 23_containers/vector/types/1.cc time make check-debug: real    0m20.406s user    0m19.522s sys    0m0.905s with the additional operator: real    0m20.391s user    0m19.689s sys    0m0.722s The diff is not huge but with the additional operator the compiler can pick up this perfect match without considering all the others, no ?