[PATCH] Warn on and fold NULL checks against inline functions

ressions? 2014-05-26 Patrick Palka * c-family/c-common.c (decl_with_nonnull_addr_p): Assume inline functions are non-null. * fold-const.c (tree_single_nonzero_warnv_p): Likewise. --- gcc/c-family/c-common.c | 4 +++- gcc/fold-const.c| 5 -

Re: [PATCH] Warn on and fold NULL checks against inline functions

On Mon, May 26, 2014 at 4:26 PM, Marc Glisse wrote: > On Mon, 26 May 2014, Patrick Palka wrote: > >> This patch teaches the C++ frontend to warn on NULL checks against >> inline functions and it teaches the middle-end to fold NULL checks >> against inline function

Re: [PATCH] Warn on and fold NULL checks against inline functions

On Tue, May 27, 2014 at 3:33 AM, Richard Biener wrote: > On Mon, May 26, 2014 at 9:01 PM, Patrick Palka wrote: >> Hi, >> >> This patch teaches the C++ frontend to warn on NULL checks against >> inline functions and it teaches the middle-end to fold NULL checks >>

Re: [PATCH] Warn on and fold NULL checks against inline functions

On Tue, May 27, 2014 at 8:32 AM, Patrick Palka wrote: > On Tue, May 27, 2014 at 3:33 AM, Richard Biener > wrote: >> On Mon, May 26, 2014 at 9:01 PM, Patrick Palka wrote: >>> Hi, >>> >>> This patch teaches the C++ frontend to warn on NULL checks against

[PATCH] Fix PR c++/25940

Hi, The following patch fixes two issues: the first is PR c++/25940 and the second is related to PR c++/13699. The first issue is that the C++ frontend fails to reject duplicate definitions of functions with C language linkage. This results in the compiler emitting ASM that defines the same symb

[PATCH v2] Fix PR c++/25940

Hi, The following patch fixes two issues: the first issue is PR c++/25940 and the second is related to PR c++/13699. The first issue is that the C++ frontend fails to reject duplicate definitions of functions declared to have C language linkage. This results in the compiler emitting ASM that def

Re: [PATCH v2] Fix PR c++/25940

On Sat, Mar 1, 2014 at 7:53 PM, Marc Glisse wrote: > On Sat, 1 Mar 2014, Patrick Palka wrote: > >> + error_at (input_location, >> + "redefinition of %q+#D with C language >> linkage", &g

Re: Why my mail is not achived

On Sat, Mar 1, 2014 at 9:57 PM, lin zuojian wrote: > Hi, > my mail is not achived by > http://gcc.gnu.org/ml/gcc-patches/2014-02/. What's happening? That's last month's archive.

Re: Patch RFC: Use internal qsort function in libbacktrace

On Tue, Mar 4, 2014 at 10:34 PM, Ian Lance Taylor wrote: > The GNU glibc qsort function will call malloc in some cases. That makes > it unsuitable for libbacktrace, which is intended to work when called > from a signal handler. This patch changes libbacktrace to use an > internal qsort function.

[PATCH] Add test for PR c++/53711

This patch adds a test case for PR c++/53711 which seems to have been resolved by r199906. PR c++/53711 * d++.dg/warn/anonymous-namespace-6.C: New test. --- gcc/testsuite/g++.dg/warn/anonymous-namespace-6.C | 8 1 file changed, 8 insertions(+) create mode 100644 gcc/test

Re: [PATCH] Add test for PR c++/53711

On Fri, Mar 14, 2014 at 11:20 AM, Jason Merrill wrote: > Applied, thanks. Thanks! The commit seems to be missing the corresponding ChangeLog entry though.

[PATCH] Fix PR c++/44859

his change was successfully bootstrapped and regtested against x86_64-unknown-linux-gnu. 2014-03-31 Patrick Palka patr...@parcs.ath.cx PR c++/44859 * typeck.c (maybe_warn_about_returning_address_of_local): Unwrap COMPONENT_REFs and ARRAY_REFs s

[PATCH] Fix PR c++/21113

this change on x86_64-unknown-linux-gnu. 2014-04-03 Patrick Palka PR c++/21113 * decl.c (decl_jump_unsafe): Consider variably-modified decls. --- gcc/cp/decl.c| 5 ++--- gcc/testsuite/g++.dg/ext/vla14.C | 23 +++ 2 files changed, 25

[PATCH] Fix PR c++/44613

x[n]; f (); } } thereby forcing the label "foo" to be placed before the initialization of saved_stack during gimplification. This is the same approach that the C frontend uses (see r85849). I bootstrapped and regtested this patch on x86_64-unknown-linux-gnu. 2014-04-03 Patrick Palka

[PATCH] Fix PR c++/60764

Hello, This patch fixes fixes an erroneous -Wnonnull warning when calling a constructor declared with __attribute__ ((nonnull (1))). The issue is that a NULL pointer is used as the placeholder object for the "this" parameter of the constructor method call until a target object is determined and s

[PATCH] Fix PR c++/60765

Hi, This patch teaches the C++ frontend how to handle function attributes attached to pointer-to-member-function declarations. I bootstrapped and regtested this patch on x86_64-unknown-linux-gnu. 2014-04-05 Patrick Palka PR c++/60765 * decl2.c (cplus_decl_attributes): Handle

[PATCH] [CLEANUP] Mark locally-used functions static

gnu. 2014-04-13 Patrick Palka gcc/c/ * c-array-notation.c (replace_invariant_exprs): Make static. gcc/cp/ * class.c (inherit_targ_abi_tags): Make static. * cp-array-notation.c (create_cmp_incr): Likewise. * mangle.c (tree_string_cmp): Likewise.

[PATCH] [CLEANUP] Wrap locally-used functions in anonymous namespaces

s to be used as template arguments. The next best thing to marking them static is to define each of these functions inside an anonymous namespace. I bootstrapped and regtested this change on x86_64-unknown-linux-gnu. 2014-04-11 Patrick Palka * alloc-pool.c (print_alloc_pool_statisti

[PATCH] [CLEANUP] Declare global functions before defining them

appropriate header file within the offending source files. Bootstrapped and regtested on x86_64-unknown-linux-gnu. 2014-04-11 Patrick Palka gcc/ * builtins.c: Include targhooks.h. * calls.c: Include calls.h. * cfgexpand.c: Include cfgexpand.h. * cfgloop.c

Re: [PATCH] [CLEANUP] Wrap locally-used functions in anonymous namespaces

On Tue, Apr 15, 2014 at 3:51 AM, Richard Biener wrote: > On Mon, Apr 14, 2014 at 4:51 PM, Patrick Palka wrote: >> Hi everyone, >> >> This patch wraps a bunch of locally-used, non-debug functions in an >> anonymous namespace. These functions can't simply be marked

Re: [PATCH] [CLEANUP] Declare global functions before defining them

On Tue, Apr 15, 2014 at 3:52 AM, Richard Biener wrote: > On Mon, Apr 14, 2014 at 4:52 PM, Patrick Palka wrote: >> Hi everyone, >> >> Many source files currently define a global function that is not >> previously declared within that source file because the source

Re: [PATCH] Fix PR c++/60765

Could someone install this on my behalf?

Re: [PATCH] Fix PR c++/60764

Could someone install this for me?

Re: [PATCH] Fix PR c++/60765

Thanks, Paolo!

Re: [PATCH 2/3] Release expanded template argument vector

On Mon, 7 Oct 2024, Jason Merrill wrote: > On 10/7/24 9:58 AM, Patrick Palka wrote: > > On Sat, 5 Oct 2024, Jason Merrill wrote: > > > > > On 10/4/24 11:00 AM, Patrick Palka wrote: > > > > On Thu, 3 Oct 2024, Jason Merrill wrote: > > > > &g

Re: [pushed] c++: address deduction and concepts [CWG2918]

On Mon, 14 Oct 2024, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > CWG2918 changes deduction from an overload set for the case where multiple > candidates succeed and have the same type; previously this made the overload > set a non-deduced context, now i

[PATCH 1/2] c++: some further concepts cleanups

This patch further cleans up the concepts code following the removal of Concepts TS support: * concept-ids are now the only kind of "concept check", so we can simplify some code accordingly. In particular resolve_concept_check seems like a no-op and can be removed. * In turn, deduce_c

[PATCH 1/2] c++: some further concepts cleanups

This patch further cleans up the concepts code following the removal of Concepts TS support: * concept-ids are now the only kind of "concept check", so we can simplify some code accordingly. In particular resolve_concept_check seems like a no-op and can be removed. * In turn, deduce_c

[PATCH 2/2] c++: constrained auto NTTP vs associated constraints

According to [temp.param]/11, the constraint on an auto NTTP is an associated constraint and so should be checked as part of satisfaction of the overall associated constraints rather than checked individually during coerion/deduction. In order to implement this we mainly need to make handling of c

[PATCH] c++: unifying lvalue vs rvalue (non-forwarding) ref [PR116710]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- When unifying two (non-forwarding) reference types, unify immediately recurses into the reference type without first comparing rvalueness. (Note that at this point forwarding references have already been coll

[PATCH] c++: checking ICE w/ lambda targ inside constexpr if [PR117054]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here we're tripping over the assert in extract_locals_r which enforces that an extra-args tree appearing inside another extra-args tree doesn't actually have extra args. This invariant no longer always holds

Re: [PATCH] libstdc++: Implement LWG 3798 for range adaptors [PR106676]

On Mon, 14 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > LWG 3798 modified the iterator_category of the iterator types for > transform_view, join_with_view, zip_transform_view and > adjacent_transform_view, to allow the iterator's reference type to be an > rvalue refer

Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints

On Tue, 15 Oct 2024, Patrick Palka wrote: > According to [temp.param]/11, the constraint on an auto NTTP is an > associated constraint and so should be checked as part of satisfaction > of the overall associated constraints rather than checked individually > during coerion/deduction.

[pushed] c++: add fixed testcase [PR80637]

Fixed by r15-4340-gcacbb4daac3e9a. PR c++/80637 gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-fn9.C: New test. --- gcc/testsuite/g++.dg/cpp2a/concepts-fn9.C | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-fn9.C d

[PATCH] doc: remove outdated C++ Concepts section

This was added as part of the initial Concepts TS implementation and reflects an early version of the Concepts TS paper, which is very different from standard C++20 concepts (and even from more recent versions of the Concepts TS, support for which we deprecated in GCC 14 and removed for GCC 15). S

Re: [PATCH v3] libstdc++: implement concatenation of strings and string_views

On Sat, 21 Sep 2024, Giuseppe D'Angelo wrote: > On 31/07/2024 00:19, Jonathan Wakely wrote: > > One more thing that I missed last time, sorry: > > > > +#if __glibcxx_string_view >= 202403L > > + // const string & + string_view > > + template > > +_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR > >

Re: [PATCH 4/4] c++: enable modules by default in c++20

On Wed, 9 Oct 2024, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, will apply to trunk with the rest of the patch > series. > > -- 8< -- > > At this point there doesn't seem to be much reason not to have modules > support enabled by default in C++20, and it's good get more test coverage to >

[PATCH] libstdc++: Implement P0849R8 auto(x) library changes

Tested on x86_64-pc-linux-gnu, does this look OK for trunk only? This doesn't seem worth backporting since there should be no behavior change. -- >8 -- This implements the library changes in P0849R8 "auto(x): decay-copy in the language" which consist of replacing most uses of the exposition-only

Re: [PATCH] libstdc++: Implement P0849R8 auto(x) library changes

On Mon, 7 Oct 2024, Patrick Palka wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only? > This doesn't seem worth backporting since there should be no > behavior change. > > -- >8 -- > > This implements the library changes in P0849R8 "aut

Re: [PATCH 2/3] Release expanded template argument vector

On Thu, 3 Oct 2024, Jason Merrill wrote: > On 10/3/24 12:38 PM, Jason Merrill wrote: > > On 10/2/24 7:50 AM, Richard Biener wrote: > > > This reduces peak memory usage by 20% for a specific testcase. > > > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > > > > > It's very ugly so I

[PATCH] libstdc++: Implement LWG 3664 changes to ranges::distance

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/backports? -- >8 -- libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (__distance_fn::operator()): Adjust iterator/sentinel overloads as per LWG 3664. * testsuite/24_iterators/range_operations/distance.cc:

Re: [PATCH 2/3] Release expanded template argument vector

On Sat, 5 Oct 2024, Jason Merrill wrote: > On 10/4/24 11:00 AM, Patrick Palka wrote: > > On Thu, 3 Oct 2024, Jason Merrill wrote: > > > > > On 10/3/24 12:38 PM, Jason Merrill wrote: > > > > On 10/2/24 7:50 AM, Richard Biener wrote: > > > > > T

Re: [PATCH 2/2 v3] libstdc++: add std::is_virtual_base_of

On Fri, 2 Aug 2024, Jonathan Wakely wrote: > On Fri, 2 Aug 2024 at 10:35, Giuseppe D'Angelo wrote: > > > > Hello, > > > > On 31/07/2024 00:55, Jonathan Wakely wrote: > > > If __cpp_lib_is_virtual_base_of depends on __has_builtin, then that > > > will do the right thing for #ifdef __cpp_lib_is_virt

Re: [PATCH 2/3] Release expanded template argument vector

On Mon, 7 Oct 2024, Jason Merrill wrote: > On 10/7/24 10:26 AM, Patrick Palka wrote: > > On Mon, 7 Oct 2024, Jason Merrill wrote: > > > > > On 10/7/24 9:58 AM, Patrick Palka wrote: > > > > On Sat, 5 Oct 2024, Jason Merrill wrote: > > > > &g

Re: [PATCH 1/7] libstdc++: Refactor std::uninitialized_{copy, fill, fill_n} algos [PR68350]

On Fri, 18 Oct 2024, Jonathan Wakely wrote: > On 16/10/24 21:39 -0400, Patrick Palka wrote: > > On Tue, 15 Oct 2024, Jonathan Wakely wrote: > > > +#if __cplusplus < 201103L > > > + > > > + // True if we can unwrap _Iter to get a pointer by using >

Re: [PATCH 1/7] libstdc++: Refactor std::uninitialized_{copy, fill, fill_n} algos [PR68350]

On Fri, 18 Oct 2024, Patrick Palka wrote: > On Fri, 18 Oct 2024, Jonathan Wakely wrote: > > > On 16/10/24 21:39 -0400, Patrick Palka wrote: > > > On Tue, 15 Oct 2024, Jonathan Wakely wrote: > > > > +#if __cplusplus < 201103L > > > > + > > >

Re: [WIP RFC] libstdc++: add module std

On Fri, 18 Oct 2024, Jason Merrill wrote: > This patch is not ready for integration, but I'd like to get feedback on the > approach (and various specific questions below). > > -- 8< -- > > This patch introduces an installed source form of module std and std.compat. > To find them, we install a l

Re: [PATCH 2/7] libstdc++: Make __normal_iterator constexpr, always_inline, nodiscard

On Tue, 15 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > The __gnu_cxx::__normal_iterator type we use for std::vector::iterator > is not specified by the standard, it's an implementation detail. This > means it's not constrained by the rule that forbids strengthening >

Re: [PATCH 1/2] libstdc++: Implement C++23 (P0429R9)

On Mon, 30 Sep 2024, Patrick Palka wrote: > This implements the C++23 container adaptors std::flat_map and > std::flat_multimap from P0429R9. The implementation is shared > as much as possible between the two adaptors via a common base > class that's parameterized according

Re: [PATCH 2/2] libstdc++: Implement C++23 (P1222R4)

On Mon, 30 Sep 2024, Patrick Palka wrote: > This implements the C++23 container adaptors std::flat_set and > std::flat_multiset from P1222R4. The implementation is essentially > an simpler and pared down version of std::flat_map. > > The main known issues are: > >

Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints

On Tue, 15 Oct 2024, Patrick Palka wrote: > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > According to [temp.param]/11, the constraint on an auto NTTP is an > > associated constraint and so should be checked as part of satisfaction > > of the overall associated constra

Re: [PATCH] libstdc++: Move std::__niter_base and std::__niter_wrap to stl_iterator.h

On Thu, 17 Oct 2024, Jonathan Wakely wrote: > I've split this out of "Refactor std::uninitialized_{copy, fill, fill_n}" > because this part can be done separately. Call it [PATCH -1/7] if you > like :-) > > This fixes the ordering problem that Patrick noticed in [PATCH 1/7], and > adds a test for

[PATCH] c++: redundant hashing in register_specialization

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- After r15-4050-g5dad738c1dd164 register_specialization needs to set elt.hash to the (maybe) precomputed hash in order to avoid redundantly rehashing. gcc/cp/ChangeLog: * pt.cc (register_specializati

Re: [PATCH] libstdc++: Enable _GLIBCXX_ASSERTIONS by default for -O0 [PR112808]

On Wed, 2 Oct 2024, Jonathan Wakely wrote: > I think we should do this. > > Tested x86_64-linux. > > -- >8 -- > > Too many users don't know about -D_GLIBCXX_ASSERTIONS and so are missing > valuable checks for C++ standard library preconditions. This change > enables libstdc++ assertions by defa

[PATCH] libstdc++/ranges: Implement various small LWG issues

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and perhaps 13? -- >8 -- This implements the following small LWG issues: 3848. adjacent_view, adjacent_transform_view and slide_view missing base accessor 3851. chunk_view::inner-iterator missing custom iter_move and iter_swap

Re: [PATCH] c++: reference variable as default targ [PR101463]

On Tue, 9 Jan 2024, Jason Merrill wrote: > On 1/5/24 15:01, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > look OK for trunk? > > > > -- >8 -- > > > > Here during default template argument substitution we wron

[PATCH] libstdc++: Implement LWG 4166 changes to concat_view::end()

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This patch proactively implements the proposed resolution for this LWG issue, which seems straightforward and slated to be approved as-is. I opted to not add a _GLIBCXX_RESOLVE_LIB_DEFECTS code comment for this since concat_vie

Re: [PATCH] libstdc++: Avoid using std::__to_address with iterators

On Fri, 18 Oct 2024, Jonathan Wakely wrote: > Do others agree with my reasoning below? > > The changes to implement the rule "use std::__niter_base before C++20 > and use std::to_address after C++20" were easier than I expected. There > weren't many places that were doing it "wrong" and needed to

Re: [PATCH] libstdc++: Implement LWG 3564 for ranges::transform_view

On Mon, 14 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > The _Iterator type returned by begin() const uses const F& to > transform the elements, so it should use const F& to determine the > iterator's value_type and iterator_category as well. > > This was accepted int

Re: [PATCH] libstdc++: Use std::move for iterator in ranges::fill [PR117094]

LGTM On Mon, 14 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > Input iterators aren't required to be copyable. > > libstdc++-v3/ChangeLog: > > PR libstdc++/117094 > * include/bits/ranges_algobase.h (__fill_fn): Use std::move for > iterator that migh

[PATCH] libstdc++: Avoid unnecessary copies in ranges::min/max [PR112349]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 14? -- >8 -- Use a local reference for the (now possibly lifetime extended) result of *__first to avoid making unnecessary copies of it. PR libstdc++/112349 libstdc++-v3/ChangeLog: * include/bits/ranges_algo

Re: [PATCH] c++: Implement P2662R3, Pack Indexing [PR113798]

On Wed, 23 Oct 2024, Jason Merrill wrote: > On 10/23/24 10:20 AM, Patrick Palka wrote: > > On Tue, 22 Oct 2024, Marek Polacek wrote: > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > -- >8 -- > > > This

Re: [PATCH v2] c++: Implement P2662R3, Pack Indexing [PR113798]

On Tue, 29 Oct 2024, Marek Polacek wrote: > On Tue, Oct 22, 2024 at 07:42:57PM -0400, Jason Merrill wrote: > > On 10/22/24 3:22 PM, Marek Polacek wrote: > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > -- >8 -- > > > This patch implements C++26 Pack Indexing, as desc

Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints

On Thu, 17 Oct 2024, Patrick Palka wrote: > On Thu, 17 Oct 2024, Patrick Palka wrote: > > > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > > > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > > > > > According to [temp.param]/11, the con

Re: [PATCH 1/2] c++: some further concepts cleanups

On Tue, 15 Oct 2024, Patrick Palka wrote: > This patch further cleans up the concepts code following the removal of > Concepts TS support: > > * concept-ids are now the only kind of "concept check", so we can > simplify some code accordingly. In particu

Re: [PATCH 3/2] c++: remove WILDCARD_DECL

On Fri, 25 Oct 2024, Patrick Palka wrote: > On Wed, 23 Oct 2024, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > OK for trunk? > > > > -- >8 -- > > > > This tree code was added as part of the init

Re: [PATCH] c++: reference variable as default targ [PR101463]

On Tue, 22 Oct 2024, Patrick Palka wrote: > On Tue, 9 Jan 2024, Jason Merrill wrote: > > > On 1/5/24 15:01, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > > look OK for trunk? > > > > > > -- >8 --

Re: [PATCH] Replace 8 consecutive spaces in leading whitespace by tab

On Fri, Oct 25, 2024 at 7:54 AM Jakub Jelinek wrote: > > On Fri, Oct 25, 2024 at 01:25:25PM +0200, Arsen Arsenović wrote: > > Maybe we should go the other way around? Compressing eight spaces into > > a tab leads to strange artifacts in diffs (where lines appear > > misindented because some were

Re: [PATCH 3/2] c++: remove WILDCARD_DECL

On Wed, 23 Oct 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk? > > -- >8 -- > > This tree code was added as part of the initial Concepts TS > implementation to support type-constraints introducing any kind

[PATCH] libstdc++: Fix complexity of drop_view::begin const [PR112641]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk/backports? Also available in PR form at https://forge.sourceware.org/gcc/gcc-TEST/pulls/8 -- >8 -- Views are required to have a amortized O(1) begin(), but our drop_view's const begin overload is O(n) for non-common ranges. This patch re

Re: [PATCH 1/2] libstdc++: Implement C++23 (P0429R9)

On Wed, 16 Oct 2024, Patrick Palka wrote: > On Mon, 30 Sep 2024, Patrick Palka wrote: > > > This implements the C++23 container adaptors std::flat_map and > > std::flat_multimap from P0429R9. The implementation is shared > > as much as possible between the two ad

Re: [PATCH] c++: Implement P2662R3, Pack Indexing [PR113798]

On Tue, 22 Oct 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > This patch implements C++26 Pack Indexing, as described in > . > > The issue discussing how to mangle pack indexes has not been resolved > yet

[PATCH 3/2] c++: remove WILDCARD_DECL

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This tree code was added as part of the initial Concepts TS implementation to support type-constraints introducing any kind of template-parameter, not just type template-parameters, e.g. template concept C

Re: [PATCH] c++: alias of decltype(lambda) is opaque [PR116714]

On Mon, 16 Sep 2024, Patrick Palka wrote: > On Mon, 16 Sep 2024, Andrew Pinski wrote: > > > On Mon, Sep 16, 2024 at 8:12 AM Patrick Palka wrote: > > > > > > Bootstrapped and regtested on x86_64-pc-linuxgnu, does this look > > > OK for trunk?

Re: [PATCH] c++: crash with anon VAR_DECL [PR116676]

On Tue, 17 Sep 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13? Why not backport this to 12 as well? > > -- >8 -- > r12-3495 added maybe_warn_about_constant_value which will crash if > it gets a nameless VAR_DECL, which is what happens in this PR.

Re: [PATCH 2/2] c++: CWG 2789 and usings [PR116492]

On Fri, 20 Sep 2024, Jason Merrill wrote: > On 9/18/24 10:59 PM, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this > > look OK for trunk? I'm not sure this is worth backporting > > without the previous CWG 2273 tweak since it'll

[PATCH] c++: CWG 2789 and reversed operator candidates

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- As a follow-up to r15-3741-gee3efe06c9c49c, which was only concerned with usings, it seems we should also compare contexts of a reversed vs non-reversed (member) candidate during operator overload resolution.

Re: [PATCH 1/2] c++: CWG 2273 and non-constructors

On Wed, 18 Sep 2024, Patrick Palka wrote: > Our implementation of the CWG 2273 inheritedness tiebreaker seems to be > incorrectly considering all inherited members, not just inherited > constructors. This patch restricts the tiebreaker accordingly. > > DR 2273 >

Re: [PATCH 2/2] c++: CWG 2789 and usings [PR116492]

On Fri, 20 Sep 2024, Jason Merrill wrote: > On 9/20/24 6:51 PM, Patrick Palka wrote: > > On Fri, 20 Sep 2024, Jason Merrill wrote: > > > > > On 9/18/24 10:59 PM, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this >

[PATCH 1/2] libstdc++: Implement C++23 (P0429R9)

This implements the C++23 container adaptors std::flat_map and std::flat_multimap from P0429R9. The implementation is shared as much as possible between the two adaptors via a common base class that's parameterized according to key uniqueness. The main known issues are: * the range insert() ov

[PATCH 2/2] libstdc++: Implement C++23 (P1222R4)

This implements the C++23 container adaptors std::flat_set and std::flat_multiset from P1222R4. The implementation is essentially an simpler and pared down version of std::flat_map. The main known issues are: * exception safety is likely incomplete/buggy * unimplemented from_range_t construc

Re: [PATCH] c++: explicit spec of constrained member tmpl [PR107522]

On Thu, 12 Sep 2024, Patrick Palka wrote: > (Sorry to resurrect this thread so late, I lost track of this patch...) > > On Fri, 2 Dec 2022, Jason Merrill wrote: > > > On 12/2/22 09:30, Patrick Palka wrote: > > > On Thu, 1 Dec 2022, Jason Merrill wrote: > > >

Re: [PATCH] c++: partial spec constraint checking context [PR105220]

On Mon, 16 Sep 2024, Patrick Palka wrote: > On Thu, 30 Nov 2023, Patrick Palka wrote: > > > On Fri, 3 Nov 2023, Patrick Palka wrote: > > > > > On Tue, 3 May 2022, Jason Merrill wrote: > > > > > > > On 5/2/22 14:50, Patrick Palka wrote: > &

[PATCH 2/2] c++: CWG 2789 and usings [PR116492]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? I'm not sure this is worth backporting without the previous CWG 2273 tweak since it'll mean inconsistent behavior between implict vs explicit object members in GCC 14: the call to S<>{}.f() in concepts-memfun4.C would

[PATCH 1/2] c++: CWG 2273 and non-constructors

Our implementation of the CWG 2273 inheritedness tiebreaker seems to be incorrectly considering all inherited members, not just inherited constructors. This patch restricts the tiebreaker accordingly. DR 2273 gcc/cp/ChangeLog: * call.cc (joust): Restrict inheritedness tiebreaker

Re: [PATCH 1/2 v2] Introduce __builtin_is_virtual_base_of

On Wed, 25 Sep 2024, Jason Merrill wrote: > On 7/30/24 6:49 PM, Giuseppe D'Angelo wrote: > > On 29/07/2024 22:53, Giuseppe D'Angelo wrote: > > > Hi, > > > > > > The attached patch is a stab at adding the necessary compiler builtin to > > > support std::is_virtual_base_of (P2985R0, approved for C+

Re: [PATCH 1/2 v2] Introduce __builtin_is_virtual_base_of

On Wed, 31 Jul 2024, Giuseppe D'Angelo wrote: > On 29/07/2024 22:53, Giuseppe D'Angelo wrote: > > Hi, > > > > The attached patch is a stab at adding the necessary compiler builtin to > > support std::is_virtual_base_of (P2985R0, approved for C++26). The name > > of the builtin matches the one jus

Re: [PATCH 1/2 v2] Introduce __builtin_is_virtual_base_of

[CC'ing Jason] On Wed, 25 Sep 2024, Patrick Palka wrote: > On Wed, 31 Jul 2024, Giuseppe D'Angelo wrote: > > > On 29/07/2024 22:53, Giuseppe D'Angelo wrote: > > > Hi, > > > > > > The attached patch is a stab at adding the necessary com

Re: [PATCH 3/7] libstdc++: Inline memmove optimizations for std::copy etc. [PR115444]

On Tue, 15 Oct 2024, Jonathan Wakely wrote: > This is a slightly different approach to C++98 compatibility than used > in patch 1/1 of this series for the uninitialized algos. It worked out a > bit cleaner this way for these algos, I think. > > Tested x86_64-linux. > > -- >8 -- > > This removes

Re: [PATCH 4/7] libstdc++: Remove indirection to __find_if in std::find etc.

ZOn Tue, 15 Oct 2024, Jonathan Wakely wrote: > Tested x86_64-linux. > > -- >8 -- > > There doesn't seem to be a lot of benefit in reusing __find_if with > __gnu_cxx::__ops predicates, since they aren't going to actually > instantiate any less code if we use different predicates every time > (e.g

Re: [PATCH 1/7] libstdc++: Refactor std::uninitialized_{copy, fill, fill_n} algos [PR68350]

On Tue, 15 Oct 2024, Jonathan Wakely wrote: > This is v2 of > https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665246.html > fixing some thinkos in uninitialized_{fill,fill_n}. We don't need to > worry about overwriting tail-padding in those algos, because we only use > memset for 1-byte int

Re: [PATCH 2/2] c++: constrained auto NTTP vs associated constraints

On Thu, 17 Oct 2024, Patrick Palka wrote: > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > On Tue, 15 Oct 2024, Patrick Palka wrote: > > > > > According to [temp.param]/11, the constraint on an auto NTTP is an > > > associated constraint and so shoul

Re: [RFC/PATCH] c++: Unwrap type traits defined in terms of builtins within concept diagnostics [PR117294]

On Fri, 8 Nov 2024, Nathaniel Shead wrote: > Does this approach seem reasonable? I'm pretty sure that the way I've > handled the templating here is unideal but I'm not sure what a neat way > to do what I'm trying to do here would be; any comments are welcome. Clever approach, I like it! > > --

[PATCH] libstdc++/ranges: make _RangeAdaptorClosure befriend operator|

Tested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- This declares the range adaptor pipe operators a friend of the _RangeAdaptorClosure base class so that the std module doesn't need to export them for ADL to find them. Note that we deliberately don't define these pipe operators

Re: [PATCH] libstdc++/ranges: make _RangeAdaptorClosure befriend operator|

On Wed, 27 Nov 2024, Jonathan Wakely wrote: > On Wed, 27 Nov 2024 at 15:43, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk? > > OK Thanks, I noticed Jason already pushed his module std fixes patch so I went ahead and removed the n

Re: [PATCH] libstdc++: module std fixes

On Tue, 26 Nov 2024, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, OK for trunk? > > -- 8< -- > > Some tests were failing due to the exported using declaration of iter_move > conflicting with friend declarations; the exported using needs to be in the > inline namespace, like the customizati

[PATCH] c++: template-id dependence wrt local static arg [PR117792]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14/13? -- >8 -- Here we end up ICEing at instantiation time for the call to f ultimately because we wrongly consider the call to be non-dependent, and so we specialize f ahead of time and then get confused when fully s

Re: [PATCH 1/2] c++: some further concepts cleanups

On Tue, 5 Nov 2024, Jason Merrill wrote: > On 10/15/24 12:45 AM, Patrick Palka wrote: > > This patch further cleans up the concepts code following the removal of > > Concepts TS support: > > > >* concept-ids are now the only kind of "concept check",

Re: [PATCH] libstdc++: Use hidden friends for __normal_iterator operators

On Mon, 2 Dec 2024, Patrick Palka wrote: > On Thu, 28 Nov 2024, Jonathan Wakely wrote: > > > As suggested by Jason, this makes all __normal_iterator operators into > > friends so they can be found by ADL and don't need to be separately > > exported in module std.

Re: [PATCH] libstdc++: Use hidden friends for __normal_iterator operators

On Thu, 28 Nov 2024, Jonathan Wakely wrote: > As suggested by Jason, this makes all __normal_iterator operators into > friends so they can be found by ADL and don't need to be separately > exported in module std. Might as well remove the __gnu_cxx exports in std.cc.in while we're at it? > > For

<    5   6   7   8   9   10   11   12   13   14   >