[PING][PATCH v3] config/rs6000/t-float128: Don't encode full build paths into headers

Hi All, Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689920.html It has already been approved here: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689922.html with a note to commit it, but I don’t have commit access. Could someone please help commit it on my behalf? Thanks, H

[PING] [PATCH] vect: Add missing skip-vector check for peeling with versioning [PR121020]

PING > [PATCH] vect: Add missing skip-vector check for peeling with versioning > [PR121020]

[PING] [PATCH] testsuite: handle-multiline-outputs must allow both cc1 and cc1.exe

Ping! On 2025-07-17 14:48, Torbjörn SVENSSON wrote: Ok for trunk, gcc-15 and gcc-14? -- Prior to 14-2027-g985d6480fe5, the input text had the file extensions pruned. In 14-2027-g985d6480fe5, due to the move of the call, the pruning is never done. This change restores the pruning of the file ex

Ping: [PATCH] builtins.cc (fold_builtin_bit_query): Don't consider MAX_FIXED_MODE_SIZE, [PR120935]

Ping! On Mon, 14 Jul 2025, Hans-Peter Nilsson wrote: > Tested to fix build for MMIX (and to fix a few type-generic-builtin > test-cases; c-c++-common/pr111309-1.c, gcc.dg/torture/pr116480-1.c). > Also regtested cris-elf and native x86_64-pc-linux-gnu. > > Ok for master and gcc-15? > > -- >8 --

Re: [PING][PATCH 0/1] aarch64: testsuite: Keep -mtune=generic when specifying -moverride

Gentle ping. On Mon, Jul 14, 2025 at 09:43:29PM +, Spencer Abson wrote: > Hi all, > > Currently, using '-moverride' in the testsuite will reset the baseline tuning > model from 'generic' to the default tuning for the architecture level. Since > 'generic' is the tuning model relied upon by mo

[PING][PATCH v2] MIPS: Add conditions for use of the -mmips16e2 and -mips16 option.

Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673877.html Thanks, Jie

[PING][PATCH] MIPS: Add MSUBF.fmt instruction for MIPSr6

Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663001.html Thanks, Jie

Ping: [PATCH, V3] Add -mcpu=future to the PowerPC

Ping patch: | Date: Tue, 1 Jul 2025 12:14:32 -0400 | From: Michael Meissner | Subject: [PATCH, V3] Add -mcpu=future to the PowerPC | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688251.html -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss

Re: [PING][PATCH] config/rs6000/t-float128: Don't encode full build paths into headers

Hi! On Thu, Jul 10, 2025 at 12:10:16PM +, Sadineni, Harish wrote: > Ping for [1]https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html. > > This patch avoids embedding full build paths into generated headers by using > only the basename of the source file. This helps to improve bui

[PING][PATCH] config/rs6000/t-float128: Don't encode full build paths into headers

Hi all, Ping for https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html. This patch avoids embedding full build paths into generated headers by using only the basename of the source file. This helps to improve build reproducibility, particularly in environments where build paths vary

[PING][PATCH v4] reassoc: Optimize CMP/XOR expressions [PR116860]

Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687530.html . Thanks, Konstantinos

[PING][PATCH] Add string_slice class.

Ping for this patch. Thanks, Alfie On 20/06/2025 14:23, Alfie Richards wrote: Thanks for the pointer Joseph. This update adds tests to gcc/testsuite/g++.dg/warn/Wformat-gcc_diag-1.C as this seems to be where similar tests are done (eg, %D for tree). I couldn't find any tests for the actual ou

[PING][PATCH v2 0/1] aarch64: Add support for unpacked SVE FP comparisons

Gentle ping for this patch. Thanks, Spencer On Mon, Jun 16, 2025 at 08:13:02PM +, Spencer Abson wrote: > Here is a V2 of patch 04/14 from the unpacked FP patch series [1], with the > changes discussed in that thread applied. The tests are also now based on VLA > codegen. > > Bootstrapped &

PING: [PATCH v2 1/3] Support symbol reference in jump label and jump table

On Thu, May 8, 2025 at 11:11 AM H.J. Lu wrote: > > Conditional and unconditional branch targets can be either a label or > a symbol. For conditional jump: > > (jump_insn 7 6 14 2 (set (pc) > (if_then_else (eq (reg:CCZ 17 flags) > (const_int 0 [0])) > (label_ref

[PING] [PATCH v4 0/6] c, dwarf, btf: Add btf_decl_tag and btf_type_tag C attributes

Ping for the series https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686373.html Thanks On 6/10/25 14:41, David Faust wrote: > [v3: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html > Changes v3->v4: > - Only patch 2 (DWARF generation) is changed; update based on Richard's >

Ping: [PATCH V4 5/5] Change TARGET_MODULO to TARGET_POWER9.

Ping patch. This is patch #5 in the set of 5 patches to change the internal names of the power5, power6, etc. switches from the instruction that adds the new feature to the power processor level: I.e. change: TARGET_POPCNTB to TARGET_POWER5 The external switch remains the same, just

Ping: [PATCH V4 4/5] Change TARGET_POPCNTD to TARGET_POWER7.

Ping patch. This is patch #4 in the set of 5 patches to change the internal names of the power5, power6, etc. switches from the instruction that adds the new feature to the power processor level: I.e. change: TARGET_POPCNTB to TARGET_POWER5 The external switch remains the same, just

Ping: [PATCH V4 3/5] Change TARGET_CMPB to TARGET_POWER6.

Ping patch. This is patch #3 in the set of 5 patches to change the internal names of the power5, power6, etc. switches from the instruction that adds the new feature to the power processor level: I.e. change: TARGET_POPCNTB to TARGET_POWER5 The external switch remains the same, just

Ping: [PATCH V4 2/5] Change TARGET_FPRND to TARGET_POWER5X.

Ping patch. This is patch #2 in the set of 5 patches to change the internal names of the power5, power6, etc. switches from the instruction that adds the new feature to the power processor level: I.e. change: TARGET_POPCNTB to TARGET_POWER5 The external switch remains the same, just

Ping: [PATCH V4 1/5] Change TARGET_POPCNTB to TARGET_POWER5.

Ping patch. This is patch 1 of 5 that changes the internal names of the power5, power6, etc. switches from the instruction that adds the new feature to the power processor level: I.e. change: TARGET_POPCNTB to TARGET_POWER5 The external switch remains the same, just the name used

Ping: [PATCH V4 0/5] Add more user friendly TARGET_ names for PowerPC

Ping patch. This is the explanation of the changes in the set of 5 patches to change the internal names of the power5, power6, etc. switches from the instruction that adds the new feature to the power processor level: I.e. change: TARGET_POPCNTB to TARGET_POWER5 The external switch

[PING][PATCH v3] reassoc: Optimize CMP/XOR expressions [PR116860]

Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677788.html . Thanks, Konstantinos

Ping²: [PATCH 0/2] asm() operand 'c' modifier handling

On 21.11.2024 13:03, Jan Beulich wrote: > Documentation is pretty clear here: "Require a constant operand and > print the constant expression with no punctuation." See the patches for > further details. > > 1: fix asm() operand 'c' modifier handling > 2: x86: fix asm() operand 'c' modifier handlin

Re: [PING][PATCH v3] match.pd: Fold (x + y) >> 1 into IFN_AVG_FLOOR (x, y) for vectors

On Thu, 22 May 2025, Pengfei Li wrote: > Hi, > > Just a gentle ping for below patch v3. > > I’ve made minor changes from v2 to v3, as listed below: > - Added check if IFN_AVG_FLOOR is supported. > - Wrapped new code in match.pd with macro "#ifdef GIMPLE". OK. Thanks, Richard. > > This patch f

Re: [PING] [PATCH] vect: Improve vectorization for small-trip-count loops using subvectors

On 6/2/25 2:23 AM, Pengfei Li wrote: Hi all, I would like to bring attention back to this patch: https://inbox.sourceware.org/gcc-patches/20250508164950.5646-1-pengfei@arm.com/ The patch improves auto-vectorization for loops with known small trip counts by introducing a new target ho

[PING] [PATCH] vect: Improve vectorization for small-trip-count loops using subvectors

Hi all, I would like to bring attention back to this patch: https://inbox.sourceware.org/gcc-patches/20250508164950.5646-1-pengfei@arm.com/ The patch improves auto-vectorization for loops with known small trip counts by introducing a new target hook for subvector selection. I fully unders

PING: [PATCH] configury: replace autoconf obsolete macros [PR/103459]

On Wed, May 21, 2025, at 8:59 PM, Pietro Monteiro wrote: > Autoreconf -Wall complains about obsolete macros, so replace them according to > the autoconf documentation[0]. > > This patch doesn't fully fix all warnings because I focused on doing simple > fixes and keeping the changes to the generated

[PING][PATCH v3] match.pd: Fold (x + y) >> 1 into IFN_AVG_FLOOR (x, y) for vectors

Hi, Just a gentle ping for below patch v3. I’ve made minor changes from v2 to v3, as listed below: - Added check if IFN_AVG_FLOOR is supported. - Wrapped new code in match.pd with macro "#ifdef GIMPLE". > This patch folds vector expressions of the form (x + y) >> 1 into > IFN_AVG_FLOOR (x, y), r

[PING][PATCH v3] reassoc: Optimize CMP/XOR expressions [PR116860]

Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677788.html . Thanks, Konstantinos

Re: [PING][PATCH][GCC15] Alpha: Fix base block alignment calculation regression

On Thu, 15 May 2025, Jeff Law wrote: > > > Address this issue by recursing into COMPONENT_REF tree nodes until the > > > outermost one has been reached, which is supposed to be a MEM_REF one, > > > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > > > Also use tree informat

Re: [PING][PATCH][GCC15] Alpha: Fix base block alignment calculation regression

On 5/12/25 11:21 AM, Maciej W. Rozycki wrote: On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: Address this issue by recursing into COMPONENT_REF tree nodes until the outermost one has been reached, which is supposed to be a MEM_REF one, accumulating the offset as we go, fixing a commit e0dae4d

Re:[ping] [PATCH v2] MIPS: Fix the issue with the '-fpatchable-function-entry=' feature.

Ping? 在 2025/5/9 上午10:14, Lulu Cheng 写道: From: ChengLulu PR target/99217 gcc/ChangeLog: * config/mips/mips.cc (mips_start_function_definition): Implements the functionality of '-fpatchable-function-entry='. (mips_print_patchable_function_entry): Define empty f

[PING][PATCH][GCC15] Alpha: Fix base block alignment calculation regression

On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: > Address this issue by recursing into COMPONENT_REF tree nodes until the > outermost one has been reached, which is supposed to be a MEM_REF one, > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > Also use tree information

[PING][PATCH][GCC15] Alpha: Fix base block alignment calculation regression

On Thu, 1 May 2025, Maciej W. Rozycki wrote: > > > OK. Clearly this one slipped through the cracks. > > > > Good timing, I've applied it now just as I'm about to head away for some > > holiday time. I'll take care of the other outstanding stuff in this area > > once GCC 16 has opened and wor

Re: [PING] [PATCH] Fortran: fix passing of inquiry ref of complex array to TRANSFER [PR102891]

Hi Jerry! Am 10.05.25 um 21:53 schrieb Jerry D: On 5/10/25 11:33 AM, Harald Anlauf wrote: Early ping. Am 06.05.25 um 21:06 schrieb Harald Anlauf: Dear all, here's another rather obvious case where a temporary is needed for an inquiry reference of a complex array which is a component of a der

Re: [PING] [PATCH] Fortran: fix passing of inquiry ref of complex array to TRANSFER [PR102891]

On 5/10/25 11:33 AM, Harald Anlauf wrote: Early ping. Am 06.05.25 um 21:06 schrieb Harald Anlauf: Dear all, here's another rather obvious case where a temporary is needed for an inquiry reference of a complex array which is a component of a derived type.  In contrast to PR119986, the argument

[PING] [PATCH] Fortran: fix passing of inquiry ref of complex array to TRANSFER [PR102891]

Early ping. Am 06.05.25 um 21:06 schrieb Harald Anlauf: Dear all, here's another rather obvious case where a temporary is needed for an inquiry reference of a complex array which is a component of a derived type.  In contrast to PR119986, the argument is handled within the code for the intrinsi

Re: PING: [PATCH] Add TARGET_STORE_BY_PIECES_ICODE

On Thu, 8 May 2025, H.J. Lu wrote: > On Mon, Apr 28, 2025 at 8:57 PM H.J. Lu wrote: > > > > On x86, both stores with 32-bit immediate and register are supported: > > > >0: 48 c7 40 10 00 00 00 00 movq $0x0,0x10(%rax) > >8: 48 89 50 10 movq %rdx,0x10(%rax) > > > > But store wi

PING: [PATCH] Add TARGET_STORE_BY_PIECES_ICODE

On Mon, Apr 28, 2025 at 8:57 PM H.J. Lu wrote: > > On x86, both stores with 32-bit immediate and register are supported: > >0: 48 c7 40 10 00 00 00 00 movq $0x0,0x10(%rax) >8: 48 89 50 10 movq %rdx,0x10(%rax) > > But store with 32-bit immediate is 4 byte longer. > > Add UNSPEC

[PING PATCH v4 00/20] FMV refactor and ACLE compliance.

Hi all, Ping for this patch series. There are a handful of other patches that are dependant on this series so I am keen to start getting this reviewed. Kind regards, Alfie On 15/04/2025 11:31, Alfie Richards wrote: Hi all, Another update to this series. This patch changes the version info

Ping: [PATCH 0/2] asm() operand 'c' modifier handling

On 21.11.2024 13:03, Jan Beulich wrote: > Documentation is pretty clear here: "Require a constant operand and > print the constant expression with no punctuation." See the patches for > further details. > > 1: fix asm() operand 'c' modifier handling > 2: x86: fix asm() operand 'c' modifier handlin

PING: [PATCH] x86: Add preserve_none and update no_caller_saved_registers attributes

On Fri, Apr 18, 2025 at 7:10 PM H.J. Lu wrote: > > Add preserve_none attribute which is similar to no_callee_saved_registers > attribute, except on x86-64, r12, r13, r14, r15, rdi and rsi registers are > used for integer parameter passing. This can be used in an interpreter > to avoid saving/rest

Re: PING: [PATCH] x86: Add a pass to remove redundant all 0s/1s vector load

On Tue, Apr 22, 2025 at 10:01 AM Hongtao Liu wrote: > > On Mon, Apr 21, 2025 at 4:30 PM H.J. Lu wrote: > > > > On Mon, Apr 21, 2025 at 11:29 AM Hongtao Liu wrote: > > > > > > On Sat, Apr 19, 2025 at 1:25 PM H.J. Lu wrote: > > > > > > > > On Sun, Dec 1, 2024 at 7:50 AM H.J. Lu wrote: > > > > >

[PING][PATCH v3] Add new warning Wmissing-designated-initializers [PR39589]

Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html Missed the version 15 freeze with the last ping, I believe the project is open for general development again now?

Re: PING: [PATCH] x86: Add a pass to remove redundant all 0s/1s vector load

On Mon, Apr 21, 2025 at 4:30 PM H.J. Lu wrote: > > On Mon, Apr 21, 2025 at 11:29 AM Hongtao Liu wrote: > > > > On Sat, Apr 19, 2025 at 1:25 PM H.J. Lu wrote: > > > > > > On Sun, Dec 1, 2024 at 7:50 AM H.J. Lu wrote: > > > > > > > > For all different modes of all 0s/1s vectors, we can use the si

Re: PING: [PATCH] x86: Add a pass to remove redundant all 0s/1s vector load

On Mon, Apr 21, 2025 at 11:29 AM Hongtao Liu wrote: > > On Sat, Apr 19, 2025 at 1:25 PM H.J. Lu wrote: > > > > On Sun, Dec 1, 2024 at 7:50 AM H.J. Lu wrote: > > > > > > For all different modes of all 0s/1s vectors, we can use the single widest > > > all 0s/1s vector register for all 0s/1s vector

Re: PING: [PATCH] x86: Add a pass to remove redundant all 0s/1s vector load

On Sat, Apr 19, 2025 at 1:25 PM H.J. Lu wrote: > > On Sun, Dec 1, 2024 at 7:50 AM H.J. Lu wrote: > > > > For all different modes of all 0s/1s vectors, we can use the single widest > > all 0s/1s vector register for all 0s/1s vector uses in the whole function. > > Add a pass to generate a single wi

Ping [PATCH/RFC] target, hooks: Allow a target to trap on unreachable [PR109267].

Hi all, I’d like to ping the patch from April 2024 at https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651100.html As far as I understand, the status of this is: - Iain posted the patch for review - Richard said "your target hook is reasonable though I'd name it expand_unreachable_as_trap may

Re: PING: [PATCH v2] x86: Add pcmpeq splitters

On Sat, Apr 19, 2025 at 4:16 PM Uros Bizjak wrote: > > On Sat, Apr 19, 2025 at 7:22 AM H.J. Lu wrote: > > > > On Mon, Dec 2, 2024 at 6:27 AM H.J. Lu wrote: > > > > > > Add pcmpeq splitters to split > > > > > > (insn 5 3 7 2 (set (reg:V4SI 100) > > > (eq:V4SI (reg:V4SI 98) > > >

Re: PING: [PATCH v2] x86: Add pcmpeq splitters

On Sat, Apr 19, 2025 at 7:22 AM H.J. Lu wrote: > > On Mon, Dec 2, 2024 at 6:27 AM H.J. Lu wrote: > > > > Add pcmpeq splitters to split > > > > (insn 5 3 7 2 (set (reg:V4SI 100) > > (eq:V4SI (reg:V4SI 98) > > (reg:V4SI 98))) 7910 {*sse2_eqv4si3} > > (expr_list:REG_DEAD (re

PING: [PATCH] x86: Add a pass to remove redundant all 0s/1s vector load

On Sun, Dec 1, 2024 at 7:50 AM H.J. Lu wrote: > > For all different modes of all 0s/1s vectors, we can use the single widest > all 0s/1s vector register for all 0s/1s vector uses in the whole function. > Add a pass to generate a single widest all 0s/1s vector set instruction at > entry of the near

PING: [PATCH v2] x86: Add pcmpeq splitters

On Mon, Dec 2, 2024 at 6:27 AM H.J. Lu wrote: > > Add pcmpeq splitters to split > > (insn 5 3 7 2 (set (reg:V4SI 100) > (eq:V4SI (reg:V4SI 98) > (reg:V4SI 98))) 7910 {*sse2_eqv4si3} > (expr_list:REG_DEAD (reg:V4SI 98) > (expr_list:REG_EQUAL (eq:V4SI (const_vector:V

Re: [PING][PATCH] doc: Clarify REG_EH_REGION note usage

Applied to trunk, thank you! --Philipp. On Thu, 17 Apr 2025 at 21:51, Jeff Law wrote: > > > > On 4/8/25 6:12 AM, Konstantinos Eleftheriou wrote: > > Hi, > > Just a ping for https://gcc.gnu.org/pipermail/gcc-patches/2025- > > March/677635.html >

Re: [PING][PATCH] doc: Clarify REG_EH_REGION note usage

On 4/8/25 6:12 AM, Konstantinos Eleftheriou wrote: Hi, Just a ping for https://gcc.gnu.org/pipermail/gcc-patches/2025- March/677635.html . OK for the trunk. I don't think it's worth porting to the release branches. jeff

[PING][PATCH][gcc-14] libcpp: Fix incorrect line numbers in large files [PR108900]

From: Jeremy Bettis This patch addresses an issue in the C preprocessor where incorrect line number information is generated when processing files with a large number of lines. The problem arises from improper handling of location intervals in the line map, particularly when locations exceed LINE

[PING][PATCH] doc: Clarify REG_EH_REGION note usage

Hi, Just a ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677635.html. Thanks, Konstantinos

[PING][PATCH v3] reassoc: Optimize CMP/XOR expressions [PR116860]

Hi, Just a ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677788.html . Thanks, Konstantinos

RE: [ping][PATCH] libgcobol: Provide fallbacks for C32 strfromf32/64 [PR119296].

gt; From: Iain Sandoe > Sent: Wednesday, April 2, 2025 14:24 > To: GCC Patches > Cc: James K. Lowden ; Robert Dubner > > Subject: [ping][PATCH] libgcobol: Provide fallbacks for C32 strfromf32/64 > [PR119296]. > > Hi folks, > it would be great to reduce the in-flight patc

RE: [ping][PATCH] libgcobol: Provide fallbacks for C32 strfromf32/64 [PR119296].

> -Original Message- > From: Iain Sandoe > Sent: Wednesday, April 2, 2025 15:05 > To: Robert Dubner > Cc: GCC Patches ; James K. Lowden > > Subject: Re: [ping][PATCH] libgcobol: Provide fallbacks for C32 > strfromf32/64 [PR119296]. > > > > > On 2 A

Re: [ping][PATCH] libgcobol: Provide fallbacks for C32 strfromf32/64 [PR119296].

red out how to handle our > joint responsibility. understood.. > > Hence delays. … will try not to hassle too much :) > > >> -Original Message- >> From: Iain Sandoe >> Sent: Wednesday, April 2, 2025 14:24 >> To: GCC Patches >> Cc: James K. Lowden ; Ro

[ping][PATCH] libgcobol: Provide fallbacks for C32 strfromf32/64 [PR119296].

Hi folks, it would be great to reduce the in-flight patch stack a bit :) > On 25 Mar 2025, at 16:40, Iain Sandoe wrote: > > This is on top of the C++-ify configure and random_r patches. > Tested on x86_64,aarch64-Linux and x86_64-darwin, OK for trunk? > thanks > Iain > > --- 8< --- > > strfro

Re: Patch ping [PATCH] tailc: Don't fail musttail calls if they use or could use local arguments, instead warn [PR119376]

On Tue, 1 Apr 2025, Jakub Jelinek wrote: > Hi! > > On Tue, Mar 25, 2025 at 08:34:10AM +0100, Jakub Jelinek wrote: > > As discussed here and in bugzilla, [[clang::musttail]] attribute in clang > > not just strongly asks for tail call or error, but changes behavior. > > To quote: > > https://clang.

Patch ping [PATCH] tailc: Don't fail musttail calls if they use or could use local arguments, instead warn [PR119376]

Hi! On Tue, Mar 25, 2025 at 08:34:10AM +0100, Jakub Jelinek wrote: > As discussed here and in bugzilla, [[clang::musttail]] attribute in clang > not just strongly asks for tail call or error, but changes behavior. > To quote: > https://clang.llvm.org/docs/AttributeReference.html#musttail > "The li

Re: Patch ping [PATCH] tailc: Don't fail musttail calls if they use or could use local arguments, instead warn [PR119376]

> I'd like to ping the > https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679182.html > patch. > I know it is quite controversial and if clang wouldn't be the first > to implement this I'd certainly not go that way; I am willing to change > the warning option names or move the maybe one from -W

[ping] [PATCH] libgcobol: C++-ify the configuration steps.

Hi folks > On 24 Mar 2025, at 17:15, Iain Sandoe wrote: > >> On 24 Mar 2025, at 16:41, Iain Sandoe wrote: >>> On 24 Mar 2025, at 16:38, Robert Dubner wrote: >>> >>> How about you create the new patch and just edit out the regenerated >>> configure before sending the e-mail? Typing "autorecon

[ping][PATCH v2] aarch64, Darwin: Initial implementation of Apple cores [PR113257].

I realise this is probably not #1 priority - but it would be nice to have in gcc-15. thanks iain > On 22 Mar 2025, at 14:31, Iain Sandoe wrote: > > 0. Sorry this has taken some time to close off; partly because of waiting > for input, but mostly that I've been stretched with other work. > 1.

Re: [PING][PATCH v3 0/4] Fix data races with sub-longword accesses on Alpha

On Sat, 22 Mar 2025, Maciej W. Rozycki wrote: > > This is v3 of the series comprising the final 4 outstanding changes. I > > note that the corresponding v2 patches have been approved, but concerns > > were discussed, which this update has addressed. > > Ping for: >

[ping] [PATCH] includes, Darwin: Handle modular use for macOS SDKs [PR116827].

C++ modules are not really usable on latest Darwin without resolving this, thanks Iain > On 23 Mar 2025, at 12:29, Iain Sandoe wrote: > > From: Iain Sandoe > > Tested on x86_64/aarch64 Darwin and x86_64-linux, > OK for trunk? > backports to branches supporting modules? > thanks > Iain > > ---

[ping] [PATCH] libiberty, gcc: Add memrchr to libiberty and use it [PR119283].

this (or an alternate implementation) is needed for the cobol FE to build on darwin, > On 21 Mar 2025, at 10:00, Iain Sandoe wrote: > > It seems that libiberty already has replacements for most of the > mem* functions, but they are not published via include/libiberty.h. > > Tested on x86_64 Li

ping: [PATCH] c-family: Improve location for -Wunknown-pragmas in a _Pragma [PR118838]

Hello- May I please ping this patch? Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675645.html -Lewis On Wed, Feb 12, 2025 at 8:27 PM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838 > > This patch addresses the issue mentioned in the PR (a

[PING][PATCH] Makefile.tpl: Implement per-stage GDCFLAGS [PR116975]

Ping. Excerpts from Iain Buclaw's message of März 3, 2025 11:14 pm: > Hi, > > This patch implements STAGE1_GDCFLAGS and others to the configure > machinery, allowing the GDCFLAGS for each bootstrap stage of building > gdc to be overriden, as is the case with CXXFLAGS for other front-ends. > > Th

[PING][PATCH v3 0/4] Fix data races with sub-longword accesses on Alpha

On Tue, 11 Mar 2025, Maciej W. Rozycki wrote: > This is v3 of the series comprising the final 4 outstanding changes. I > note that the corresponding v2 patches have been approved, but concerns > were discussed, which this update has addressed. Ping for:

Ping [PATCH 0/2] v2 Add prime path coverage to gcc/gcov

Ping. On 3/5/25 20:21, Jørgen Kvalsvik wrote: Ping. On 2/21/25 19:15, Jørgen Kvalsvik wrote: Ping On 2/12/25 16:30, Jørgen Kvalsvik wrote: I have applied fixes for everything in the last review, plus some GNU style fixes that I had missed previously. We have tested and used a build with this

Ping: [PATCH v4] get source line for diagnostic from preprocessed file [PR preprocessor/79106]

Gentle ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676875.html

[PING] [PATCH v3] c++: Use capture from outer lambda, if any, instead of erroring out [PR110584]

Hi, On Thu Mar 6, 2025 at 8:06 PM CET, Simon Martin wrote: > Hi Jason, > > On Wed Mar 5, 2025 at 9:40 PM CET, Jason Merrill wrote: >> On 3/5/25 10:39 AM, Simon Martin wrote: >>> Hi Jason, >>> >>> On Wed Mar 5, 2025 at 12:03 AM CET, Jason Merrill wrote: On 2/18/25 5:12 AM, Simon Martin wrote:

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

PING! On Thu, 20 Feb 2025 10:54:30 +0100 Andre Vehreschild wrote: > Hi all, > > attached patch makes an attempt to announce the ABI-changes in the coarrays > library. Me being German always has difficulties to find a proper wording. So > please propose improvements. > > Stupid question: How to I

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/10/25 9:57 AM, Jerry D wrote: On 3/10/25 1:08 AM, Andre Vehreschild wrote: Hi Steve and Jerry, thanks for the review and the proposed changes. I have based on them, but needed to adapt some places, because the meaning was changed. Can you please take another look? Jerry, where do I find

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/10/25 1:08 AM, Andre Vehreschild wrote: Hi Steve and Jerry, thanks for the review and the proposed changes. I have based on them, but needed to adapt some places, because the meaning was changed. Can you please take another look? Jerry, where do I find this check-script? In bin/ nothing ju

[PING][PATCH] Alpha: Fix base block alignment calculation regression

On Tue, 25 Feb 2025, Maciej W. Rozycki wrote: > Address this issue by recursing into COMPONENT_REF tree nodes until the > outermost one has been reached, which is supposed to be a MEM_REF one, > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > Also use tree information

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

Hi Jerry, thanks for the review. Committed as 87c7db8b1b2c1484d6de3331098669735d33f95e. I also had it checked using the W3C validator w/o any errors. Therefore committed. Thanks again, Andre On Mon, 10 Mar 2025 10:01:46 -0700 Jerry D wrote: > On 3/10/25 9:57 AM, Jerry D wrote: > > On

Re: Ping: [PATCH] LoongArch: combine related slli operations

在 2025/3/10 下午3:24, Zhou Zhao 写道: Ping Hi, You need to send another patch for version V2 with modifications. However, I am currently testing the value of align, and GCC15 is already in stage 4, so this patch might have to wait until the GCC16 stage 1 phase before it can be integrated.

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

Hi Steve and Jerry, thanks for the review and the proposed changes. I have based on them, but needed to adapt some places, because the meaning was changed. Can you please take another look? Jerry, where do I find this check-script? In bin/ nothing jumps out at me to be a check-script. Thanks,

Ping: [PATCH] LoongArch: combine related slli operations

Ping 在 2025/1/7 下午8:45, Zhou Zhao 写道: 在 2025/1/7 下午7:49, Lulu Cheng 写道: 在 2025/1/2 下午5:46, Zhou Zhao 写道: If SImode reg is continuous left shifted twice, combine related instruction to one. gcc/ChangeLog: * config/loongarch/loongarch.md (extsv_ashlsi3):     New template Hi, zhaozhou:

Ping: [PATCH v2 1/5][STAGE1] c-family: add btf_type_tag and btf_decl_tag attributes

Ping. this patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675242.html series: https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html On 2/6/25 11:54, David Faust wrote: > Add two new c-family attributes, "btf_type_tag" and "btf_decl_tag" > along with a simple shar

Ping: [PATCH v2 2/5][STAGE1] dwarf: create annotation DIEs for btf tags

Ping. Patches 3-5 in the series have been reviewed, but depend heavily upon the DWARF implementation in this patch. It would be useful to have some indication of whether the new DWARF implementation is generally OK... Richard, your feedback on earlier iterations was very helpful, maybe you could

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/6/25 10:02 AM, Steve Kargl wrote: Andre, Here's a bit of wordsmith. I removed the abbreviation "Esp." I'm not sure if there is additional markup needed; especially, with the "-fcoarray=single" I inserted. Coarray support has been reworked to allow access to components in derived typ

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

Andre, Here's a bit of wordsmith. I removed the abbreviation "Esp." I'm not sure if there is additional markup needed; especially, with the "-fcoarray=single" I inserted. Coarray support has been reworked to allow access to components in derived types that have not been compiled with coarray

Ping [PATCH] Record, report basic blocks of conditional exprs

Ping. On 2/12/25 19:00, Jørgen Kvalsvik wrote: Ping. On 1/31/25 10:35, Jørgen Kvalsvik wrote: Record basic blocks that make up a conditional expression with -fcondition-coverage and report when using the gcov -w/--verbose flag. This makes the report more accurate when basic blocks are included

Ping [PATCH 0/2] v2 Add prime path coverage to gcc/gcov

Ping. On 2/21/25 19:15, Jørgen Kvalsvik wrote: Ping On 2/12/25 16:30, Jørgen Kvalsvik wrote: I have applied fixes for everything in the last review, plus some GNU style fixes that I had missed previously. We have tested and used a build with this applied for 3-4 months now and haven't run into

[PING] [PATCH] c++: Don't replace INDIRECT_REFs by a const capture proxy too eagerly [PR117504]

Hi, On 14 Feb 2025, at 18:08, Simon Martin wrote: > We have been miscompiling the following valid code since GCC8, and > r8-3497-g281e6c1d8f1b4c > > === cut here === > struct span { > span (const int (&__first)[1]) : _M_ptr (__first) {} > int operator[] (long __i) { return _M_ptr[__i]; } >

[PING] [PATCH] c++: Use capture from outer lambda, if any, instead of erroring out [PR110584]

Hi, On 18 Feb 2025, at 11:12, Simon Martin wrote: > We've been rejecting this valid code since r8-4571: > > === cut here === > void foo (float); > int main () { > constexpr float x = 0; > (void) [&] () { > foo (x); > (void) [] () { > foo (x); > }; > }; > } > === cut here =

[PING] [PATCH] c++: Fix checking assert upon invalid class definition [PR116740]

Hi, On 18 Feb 2025, at 14:00, Simon Martin wrote: > A checking assert triggers upon the following invalid code since > GCC 11: > > === cut here === > class { a (struct b; > } struct b > === cut here === > > The problem is that during error recovery, we call > set_identifier_type_value_with_scope

[PING] [PATCH v3] get source line for diagnostic from preprocessed file [PR preprocessor/79106]

Gentle ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675450.html

Ping [PATCH 0/2] v2 Add prime path coverage to gcc/gcov

Ping On 2/12/25 16:30, Jørgen Kvalsvik wrote: I have applied fixes for everything in the last review, plus some GNU style fixes that I had missed previously. We have tested and used a build with this applied for 3-4 months now and haven't run into any issues. Jørgen Kvalsvik (2): gcov: branc

Ping: [PATCH v2 0/5][STAGE1] Add btf_decl_tag and btf_type_tag C attributes

Gentle ping for this series. https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html On 2/6/25 11:54, David Faust wrote: > [v1: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666911.html > Changes from v1: > - Fix a bug in v1 related to generating DWARF for type tags applie

Re: Ping: [PATCH] testsuite: Fix up toplevel-asm-1.c for LoongArch

在 2025/2/19 下午3:27, Xi Ruoyao 写道: On Wed, 2025-02-05 at 08:57 +0800, Xi Ruoyao wrote: Like RISC-V, on LoongArch we don't really support %cN for SYMBOL_REFs even with -fno-pic. gcc/testsuite/ChangeLog: * c-c++-common/toplevel-asm-1.c: Use %cc3 %cc4 instead of %c3 %c4 on LoongA

Ping: [PATCH] testsuite: Fix up toplevel-asm-1.c for LoongArch

On Wed, 2025-02-05 at 08:57 +0800, Xi Ruoyao wrote: > Like RISC-V, on LoongArch we don't really support %cN for SYMBOL_REFs > even with -fno-pic. > > gcc/testsuite/ChangeLog: > > * c-c++-common/toplevel-asm-1.c: Use %cc3 %cc4 instead of %c3 > %c4 on LoongArch. > --- > > Ok for trunk?

Re: Ping: [PATCH] late-combine: Tighten register class check [PR108840]

On 2/17/25 4:33 AM, Richard Sandiford wrote: Ping Feel through the cracks. We really should acknowledge that you know this code better than anyone and shouldn't need to wait on review. Anyway, LGTM. jeff

Re: [PING][PATCH v2] libcpp: Fix incorrect line numbers in large files [PR108900]

Hi, you may want to Cc Lewis Hyatt on such patches (adding him now), I didn't touch this area. Alexander On Mon, 17 Feb 2025, yash.shi...@windriver.com wrote: > From: Yash Shinde > > This patch addresses an issue in the C preprocessor where incorrect line > number information is generated wh

Ping: [PATCH] late-combine: Tighten register class check [PR108840]

Ping Richard Sandiford writes: > gcc.target/aarch64/pr108840.c has failed since r15-268-g9dbff9c05520 > (which means that I really ought to have looked at it earlier). > > The test wants us to fold an SImode AND into all shifts that use it. > This is something that late-combine is supposed to do,

  1   2   3   4   5   6   7   8   9   10   >