[PATCH] gimple-fold: Improve optimize_memcpy_to_memset to handle STRING_CST [PR78408]

While looking into PR 118947, I noticed that optimize_memcpy_to_memset didn't handle STRING_CST which are also used for a memset of 0 but for char arrays. This fixes that and improves optimize_memcpy_to_memset to handle that case. This fixes part of PR 118947 but not the whole thing; we still need

[PATCH] Append a newline in debug_edge

Append a newline in debug_edge so that we get (gdb) call debug_edge (e) edge (bb_9, bb_1) (gdb) instead of (gdb) call debug_edge (e) edge (bb_9, bb_1)(gdb) * sese.cc (debug_edge): Append a newline. -- H.J. From 9d209112f37f681cd1e214a3412336476ca18527 Mon Sep 17 00:00:00 2001 From: "H.J. Lu"

Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)

On Thu, 20 Feb 2025, James K. Lowden wrote: > The Makefile fetches the NIST archive from our website. (We originally > got it from NIST, but their site was reorganized last year. The file > went missing, as apparently did my email to the webmaster. > Technology!) The file might have 100 targets

[PATCH] c++: too many errors with sneaky template [PR118516]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Since C++20 P0846, a name followed by a < can be treated as a template-name even though name lookup did not find a template-name. That happens in this test with "i < foo ()": for (int id = 0; i < foo(); ++id); and results i

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

[pushed: r15-7659] diagnostics: add comments about global_dc

No functional change intended. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r15-7659-g4e9ee99647ebb9. gcc/ChangeLog: * diagnostic-core.h: Add comments making clear that these functions implicitly use global_dc. Signed-off-by: David Malcolm --

[pushed: r15-7658] sarif-replay: add testcase for empty input file

Successfully tested on x86_64-pc-linux-gnu. Pushed to trunk as r15-7658-gc5f541e40aca2d gcc/testsuite/ChangeLog: * sarif-replay.dg/malformed-json/empty.sarif: New test. Signed-off-by: David Malcolm --- gcc/testsuite/sarif-replay.dg/malformed-json/empty.sarif | 2 ++ 1 file changed, 2 in

[pushed: r15-7657] sarif-replay: improve error for unescaped braces in messages (§3.11.5)

Spotted via https://github.com/llvm/llvm-project/issues/128024 Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r15-7657-g5a30a3aba065f6. gcc/ChangeLog: * libsarifreplay.cc (sarif_replayer::make_plain_text_within_result_message): Capture wh

[PATCH 2/4] libstdc++: Avoid '-Wunused-parameter' for 'nofollow' in static member function 'static std::filesystem::__gnu_posix::DIR* std::filesystem::_Dir_base::openat(const _At_path&, bool)'

In a newlib configuration: In file included from ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:37, from ../../../../../source-gcc/libstdc++-v3/src/c++17/cow-fs_dir.cc:26: ../../../../../source-gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h: In s

RE: [PATCH] COBOL 3/15 92K bld: config and build machinery

> -Original Message- > From: Paul Koning > Sent: Thursday, February 20, 2025 13:22 > To: James K. Lowden > Cc: Matthias Klose ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] COBOL 3/15 92K bld: config and build machinery > > > > > On Feb 19, 2025, at 8:18 PM, James K. Lowden > wrote:

[PATCH] i386: Fix pr101950-2.c [PR115028]

So what is happening here is that after r15-268-g9dbff9c05520a7, a move instruction still exists after combine and the register allocator choses different register allocation order for the xor and because the input operand of lzcntq is not the same as output operand, there is an extra xor that happ

[PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer [PR48958]

Dear all, the attached simple patch addresses a small, left-over issue in the above PR and was already OK'ed in the PR by Thomas. With it we initialize the data component of a non-saved pointer variable when -fcheck=pointer is specified, so that subsequent pointer checks (e.g. for the SIZE intri

Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)

On Thu, 20 Feb 2025 11:38:58 +0100 Richard Biener wrote: > Can you clarify on the future development model for Cobol after it has > been merged? Is the cobolworx gitlab still going to be the primary > development location and changes should be made there and then merged > to the GCC side? I w

Re: 6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes

Hi Andre, this patch broke Solaris bootstrap: /vol/gcc/src/hg/master/local/libgfortran/caf/single.c: In function ‘_gfortran_caf_transfer_between_remotes’: /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:675:23: error: implicit declaration of function ‘alloca’ [-Wimplicit-function-declarat

Re: [PATCH] COBOL 3/15 92K bld: config and build machinery

> On Feb 19, 2025, at 8:18 PM, James K. Lowden wrote: > > On Wed, 19 Feb 2025 12:55:03 +0100 > Matthias Klose wrote: > >> libgcobol/ChangeLog >> * Makefile.in: New file. >> * acinclude.m4: New file. >> * aclocal.m4: New file. >> * configure.ac: New file. >> * configure.tgt: New file. >> >>

Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'

On 2/19/25 10:08 AM, Tobias Burnus wrote: The attached patch does some ground-laying work for OpenMP deep mapping - touching common gfortran code. It does so by: (1)gfc_tree_array_size now can determine the array size not only from the passed Fortran gfc_expr but also using a descriptor, passe

Re: libstdc++: Avoid '-Wunused-parameter's

On Thu, 20 Feb 2025 at 17:06, Thomas Schwinge wrote: > > Hi! > > In the following, a few patches for libstdc++ to avoid > '-Wunused-parameter' diagnostics (actually '-Werror=unused-parameter', > for my '--enable-werror' builds). So far, only build-tested for GCN, > nvptx. Are these changes OK? >

Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'

Just to be clear: the following touches generic Fortran code and, hence, needs Fortran FE review (still pending): Tobias Burnus wrote: (1) gfc_tree_array_size now can determine the array size not only from the passed Fortran gfc_expr but also using a descriptor, passed as gimple 'tree'. (2)

Re: [PATCH v2] ira: Add a target hook for callee-saved register cost scale

> > Thanks for running these. I saw poor results for perlbench with my > initial aarch64 hooks because the hooks reduced the cost to zero for > the entry case: > > auto entry_cost = targetm.callee_save_cost > (spill_cost_type::SAVE, hard_regno, mode, saved_nregs, >

Re: Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations (was: libstdc++: '_GLIBCXX_HAS_GTHREADS' -- '__GTHREADS' vs. '__GTHREADS_CXX0X')

On Thu, 20 Feb 2025 at 17:28, Thomas Schwinge wrote: > > Hi! > > On 2025-02-20T16:36:56+, Jonathan Wakely wrote: > > On 20/02/25 15:50 +0100, Thomas Schwinge wrote: > >>From 820e015494e25187c9a5ffbd69911ec6ce612789 Mon Sep 17 00:00:00 2001 > >>From: Jonathan Wakely > >>Date: Thu, 20 Feb 2025

Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations (was: libstdc++: '_GLIBCXX_HAS_GTHREADS' -- '__GTHREADS' vs. '__GTHREADS_CXX0X')

Hi! On 2025-02-20T16:36:56+, Jonathan Wakely wrote: > On 20/02/25 15:50 +0100, Thomas Schwinge wrote: >>From 820e015494e25187c9a5ffbd69911ec6ce612789 Mon Sep 17 00:00:00 2001 >>From: Jonathan Wakely >>Date: Thu, 20 Feb 2025 14:08:11 + >>Subject: [PATCH] Fix 'libstdc++-v3/src/c++20/tzdb.c

Re: [PATCH 1/4] libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'

On Thu, 20 Feb 2025 at 17:06, Thomas Schwinge wrote: > > In a '-fno-exceptions' configuration: > > In file included from > ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29: > [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void > std::__throw_format_error(con

[pushed] aarch64: Remove old aarch64_expand_sve_vec_cmp_float code

While looking at PR118956, I noticed that we had some dead code left over after the removal of the vcond patterns. The can_invert_p path is no longer used. Tested on aarch64-linux-gnu & pushed. Richard gcc/ * config/aarch64/aarch64-protos.h (aarch64_expand_sve_vec_cmp_float): R

[PATCH] i386: Quote user-defined symbols in assembly in Intel syntax

Hello, This patch proposes a solution to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929, and is required by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881. I have so far bootstrapped master on i686-w64-mingw32 with DWARF2 exception model, and on x86_64-w64-mingw32 with SEH exception m

Re: [PATCH 3/4] libstdc++: Avoid '-Wunused-parameter' for 'is_directory' in member function 'bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_code&) const'

On Thu, 20 Feb 2025 at 17:02, Thomas Schwinge wrote: > > In a newlib configuration: > > ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc: In member > function ‘bool std::filesystem::__cxx11::_Dir::do_unlink(bool, > std::error_code&) const’: > ../../../../../source-gcc/libstdc++

Re: [PATCH 4/4] libstdc++: Avoid '-Wunused-parameter' for 'out' in member function 'std::codecvt_base::result std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&) const'

On Thu, 20 Feb 2025 at 16:59, Thomas Schwinge wrote: > > In a newlib configuration: > > ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc: In member > function ‘std::codecvt_base::result > std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&) > const’: >

libstdc++: Avoid '-Wunused-parameter's

Hi! In the following, a few patches for libstdc++ to avoid '-Wunused-parameter' diagnostics (actually '-Werror=unused-parameter', for my '--enable-werror' builds). So far, only build-tested for GCN, nvptx. Are these changes OK? What are exactly the semantics for '_GLIBCXX_THROW_OR_ABORT', shoul

[PATCH 1/4] libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'

In a '-fno-exceptions' configuration: In file included from ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29: [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void std::__throw_format_error(const char*)’: [...]/build-gcc/[...]/libstdc++-v3/include/format:2

[PATCH 4/4] libstdc++: Avoid '-Wunused-parameter' for 'out' in member function 'std::codecvt_base::result std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&) const'

In a newlib configuration: ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc: In member function ‘std::codecvt_base::result std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&) const’: ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:100:35: er

Re: [PATCH 2/4] libstdc++: Avoid '-Wunused-parameter' for 'nofollow' in static member function 'static std::filesystem::__gnu_posix::DIR* std::filesystem::_Dir_base::openat(const _At_path&, bool)'

On Thu, 20 Feb 2025 at 16:58, Thomas Schwinge wrote: > > In a newlib configuration: > > In file included from > ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:37, > from > ../../../../../source-gcc/libstdc++-v3/src/c++17/cow-fs_dir.cc:26: > > ../../../..

[PATCH 3/4] libstdc++: Avoid '-Wunused-parameter' for 'is_directory' in member function 'bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_code&) const'

In a newlib configuration: ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc: In member function ‘bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_code&) const’: ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:147:18: error: unused parameter ‘is_direct

Re: [PATCH] arm: Fix signedness of some vld1q intrinsic parameters for ARM NEON

Hi, On Thu, 20 Feb 2025 at 15:18, Hannes Braun wrote: > > vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting > pointers to unsigned integers. These parameters should be pointers to > signed integers. > > gcc/ChangeLog: > > * config/arm/arm_neon.h (vld1q_s8_x3): Use in

Re: Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations (was: libstdc++: '_GLIBCXX_HAS_GTHREADS' -- '__GTHREADS' vs. '__GTHREADS_CXX0X')

On 20/02/25 15:50 +0100, Thomas Schwinge wrote: Hi! On 2025-02-20T14:14:44+, Jonathan Wakely wrote: On Thu, 20 Feb 2025 at 14:08, Jonathan Wakely wrote: On Thu, 20 Feb 2025 at 13:53, Thomas Schwinge wrote: > On 2025-02-20T12:51:15+, Jonathan Wakely wrote: > > On Thu, 20 Feb 2025 at

Re: [PATCH] libstdc++: implement constexpr memory algorithms

On Sun, 16 Feb 2025, Giuseppe D'Angelo wrote: > Hello, > > the attached patch implements the C++26 papers that add `constexpr` to the > specialized memory algorithms (the uninitialized_* family). Tested on x86-64 > Linux. > > Thank you, > -- > Giuseppe D'Angelo > > Subject: [PATCH] libstdc++:

Re: [PATCH 1/2] libstdc++: Fix invalid signed arguments to functions

On Thu, 20 Feb 2025 at 14:41, Patrick Palka wrote: > > On Sat, 15 Feb 2025, Jonathan Wakely wrote: > > > These should have been unsigned, but the static assertions are only in > > the public std::bit_ceil and std::bit_width functions, not the internal > > __bit_ceil and __bit_width ones. > > > > l

Re: Larger diagnostic questions/plan

On 2/20/25 7:17 AM, Richard Biener wrote: I hesitate to even bring it up (but we need to). Do we want to consider the state/future of these warnings for gcc-16? Is this stuff salvageable? I think there's utility in these warnings, but they're clearly a pain point across multiple contexts.

[PATCH] libiberty: move DW_LANG_* definitions to dwarf2.def

[Note: I don't have push access to gcc, so if approved, please push it on my behalf, thanks.] I need to have a "DW_LANG_* to string" function for a change I'm making in binutils-gdb. I'm sending this patch to gcc first, once merged I'll sync it to binutils-gdb. - move the "DW_LANG_*" definiti

Re: [PATCH v2] aarch64: Ignore target pragmas while defining intrinsics

On Wed, Feb 19, 2025 at 12:17:55PM +, Richard Sandiford wrote: > Andrew Carlotti writes: > > [...] > > @@ -204,6 +207,18 @@ static constexpr aarch64_processor_info all_cores[] = > >{NULL, aarch64_no_cpu, aarch64_no_arch, 0} > > }; > > > > +/* Return the set of feature flags that are req

Re: [PATCH][RFC][PR tree-optimization/117829] Bogus Warray-bounds warning

On Thu, Feb 20, 2025 at 3:14 PM Jeff Law wrote: > > > > On 2/20/25 12:52 AM, Richard Biener wrote: > > On Wed, Feb 19, 2025 at 11:29 PM Jeff Law wrote: > >> > >> > >> An interesting little bug. We're just emitting what appears to me to be > >> a silly warning. > >> > >> By the time the array-bou

Re: [PATCH] config.host: add crtbeginT.o to extra_parts for FreeBSD [PR118685]

On Sat, 8 Feb 2025, Gerald Pfeifer wrote: > On Tue, 28 Jan 2025, Dimitry Andric wrote: >> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685 >> >> This ensures that gcc uses its own crt objects for static linking. >> Otherwise, it could mix the base system's crtbeginT.o with libgcc's >> crte

Re: rs6000: Add -msplit-patch-nops (PR112980)

On Wed, Nov 13, 2024 at 4:45 PM Andreas Schwab wrote: > > On Nov 13 2024, Michael Matz wrote: > > > @@ -31658,6 +31660,17 @@ requires @code{.plt} and @code{.got} > > sections that are both writable and executable. > > This is a PowerPC 32-bit SYSV ABI option. > > > > +@opindex msplit-patch-nops

Re: [PATCH] c++: ICE with GOTO_EXPR [PR118928]

Now with the test fixed. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- In this PR we crash in cxx_eval_constant_expression/GOTO_EXPR on: gcc_assert (cxx_dialect >= cxx23); The code obviously doesn't expect to see a goto pre-C++23. But we can get here with the new prva

Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && !__GTHREADS_CXX0X' configurations (was: libstdc++: '_GLIBCXX_HAS_GTHREADS' -- '__GTHREADS' vs. '__GTHREADS_CXX0X')

Hi! On 2025-02-20T14:14:44+, Jonathan Wakely wrote: > On Thu, 20 Feb 2025 at 14:08, Jonathan Wakely wrote: >> On Thu, 20 Feb 2025 at 13:53, Thomas Schwinge wrote: >> > On 2025-02-20T12:51:15+, Jonathan Wakely wrote: >> > > On Thu, 20 Feb 2025 at 12:29, Thomas Schwinge >> > > wrote: >

Re: [PATCH 1/2] libstdc++: Fix invalid signed arguments to functions

On Sat, 15 Feb 2025, Jonathan Wakely wrote: > These should have been unsigned, but the static assertions are only in > the public std::bit_ceil and std::bit_width functions, not the internal > __bit_ceil and __bit_width ones. > > libstdc++-v3/ChangeLog: > > * include/experimental/bits/simd

[PATCH] arm: Fix signedness of some vld1q intrinsic parameters for ARM NEON

vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting pointers to unsigned integers. These parameters should be pointers to signed integers. gcc/ChangeLog: * config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of uint16_t. (vld1q_s16_x3): Use int16_t

Re: [PATCH v2] ira: Add a target hook for callee-saved register cost scale

Jan Hubicka writes: >> On Wed, Feb 19, 2025 at 9:06 PM Jan Hubicka wrote: >> > >> > Hi, >> > this is a variant of a hook I benchmarked on cpu2016 with -Ofast -flto >> > and -O2 -flto. For non -Os and no Windows ABI should be pratically the >> > same as your variant that was simply returning mem_

Re: [PATCH] tree-optimization/118521 - bogus diagnostic from unreachable code

On Thu, 20 Feb 2025, Jeff Law wrote: > > > On 2/20/25 5:47 AM, Richard Biener wrote: > > When SCCP does final value replacement we end up with unfolded IL like > > > > __result_274 = _150 + 1; > > ... > > __new_finish_106 = __result_274 + 3; <-- from SCCP > > _115 = _150 + 4; > > if (__new_fin

Re: [PATCH][RFC][PR tree-optimization/117829] Bogus Warray-bounds warning

On 2/20/25 12:52 AM, Richard Biener wrote: On Wed, Feb 19, 2025 at 11:29 PM Jeff Law wrote: An interesting little bug. We're just emitting what appears to me to be a silly warning. By the time the array-bounds checker runs we have this statement in the IL: MEM[(int *)_42 + -4B] ={v

[PATCH v2] rs6000: Adding missed ISA 3.0 atomic memory operation instructions.

Hi All, The following patch has been bootstrapped and regtested on powerpc64le-linux. Changes to amo.h include the addition of the following load atomic operations: Compare and Swap Not Equal, Fetch and Increment Bounded, Fetch and Increment Equal, and Fetch and Decrement Bounded. Additionally, S

Re: [PATCH][v3] tree-optimization/86270 - improve SSA coalescing for loop exit test

On 2/20/25 12:38 AM, Richard Biener wrote: On Wed, 19 Feb 2025, Jeff Law wrote: On 2/15/25 6:36 AM, Richard Biener wrote: The PR indicates a very specific issue with regard to SSA coalescing failures because there's a pre IV increment loop exit test. While IVOPTs created the desired IL w

Re: [PATCH v2] ira: Add a target hook for callee-saved register cost scale

> On Wed, Feb 19, 2025 at 9:06 PM Jan Hubicka wrote: > > > > Hi, > > this is a variant of a hook I benchmarked on cpu2016 with -Ofast -flto > > and -O2 -flto. For non -Os and no Windows ABI should be pratically the > > same as your variant that was simply returning mem_cost - 2. > > > I've tested

Re: [PATCH] tree-optimization/118521 - bogus diagnostic from unreachable code

On 2/20/25 5:47 AM, Richard Biener wrote: When SCCP does final value replacement we end up with unfolded IL like __result_274 = _150 + 1; ... __new_finish_106 = __result_274 + 3; <-- from SCCP _115 = _150 + 4; if (__new_finish_106 != _115) this does only get rectified by the next full foldi

[PATCH] tree-optimization/118521 - bogus diagnostic from unreachable code

When SCCP does final value replacement we end up with unfolded IL like __result_274 = _150 + 1; ... __new_finish_106 = __result_274 + 3; <-- from SCCP _115 = _150 + 4; if (__new_finish_106 != _115) this does only get rectified by the next full folding which happens in forwprop4 which is after th

[COMMITED] invoke.texi: Fix typo in the file-cache-lines param

Pushed as obvious. Filip Kastl -- 8< -- file-cache-lines param was documented as file-cache-files. This fixes the typo. gcc/ChangeLog: * doc/invoke.texi: Fix typo file-cache-files -> file-cache-lines. Signed-off-by: Filip Kastl --- gcc/doc/invoke.texi | 2 +- 1 file chang

[PATCH v2 2/2] libstdc++: Use new type-generic built-ins in [PR118855]

This makes several functions in faster to compile, with fewer expressions to parse and fewer instantiations of __numeric_traits required. libstdc++-v3/ChangeLog: PR libstdc++/118855 * include/std/bit (__count_lzero, __count_rzero, __popcount): Use type-generic built-ins w

[PATCH 1/2] libstdc++: Add parentheses around _GLIBCXX_HAS_BUILTIN definition

This allows _GLIBCXX_HAS_BUILTIN (or _GLIBCXX_USE_BUILTIN_TRAIT) to be used as part of a larger logical expression. libstdc++-v3/ChangeLog: * include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Add parentheses. --- Tested x86_64-linux. Pushed to trunk. This isn't currently necessary on the r

[PATCH 2/2] libstdc++: Workaround Clang bug with __array_rank built-in [PR118559]

We started using the __array_rank built-in with r15-1252-g6f0dfa6f1acdf7 but that built-in is buggy in versions of Clang up to and including 19. libstdc++-v3/ChangeLog: PR libstdc++/118559 * include/std/type_traits (rank, rank_v): Do not use __array_rank for Clang 19 and o

[PATCH 2/2] libstdc++: Remove workaround for reserved init_priority warnings

Since r15-7511-g4e7f74225116e7 we can disable the warnings for using a reserved priority using a diagnostic pragma. That means we no longer need to put globals using that attribute into separate files that get included. This replaces the two uses of such separate files by moving the variable defin

[PATCH 1/2] libstdc++: Use init_priority attribute for tzdb globals [PR118811]

When linking statically to libstdc++.a (or to libstdc++_nonshared.a in the RHEL devtoolset compiler) there's a static initialization order problem where user code might be constructed before the std::chrono::tzdb_list globals, and so might try to use them after they've already been destroyed. Use

Re: The COBOL front end, version 3, now in 14 easy pieces

On Wed, Feb 19, 2025 at 12:38 AM James K. Lowden wrote: > > The following 14 patches constitute 105,720 lines of code in 83 files > to build and document the COBOL front end. The messages are > in a more or less logical order. We have: > > 1/14 4K dir: create gcc/cobol and libgcobol directorie

Contents of PO file 'cpplib-15-b20250216.zh_CN.po'

cpplib-15-b20250216.zh_CN.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

New Chinese (simplified) PO file for 'cpplib' (version 15-b20250216)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Chinese (simplified) team of translators. The file is available at: https://translationproject.org/latest/cpplib/zh_CN.po (This file, 'cpp

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

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 test this? The change looks good in my browser. Is there a style checker, I don'

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

Hi all, I just merged the patch series as gcc-15-7644-gd3244675441. Thanks for all the reviews. I will now prepare the Relasenotes. Regards and thanks again, Andre On Tue, 18 Feb 2025 18:13:53 +0100 Thomas Koenig wrote: > Am 18.02.25 um 16:00 schrieb Andre Vehreschild: > > Hi Thomas,

Re: [PATCH] RISC-V: Minimal support for Qualcomm uC Xqccmp extension.

Seeing some work submitted in llvm, I would like to add support in gcc as well. I am sorry that the binutils patch is working in progress, and I will CC you the binutils patches as soon as possible. Thanks, Dongyan Chen 在 2025/2/20 16:39, Andrew Pinski 写道: On Thu, Feb 20, 2025 at 12:33 AM D

Re: [PATCH] RISC-V: Minimal support for Qualcomm uC Xqccmp extension.

On Thu, Feb 20, 2025 at 12:33 AM Dongyan Chen wrote: > > This patch support Qualcomm uC Xqccmp extension[1]. > To enable GCC to recognize and process xqccmp extension correctly at compile > time. > > [1]https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0 I am kinda of cu

Re: [PATCH] RISC-V: Minimal support for Qualcomm uC Xqccmp extension.

On 20/2/2025 16:31, Dongyan Chen wrote: This patch support Qualcomm uC Xqccmp extension[1]. To enable GCC to recognize and process xqccmp extension correctly at compile time. [1]https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0 gcc/ChangeLog: * common/con

[PATCH] RISC-V: Minimal support for Qualcomm uC Xqccmp extension.

This patch support Qualcomm uC Xqccmp extension[1]. To enable GCC to recognize and process xqccmp extension correctly at compile time. [1]https://github.com/quic/riscv-unified-db/releases/tag/Xqccmp_extension-0.1.0 gcc/ChangeLog: * common/config/riscv/riscv-common.cc: New extension.