From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id EB868385DC3E; Sat, 17 Feb 2024 14:14:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EB868385DC3E 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 EB868385DC3E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::235 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708179282; cv=none; b=EG9u9dypMdYRXEqrnBmiTgqhAbZAnlmpo2IUMPqmsCTcavFM+YIJJk6+Syk0XAtc4GMSupYu7IFDk3UcoeLbFqzo3fjLxXAlxEH7ou+sX6C/KZSKa4ZPEmbmSGWqnVbrE3FfGboHLKv06Oq6qJnFYP75qWAP5cnRxHxwNKtC9Hg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708179282; c=relaxed/simple; bh=vmGrm/1i/nol1VrTbfJ9lMHRnv2aDZLrf7kkUvfTXYA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=WjGdav6aox+cT4hurRYvZMS4zroF7R0zzRX6R/eJX6bl2OSPRKHajBmzBvaG/nDCSQiYFl18utXAo6towraJL2JcXwo7WXAgXwQi/4bpxU8bu3iOP0glS5prBkFaxOL3OIqoo1nakXKCadpKqKsjOhAn8e2Po7HgenmHkPzEIyg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2d0f7585d89so19535581fa.3; Sat, 17 Feb 2024 06:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708179273; x=1708784073; darn=gcc.gnu.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=bfFdbYVDvbwcrCSHkbg3jGR5aQpAwIt4c+43Cui6e9E=; b=H2j2cdhghNM3eyoeMf41MvwslP244zbGzP1RAiCvQi1FJjFnBukCNpUmqtButiDeZq eu3/BFLZzOhEiZ/phXirOVr4Tt7WbYEefwMcZ0SCzMinxq9i6XtY2SMjHJ7rTGxsMieD CFKLBGBOW+Zkl96lwTDWDSizc27XfdhO9gcEZp58fJaBoM4GAAVo+LKb22dHyivsT7/H iNtYlttmH5az8QqGcfwgKhQug37HyC8GYGf8aJik63qfklKJO/nXHWRCVLSuVAHHptfo w1K5NtLNKufPGs/mTxn5xYUIN2EDwMYb0LaWpxq39FCeL7Ho1EdXsiGM+s8uF9BClNjY soyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708179273; x=1708784073; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=bfFdbYVDvbwcrCSHkbg3jGR5aQpAwIt4c+43Cui6e9E=; b=XtdRdX1rjc1FPb25LPKAuoeWiI6VSqIsaJD2IMT3LNqxmI14qPKF/4j+JDxL0elN62 8us9eX+CsWPQ8+LziFT7mlgSelBvTFj3jxJh1WF7qtnDyDLgGqIRI9SjYxhOtg1JVCDh x2gPj5Fe0ICvgnba0wZk9wXIrkUNsCUHzR60U+zEwZaNnQSNk7g870M3dOih27C1MQwt KZXMkrWjYgGgATOG2MfZEE1231NbZOXJTk6VTL6DcqgTGkmyR8QaC3GOjj1ww5xa/knC bXYDb0n7qWQtrrpowLDdM5uDN46Ax78C7JKRWKwDOrH3pDnjjH9MTqlq1aF0nerCwzF7 tG9w== X-Forwarded-Encrypted: i=1; AJvYcCXzklZMcIhC7HYfRzxuQZuOGdRPW1NQPrUiMVF1cBBOvqHkkwrNIvLvow6McGWZ3TzTWnNBpZgJiSgXFCkPPhI0ssPGzXMfZQ== X-Gm-Message-State: AOJu0Yzu9NlwKFsAbjcs9/UfdypN2WQ9QddD81IAS2wbZyZ9b9kyAxpo TrDwsLVb2aYeZrUsjPSackQVWj1rq4pXrN/1xlL1CMqmqYnZAc4M X-Google-Smtp-Source: AGHT+IGq13q8Xu2Q1ZiXYhIhqLq+Lf+UpF+TLive3jN+feILHCNiM2v8HAOI7qBgFUvcsgFyOhiCVg== X-Received: by 2002:a05:651c:1062:b0:2d2:31cf:f4af with SMTP id y2-20020a05651c106200b002d231cff4afmr53762ljm.22.1708179272813; Sat, 17 Feb 2024 06:14:32 -0800 (PST) Received: from ?IPV6:2a01:e0a:1dc:b1c0:5d18:3b5b:98dd:f567? ([2a01:e0a:1dc:b1c0:5d18:3b5b:98dd:f567]) by smtp.gmail.com with ESMTPSA id p17-20020a05600c469100b004120b4c57c9sm5450812wmo.4.2024.02.17.06.14.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Feb 2024 06:14:32 -0800 (PST) Content-Type: multipart/alternative; boundary="------------VCagopoaaLDJ5GX6EeWGtDdZ" Message-ID: <3e1e1652-4320-4b63-a72f-572f045780ca@gmail.com> Date: Sat, 17 Feb 2024 15:14:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH][_GLIBCXX_DEBUG] Fix std::__niter_base behavior To: Jonathan Wakely Cc: libstdc++ , gcc-patches References: <4c78d538-da4d-4a54-987d-3c4257913035@gmail.com> <9a6615ee-0a2c-4bcb-ad13-ba810edb9ee1@gmail.com> Content-Language: en-US From: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,BODY_8BITS,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: This is a multi-part message in MIME format. --------------VCagopoaaLDJ5GX6EeWGtDdZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the link, tested and committed. On 15/02/2024 19:40, Jonathan Wakely wrote: > > > On Thu, 15 Feb 2024 at 18:38, François Dumont > wrote: > > > On 15/02/2024 14:17, Jonathan Wakely wrote: >> >> >> On Wed, 14 Feb 2024 at 21:48, François Dumont >> wrote: >> >> >> On 14/02/2024 20:44, Jonathan Wakely wrote: >>> >>> >>> On Wed, 14 Feb 2024 at 18:39, François Dumont >>> wrote: >>> >>> libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_base behavior >>> >>> std::__niter_base is used in _GLIBCXX_DEBUG mode to >>> remove _Safe_iterator<> >>> wrapper on random access iterators. But doing so it >>> should also preserve >>> original >>> behavior to remove __normal_iterator wrapper. >>> >>> libstdc++-v3/ChangeLog: >>> >>>      * include/bits/stl_algobase.h (std::__niter_base): >>> Redefine the >>> overload >>>      definitions for __gnu_debug::_Safe_iterator. >>>      * include/debug/safe_iterator.tcc >>> (std::__niter_base): Adapt >>> declarations. >>> >>> Ok to commit once all tests completed (still need to >>> check pre-c++11) ? >>> >>> >>> >>> The declaration in include/bits/stl_algobase.h has a >>> noexcept-specifier but the definition in >>> include/debug/safe_iterator.tcc does not have one - that >>> seems wrong (I'm surprised it even compiles). >> >> It does ! >> >> >> The diagnostic is suppressed without -Wsystem-headers: >> >> /home/jwakely/gcc/14/include/c++/14.0.1/debug/safe_iterator.tcc:255:5:warning: >> declaration of 'template constexpr >> decltype (std::__ >> niter_base(declval<_Ite>())) std::__niter_base(const >> __gnu_debug::_Safe_iterator<_Iterator, _Sequence, >> random_access_iterator_tag>&)' has a different except >> ion specifier [-Wsystem-headers] >>  255 | __niter_base(const ::__gnu_debug::_Safe_iterator<_Ite, _Seq, >>      | ^~~~~~~~~~~~ >> /home/jwakely/gcc/14/include/c++/14.0.1/bits/stl_algobase.h:335:5:note: >> from previous declaration 'template >> constexpr decltype (std >> ::__niter_base(declval<_Ite>())) std::__niter_base(const >> __gnu_debug::_Safe_iterator<_Iterator, _Sequence, >> random_access_iterator_tag>&) noexcept (noexcept >> (is_nothrow_copy_constructible> (std::__niter_base(declval<_Ite>()))>::value))' >>  335 | __niter_base(const ::__gnu_debug::_Safe_iterator<_Ite, _Seq, >>      | ^~~~~~~~~~~~ >> >> >> It's a hard error with Clang though: >> >> deb.cc:7:10: error: call to '__niter_base' is ambiguous >> >> > Yes, I eventually got the error too, I hadn't run enough tests yet. > > >> >> >> I thought it was only necessary at declaration, and I also >> had troubles doing it right at definition because of the >> interaction with the auto and ->. >> >> >> The trailing-return-type has to come after the noexcept-specifier. >> >> Now simplified and consistent in this new proposal. >> >> >>> Just using std::is_nothrow_copy_constructible<_Ite> seems >>> simpler, that will be true for __normal_iterator if >>> is_nothrow_copy_constructible is true. >>> >> Ok >> >> >>> The definition in include/debug/safe_iterator.tcc should use >>> std::declval<_Ite>() not declval<_Ite>(). Is there any >>> reason why the definition uses a late-specified-return-type >>> (i.e. auto and ->) when the declaration doesn't? >>> >>> >> I initially plan to use '-> >> std::decltype(std::__niter_base(__it.base()))' but this did >> not compile, ambiguity issue. So I resort to using >> std::declval and I could have then done it the same way as >> declaration, done now. >> >> Attached is what I'm testing, ok to commit once fully tested ? >> >> >> OK, thanks. >> > Thanks for validation but I have a problem to test for c++98. > > When I do: > > make CXXFLAGS=-std=c++98 check-debug > > > That doesn't work any more, see > https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations > > I see in debug/libstdc++.log for example: > > Executing on host: /home/fdumont/dev/gcc/build/./gcc/xg++ > -shared-libgcc ... -mshstk -std=c++98 -g -O2 -DLOCALEDIR="." > -nostdinc++ -I/home/fdumont/dev/gcc/... > /home/fdumont/dev/gcc/git/libstdc++-v3/testsuite/25_algorithms/copy/3.cc > -D_GLIBCXX_DEBUG   -std=gnu++17  -include bits/stdc++.h ...  -lm  > -o ./3.exe    (timeout = 360) > > The -std=c++98 is there but later comes the -std=gnu++17 so I > think it runs in C++17, no ? > > I also tried the documented alternative: > > make check 'RUNTESTFLAGS=--target_board=unix/-O3\"{-std=gnu++98,-std=gnu++11,-std=gnu++14}\"' > > but same problem, -std=gnu++17 comes last. > > I'll try to rebuild all from scratch but I won't commit soon then. > > --------------VCagopoaaLDJ5GX6EeWGtDdZ--