[PATCHv4, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

Hi, I refined the patch according to reviewer's advice. The main change is to check if buffer_p is set and buffered error exists. Also two regtests are fixed by catching the new error. I sent out the revised one for review due to my limited knowledge on Fortran front end. The patch escalate

Re: [PATCH] rs6000: Don't ICE when compiling the __builtin_vec_xst_trunc built-in [PR109178]

On 3/19/23 10:20 PM, Kewen.Lin via Gcc-patches wrote: > Nice, OK for trunk and gcc12 branch, thanks! Pushed to trunk and the GCC 12 release branch. Thanks. Peter

Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

I would prefer this is the branch based on gcc-13 where we backport autovec-related patches once they've landed on trunk. I won't do any development on this branch, instead, I would just use it for releasing my downstream GCC. I will directly support auto-vectorization on the trunk since the mos

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

Sandra Loosemore writes: > On 3/18/23 14:14, Arsen Arsenović via Gcc-patches wrote: >> Evening, >> Ping on this patch series. >> I believe we're close to being able to apply it, with contents of the >> documentation changes being approved, and only a small build system >> change and a revised pa

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

Joseph Myers writes: > On Mon, 20 Mar 2023, Sandra Loosemore wrote: > >> Joseph, could you maybe review the last piece? A direct pointer to it in >> Arsen's git is >> >> https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3 > > That's OK, assuming I understand correctly

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

On Mon, 20 Mar 2023, Sandra Loosemore wrote: > Joseph, could you maybe review the last piece? A direct pointer to it in > Arsen's git is > > https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3 That's OK, assuming I understand correctly that makeinfo will still succeed

[committed] libstdc++: Fix formatting in std::filesystem helper function

Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * src/filesystem/ops-common.h (get_temp_directory_from_env): Fix formatting. --- libstdc++-v3/src/filesystem/ops-common.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libstdc++-v3/src

Re: [PATCH V4] Rework 128-bit complex multiply and divide.

On Mon, Mar 20, 2023 at 01:43:41PM -0400, Michael Meissner wrote: > On Fri, Mar 17, 2023 at 02:35:16PM -0500, Segher Boessenkool wrote: > > On Thu, Mar 09, 2023 at 08:40:36PM -0500, Michael Meissner wrote: > > /* { dg-final { scan-assembler {\m__divtc3\M} } } */ > > > > It might well be that we ca

Re: [PATCH v2 1/2] libstdc++: also use sendfile for big files

On 20/03/23 22:27 +, Jonathan Wakely wrote: On 06/03/23 20:52 +0100, Jannik Glückert wrote: we were previously only using sendfile for files smaller than 2GB, as sendfile needs to be called repeatedly for files bigger than that. some quick numbers, copying a 16GB file, average of 10 repetit

Re: [PATCH v2 1/2] libstdc++: also use sendfile for big files

On 06/03/23 20:52 +0100, Jannik Glückert wrote: we were previously only using sendfile for files smaller than 2GB, as sendfile needs to be called repeatedly for files bigger than that. some quick numbers, copying a 16GB file, average of 10 repetitions: old: real: 13.4s user: 0.1

Re: Should -ffp-contract=off the default on GCC?

On Mon, Mar 20, 2023 at 10:05:57PM +, Qing Zhao via Gcc-patches wrote: > My question: is the above section the place in C standard “explicitly allows > contractions”? If not, where it is in C standard? http://port70.net/%7Ensz/c/c99/n1256.html#6.5p8 http://port70.net/%7Ensz/c/c99/n1256.html#n

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

Please disregard this email. On Mon, Mar 20, 2023 at 6:26 AM Ken Matsui wrote: > Thank you! > > On Mon, Mar 20, 2023 at 2:12 AM Jonathan Wakely > wrote: > >> On Mon, 20 Mar 2023 at 08:08, Ken Matsui >> wrote: >> > >> > Ooh... Thank you for pointing that out! >> > >> > > The helper doesn't nee

Re: [PATCH] c++: implement __remove_pointer built-in trait

Please disregard this email. On Sun, Mar 19, 2023 at 1:21 PM Ken Matsui wrote: > This patch implements built-in trait for std::remove_pointer. > > gcc/cp/ChangeLog: > > * cp-trait.def: Define __remove_pointer. > * semantics.cc (finish_trait_type): Handle CPTK_REMOVE_POINTER. > > gcc/testsuite/C

[PATCH 2/2] libstdc++: use new built-in trait __remove_pointer

This patch lets libstdc++ use new built-in trait __remove_pointer. libstdc++-v3/ChangeLog: * include/std/type_traits (remove_pointer): Use __remove_pointer built-in trait. --- libstdc++-v3/include/std/type_traits | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff -

[PATCH 1/2] c++: implement __remove_pointer built-in trait

This patch implements built-in trait for std::remove_pointer. gcc/cp/ChangeLog: * cp-trait.def: Define __remove_pointer. * semantics.cc (finish_trait_type): Handle CPTK_REMOVE_POINTER. gcc/testsuite/ChangeLog: * g++.dg/ext/has-builtin-1.C: Test existence of __remove_poin

[PATCH v2] c++: further -Wdangling-reference refinement [PR107532]

On Sat, Mar 18, 2023 at 08:35:36AM -0400, Jason Merrill wrote: > On 3/17/23 16:29, Marek Polacek wrote: > > Based on , > > it seems like we should treat *any* class with a reference member > > as a reference wrapper. This simplifies the code

[PATCH] testsuite: always use UTF-8 in scan-sarif-file[-not] [PR105959]

c-c++-common/diagnostic-format-sarif-file-4.c is a test case for quoting non-ASCII source code in a SARIF diagnostic log. The SARIF standard mandates that .sarif files are UTF-8 encoded. PR testsuite/105959 notes that the test case fails when the system encoding is not UTF-8, such as when the "ma

Re: Should -ffp-contract=off the default on GCC?

Hi, > On Mar 16, 2023, at 12:53 PM, Jakub Jelinek wrote: > > On Thu, Mar 16, 2023 at 04:38:41PM +, Qing Zhao via Gcc-patches wrote: >>> NO. We have this debate every few years and such. >> >> So, what’s the major reason we keep the default that is not IEEE754 >> compliant from the begin

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

On 3/18/23 14:14, Arsen Arsenović via Gcc-patches wrote: Evening, Ping on this patch series. I believe we're close to being able to apply it, with contents of the documentation changes being approved, and only a small build system change and a revised patch series "shape" left to review. Yup.

Re: [PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]

On 3/20/23 14:05, Harald Anlauf via Gcc-patches wrote: Dear all, as reported, the implicit documentation of -funderscoring, which is found under -fno-underscoring, has gone sideways long time ago. The attached patch should fix it. OK for mainline, or did I miss something? This is OK. -Sandra

Re: [patch, fortran, doc] Explicitly mention undefined overflow

Hi Thomas, Am 20.03.23 um 08:14 schrieb Thomas Koenig via Gcc-patches: so it the general problem is not restricted to -O3 and not to current trunk, it depends on the details. I doubt that the result from 9.4.0 was expected, but rather nobody noticed.  Or, bringing out the pseudo-RNG into a diff

[PATCH] Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]

Dear all, the attached trivial patch catches a MODULE PROCEDURE outside of a module interface before we run into an internal error. Regtested on x86_64-pc-linux-gnu. OK for mainline? This PR is marked as an 11/12/13 regression, so this is a candidate for backporting. Thanks, Harald From 9c597

Re: [PATCH V4] Rework 128-bit complex multiply and divide.

On Mon, Mar 20, 2023 at 01:43:41PM -0400, Michael Meissner wrote: > I think we will need backports for GCC 12. The issue exists in GCC 11, but I > don't think that GCC 11 can really work on systems with IEEE long double, > since > a lot of the stuff to really finish up the support was not in GCC

Re: [PATCH] libstdc++: use new built-in trait __is_reference

Thank you so much for taking the benchmark! This is a great improvement than I thought. In GCC contributions, do I need to benchmark (and report) every built-in trait I implement? On Mon, Mar 20, 2023 at 8:24 AM Patrick Palka wrote: > On Mon, Mar 20, 2023 at 5:56 AM Ken Matsui > wrote: > > > >

[PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]

Dear all, as reported, the implicit documentation of -funderscoring, which is found under -fno-underscoring, has gone sideways long time ago. The attached patch should fix it. OK for mainline, or did I miss something? Thanks, Harald From c296196044248f974b4907bb2f5bdeeea24adb5b Mon Sep 17 00:00

stor-layout: Set TYPE_TYPELESS_STORAGE consistently for type variants

I've observed an LTO wrong-code bug with a large testcase in GCC 12, that results from TYPE_TYPELESS_STORAGE not being set consistently on type variants. Specifically, in the LTO stage of compilation, there is an aggregate type passed to get_alias_set, whose TYPE_MAIN_VARIANT does not have TYPE_TY

Add notes for Go to gcc 12 and 13 changes file

I committed this patch to the gcc-wwwdocs repo to add some notes about Go to the gcc 12 and 13 changes file. Ian pat e24f9ef56c11c69fc07bddf9a708ea2fc662f2b3 diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index c47d3285..d565c217 100644 --- a/htdocs/gcc-12/changes.html +++ b

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

On 3/20/23 15:26, Jakub Jelinek wrote: On Mon, Mar 20, 2023 at 03:15:32PM -0400, Jason Merrill wrote: + else if (VAR_P (decl) + && CP_DECL_THREAD_LOCAL_P (decl) + && (!DECL_EXTERNAL (decl) || flag_extern_tls_init) Hmm, I wonder why we don't check the above line i

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

On Mon, Mar 20, 2023 at 03:15:32PM -0400, Jason Merrill wrote: > > + else if (VAR_P (decl) > > + && CP_DECL_THREAD_LOCAL_P (decl) > > + && (!DECL_EXTERNAL (decl) || flag_extern_tls_init) > > Hmm, I wonder why we don't check the above line in var_needs_tls_wrapper? It is tes

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

On 3/18/23 11:09, Jakub Jelinek wrote: On Sat, Mar 18, 2023 at 01:54:58PM +0100, Jakub Jelinek via Gcc-patches wrote: The patch is mostly about DECL_EXTERNAL cases, the others are supposedly handled by the var_definition_p code there (or at least I assumed; testcases certainly test only DECL_EXT

Re: [PATCH] c++: explicit ctor and list-initialization [PR109159]

On 3/20/23 11:55, Marek Polacek wrote: When I implemented explicit(bool) in r9-3735, I added this code to add_template_candidate_real: + /* Now the explicit specifier might have been deduced; check if this + declaration is explicit. If it is and we're ignoring non-converting + construct

Re: [PATCH] fix for __sanitizer_struct_mallinfo with mallinfo2

On Sun, Mar 19, 2023 at 11:08 PM Reini Urban via Gcc-patches wrote: > > Fix sanititzers with mallinfo2 > e.g fedora already uses mallinfo2 with long v[10]; Parts of these patches should go upstream first. Thanks, Andrew > > -- > Reini Urban

Re: [PATCH] libstdc++: Fix handling of surrogate CP in codecvt [PR108976]

On Mon, 2023-03-20 at 15:21 +, Jonathan Wakely wrote: > > Thanks, the patch looks OK to my uninformed eye, but I'm seeing a new > regression: > > /home/jwakely/src/gcc/gcc/libstdc++- > v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc:86: void > test06(): Assertion 'result == u"from_bytes

Re: [PATCH V4] Rework 128-bit complex multiply and divide.

On Fri, Mar 17, 2023 at 02:35:16PM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Mar 09, 2023 at 08:40:36PM -0500, Michael Meissner wrote: > > PR target/109067 > > * config/rs6000/rs6000.cc (create_complex_muldiv): Delete. > > (init_float128_ieee): Delete code to switch complex mu

Re: [PATCH] range-op-float: Fix up -ffinite-math-only range extension and don't extend into infinities [PR109008]

On Mon, Mar 13, 2023 at 09:41:47AM +0100, Aldy Hernandez wrote: > On 3/13/23 09:06, Jakub Jelinek wrote: > > On Mon, Mar 13, 2023 at 08:59:15AM +0100, Aldy Hernandez wrote: > > > > Yes, sure - I just noticed that we're forced to use high-level API for > > > > something that's quite low-level and sh

[PATCH] c++: explicit ctor and list-initialization [PR109159]

When I implemented explicit(bool) in r9-3735, I added this code to add_template_candidate_real: + /* Now the explicit specifier might have been deduced; check if this + declaration is explicit. If it is and we're ignoring non-converting + constructors, don't add this function to the set o

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

On Sat, Mar 18, 2023 at 04:09:55PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Sat, Mar 18, 2023 at 01:54:58PM +0100, Jakub Jelinek via Gcc-patches wrote: > > The patch is mostly about DECL_EXTERNAL cases, the others are supposedly > > handled by the var_definition_p code there (or at least I

Re: [PATCH] libstdc++: use new built-in trait __is_reference

On Mon, Mar 20, 2023 at 5:56 AM Ken Matsui wrote: > > > Does it actually make compilation faster though? > > > > Has it been measured? > > In my understanding, what I have implemented so far is so simple that > it does not affect the speed. These traits are what Partick kindly > recommended to get

Re: [PATCH] libstdc++: Fix handling of surrogate CP in codecvt [PR108976]

On Wed, 8 Mar 2023 at 14:09, Dimitrij Mijoski via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This patch fixes the handling of surrogate code points in all standard > facets for transcoding Unicode that are based on std::codecvt. Surrogate > code points should always be treated as error. On the ot

Re: [PATCH v2 1/2] libstdc++: use copy_file_range, improve sendfile in filesystem::copy_file

On Mon, 20 Mar 2023 at 15:16, Jonathan Wakely wrote: > > > On Wed, 15 Mar 2023 at 19:30, Jannik Glückert via Libstdc++ < > libstd...@gcc.gnu.org> wrote: > >> This iteration improves error handling for copy_file_range, >> particularly around undocumented error codes in earlier kernel >> versions. >

Re: [PATCH v2 1/2] libstdc++: use copy_file_range, improve sendfile in filesystem::copy_file

On Wed, 15 Mar 2023 at 19:30, Jannik Glückert via Libstdc++ < libstd...@gcc.gnu.org> wrote: > This iteration improves error handling for copy_file_range, > particularly around undocumented error codes in earlier kernel > versions. > Additionally this fixes the userspace copy fallback to handle > z

Re: [committed] Docs: Fix formatting issues in BPF built-ins documentation

Hi Sandra. > This section of the GCC manual had some issues with lines in the > example overflowing into the right margin of the PDF-format document, > but as I looked at it more closely I also saw that it was full of > missing or incorrect Texinfo markup, too. I've cleaned it up thusly. Thank

Re: [PATCH v1] [RFC] Improve folding for comparisons with zero in tree-ssa-forwprop.

On Fri, Mar 17, 2023 at 10:31 AM Richard Biener wrote: > > On Thu, Mar 16, 2023 at 4:27 PM Manolis Tsamis > wrote: > > > > For this C testcase: > > > > void g(); > > void f(unsigned int *a) > > { > > if (++*a == 1) > > g(); > > } > > > > GCC will currently emit a comparison with 1 by using

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

Thank you! On Mon, Mar 20, 2023 at 2:12 AM Jonathan Wakely wrote: > On Mon, 20 Mar 2023 at 08:08, Ken Matsui > wrote: > > > > Ooh... Thank you for pointing that out! > > > > > The helper doesn't need to be defined for the case where we don't use > it. > > > > I thought that macroing them out le

Re: [PATCH] c++: implement __is_reference built-in trait

I created new patches which is a series, but I couldn't figure out how to associate them with this email and another email. Please disregard this email. On Sun, Mar 19, 2023 at 1:19 PM Ken Matsui wrote: > > * cp-trait.def (names_builtin_p): Define __is_reference. > > This changelog should be the

Re: [PATCH] tree-optimization/109170 - bogus use-after-free with __builtin_expect

On Mon, Mar 20, 2023 at 12:12:14PM +, Richard Biener wrote: > PR tree-optimization/109170 > * gimple-range-op.cc (cfn_pass_through_arg1): New. > (gimple_range_op_handler::maybe_builtin_call): Handle > __builtin_expect and similar via cfn_pass_through_arg1 > and ins

Re: [PATCH] libstdc++: use new built-in trait __is_reference

It looks like I was able to use git send-email. The new patches became a series, so I couldn't figure out how to associate them with this email and another email. Please disregard this email. On Mon, Mar 20, 2023 at 2:56 AM Ken Matsui wrote: > > > Does it actually make compilation faster though?

[PATCH 2/2] libstdc++: use new built-in trait __is_reference

This patch lets libstdc++ use new built-in trait __is_reference. libstdc++-v3/ChangeLog: * include/std/type_traits (is_reference): Use __is_reference built-in trait. --- libstdc++-v3/include/std/type_traits | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libstdc++-v3/include/

[PATCH 1/2] c++: implement __is_reference built-in trait

This patch implements built-in trait for std::is_reference. gcc/cp/ChangeLog: * cp-trait.def: Define __is_reference. * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_REFERENCE. * semantics.cc (trait_expr_value): Likewise. (finish_trait_expr): Likewise. gcc/te

Re: [PATCH] tree-optimization/109170 - bogus use-after-free with __builtin_expect

On Mon, 20 Mar 2023, Richard Biener wrote: > On Fri, 17 Mar 2023, Jakub Jelinek wrote: > > > On Fri, Mar 17, 2023 at 02:18:52PM +, Richard Biener wrote: > > > > And as you show on the testcases, it probably isn't a good idea for > > > > BUILT_IN_EXPECT* either. > > > > > > > > So, perhaps us

Re: [PATCH] New testcase

On Mon, 20 Mar 2023, Jakub Jelinek wrote: > On Tue, Mar 14, 2023 at 07:29:19AM +, Richard Biener via Gcc-patches > wrote: > > This is a reduced testcase for an issue I ran into when trying to > > improve PTA compile-time further, there wasn't any C family runfail > > in the testsuite for this

Re: [RFC] internal documentation for OMP_FOR

Hi Sandra, https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612298.html On 19.02.23 06:21, Sandra Loosemore wrote: Here is a patch I put together for the internals manual; can other people familiar with this functionality review it for technical correctness? Glancing at it, it seems t

Re: [PATCHv3, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

Hi, sorry for the belated reply. On 07.03.23 09:55, HAO CHEN GUI wrote: 2023-03-07 Haochen Gui gcc/ PR target/103628 * fortran/target-memory.cc (gfc_interpret_float): Return FAIL when native_interpret_expr gets a NULL tree. * fortran/arith.cc (gfc_hollerith2real): Ret

Re: [PATCH] New testcase

On Tue, Mar 14, 2023 at 07:29:19AM +, Richard Biener via Gcc-patches wrote: > This is a reduced testcase for an issue I ran into when trying to > improve PTA compile-time further, there wasn't any C family runfail > in the testsuite for this. > > Pushed. > > * g++.dg/torture/20230313.C:

Re: [PATCH] libstdc++: use new built-in trait __is_reference

> Does it actually make compilation faster though? > > Has it been measured? In my understanding, what I have implemented so far is so simple that it does not affect the speed. These traits are what Partick kindly recommended to get started. As explained on the GSoC page, some traits might involve

Re: [RFC/PATCH] sched: Consider debug insn in no_real_insns_p [PR108273]

Hi Alexander, Thanks a lot for your comments and suggestions! on 2023/3/20 16:03, Alexander Monakov wrote: > > On Mon, 20 Mar 2023, Kewen.Lin wrote: > >> Hi, > > Hi. Thank you for the thorough analysis. Since I analyzed > PR108519, I'd like to offer my comments. > >> As PR108273 shows, when t

Re: [PATCH] driver: Treat include path args the same way between cpp_unique_options and asm_options. [PR71850]

ping On Thu, 9 Mar 2023 at 13:39, Costas Argyris wrote: > Pinging list and driver reviewer. > > Details here: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850 > > On Thu, 2 Mar 2023 at 19:25, Costas Argyris > wrote: > >> This is a proposal to fix PR71850 by applying the existing logic for

[committed] libstdc++: Remove template-head from std::expected ctor [PR109182]

Tested x86_64-linux. Pushed to trunk. Will backport to gcc-12 too. -- >8 -- The presence of a template-head on this constructor is a copy & paste error from the primary template. libstdc++-v3/ChangeLog: PR libstdc++/109182 * include/std/expected (expected::expected(in_place_t)):

Re: [PATCH] libstdc++: use new built-in trait __is_reference

On Mon, 20 Mar 2023 at 08:08, Xi Ruoyao via Libstdc++ wrote: > > On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote: > > Oops, I assumed those were my email... Thank you for your heads up and > > your comments! > > > > > Bad ChangeLog format. You should have a tab (not 4 or 8 spaces, nor > > > n

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

On Mon, 20 Mar 2023 at 08:08, Ken Matsui wrote: > > Ooh... Thank you for pointing that out! > > > The helper doesn't need to be defined for the case where we don't use it. > > I thought that macroing them out leads to compiler errors since users > are possibly using those helpers. But do we not ha

Re: [PATCH] tree-optimization/106912 - IPA profile and pure/const

On Fri, 17 Mar 2023, Jakub Jelinek wrote: > On Fri, Mar 17, 2023 at 08:40:34PM +0100, Jan Hubicka wrote: > > > + /* Drop the const attribute from the call type (the pure > > > +attribute is not available on types). */ > > > + tree fntype = gimple_call_fntype (call); >

Re: [PATCH] libstdc++: use new built-in trait __is_reference

Thank you! On Mon, Mar 20, 2023 at 1:07 AM Xi Ruoyao wrote: > > On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote: > > Oops, I assumed those were my email... Thank you for your heads up and > > your comments! > > > > > Bad ChangeLog format. You should have a tab (not 4 or 8 spaces, nor > > > n

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

Ooh... Thank you for pointing that out! > The helper doesn't need to be defined for the case where we don't use it. I thought that macroing them out leads to compiler errors since users are possibly using those helpers. But do we not have to care about that? --- libstdc++-v3/ChangeLog: * includ

Re: [PATCH] libstdc++: use new built-in trait __is_reference

On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote: > Oops, I assumed those were my email... Thank you for your heads up and > your comments! > > > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor > > nothing) to indent the ChangeLog content. > > Do you mean like the followin

Re: [PATCH] libstdc++: use new built-in trait __is_reference

Oops, I assumed those were my email... Thank you for your heads up and your comments! > Bad ChangeLog format. You should have a tab (not 4 or 8 spaces, nor > nothing) to indent the ChangeLog content. Do you mean like the following? ``` libstdc++-v3/ChangeLog: [TAB]* include/std/type_traits (is

Re: [RFC/PATCH] sched: Consider debug insn in no_real_insns_p [PR108273]

On Mon, 20 Mar 2023, Kewen.Lin wrote: > Hi, Hi. Thank you for the thorough analysis. Since I analyzed PR108519, I'd like to offer my comments. > As PR108273 shows, when there is one block which only has > NOTE_P and LABEL_P insns at non-debug mode while has some > extra DEBUG_INSN_P insns at d

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

On Mon, 20 Mar 2023, 07:32 Ken Matsui via Libstdc++, wrote: > CCing libstd...@gcc.gnu.org. > > On Sun, Mar 19, 2023 at 7:53 PM Ken Matsui > wrote: > > > > libstdc++-v3/ChangeLog: > > > > * include/std/type_traits (is_reference): Use __remove_pointer built-in > trait. > The changelog entry says

Re: [PATCH] libstdc++: use new built-in trait __is_reference

On Mon, 2023-03-20 at 00:30 -0700, Ken Matsui wrote: > I see. Thank you! Please continue to read. I guess you missed some inline comments from me... > > On Mon, Mar 20, 2023 at 12:26 AM Xi Ruoyao wrote: > > > > You need to CC libstd...@gcc.gnu.org for any patches touching > > libstdc++. > >

[PATCH] c++: implement __add_pointer built-in trait

This patch implements built-in trait for std::add_pointer. gcc/cp/ChangeLog: * cp-trait.def: Define __add_pointer. * semantics.cc (finish_trait_type): Handle CPTK_ADD_POINTER. gcc/testsuite/ChangeLog: * g++.dg/ext/has-builtin-1.C: Test existence of __add_pointer. * g++.dg/ext/add_pointer.C: New

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

CCing libstd...@gcc.gnu.org. On Sun, Mar 19, 2023 at 7:53 PM Ken Matsui wrote: > > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_reference): Use __remove_pointer built-in trait. > > --- > diff --git a/libstdc++-v3/include/std/type_traits > b/libstdc++-v3/include/std/type_traits > inde

Re: [PATCH] libstdc++: use new built-in trait __is_reference

I see. Thank you! On Mon, Mar 20, 2023 at 12:26 AM Xi Ruoyao wrote: > > You need to CC libstd...@gcc.gnu.org for any patches touching libstdc++. > > On Sat, 2023-03-18 at 21:21 -0700, Ken Matsui via Gcc-patches wrote: > > libstdc++-v3/ChangeLog: > > > > * include/std/type_traits (is_reference): U

Re: [PATCH] libstdc++: use new built-in trait __is_reference

You need to CC libstd...@gcc.gnu.org for any patches touching libstdc++. On Sat, 2023-03-18 at 21:21 -0700, Ken Matsui via Gcc-patches wrote: > libstdc++-v3/ChangeLog: > > * include/std/type_traits (is_reference): Use __is_reference built-in > trait. Bad ChangeLog format. You should have a tab

Re: [patch, fortran, doc] Explicitly mention undefined overflow

I wrote: Yes, that's fine for trunk. I wonder if it is worth being explicit that linear congruential pseudo-random number generators can and do fail at -O3? I don't think we should put this into the docs, because that can change at any time.  Maybe into porting_to.html, though (where I have