Re: Fwd: [PATCH v3] C: Support Function multiversionsing in the C front end

On Mon, 11 Nov 2024, Alfie Richards wrote: > I see this code is very unclear in hindsight. The logic of this code > relies on that FMV functions are only allowed at file scope. > This should have a DECL_FILE_SCOPE_P check to avoid some of the ridiculous > cases you mentioned. If you have an actua

Fwd: [PATCH v3] C: Support Function multiversionsing in the C front end

Adding missing CC's Forwarded Message Subject: Re: [PATCH v3] C: Support Function multiversionsing in the C front end Date: Mon, 11 Nov 2024 12:29:57 + From: Alfie Richards To: Joseph Myers Hi Joseph, Thank you for the detailed feedback. I am quite junior a

Fwd: [PATCH] PR target/117449: Restrict vector rotate match and split to pre-reload

Forwarding to the correct ML... > Begin forwarded message: > > From: Kyrylo Tkachov via Gcc > Subject: [PATCH] PR target/117449: Restrict vector rotate match and split to > pre-reload > Date: 5 November 2024 at 17:57:40 GMT+1 > To: gcc mailing list > Reply-To: Kyrylo Tkachov > > Hi all, > > Th

Fwd: [patch, fortran] Implement maxloc and minloc for unsigned

Hello world, the original messages seems to have been rejected because the patch was too big. The patch (wich was not rejected for fortran@) can be found at https://gcc.gnu.org/pipermail/fortran/2024-October/061127.html Weitergeleitete Nachricht Betreff: [patch, fortran] Imple

Re: Fwd: [patch, fortran] Matmul and dot_product for unsigned

Le 27/09/2024 à 17:08, Thomas Koenig a écrit : Hi Mikael, Now for the remaining intrinsics (FINDLOC, MAXLOC, MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing). I have one patch series touching (inline) MINLOC and MAXLOC to post in the coming days.  Could you please keep away from them

Re: Fwd: [patch, fortran] Matmul and dot_product for unsigned

Hi Mikael, Now for the remaining intrinsics (FINDLOC, MAXLOC, MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing). I have one patch series touching (inline) MINLOC and MAXLOC to post in the coming days.  Could you please keep away from them for one more week or two? Looking at the pre

Re: Fwd: [patch, fortran] Matmul and dot_product for unsigned

Le 26/09/2024 à 21:57, Thomas Koenig a écrit : Now for the remaining intrinsics (FINDLOC, MAXLOC, MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing). I have one patch series touching (inline) MINLOC and MAXLOC to post in the coming days. Could you please keep away from them for one mor

Fwd: [patch, fortran] Matmul and dot_product for unsigned

[I just saw I hit the wrong reply button on this] Hi Andre, thanks for your answers. I am ok with the patch. I have committed all four patches. Thanks a lot for the reviews! Now for the remaining intrinsics (FINDLOC, MAXLOC, MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing). And af

Re: Fwd: [PATCH] Don't force-enable ifuncs on RISC-V

On 7/18/24 12:25 PM, Jeff Law wrote: On 7/18/24 4:09 AM, Maxim Blinov wrote: Let the user turn off ifunc support at configure time if they want to. Currently, the logic in gcc/autoconf.ac will override the default logic in gcc/config.gcc. gcc/ChangeLog: * config.gcc: Default-enable i

Re: Fwd: [PATCH] Don't force-enable ifuncs on RISC-V

On 7/18/24 4:09 AM, Maxim Blinov wrote: Let the user turn off ifunc support at configure time if they want to. Currently, the logic in gcc/autoconf.ac will override the default logic in gcc/config.gcc. gcc/ChangeLog: * config.gcc: Default-enable ifunc support for RISC-V on Linux. *

Re: Fwd: [PATCH] Don't force-enable ifuncs on RISC-V

On Jul 18 2024, Maxim Blinov wrote: > +if test $default_gnu_indirect_function = yes; then > + case "${target}" in > +riscv*-*-linux*) > + AC_MSG_CHECKING(linker ifunc IRELATIVE support) > + cat > conftest.s < + .text > + .typefoo_resolver, @function > + foo_resolver:

Fwd: [PATCH] Don't force-enable ifuncs on RISC-V

Let the user turn off ifunc support at configure time if they want to. Currently, the logic in gcc/autoconf.ac will override the default logic in gcc/config.gcc. gcc/ChangeLog: * config.gcc: Default-enable ifunc support for RISC-V on Linux. * autoconf.ac: Honor the default_gnu_indirect_fu

Re: Fwd: [PATCH 2/7 v2] lto: Remove random_seed from section name.

> This patch removes suffixes from section names during LTO linking. > > These suffixes were originally added for ld -r to work (PR lto/44992). > They were added to all LTO object files, but are only useful before WPA. > After that they waste space, and if kept random, make LTO caching > impossibl

Fwd: [PATCH V2 0/4] Add DF_LIVE_SUBREG data and apply to IRA and LRA

I am resending this message as the previous one had one wrong response email address "gcc-pat...@gcc.gnu.org" Forwarded Message Subject: Re: [PATCH V2 0/4] Add DF_LIVE_SUBREG data and apply to IRA and LRA Date: Wed, 1 May 2024 08:35:27 -0400 From: Vladimir Makarov To:

Fwd: [PATCH v3] combine: Fix ICE in try_combine on pr112494.c [PR112560]

Forgot to CC gcc-patches@ ML... sorry for the duplicate... The compiler, configured with --enable-checking=yes,rtl,extra ICEs with: internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in try_combine, at combine.cc:3237 This is 3236 /* Just repl

Fwd: [Bug libstdc++/90276] PSTL tests fail in Debug Mode

I replied to bugzilla rather than sending to proper mailing list ! At the same time it looks like you also found the root cause of the problem Jonathan. Just let me know if you want to deal with it eventually. François Forwarded Message Subject:Re: [Bug libstdc++/90

Fwd: [PATCH V2] rs6000: New pass for replacement of adjacent loads fusion (lxv).

Hello All: New pass to replace adjacent memory addresses lxv with lxvp. Added common infrastructure for load store fusion for different targets. Common routines are refactored in fusion-common.h. AARCH64 load/store fusion pass is not changed with the common infrastructure. For AARCH64 archit

Fwd: [PATCH] libstdc++: use updated type for __unexpected_handler

Forwarding since I forgot to add gcc-patches in the original mail. Sorry for the noise. -- >8 -- Commit f4130a3eb545ab1aaf3ecb44f3d06b43e3751e04 changed the type of __expected_handler in libsupc++/unwind-cxx.h to be a std::terminate_handler to avoid a deprecated warning. However, the definition i

Fwd: [PATCH] gprofng: a new GNU profiler

PING. If the patch is approved, can anyone apply this patch. I don't have permissions for `git push`. Thank you, -Vladimir Forwarded Message Subject:[PATCH] gprofng: a new GNU profiler Date: Wed, 13 Dec 2023 17:23:01 -0800 From: vladimir.mezent...@oracle.com To:

Re: Fwd: [PATCH] LoongArch: Fix FP vector comparsons [PR113034]

On Tue, 2023-12-19 at 17:15 +0800, Chenghui Pan wrote: > Hi, I checked the correctness of spec2017 and regression test of gcc, it > seems ok! /* snip */ > > For every RTX code for which the LSX/LASX code is different from the > > scalar code, the scalar code is correct and the LSX/LASX code is w

Re: Fwd: [PATCH] LoongArch: Fix FP vector comparsons [PR113034]

Hi, I checked the correctness of spec2017 and regression test of gcc, it seems ok! On 2023/12/18 17:04, chenglulu wrote: 转发的消息 主题: [PATCH] LoongArch: Fix FP vector comparsons [PR113034] 日期: Sun, 17 Dec 2023 23:12:18 +0800 发件人:Xi Ruoyao 收件人:gcc-patches@gcc.gnu.

Re: Fwd: [PATCH v2] extend.texi: Fix typos in LSX intrinsics

在 2023-12-14四的 20:27 +0800，chenglulu写道： > > > > > > > > 转发的消息 > > > > 主题: > [PATCH v2] extend.texi: Fix typos in LSX intrinsics > > > 日期: > Wed, 13 Dec

Re: Fwd: [PATCH, expand] Call misaligned memory reference in expand_builtin_return [PR112417]

On Mon, Nov 13, 2023 at 9:09 AM HAO CHEN GUI wrote: > > Sorry, forgot to cc gcc-patches. > > 在 2023/11/13 16:05, HAO CHEN GUI 写道: > > Andrew, > > Could you kindly inform us what's the functionality of __objc_forward? > > Does it change the memory content pointed by args? Thanks a lot. > > > > Th

Re: Fwd: [PATCH, expand] Call misaligned memory reference in expand_builtin_return [PR112417]

Sorry, forgot to cc gcc-patches. 在 2023/11/13 16:05, HAO CHEN GUI 写道: > Andrew, > Could you kindly inform us what's the functionality of __objc_forward? > Does it change the memory content pointed by args? Thanks a lot. > > Thanks > Gui Haochen > > > libobjc/sendmsg.c. > >void *args, *re

Fwd: [PING][PATCH V15 4/4] ree: Improve ree pass using defined abi interfaces

Ping! Ok for trunk. Thanks & Regards Ajit Forwarded Message Subject: [PATCH V15 4/4] ree: Improve ree pass using defined abi interfaces Date: Sun, 29 Oct 2023 16:14:17 +0530 From: Ajit Agarwal To: gcc-patches , Jeff Law , Vineet Gupta , Bernhard Reutner-Fischer CC: Richard

Ping * 2 : Fwd: [V9][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

Hi, I’d like to ping this patch again for the Middle-end approval (on gcc/tree-object-size.cc change). This is an important patch to Linux Kernel security. The patch has addressed all the comments and suggestions raised during the review process. The C FE, Doc changes has been approved. Most

Fwd: [PATCH] analyzer: Standalone OOB-warning [PR109437, PR109439]

Hi David, So first real committed patch actually was a misstep. So I'm currently fixing that. The issue is that the original idea, to return a boolean and create a unknown_svalue on OOB access to prevent further "use-of-uninitialized-value" caused a loss of information on the location of the buffe

Fwd: [PATCH][RFC] c++: Accept elaborated-enum-base in system headers

> Begin forwarded message: > > From: Jason Merrill > Subject: Re: [PATCH][RFC] c++: Accept elaborated-enum-base in system headers > Date: 8 June 2023 at 19:06:36 BST > To: Alex Coplan , gcc-patches@gcc.gnu.org > Cc: Nathan Sidwell , Iain Sandoe > > On 6/8/23 07:06, Alex Coplan wrote: >> Hi,

Ping: Fwd: [V9][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

Ping on this patch. The C FE and Doc changes has been approved. Please help to review and approve the Middle-end change. Or provide guide on how to move this patch forward. Thanks a lot for the help. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V9][PAT

Ping * 3: Fwd: [V6][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

This is the 3rd ping for the 6th version of the patches. Now, GCC14 is open. Is it ready to commit these patches to GCC14? Kees has tested this version of the patch with Linux kernel, and everything is good, and relsolved many false positives for bounds checking. Note for the review history of

Fwd: [V6][PATCH 2/2] Update documentation to clarify a GCC extension

@gcc.gnu.org>> Subject: Fwd: [V6][PATCH 2/2] Update documentation to clarify a GCC extension Date: April 4, 2023 at 9:07:55 AM EDT To: Joseph Myers mailto:jos...@codesourcery.com>> Cc: Jakub Jelinek mailto:ja...@redhat.com>>, Richard Biener mailto:richard.guent...@gmail.com>>,

Fwd: [V6][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

@gcc.gnu.org>> Subject: Fwd: [V6][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] Date: April 4, 2023 at 9:06:37 AM EDT To: Jakub Jelinek mailto:ja...@redhat.com>> Cc: Joseph Myers mailto:jos...@codesourcery.com>>

Fwd: [V6][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

Hi, Joseph and Jakub, This is the 2nd ping to the 6th version of the patches -:) Please let me know if you have any further comments on the patches, and whether it’s Okay to commit them to trunk? Thanks a lot for the help. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle

Fwd: [V6][PATCH 2/2] Update documentation to clarify a GCC extension

Ping…. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [PATCH 2/2] Update documentation to clarify a GCC extension Date: March 28, 2023 at 11:49:44 AM EDT To: ja...@redhat.com, jos...@codesourcery.com

Fwd: [V6][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

Ping… Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V6][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] Date: March 28, 2023 at 11:49:43 AM EDT To: ja...@redhat.com, jos...@cod

Re: Fwd: [V5][PATCH 2/2] Update documentation to clarify a GCC extension

On Thu, 23 Mar 2023, Qing Zhao via Gcc-patches wrote: > +Wgnu-variable-sized-type-not-at-end > +C C++ Var(warn_variable_sized_type_not_at_end) Warning > +Warn about structures or unions with C99 flexible array members are not > +at the end of a structure. I think there's at least one word missing

Re: Fwd: [V5][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

On Thu, 23 Mar 2023, Qing Zhao via Gcc-patches wrote: > gcc/c/ChangeLog: > > PR tree-optimization/101832 > * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for > struct/union type. The C front-end changes are OK (supposing the original patch has correct whitespace, sinc

Fwd: [V5][PATCH 2/2] Update documentation to clarify a GCC extension

Ping… Please let me know if you have any further comments on the patch. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V5][PATCH 2/2] Update documentation to clarify a GCC extension Date: March 16, 2023 at 5:47:15 PM EDT To: jos...@codesourcery.co

Fwd: [V5][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

Ping… Please let me know if you have any further comments on the patch. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V5][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] Date: March 16, 2023

Fwd: [V5][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

Ping… Please let me know if you have any further comments on the patch. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V5][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size Date: March 16, 2023 at 5:

Re: Now gcc-13: [Fwd: [PATCH] gcc-12: Re-enable split-stack support for GNU/Hurd.]

On Wed, Mar 15, 2023 at 9:14 AM Svante Signell wrote: > > Package: gcc-snapshot > Version: 1:20230315-1 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > Usertags: hurd > Affects: gcc-snapshot > X-Debbugs-CC: debian-h...@lists.debian.org > > Hello, seems like the patch gcc

Now gcc-13: [Fwd: [PATCH] gcc-12: Re-enable split-stack support for GNU/Hurd.]

Package: gcc-snapshot Version: 1:20230315-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Affects: gcc-snapshot X-Debbugs-CC: debian-h...@lists.debian.org Hello, seems like the patch gcc_config_gnu.h.diff, in debian gcc-12 named: pr104290-followup.diff was lost

Re: Fwd: [PATCHJ]: Bugzilla 88860 - Clarify online manual infelicities

On 3/1/23 05:54, Jonny Grant wrote: Hello I don't have write access, could someone review and apply this please? Done. Edited the ChangeLog a bit and pushed to the trunk. Thanks, jeff

Re: Fwd: Bugzilla Bug 81649 [PATCH]: Clarify LeakSanitizer in documentation

On 07/03/2023 23:42, Sandra Loosemore wrote: > On 3/1/23 05:53, Jonny Grant wrote: >> Hello >> I don't have write access, could someone review and apply this please? >> Kind regards >> Jonny > > Looks good; I've gone ahead and pushed it for you. > > -Sandra Awesome - thank you. My first gcc p

Re: Fwd: Bugzilla Bug 81649 [PATCH]: Clarify LeakSanitizer in documentation

On 3/1/23 05:53, Jonny Grant wrote: Hello I don't have write access, could someone review and apply this please? Kind regards Jonny Looks good; I've gone ahead and pushed it for you. -Sandra

Fwd: [PATCHJ]: Bugzilla 88860 - Clarify online manual infelicities

Hello I don't have write access, could someone review and apply this please? Kind regards Jonny Forwarded Message Subject: [PATCHJ]: Bugzilla 88860 - Clarify online manual infelicities Date: Mon, 26 Dec 2022 21:00:05 + From: Jonny Grant To: gcc-patches@gcc.gnu.org 2022-1

Fwd: Bugzilla Bug 81649 [PATCH]: Clarify LeakSanitizer in documentation

Hello I don't have write access, could someone review and apply this please? Kind regards Jonny Forwarded Message Subject: Bugzilla Bug 81649 [PATCH]: Clarify LeakSanitizer in documentation Date: Mon, 26 Dec 2022 20:50:23 + From: Jonny Grant To: gcc-patches@gcc.gnu.org M

Fwd: [PATCH] update copyright year in libstdcc++ manual

Hello I don't have write access, could someone review and apply this? Kind regards Jonny Forwarded Message Subject: [PATCH] update copyright year in libstdcc++ manual Date: Fri, 30 Dec 2022 10:30:22 + From: Jonny Grant To: gcc-patches@gcc.gnu.org CC: Jonny Grant 2022-12-3

Re: Fwd: [V2][PATCH] Fixing PR107411

On Mon, 27 Feb 2023, Qing Zhao wrote: > Ping. OK. Thanks, Richard. > Qing > > Begin forwarded message: > > From: Qing Zhao mailto:qing.z...@oracle.com>> > Subject: [V2][PATCH] Fixing PR107411 > Date: February 21, 2023 at 9:46:04 AM EST > To: ja...@redhat.com, > rguen

Fwd: [V2][PATCH] Fixing PR107411

Ping. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [V2][PATCH] Fixing PR107411 Date: February 21, 2023 at 9:46:04 AM EST To: ja...@redhat.com, rguent...@suse.de Cc: gcc-patches@gcc.gnu.org

Re: Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > +@item > +The structure with a C99 flexible array member is the field of > +another union, for example: > + > +@smallexample > +struct flex1 @{ int length1; char data1[]; @} > +struct flex2 @{ int length2; char data2[]; @} > + > +union out_

Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

Ping * 2. Hi, Joseph and Richard, Could you please review this patch and let me know whether it’s ready for committing into GCC13? thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR7

Fwd: [v3][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

Ping * 2. Hi, Joseph and Richard, Could you please review this patch and let me know whether it’s ready for committing into GCC13? This is an important bug that need to be fixed for kernel security purpose. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>>

Fwd: [PATCH] libstdc++: Add error handler for

Weitergeleitete Nachricht Betreff: [PATCH] libstdc++: Add error handler for Datum: Tue, 29 Nov 2022 22:41:07 +0100 Von: Björn Schäpers An: gcc-patc...@gc.gnu.org, libstd...@gcc.gnu.org From: Björn Schäpers Not providing an error handler results in a nullpointer dereferen

Re: Fwd: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote: > Hi, Joseph and Nathan, > > Could you please review the C and C++ FE parts of the patch? > > https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html I think some work is still needed on the diagnostic wording. > + "%qE attribute

Fwd: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Hi, Joseph and Nathan, Could you please review the C and C++ FE parts of the patch? https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html The middle-end changes have been approved by Richard already. https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600379.html Thanks. Begin

Fwd: RFA: crc builtin functions & optimizations

Oops, that was meant to go to the list too. On Tue, 15 Mar 2022 at 01:04, Andrew Pinski wrote: > > On Mon, Mar 14, 2022 at 5:33 PM Joern Rennecke > wrote: > > > > Most microprocessors have efficient ways to perform CRC operations, be > > that with lookup tables, rotates, or even special instruc

Fwd: [PATCH 2/2][middle-end/102276] Adding -Wtrivial-auto-var-init and update documentation.

Ping... Qing Begin forwarded message: From: Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> Subject: [PATCH 2/2][middle-end/102276] Adding -Wtrivial-auto-var-init and update documentation. Date: February 19, 2022 at 10:24:09 AM CST To: richard Biener mailto:rguent...@suse.de>>, Jaku

Fwd: [PATCH 1/2][middle-end/102276] Don't emit switch-unreachable warnings for -ftrivial-auto-var-init (PR102276)

Ping. Qing Begin forwarded message: From: Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> Subject: [PATCH 1/2][middle-end/102276] Don't emit switch-unreachable warnings for -ftrivial-auto-var-init (PR102276) Date: February 19, 2022 at 10:22:43 AM CST To: richard Biener mailto:rguent

Fwd: [PATCH 2/4] tree-optimization/104288 - Register side effects during ranger vrp domwalk.

bah.. wrong reply function Forwarded Message Subject: Re: [PATCH 2/4] tree-optimization/104288 - Register side effects during ranger vrp domwalk. Date: Tue, 8 Feb 2022 09:52:49 -0500 From: Andrew MacLeod To: Richard Biener On 2/8/22 03:14, Richard Biener wrote:

Fwd: [committed] libstdc++: Improve generated man pages for libstdc++

I messed up the CC to gcc-patches for this. And I forgot to mention in the commit msg that the reason I started looking at stdheader.cc in the first place was to fix a use-after-free bug in the old code: -// come on, gdb, find `p' already... -const char* p = longheader.substr(start).c_str

Fwd: [committed] libstdc++: Add Doxygen comments to contents of

I messed up the CC to gcc-patches for this ... -- Forwarded message - From: Jonathan Wakely via Libstdc++ Date: Thu, 21 Oct 2021 at 22:57 Subject: [committed] libstdc++: Add Doxygen comments to contents of To: , Tested x86_64-linux, committed to trunk. libstdc++-v3/ChangeLog:

Fwd: [committed] libstdc++: Suppress Doxygen docs for more implementation details

I messed up the CC to gcc-patches for this ... -- Forwarded message - From: Jonathan Wakely via Libstdc++ Date: Thu, 21 Oct 2021 at 22:56 Subject: [committed] libstdc++: Suppress Doxygen docs for more implementation details To: , Tested x86_64-linux, committed to trunk. libstd

Fwd: [PATCH][testsuite][aarch64]: Fix gcc.target/aarch64/auto-init-* tests.

Ping… Qing Begin forwarded message: From: Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> Subject: [PATCH][testsuite][aarch64]: Fix gcc.target/aarch64/auto-init-* tests. Date: September 21, 2021 at 2:20:58 PM CDT To: gcc-patches Nick Alcock via mailto:gcc-patches@gcc.gnu.org>> Reply

Fwd: [PUSHED] Skip out on processing __builtin_clz when varying.

Ping*2 -- Forwarded message - From: Aldy Hernandez Date: Thu, May 13, 2021, 20:02 Subject: Re: [PUSHED] Skip out on processing __builtin_clz when varying. To: Jakub Jelinek Cc: GCC patches On 5/12/21 5:08 PM, Jakub Jelinek wrote: > On Wed, May 12, 2021 at 05:01:00PM -0400, A

Fwd: Re: [PATCH] plug memory leaks in warn_parm_array_mismatch (PR 99055)

On 2/11/21 12:59 AM, Richard Biener wrote: On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor wrote: The attached patch replaces calls to print_generic_expr_to_str() with a helper function that returns a std::string and releases the caller from the responsibility to explicitly free memory. I don't

Re: Fwd: libstdc++: Attempt to resolve PR83562

On 11/6/20 8:34 AM, Martin Storsjö wrote: On Fri, 6 Nov 2020, Liu Hao via Gcc-patches wrote: 在 2020/10/29 下午3:56, Liu Hao 写道: I forward it here for comments. Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is used to register the destructor of thread_local objects directl

Re: Fwd: libstdc++: Attempt to resolve PR83562

On Fri, 6 Nov 2020, Liu Hao via Gcc-patches wrote: 在 2020/10/29 下午3:56, Liu Hao 写道: I forward it here for comments. Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is used to register the destructor of thread_local objects directly, suggesting the first parameter should h

Re: Fwd: libstdc++: Attempt to resolve PR83562

Ping? 在 2020/10/29 下午3:56, Liu Hao 写道: > I forward it here for comments. > > Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is used > to register the > destructor of thread_local objects directly, suggesting the first parameter > should have `__thiscall` > convention.

Fwd: libstdc++: Attempt to resolve PR83562

I forward it here for comments. Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is used to register the destructor of thread_local objects directly, suggesting the first parameter should have `__thiscall` convention. libstdc++ used the default `__cdecl` convention and caused

Re: PING: Fwd: [PATCH] Refactor range handling of builtins in vr_values and ranger.

On Tue, Oct 20, 2020 at 6:19 PM Andrew MacLeod wrote: > > On 10/19/20 6:03 AM, Aldy Hernandez wrote: > > > > > > > > Forwarded Message > > Subject: [PATCH] Refactor range handling of builtins in vr_values and > > ranger. > > Date: Fri, 9 Oct 2020 14:32:05 +0200 > > From: Aldy H

Re: PING: Fwd: [PATCH] Refactor range handling of builtins in vr_values and ranger.

On 10/19/20 6:03 AM, Aldy Hernandez wrote: Forwarded Message Subject: [PATCH] Refactor range handling of builtins in vr_values and ranger. Date: Fri,  9 Oct 2020 14:32:05 +0200 From: Aldy Hernandez To: GCC patches , Jakub Jelinek CC: Andrew MacLeod , Aldy Hernandez

PING: Fwd: [PATCH] Refactor range handling of builtins in vr_values and ranger.

Forwarded Message Subject: [PATCH] Refactor range handling of builtins in vr_values and ranger. Date: Fri, 9 Oct 2020 14:32:05 +0200 From: Aldy Hernandez To: GCC patches , Jakub Jelinek CC: Andrew MacLeod , Aldy Hernandez Hi Jakub. As the last known expert in this are

Re: PING: Fwd: [PATCH] Adjust tree-ssa-strlen.c for irange API.

PING * 2 On 8/11/20 1:55 PM, Aldy Hernandez wrote: -- Forwarded message - From: *Aldy Hernandez* mailto:al...@redhat.com>> Date: Tue, Aug 4, 2020, 13:34 Subject: [PATCH] Adjust tree-ssa-strlen.c for irange API. To: mailto:gcc-patches@gcc.gnu.org>> Cc: mailto:l...@redhat.com>>, <

Re: PING: Fwd: [PATCH] Rewrite get_size_range for irange API.

PING * 2 On 8/11/20 1:56 PM, Aldy Hernandez wrote: -- Forwarded message - From: *Aldy Hernandez* mailto:al...@redhat.com>> Date: Thu, Aug 6, 2020, 16:54 Subject: [PATCH] Rewrite get_size_range for irange API. To: mailto:gcc-patches@gcc.gnu.org>> Cc: mailto:mse...@redhat.com>>, A

Re: PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.

On 8/18/20 12:38 PM, Aldy Hernandez wrote: And here's the patch without the sanity check. Aldy That diff was difficult to read.. I had to apply the patch to really follow it :-P Anyway, yeah, this looks better.  effectively, you have   1) left the input range "vr" range merging in adjust-ra

Re: PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.

And here's the patch without the sanity check. Aldy diff --git a/gcc/vr-values.c b/gcc/vr-values.c index fe51a6faeb8..9b21441dff3 100644 --- a/gcc/vr-values.c +++ b/gcc/vr-values.c @@ -1006,7 +1006,7 @@ vr_values::extract_range_from_comparison (value_range_equiv *vr, overflow. */ static b

Re: PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.

On 8/17/20 5:59 PM, Andrew MacLeod wrote: On 8/17/20 6:04 AM, Aldy Hernandez wrote: On 8/14/20 7:16 PM, Andrew MacLeod wrote: On 8/14/20 12:05 PM, Aldy Hernandez wrote: I made some minor changes to the function comments. gcc/ChangeLog: * vr-values.c (check_for_binary_op_overflow): Ch

Re: PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.

On 8/17/20 6:04 AM, Aldy Hernandez wrote: On 8/14/20 7:16 PM, Andrew MacLeod wrote: On 8/14/20 12:05 PM, Aldy Hernandez wrote: I made some minor changes to the function comments. gcc/ChangeLog: * vr-values.c (check_for_binary_op_overflow): Change type of store to range_query. (v

Re: PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.

On 8/14/20 7:16 PM, Andrew MacLeod wrote: On 8/14/20 12:05 PM, Aldy Hernandez wrote: I made some minor changes to the function comments. gcc/ChangeLog: * vr-values.c (check_for_binary_op_overflow): Change type of store to range_query. (vr_values::adjust_range_with_scev): Abstract

Re: PING: Fwd: [PATCH 1/2] Add statement context to get_value_range.

On 8/14/20 6:03 PM, Andrew MacLeod wrote: On 8/11/20 7:53 AM, Aldy Hernandez via Gcc-patches wrote: -- Forwarded message - From: Aldy Hernandez Date: Tue, Aug 4, 2020, 13:55 Subject: [PATCH 1/2] Add statement context to get_value_range. To: Cc: , Aldy Hernandez This is in

Re: Fwd: [PATCH V2 3/4] Work around bootstrap failure in Fortran front end.

Hi, the change looks good to me, OK for master. Regards Thomas This arose from work by Sandra on "Unify C and C++ handling of loops and switches" Kind regards, Toon. Forwarded Message Subject: [PATCH V2 3/4] Work around bootstrap failure in Fortran front end. Date:

Re: PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.

On 8/14/20 12:05 PM, Aldy Hernandez wrote: I made some minor changes to the function comments. gcc/ChangeLog: * vr-values.c (check_for_binary_op_overflow): Change type of store to range_query. (vr_values::adjust_range_with_scev): Abstract most of the code... (range_of_var_in_loo

Re: PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.

I made some minor changes to the function comments. gcc/ChangeLog: * vr-values.c (check_for_binary_op_overflow): Change type of store to range_query. (vr_values::adjust_range_with_scev): Abstract most of the code... (range_of_var_in_loop): ...here. Remove value_r

Re: PING: Fwd: [PATCH 1/2] Add statement context to get_value_range.

On 8/11/20 7:53 AM, Aldy Hernandez via Gcc-patches wrote: -- Forwarded message - From: Aldy Hernandez Date: Tue, Aug 4, 2020, 13:55 Subject: [PATCH 1/2] Add statement context to get_value_range. To: Cc: , Aldy Hernandez This is in line with the statement context that we have

PING: Fwd: [PATCH] Rewrite get_size_range for irange API.

-- Forwarded message - From: Aldy Hernandez Date: Thu, Aug 6, 2020, 16:54 Subject: [PATCH] Rewrite get_size_range for irange API. To: Cc: , Aldy Hernandez [Martin, does this sound reasonable to you?] The following patch converts get_size_range to the irange API, thus removing

PING: Fwd: [PATCH] Adjust tree-ssa-strlen.c for irange API.

-- Forwarded message - From: Aldy Hernandez Date: Tue, Aug 4, 2020, 13:34 Subject: [PATCH] Adjust tree-ssa-strlen.c for irange API. To: Cc: , , Aldy Hernandez This patch adapts the strlen pass to use the irange API. I wasn't able to remove the one annoying use of VR_ANTI_RANGE

PING: Fwd: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv.

-- Forwarded message - From: Aldy Hernandez Date: Tue, Aug 4, 2020, 14:03 Subject: [PATCH 2/2] Decouple adjust_range_from_scev from vr_values and value_range_equiv. To: Cc: , Aldy Hernandez I've abstracted out the parts of the code that had nothing to do with value_range_equiv

PING: Fwd: [PATCH 1/2] Add statement context to get_value_range.

-- Forwarded message - From: Aldy Hernandez Date: Tue, Aug 4, 2020, 13:55 Subject: [PATCH 1/2] Add statement context to get_value_range. To: Cc: , Aldy Hernandez This is in line with the statement context that we have for get_value() in the substitute_and_fold_engine class. ---

PING: Fwd: [PATCH] Adjust tree-ssa-dom.c for irange API.

-- Forwarded message - From: Aldy Hernandez Date: Tue, Aug 4, 2020, 13:39 Subject: [PATCH] Adjust tree-ssa-dom.c for irange API. To: Cc: , Aldy Hernandez This patch removes all uses of VR_ANTI_RANGE in DOM. It required minor surgery in the switch handling code. In doing so, I

Fwd: [PATCH 00/29] rs6000: Auto-generate builtins from descriptions [V2]

I apologize for the useless "From" address (and lack of "Reply-To" address) on this patch series.  My usual machine is down for maintenance, so I ended up sending this from my laptop, which was clearly not configured well enough for that.  My bad.  I won't do that again. Meantime, please repl

Fwd: [patch] substitute_and_fold_engine merge with evrp domwalker

PING -- Forwarded message - From: Aldy Hernandez Date: Mon, May 18, 2020 at 7:59 PM Subject: [patch] substitute_and_fold_engine merge with evrp domwalker To: Jeff Law Cc: gcc-patches Howdy. The main evrp domwalker seems cut and pasted from the substitute_and_fold_engine (or w

Fwd: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Ping. We need this patch for our product building. thanks. Qing > Begin forwarded message: > > From: Qing Zhao via Gcc-patches > Subject: PING [PATCH][gcc][PR94230]provide an option to change the size > limitation for -Wmisleading-indent > Date: April 8, 2020 at 2:39:22 PM CDT > To: dmalc..

Fwd: Re: [Fortran, OpenACC] Reject vars of different scope in $acc declare (PR94120)

(I assume that should have gone to gcc-patches@ and fortran@ as well.) Forwarded Message Subject:Re: [Fortran, OpenACC] Reject vars of different scope in $acc declare (PR94120) Date: Tue, 10 Mar 2020 18:02:41 + From: Paul Richard Thomas To: Tobias Burnus

Fwd: [testsuite] Add @ lines to check-function-bodies fluff

Cc'ing maintainers and original author of `check-function-bodies`. It looks like I missed that the first time around. Forwarded Message Subject: [testsuite] Add @ lines to check-function-bodies fluff Date: Tue, 10 Mar 2020 17:22:52 + From: Matthew Malcomson To: gcc-patche

Fwd: [PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums

Forwarding to public list. -- Forwarded message - From: Bin.Cheng Date: Mon, Mar 9, 2020 at 5:07 PM Subject: Re: [PATCH PR93674]Avoid introducing IV of enumeral type in case of -fstrict-enums To: Richard Biener On Tue, Mar 3, 2020 at 5:36 PM Richard Biener wrote: > > On Mon, M

Fwd: Re: [Patch][Fortran] On unformatted read, convert != 0 logical to 1

Just saw that gcc-patches@ wasn't included in the list. See: https://gcc.gnu.org/ml/fortran/2020-01/threads.html#00088 for the thread. Tobias Forwarded Message Subject: Re: [Patch][Fortran] On unformatted read, convert != 0 logical to 1 Date: Mon, 27 Jan 2020 17:29:10 +01

Re: Fwd: [C++ coroutines 3/7, v2] Front end parsing and transforms.

[for some reason something dropped the emails on their first reposting, it took me a while to realize I'd missed something] On 1/10/20 7:29 AM, Iain Sandoe wrote: I was able to address all the comments that you made without finding any show-stoppers. In addition to your comments, I’ve had one

Re: Fwd: [PATCH, GCC, Vect] Fix costing for vector shifts

Hi Christophe On 10/12/2019 09:01, Christophe Lyon wrote: > Hi, > > On Mon, 9 Dec 2019 at 11:23, Sudakshina Das wrote: >> >> Hi Jeff >> >> On 07/12/2019 17:44, Jeff Law wrote: >>> On Fri, 2019-12-06 at 14:05 +, Sudakshina Das wrote: Hi While looking at the vectorization for fo

Re: Fwd: [PATCH, GCC, Vect] Fix costing for vector shifts

Hi, On Mon, 9 Dec 2019 at 11:23, Sudakshina Das wrote: > > Hi Jeff > > On 07/12/2019 17:44, Jeff Law wrote: > > On Fri, 2019-12-06 at 14:05 +, Sudakshina Das wrote: > >> Hi > >> > >> While looking at the vectorization for following example, we > >> realized > >> that even though vectorizable_

  1   2   3   4   5   6   >