Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

Am Mittwoch, dem 09.04.2025 um 18:31 + schrieb Qing Zhao: > Hi, Joseph and Martin, > > When I implemented the patch to attach the counted_by information to an array > reference (FAM reference) in C FE, > The work was done inside the routine “build_component_ref” in > gcc/c/c-typeck.cc

Re: [PATCH] libbacktrace: Add hpux fileline support

On Wed, Apr 9, 2025 at 7:16 AM John David Anglin wrote: > > Tested on hppa64-hp-hpux11.11. > > Okay? > > Dave > --- > > libbacktrace: Add hpux fileline support > > Fixes libstdc++ stacktrace tests. > > 2025-04-09 John David Anglin > > libbacktrace/ChangeLog: > * fileline.c (hpux_get_exe

Re: [committed] cobol: Proper comparison of alphanumeric to refmoded numeric-display [PR119682]

> Am 09.04.2025 um 23:19 schrieb Robert Dubner : > > This patch eliminates the error. > >cobol: Proper comparison of alphanumeric to refmoded numeric-display > [PR119682] Can you add the testcase as part of the fix? >gcc/cobol > >PR cobol/119682 >* genapi.cc

[PATCH] h8300: Fix up bit test and jump splitter [PR119664]

Hi! r12-2601 has added this define_insn_and_split and corresponding (define_insn "" [(set (reg:CCZ CC_REG) (eq (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r") (const_int 1) (match_operand 1 "const_int_operand" "n"

Re: [PATCH] Fortran: fix issue with impure elemental subroutine and interface [PR119656]

Am 09.04.25 um 04:06 schrieb Jerry D: On 4/8/25 1:43 PM, Harald Anlauf wrote: Hi all, the attached patch fixes a rather strange 12/13/14/15 regression. When walking through the list of procedures in an interface to find the matching one, the code could remember an inferred type from a false mod

Re: [PATCH] h8300: Fix up bit test and jump splitter [PR119664]

On 4/9/25 1:25 PM, Jakub Jelinek wrote: Hi! r12-2601 has added this define_insn_and_split and corresponding (define_insn "" [(set (reg:CCZ CC_REG) (eq (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r") (const_int 1)

[PUSHED] aarch64: Add sve testcase for PR 116595 [PR116595]

This was fixed with r15-9329-gf183ae0ae891a471764876eb but only a RISC-V V testcase was added. So this adds an aarch64 SVE testcase too. Pushed as obvious after a quick test to make sure it passes. PR middle-end/116595 gcc/testsuite/ChangeLog: * g++.target/aarch64/sve/pr116595.C

[committed] modula2: Fix a comment typo

Hi! During make gcc.pot I've noticed among tons of other warnings (e.g. because can't appears in non-C/C++ style comment and so gettext considers it unterminated) a warning where the lack of " looked unintentional. Committed to trunk as obvious. 2025-04-09 Jakub Jelinek * gm2-compile

[committed] pretty-print: Fix format specifier description

Hi! I've noticed we talk about %Ns even when that isn't supported and we actually only support %.Ns which the comment describes. Committed to trunk as obvious. 2025-04-09 Jakub Jelinek * pretty-print.cc (pretty_printer::format): Use %.Ns instead of %Ns in function comment. -

[committed] libquadmath: Fix up THREEp96 constant in expq

Hi! Here is a cherry-pick from glibc [BZ #32411] fix. As mentioned by the reporter in a pull request against gcc-mirror, the THREEp96 constant in e_expl.c is incorrect, it is actually 0x3.p+94f128 rather than 0x3.p+96f128. The algorithm uses that to compute the t2 integer (tval2), by whose delta

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

On 2025-04-08 12:41, Qing Zhao wrote: The gimple IR is: 1 int main () 2 { 3 int D.5072; 4 5 { 6 struct annotated * q; 7 8 q = alloc_buf (10); 9 _1 = __builtin_dynamic_object_size (q, 1); 10 __builtin_printf ("the bdos whole is %d\n", _1); 11

Re: [PATCH] lto: lto-opts fixes [PR119625]

On Fri, Apr 04, 2025 at 08:56:40PM +0200, Jakub Jelinek wrote: > On Fri, Apr 04, 2025 at 08:52:10PM +0200, Richard Biener wrote: > > > Or do you want something further (like > > > switch (global_options.x_flag_cf_protection & ~CF_SET) > > > )? > > > > Dunno what that CF_SET is, we’re supposed to r

Re: [PATCH] riscv: Fix r15-9270 fallout on RISC-V

Hi Jakub: Checked with SVE's implementation and seems right for RVV, so OK for trunk, thanks :) On Wed, Apr 9, 2025 at 9:24 PM Jakub Jelinek wrote: > > Hi! > > On Wed, Apr 09, 2025 at 02:38:01PM +0200, Mark Wielaard wrote: > > Unfortunately this seems to have broken the riscv bootstrap: > > http

[committed][RISC-V] Adjust expected output for rvv test

The recent combine changes twiddled code generation ever so slightly on risc-v and is causing pr117722.c to fail. The relevant change is this sequence to perform an abs() across elements in a vector: ! vwsubu.vv v1,v4,v3 vsetvli zero,zero,e16,mf2,tu,ma - vrsub.vi

RE: [PATCH][contrib]: support json output from check_GNU_style_lib.py

Ping > -Original Message- > From: Tamar Christina > Sent: Tuesday, July 23, 2024 3:30 PM > To: Jonathan Wakely ; Filip Kastl > Cc: gcc-patches@gcc.gnu.org; nd > Subject: RE: [PATCH][contrib]: support json output from check_GNU_style_lib.py > > Hi Both, > > > -Original Message-

[PATCH] bf-ms-attrib.c: Fix expected struct size

Attached patch OK for master branch? Gcc produced struct sizes match those of MSVC when __ms_struct__ is used, both producing a layout size of 12. Will push soon if there are no objections. From 522b0aa6473e109becc45e57255f14e23fc6a404 Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10wa...@gmail

[PATCH v2] RISC-V: vsetvl: elide abnormal edges from LCM computations [PR119533]

Changes since v2 - Elide abnormal edges before LCM not after LCM --- vsetvl phase4 uses LCM guided info to insert VSETVL insns, including a straggler loop for "mising vsetvls" on certain edges. Currently it asserts on encountering EDGE_ABNORMAL. When enabling go frontend with V enabled, libgo bu

Re: .ACCESS_WITH_SIZE and pointer ranges

On 2025-04-09 08:30, Qing Zhao wrote: After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument. And all the size expression before the call to .ACCESS_WITH_SIZE might be dead code eliminated later in the RTL phases. So, I don’t think there will be run-time overhead concern.

Re: [PATCH] rtl-optimization/119689 - compare-debug failure with LRA

On 4/9/25 8:40 AM, Richard Biener wrote: The previous change to fix LRA rematerialization broke compare-debug for i586 bootstrap. Fixed by using prev_nonnote_nondebug_insn instead of prev_nonnote_insn. Bootstrapped on i586-linux where the miscompare is gone with this patch. Bootstrap and reg

New German PO file for 'gcc' (version 15.1-b20250406)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/gcc/de.po (This file, 'gcc-15.1-b20250406.de.po',

[PATCH v1 0/4] Add SEH, stack unwinding and C++ exceptions

> This patch series adds SEH, stack unwinding and C++ exceptions > implementation to the aarch64-w64-mingw32 target. This patch series is supported by the binutils patch series. https://sourceware.org/pipermail/binutils/2025-April/140495.html The Boost library testing identified some issues that

Re: [PATCH] c++: wrong targs printed in hard satisfaction error [PR99214]

On Wed, 5 Mar 2025, Jason Merrill wrote: > On 3/5/25 10:13 AM, Patrick Palka wrote: > > On Tue, 4 Mar 2025, Jason Merrill wrote: > > > > > On 3/4/25 2:49 PM, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > > > > for trunk/14? > > > > > > > > --

Re: [PATCH] c++: wrong targs printed in hard satisfaction error [PR99214]

On Wed, 9 Apr 2025, Patrick Palka wrote: > On Wed, 5 Mar 2025, Jason Merrill wrote: > > > On 3/5/25 10:13 AM, Patrick Palka wrote: > > > On Tue, 4 Mar 2025, Jason Merrill wrote: > > > > > > > On 3/4/25 2:49 PM, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, doe

OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause [PR119692]

Hi! To allow me to progress with other work items, is the attached "OpenACC: Support GCC/C++-special 'default(_GCC_firstprivate)' clause [PR119692]" OK to push to trunk branch, with a few test cases added? (I might also suggest OpenACC 'default(firstprivate)' for standardization by the OpenACC

Re: [PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

On Wed, Apr 9, 2025 at 8:54 AM Ard Biesheuvel wrote: > > On Wed, 9 Apr 2025 at 16:46, H.J. Lu wrote: > > > > On Wed, Apr 9, 2025 at 1:53 AM Ard Biesheuvel wrote: > > > > > > From: Ard Biesheuvel > > > > > > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling > > > __fentry__")

[committed] d: Use CONSTRUCTOR_ZERO_PADDING_BITS in the D FE [PR117832]

Hi, This patch adds a new wrapper function for `build_constructor', and calls it instead to ensure that all CONSTRUCTOR nodes explicitly created by the front-end have CONSTRUCTOR_ZERO_PADDING_BITS set. Some places may not be necessary as it's guaranteed for there to be no padding in the type, suc

Re: [PATCH] deref-before-check-pr113253.c: Fix bogus warnings on lp32

On 4/7/25 3:48 PM, Jonathan Yong wrote: Attached patch OK for master branch? Will push soon if there are no objections. Pushed to master branch.

Re: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3

I see, reverted. Thanks Robin for reminder. Thanks! BTW and just for open discussion, is this really a good way for such kind of tests? Though most of the tests are similar like this but it may hide possible unexpected results up to a point. Yeah we have several flaky tests and in those cas

[PATCH] c++: Use G_ instead of _ around cp/errors.cc gcc-internal-format strings [PR119684]

Hi! These pp_printf/pp_verbatim format strings should be gcc-internal-format, they use the pretty-print.cc format specifier handling rather than libc *printf, but pp_printf/pp_verbatim are intentionally not handled through exgettext because not everything done through them should be translated (e.

[PATCH] riscv: Fix r15-9270 fallout on RISC-V

Hi! On Wed, Apr 09, 2025 at 02:38:01PM +0200, Mark Wielaard wrote: > Unfortunately this seems to have broken the riscv bootstrap: > https://builder.sourceware.org/buildbot/#/builders/337/builds/105 > > ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: > enumeration value ‘TCTX_

[PATCH] c++: alias_ctad_tweaks ICE w/ inherited CTAD [PR119687]

Bootstrap and regtest running on x86_64-pc-linux-gnu, does this look OK for trunk/14 if successful? On a similar note, as a small optimization in deduction_guides_for I think we can replace the lookup_add loop with a single call to lookup_add, but I'll leave that for GCC 16. -- >8 -- With inheri

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 9, 2025, at 11:31, Siddhesh Poyarekar wrote: > > On 2025-04-09 08:30, Qing Zhao wrote: >> After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument. >> And all the size expression before the call to .ACCESS_WITH_SIZE might be >> dead >> code eliminated later in the

[committed] [RISC-V] Fix more fallout from combine.c changes

Trivial fallout from the recent combine work. We end up with a srai rather than an xor in some of the saturation sequences. Both variants look equally performant, so I'm just adjusting the expected test output. Pushing to the trunk. Jeff commit c08d717ce9e18dcfa5b4efe49a5f570ac32fd1cf Autho

Re: [PATCH] libgcobol: Handle long double as an alternate IEEE754 128b

Hi Iain, > Here is what I'm testing as an incremental fix, so far OK on x86_64-darwin > and powerpcle64 (GLIBC 2.34) .. others in progress. Does it help the > Solaris cases? I'll give it a try. Here's what I have (I believe it's more readable in some cases), but as I said something's not right

[PATCH] libbacktrace: Add hpux fileline support

Tested on hppa64-hp-hpux11.11. Okay? Dave --- libbacktrace: Add hpux fileline support Fixes libstdc++ stacktrace tests. 2025-04-09 John David Anglin libbacktrace/ChangeLog: * fileline.c (hpux_get_executable_path): New. (fileline_initialize): Add pass to get hpux executable

Re: [PATCH GCC 14] c++: ICE with nested default targ lambdas [PR119574]

On 4/8/25 10:29 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for the 14 branch? OK. -- >8 -- In GCC 14 we fixed PR116567 in a more conservative way that doesn't distinguish between the two kinds of deferred substitutions, and we instead ICE fr

[PATCH v2] RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547].

Hi, when lifting up a vsetvl into a block we currently don't consider the block's transparency with respect to the vsetvl as in other parts of the pass. This patch does not perform the lift when transparency is not guaranteed. This condition is more restrictive than necessary as we can still pe

Re: [PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

On Wed, Apr 9, 2025 at 6:21 PM H.J. Lu wrote: > fprintf (file, "1:\tcall\t*%s@GOT(%%ebx)\n", mcount_name); > diff --git a/gcc/testsuite/gcc.target/i386/pr119386-1.c > b/gcc/testsuite/gcc.target/i386/pr119386-1.c > index 174d00f1e27..56e44c89859 100644 > --- a/gcc/testsuite/gcc.target/i386/pr119

[committed] d: Fix forward referenced enums missing type names in debug info [PR118309]

Hi, This patch fixes a crash seen when gdb was debugging D programs. Calling `rest_of_type_compilation' as the D types were built meant that debug info was being emitted before all forward references were resolved, resulting in DW_AT_name's to be missing. Instead, defer outputting type debug inf

Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

Hi, Joseph and Martin, When I implemented the patch to attach the counted_by information to an array reference (FAM reference) in C FE, The work was done inside the routine “build_component_ref” in gcc/c/c-typeck.cc . and this is very reasonable and quite clean. Now, If

[PATCH] libgcobol: Handle long double as an alternate IEEE754 128b

Here is what I'm testing as an incremental fix, so far OK on x86_64-darwin and powerpcle64 (GLIBC 2.34) .. others in progress. Does it help the Solaris cases? --- 8< --- In some cases, we might be able to use strtold and snprintf for 128b IEEE754 (when the long double format agrees). libgcobol/

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 8, 2025, at 21:13, Siddhesh Poyarekar wrote: > > On 2025-04-08 15:22, Qing Zhao wrote: >> Changing a pointer reference to a call to .ACCESS_WITH_SIZE will impact the >> compiler optimization in two aspects: >> 1. The new call site might become a barrier that prevents code movement >

[committed] testsuite/x86: Correctly escape asterisk in scan-assembler

Asterisk in []* regexp applies to bracket expression. When asterisk is a part of the word, then it needs to be escaped with \\. Also use []+ instead of []* to match elements in bracket expression one or more times. gcc/testsuite/ChangeLog: * gcc.target/i386/pr67215-1.c: Correctly escape

Re: [PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

On Wed, Apr 9, 2025 at 1:53 AM Ard Biesheuvel wrote: > > From: Ard Biesheuvel > > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling > __fentry__") updated the logic that emits mcount() / __fentry__() calls > into function prologues when profiling is enabled, to avoid GOT-based

Re: vsetvl abormal edge (was Re: [PATCH v2] RISC-V: vsetvl: skip abnormal edge on vsetvl insertion [PR119533])

Hi Robin, On 4/8/25 21:56, Robin Dapp wrote: Yay ! It does work. Awesome. I've uploaded the further reduced test to PR/119533 >>> Hmm, I'm seeing the same ICE as before with my patch. Did you happen >>> to change >>> something else on your local tree still? Ye

Re: [PATCH v3] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

On Tue, 8 Apr 2025 at 15:33, H.J. Lu wrote: > > On Tue, Apr 8, 2025 at 3:46 AM Ard Biesheuvel wrote: > > > > From: Ard Biesheuvel > > > > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling > > __fentry__") updated the logic that emits mcount() / __fentry__() calls > > into fun

Re: [PATCH v2] RISC-V: Disable unsupported vsext/vzext patterns for XTheadVector.

On 4/8/25 8:54 PM, Jin Ma wrote: On Tue, 8 Apr 2025 14:27:16 -0600, Jeff Law wrote: On 4/7/25 12:26 AM, Jin Ma wrote: XThreadVector does not support the vsext/vzext instructions; however, due to the reuse of RVV optimizations, it may generate these instructions in certain cases. To prevent

cobol.1 fix for not using underscores in intrinsic function names

just stumbled over this and only have a mail client running, so... patch as text. The change is in all those cases: change _ (likely parsed from the parser or similar) to -. Kind regards, Simon -BASECONVERT BIT_OF BIT_TO_CHAR BOOLEAN_OF_INTEGER BYTE_LENGTH +BASECONVERT BIT-OF BIT-TO-CHAR BOO

[committed] cobol: Proper comparison of alphanumeric to refmoded numeric-display [PR119682]

This patch eliminates the error. cobol: Proper comparison of alphanumeric to refmoded numeric-display [PR119682] gcc/cobol PR cobol/119682 * genapi.cc: (cobol_compare): Change the call to __gg__compare(). libgcobol PR cobol/119682 * c

[PATCH] rs6000: Disable __builtin_scalar_byte_in_set when using -m32 [PR119629]

The __builtin_scalar_byte_in_set() built-in emits the cmpeqb instruction which produces undefined results when run in 32-bit mode. The current selector [power9-64] enables the built-in when using -m32 -mpowerpc64. Use the no32bit attribute to fully disable it for all -m32 compiles. This was boot

Re: [PATCH v3] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

On Tue, Apr 8, 2025 at 6:59 PM Ard Biesheuvel wrote: > > On Tue, 8 Apr 2025 at 18:44, H.J. Lu wrote: > > > > On Tue, Apr 8, 2025 at 9:39 AM Ard Biesheuvel wrote: > > > > > > On Tue, 8 Apr 2025 at 15:33, H.J. Lu wrote: > > > > > > > > On Tue, Apr 8, 2025 at 3:46 AM Ard Biesheuvel > > > > wrote

[PATCH v1 2/4] libstdc++: Add header mdspan to the build-system.

Creates a nearly empty header mdspan and adds it to the build-system and Doxygen config file. libstdc++-v3/ChangeLog: * doc/doxygen/user.cfg.in: Add . * include/Makefile.am: Ditto. * include/Makefile.in: Ditto. * include/precompiled/stdc++.h: Ditto. * inclu

[PATCH v1 0/4] Implement extents from the mdspan header.

Hi, This is a patch series that implements std::extents from . I've never contributed to GCC or libstdc++. Hence, any comments about obvious issues, e.g. too few/many tests, not following conventions w.r.t. checking prerequisites, use of 'friend class', choice of uglified names that could clash w

[PATCH v1 3/4] libstdc++: Implement std::extents [PR107761].

This implements std::extents from according to N4950 and contains partial progress towards PR107761. If an extent changes its type, there's a precondition in the standard, that the value is representable in the target integer type. This commit uses a static_cast for all of these conversions, with

Re: [PATCH v1 2/4] libstdc++: Add header mdspan to the build-system.

On Wed, 9 Apr 2025, 08:25 Luc Grosheintz, wrote: > Creates a nearly empty header mdspan and adds it to the build-system and > Doxygen config file. > Nice, thanks! I'll look at these patches properly another time (I'm unavailable today) but one quick comment below ... > libstdc++-v3/ChangeLog:

[PATCH v4 2/2] i386: Enable -mnop-mcount for -fpic with PLTs

From: Ard Biesheuvel On 64-bit, -mnop-mcount can be trivially enabled for -fPIC codegen as long as PLTs are being used, given that the instruction encodings are identical, only the target may resolve differently depending on how the linker decides to incorporate the object file. So relax the opt

[PATCH v4 1/2] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

From: Ard Biesheuvel Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling __fentry__") updated the logic that emits mcount() / __fentry__() calls into function prologues when profiling is enabled, to avoid GOT-based indirect calls when a direct call would suffice. There are two

Re: [PATCH 2/2] libgcobol: Allow libgcobol to use libquadmath [PR119244].

> On 9 Apr 2025, at 09:00, Rainer Orth wrote: > > Jakub Jelinek writes: > >> On Sun, Apr 06, 2025 at 09:02:07AM +0100, Iain Sandoe wrote: >>> >>> + >>> +#if !defined (HAVE_STRTOF128) >>> +# if USE_QUADMATH >>> +# define strtof128 strtoflt128 >>> +# else >>> +# error "no available string to

Re: [PATCH v1 4/4] libstdc++: Add tests for std::extents.

On Wed, 9 Apr 2025 at 08:30, Luc Grosheintz wrote: > > A prior commit added std::extents, this commits adds the tests. The bulk > is focussed on testing the constructors. These are split into three > groups: > > 1. the ctor from other extents and the copy ctor, > 2. the ctor from a pack of integer

Re: [PATCH v3] i386: Prefer PLT indirection for __fentry__ calls under -fPIC

On Tue, Apr 8, 2025 at 7:09 PM H.J. Lu wrote: > > Are there any existing test cases I should look at? > > Please see "gcc.target/i386/pr67215-*.c" While looking there, I noticed that the asterisk is not correctly escaped in scan strings. Asterisk in [...]* applies to square brackets, not scan st

New template for 'gcc' made available

Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: https://translationproject.org/POT-files/gcc

[PATCH] testsuite: Add -mabi to pr116595.C

Hi, as usual, I forgot to add -mabi=lp64d to the test case. This patch adds it. Going to push as obvious. Regards Robin gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/autovec/pr116595.C: Add -mabi. --- gcc/testsuite/g++.target/riscv/rvv/autovec/pr116595.C | 2 +- 1 file changed, 1 in

Re: [PATCH] libgomp: Update SVE tests

On 4/9/25 2:32 AM, Richard Sandiford wrote: The new SVE tests didn't explicitly force SVE to be enabled, which meant that they wouldn't work on targets that aren't configured for SVE by default. The least invasive way of fixing that is to add a pragma, which works for most tests. However, for ud

Re: [PATCH] libgomp: Update SVE tests

On Wed, Apr 09, 2025 at 04:01:49PM +0530, Tejas Belagod wrote: > > It also looks like there might be a missing "+" in simd_reduction: > > > >#pragma omp simd reduction (+:va, i) > >for (j = 0; j < 16; j++) > > va = svld1_s32 (svptrue_b32 (), a); > > > >res = svaddv_s32 (svptrue_b

Re: [PATCH v1 2/4] libstdc++: Add header mdspan to the build-system.

On Wed, 9 Apr 2025, 09:12 Jonathan Wakely, wrote: > > > On Wed, 9 Apr 2025, 08:25 Luc Grosheintz, > wrote: > >> Creates a nearly empty header mdspan and adds it to the build-system and >> Doxygen config file. >> > > Nice, thanks! I'll look at these patches properly another time (I'm > unavailabl

Re: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3

Hi Pan, Richard committed combine patches that restored most of the previous behavior so we shouldn't need the refinement any more. AFAICT the tests should now pass in their previous state but definitely fail in their current state. Do you want to revert this change? Thanks. -- Regards Robi

Re: [PATCH] libstdc++: Fix constraint recursion in basic_const_iterator operator- [PR115046]

On Tue, 8 Apr 2025, 23:01 Patrick Palka, wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? > OK for both. > -- >8 -- > > It was proposed in PR112490 to also adjust basic_const_iterator's friend > operator-(sent, iter) overload alongside the r15-7757-g4342c50ca84ae5 > adju

New template for 'gcc' made available

Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: https://translationproject.org/POT-files/gcc

New French PO file for 'gcc' (version 15.1-b20250406)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/gcc/fr.po (This file, 'gcc-15.1-b20250406.fr.po',

RE: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3

I see, reverted. Thanks Robin for reminder. BTW and just for open discussion, is this really a good way for such kind of tests? Though most of the tests are similar like this but it may hide possible unexpected results up to a point. Pan -Original Message- From: Robin Dapp Sent: Wedn