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'
cpplib-15-b20250216.zh_CN.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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
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
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
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
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
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
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
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
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,
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
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"
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
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
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
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
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
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
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
> 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
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
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
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
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_
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
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
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:
>
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
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
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
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
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
[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
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.
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
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++:
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
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
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
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:
>
> ../../../..
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
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
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
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’:
>
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++
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
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
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
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
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
>
> 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,
>
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)
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?
>
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
> 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.
>>
>>
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
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
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
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
> -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:
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
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.
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
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
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
--
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
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
68 matches
Mail list logo
