Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The warning compares the position of a field depending on whether or not the
previous base/field is considered a POD for layout, but failed to consider
whether the previous base/field is empty; layout of an empty base doesn't
consider PODnes
Thomas Schwinge wrote:
On 2025-05-12T17:03:29+0200, I wrote:
"Add effective-target 'offload_device_usm',
'libgomp.c-c++-common/target-usm-1.c'"
On top, we could then add the attached
"libgomp: Add a few more OpenMP/USM test cases"? These all PASS for GCN
gfx90a with 'HSA_XNACK=1'.
For the c
On Mon, May 12, 2025 at 3:56 AM Richard Biener
wrote:
>
> On Sat, May 10, 2025 at 3:13 AM Andrew Pinski
> wrote:
> >
> > This move this canonicalization from forwprop
> > (forward_propagate_into_gimple_cond)
> > to gimple-fold.
> > This is a step in removing forward_propagate_into_gimple_cond f
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 Spanish team of translators. The file is available at:
https://translationproject.org/latest/cpplib/es.po
(This file, 'cpplib-15.1-b202503
cpplib-15.1-b20250316.es.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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
On Mon, May 12, 2025 at 3:51 AM Richard Biener
wrote:
>
> On Sat, May 10, 2025 at 3:19 AM Andrew Pinski
> wrote:
> >
> > with -ftrapping-math -fnon-call-exceptions and:
> > ```
> > tmp = FP0 CMP FP1;
> >
> > if (tmp != 0) ...
> > ```
> > a call fold_stmt on the GIMPLE_COND will replace the above
On 12/05/25 17:53 +0200, Alejandro Colomar wrote:
This operator is similar to sizeof but can only be applied to an array,
and returns its number of elements.
FUTURE DIRECTIONS:
- We should make it work with array parameters to functions,
and somehow magically return the number of elements of
Hi,
I concur that it would be useful to have information about
USM suport something. I am less sure what we should test for.
Q1: Does the default device support USM (and is not the host)?
Q2: Is there a device that support 'requires unified_shared_memory'?
At a glance, the answer for both is id
Hi
As back to stage 1is it ok to commit this change ?
François
On 31/03/2025 22:20, François Dumont wrote:
Hi
Following this previous patch
https://gcc.gnu.org/pipermail/libstdc++/2024-August/059418.html I've
completed it for the _Safe_unordered_container_base type and
implemented the res
Andreas Schwab writes:
> * regex.c (regex_compile): Don't write beyond array bounds when
> collecting range expression.
This is OK.
Thanks.
Ian
On Mon, 12 May 2025, Alejandro Colomar wrote:
> + if (strcmp (xstr(countof), "_Alignas") != 0)
countof should definitely not expand to _Alignas! I don't recommend
posting untested patches.
--
Joseph S. Myers
josmy...@redhat.com
On Mon, 12 May 2025 at 17:34, Jonathan Wakely wrote:
>
> On Mon, 12 May 2025 at 16:46, Alejandro Colomar wrote:
> >
> > contrib/ChangeLog:
> >
> > * gcc-changelog/git_commit.py (GitCommit):
> > Add support for 'Link:' tags.
> >
> > Cc: Jason Merrill
>
> I don't think we want a Cc
On Mon, 12 May 2025 at 16:46, Alejandro Colomar wrote:
>
> contrib/ChangeLog:
>
> * gcc-changelog/git_commit.py (GitCommit):
> Add support for 'Link:' tags.
>
> Cc: Jason Merrill
I don't think we want a Cc: trailer in the actual commit message. do we?
What is a Link: tag? I assu
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
Richard Biener writes:
> The following moves vector lowering to before vectorization - in fact
> to before DCE/forwprop and CSE. This gets us the chance to re-vectorize
> the lowered form eventually. Note that when the vectorizer learns to
> handle vector code vector lowering should be likely in
This patch folds vector expressions of the form (x + y) >> 1 into
IFN_AVG_FLOOR (x, y), reducing instruction count on platforms that
support averaging operations. For example, it can help improve the
codegen on AArch64 from:
add v0.4s, v0.4s, v31.4s
ushrv0.4s, v0.4s, 1
to:
Thank you for all the work that you have done by doing the two
implementations and
extensive test cases. I wanted to respond to a few points that I think we
may want
to consider to be bugs in specification, and report them as bugs in
standard.
(Would you be interested in doing so?)
I do not unders
It has been standardized in C2y.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_sizeof_or_countof_expression):
Add -Wpedantic diagnostic for _Countof in <= C23 mode.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-compat.c
* gcc.dg/countof-no-compat.c
* gcc.dg/counto
Hi!
Here's the list of changes in v21:
- Drop patch 1 (I've sent it separately, as Joseph requested).
- Keep Link tags. This means the other patch is an implicit dependency
of this patch set.
- Fix test compiler flags. [Joseph]
- Add tests for . [Joseph]
- Add tests for pedantic diagno
gcc/ChangeLog:
* Makefile.in (USER_H): Add .
* ginclude/stdcountof.h: Add countof macro.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-stdcountof.c: Add tests for .
Signed-off-by: Alejandro Colomar
---
gcc/Makefile.in | 1 +
gcc/ginclude/stdcount
This operator is similar to sizeof but can only be applied to an array,
and returns its number of elements.
FUTURE DIRECTIONS:
- We should make it work with array parameters to functions,
and somehow magically return the number of elements of the array,
regardless of it being really a poin
cmov optab was added back in r0-24110-g1c0290eaac4094
(https://gcc.gnu.org/pipermail/gcc-patches/1999-September/018596.html)
but it was never used. movcc is used instead and since r0-93453-gf90b7a5a7913cc
(cond-optab),
movcc becomes what cmov_optab was going to be; in having a combined compare and
> -Original Message-
> From: Richard Biener
> Sent: Monday, May 12, 2025 1:46 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina ; RISC-V CI c...@rivosinc.com>
> Subject: [PATCH] Cleanup internal vectorizer costing API
>
> This tries to cleanup the API available to vectorizable_* to
contrib/ChangeLog:
* gcc-changelog/git_commit.py (GitCommit):
Add support for 'Link:' tags.
Cc: Jason Merrill
Signed-off-by: Alejandro Colomar
---
Hi,
This patch is needed by my patches that add _Countof.
Have a lovely day!
Alex
contrib/gcc-changelog/git_commit.py | 3 +++
On 5/9/25 8:16 AM, Tomasz Kaminski wrote:
The test I would perform would be :
std::layout_left::mapping> l0;
std::layout_right:mapping> r0;
// stride
bool all_unique()
{
return l0.is_unique();
return r0.is_unique();
}
And we should have only one is_unique symbol.
but with a lot more d
On 5/9/25 11:33 AM, Nathaniel Shead wrote:
On Fri, May 09, 2025 at 08:18:58AM -0400, Jason Merrill wrote:
On 4/21/25 6:22 AM, Nathaniel Shead wrote:
This call is not necessary, as we don't access the bodies of any classes
that we instantiate here.
This turns out to break
20_util/function_obj
Hi Tobias,
Following up on your review comments, I have updated the patch.
Specifically, I have:
* Added the PR number to the subject line.
* Used the -b and -p options when running git gcc-commit-mklog.
* Updated the intrinsic documentation as requested.
Could you please take another look when yo
On 5/9/25 1:31 PM, Jonathan Wakely wrote:
On Fri, 9 May 2025 at 18:13, Jonathan Wakely wrote:
On Fri, 9 May 2025 at 11:19, Jonathan Wakely wrote:
On Thu, 8 May 2025 at 20:56, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense for trunk?
Yes, it looks useful. I'm goi
On Mon, May 12, 2025 at 10:54:34AM +, Joseph Myers wrote:
> On Sun, 11 May 2025, Alejandro Colomar wrote:
>
> > +/* { dg-options "-Wno-declaration-after-statement -Wno-pedantic -Wno-vla"
> > } */
>
> > +/* { dg-options "-Wno-pedantic -Wvla-parameter" } */
>
> > +/* { dg-options "-Wno-declar
PING.
There is actually a minor update as meanwhile CUDA 12.8 was
released that added the 'f' suffix and sm_103 and sm_121.
Still, the pattern remains the same; hence, a normal PING.
On April 25, 2025, Tobias Burnus wrote:
The idea of -march-map= is to simply and future proof select the
best -
Hi!
On 2025-05-12T17:03:29+0200, I wrote:
> "Add effective-target 'offload_device_usm',
> 'libgomp.c-c++-common/target-usm-1.c'"
On top, we could then add the attached
"libgomp: Add a few more OpenMP/USM test cases"? These all PASS for GCN
gfx90a with 'HSA_XNACK=1'.
Grüße
Thomas
>From 8c04
Hi!
On 2025-05-07T13:58:38+0200, Tobias Burnus wrote:
> Committed asr16-445-g9565076f9b8105. This test supports mapping + accessing
> the vtab
> of the polymorphic variable on the host. Obviously, this only works if
> the host pointer is device accessible ("unified-shared memory"). In
> princ
Kugan Vivekanandarajah writes:
> diff --git a/configure.ac b/configure.ac
> index 730db3c1402..701284e38f2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -621,6 +621,14 @@ case "${target}" in
> ;;
> esac
>
> +autofdo_target="i386"
> +case "${target}" in
> + aarch64-*-*)
> +auto
On Thu, 2025-05-08 at 23:29 -0300, Alexandre Oliva wrote:
>
> On vxworks, the included netinet/in.h header indirectly includes
> , that fails on C++ <11. Skip the test.
>
> Tested with gcc-14 targeting ppc-vx7r2 and ppc64-vx7r2. Also tested
> with trunk on ppc64le-linux-gnu, and with gcc-14 tar
On Thu, 2025-05-08 at 23:31 -0300, Alexandre Oliva wrote:
>
> vxworks' headers use #if instead of #ifdef to test for
> __STDC_WANT_LIB_EXT1__, so the definition in the analyzer test
> strotok-cppreference.c catches a bug there, but not something it's
> meant to catch or that we could fix in GCC, s
On Mon, May 12, 2025 at 10:54:52AM +, Joseph Myers wrote:
> On Sun, 11 May 2025, Alejandro Colomar wrote:
>
> > gcc/ChangeLog:
> >
> > * Makefile.in (USER_H): Add .
> > * ginclude/stdcountof.h: Add countof macro.
>
> This is missing tests for the header.
Hi Joseph,
Yep, I hadn't fo
On 5/11/25 7:11 PM, Owen Avery wrote:
Yeah, that looks way simpler. Should I add you as co-author on the
patch?
Sounds good, thanks.
On 4/28/25 22:13, Jason Merrill wrote:
On 4/28/25 5:07 PM, Owen Avery wrote:
As far as I can tell, that would need to be applied to every class
which virtuall
Sure @Palmer Dabbelt ,sent in a different thread email with updated patch.
Thank you
~U
-Original Message-
From: Palmer Dabbelt
Sent: 08 May 2025 23:38
To: Umesh Kalappa
Cc: jeffreya...@gmail.com; gcc-patches@gcc.gnu.org; kito.ch...@sifive.com;
jesse.hu...@sifive.com; Andrew Water
On 09/05/2025 13:49, Kyrylo Tkachov wrote:
>
>> On 8 May 2025, at 21:10, Karl Meakin wrote:
>>
>> Add rules for lowering `cbranch4` to
CBB/CBH/CB when
>> CMPBR extension is enabled.
>>
>> gcc/ChangeLog:
>>
>> * config/aarch64/aarch64.md (cbranch4): Mmit CMPBR
>> instructions if possible.
>> (
Refactor extension flag handling by removing the old riscv_ext_flag_table and
sourcing all flag definitions directly from the flags field of the unified
riscv_ext_info_t structures generated from riscv-ext.def.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_extra_ext_flag_tab
Consolidate implied-extension logic by removing the old `riscv_implied_info`
array and using the `implied_exts` field in the unified riscv_ext_info_t
structures generated from `riscv-ext.def`.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_implied_info::riscv_implied_
Define a new riscv_ext_info_t struct to aggregate all ISA extension fields
(name, version, flags, implied extensions, bitmask and extra flags) generated
from riscv-ext.def.
Also adjust riscv_ext_flag_table_t and riscv_implied_info_t to make it
able to not hold extension name, this part will refact
Fixes this error during build of fixincludes:
In function ‘byte_regex_compile’,
inlined from ‘xregcomp’ at ../libiberty/../../libiberty/regex.c:7973:11:
../libiberty/../../libiberty/regex.c:3477:29: warning: writing 1 byte into a
region of size 0 [-Wstringop-overflow=]
3477 |
Leverage the centralized riscv-ext.def definitions to auto-generate
the target option parsing and associated internal flags, replacing
manual listings in riscv.opt; `riscv_ext_flag_table` part will remove in
later patch.
gcc/ChangeLog:
* config/riscv/gen-riscv-ext-opt.cc: New.
* c
Automatically build the ISA extension reference table in invoke.texi from
the unified riscv-ext.def metadata, ensuring documentation stays in sync
with extension definitions and reducing manual maintenance.
gcc/ChangeLog:
* doc/invoke.texi: Replace hand‑written extension table with
We don't hold any extenison flags in `target_flags`, so no need to
gather the extenison flags in `target_flags`.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_can_inline_p): Drop
extension flags check from `target_flags`.
* config/riscv/riscv-subset.h (riscv_
This commit drops the riscv_ext_version_table and instead uses the
riscv_ext_info_t data structure to provide the version information
for RISC-V extensions.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_ext_version_table):
Remove.
(standard_extensions_p): Use
Adding a new ISA extension to RISC-V GCC requires modifying several places:
1. riscv_ext_version_table for the extension version.
2. riscv.opt for the target option and variable.
3. riscv_ext_flag_table to bind the extension to its target option.
4. riscv_combine_info if this extension is just a ma
The file now includes copyable_function in addition to
move_only_function.
PR libstdc++/119125
libstdc++-v3/ChangeLog:
* include/bits/move_only_function.h: Move to...
* include/bits/funcwrap.h: ...here.
* doc/doxygen/stdheader.cc (init_map): Replaced move_only_func
I think we need the run tests for each op combine up to a point. But for asm
check,
Seems we can put it together? I mean something like below:
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d --param=gpr2vr-cost=0" } */
+
+#include "vx_binary.h"
+
+DEF_VX_BINARY_CASE_0(int3
PR target/119692
libgomp/
* testsuite/libgomp.c++/pr119692-1-4.C: '{ dg-timeout 10 }'.
* testsuite/libgomp.c++/pr119692-1-5.C: Likewise.
* testsuite/libgomp.c++/target-exceptions-bad_cast-1.C: Likewise.
* testsuite/libgomp.c++/target-exceptions-bad_ca
This patch implements C++26 copyable_function as specified in P2548R6.
It also implements LWG 4255 that adjust move_only_function so constructing
from empty copyable_function, produces empty functor. This falls from
existing checks, after specializing __is_polymorphic_function_v for
copyable_functi
Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the
generic
move_only_function(_Fn&&) constructor, such that when _Fn refers to selected
move_only_function instantiations, the ownership of the target object is
direclty
transfered to constructor object. This avoid cost of
gcc/
* config/nvptx/nvptx-sm.def: Add '61'.
* config/nvptx/nvptx-gen.h: Regenerate.
* config/nvptx/nvptx-gen.opt: Likewise.
* config/nvptx/nvptx.cc (first_ptx_version_supporting_sm): Adjust.
* config/nvptx/nvptx.opt (-march-map=sm_61, -march-map=sm_62
gcc/
* config/nvptx/nvptx-opts.h (enum ptx_version): Add
'PTX_VERSION_5_0'.
* config/nvptx/nvptx.cc (ptx_version_to_string)
(ptx_version_to_number): Adjust.
* config/nvptx/nvptx.h (TARGET_PTX_5_0): New.
* config/nvptx/nvptx.opt (Enum(ptx_versi
Thanks to commit 86627faec10da53d7532805019e5296fcf15ac09
"libstdc++: Rewrite atomic builtin checks [PR70560]", for both GCN, nvptx
we now get:
+configure:16060: checking for atomic builtins for _Atomic_word
+[...]
+configure:16073: result: yes
..., and thus may revert the 'atomicity_
Okay, thanks!
在 2025/5/12 21:32, Kito Cheng 写道:
This patch is somewhat corrupt...but anyway, fixed and pushed to trunk
pushed to trunk, thanks :)
On Mon, May 12, 2025 at 5:20 PM Dongyan Chen
wrote:
>
> This patch support ssnpm, smnpm, smmpm, sspm and supm extensions[1].
> To enable GCC to recognize and process ssnpm, smnpm, smmpm, sspm and
> supm extensions correctly at compile time.
>
> [1]https://github.com/ris
This patch is somewhat corrupt...but anyway, fixed and pushed to trunk
On Thu, May 8, 2025 at 12:43 PM Dongyan Chen
wrote:
>
> This patch support zilsd and zclsd[1] extensions.
> To enable GCC to recognize and process zilsd and zclsd extension
> correctly at compile time.
>
> [1] https://github.
On Mon, May 12, 2025 at 12:57 PM Tomasz Kamiński
wrote:
> Based on the provision in C++26 [func.wrap.general] p2 this patch adjust
> the generic
> move_only_function(_Fn&&) constructor, such that when _Fn refers to
> selected
> move_only_function instantiations, the ownership of the target object
On Mon, May 12, 2025 at 3:01 PM Patrick Palka wrote:
> On Tue, 6 May 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Mon, May 5, 2025 at 8:50 PM Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
> >
> > This LGTM.
> > Out of curiosity, would declaring th
On Mon, 12 May 2025, Icen Zeyada wrote:
> Generalize existing scalar gimple_fold rules to apply the same
> bitwise comparison simplifications to vector types. Previously, an
> expression like
>
> (x < y) && (x > y)
>
> would fold to `false` if x and y are scalars, but eq
On Tue, 6 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 5, 2025 at 8:50 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
>
> This LGTM.
> Out of curiosity, would declaring them as members also fix the issue?
Ah yes it does fix it, and in fact
On Mon, 2025-05-12 at 12:59 +0100, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > The tranform would be unsafe if !TRULY_NOOP_TRUNCATION because on these
> > machines the hardware may look at bits outside of the given mode.
> >
> > gcc/ChangeLog:
> >
> > PR rtl-optimization/120050
> >
This tries to cleanup the API available to vectorizable_* to record
stmt costs. There are several overloads of record_stmt_cost for this
and the patch adds one only specifying SLP node and makes the one
only having a stmt_vec_info suitable for scalar stmt processing only.
There are awkward spots
Generalize existing scalar gimple_fold rules to apply the same
bitwise comparison simplifications to vector types. Previously, an
expression like
(x < y) && (x > y)
would fold to `false` if x and y are scalars, but equivalent vector
comparisons were left untouched. T
The libgcobol build is broken again on Solaris:
/vol/gcc/src/hg/master/local/libgcobol/libgcobol.cc: In function ‘void
default_exception_handler(ec_type_t)’:
/vol/gcc/src/hg/master/local/libgcobol/libgcobol.cc:11196:44: error:
‘LOG_PERROR’ was not declared in this scope; did you mean ‘LOG_ERR’?
Xi Ruoyao writes:
> The tranform would be unsafe if !TRULY_NOOP_TRUNCATION because on these
> machines the hardware may look at bits outside of the given mode.
>
> gcc/ChangeLog:
>
> PR rtl-optimization/120050
> * ext-dce.cc (ext_dce_try_optimize_insn): Only transform the
> insn
On Mon, 12 May 2025 at 11:19, Tomasz Kaminski wrote:
>
>
>
> On Mon, May 12, 2025 at 12:04 PM Jonathan Wakely wrote:
>>
>> This was a regression introduced with using version.def to define
>> feature test macros.
>
> Could you add link to commit here, I think this is r14-3248-g083b7f2833d71d.
Do
The following syncs up LTO tree hashing and streaming of TYPE_MODE
and DECL_MODE which long had a discrepancy for vector types and
recently got special-casing of streaming for offloading. Failure
to handle this results in less possible type merging to occur.
Note the compare step will still use TY
---
gcc/config/riscv/mips-p8700.md | 139 +++
gcc/config/riscv/riscv-cores.def | 5 ++
gcc/config/riscv/riscv-opts.h| 3 +-
gcc/config/riscv/riscv.cc| 22 +
gcc/config/riscv/riscv.md| 3 +-
5 files changed, 170 insertions(+), 2 deletions
> Right now it looks like plus/minus don't need to be different tests
> (and mult won't need to be either I presume)? While I'm not against adding
> individual tests for now I'd prefer us to consolidate them where possible in
> the long term. Is that in your plans?
I think we need the run tes
Thanks Richard.
> I think it's enough to put :c on one of the (plus
> OK with that change.
Oh, yes, will commit if no surprise from test for this change.
Pan
-Original Message-
From: Richard Biener
Sent: Monday, May 12, 2025 2:57 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh.
These patch makes following changes to _Pres_type values:
* _Pres_esc is replaced with separate _M_debug flag.
* _Pres_s, _Pres_p do not overlap with _Pres_none.
* hexadecimal presentation use same values for pointer, integer
and floating point types.
The members of _Spec<_CharT> are rearang
On Sun, 11 May 2025, Alejandro Colomar wrote:
> +/* { dg-options "-Wno-declaration-after-statement -Wno-pedantic -Wno-vla" }
> */
> +/* { dg-options "-Wno-pedantic -Wvla-parameter" } */
> +/* { dg-options "-Wno-declaration-after-statement -Wno-pedantic -Wno-vla" }
> */
Most of these options a
On Fri, May 9, 2025 at 10:12 PM Andrew Pinski wrote:
>
> On Mon, Apr 21, 2025 at 1:42 AM Richard Biener
> wrote:
> >
> > On Thu, Apr 17, 2025 at 7:37 PM Andrew Pinski
> > wrote:
> > >
> > > So unlike constants, address invariants are currently put first if
> > > used with a SSA NAME.
> > > It w
The file now includes copyable_function in addition to
move_only_function.
PR libstdc++/119125
libstdc++-v3/ChangeLog:
* include/bits/move_only_function.h: Move to...
* include/bits/funcwrap.h: ...here.
* doc/doxygen/stdheader.cc (init_map): Replaced move_only_func
On Sun, 11 May 2025, Alejandro Colomar wrote:
> gcc/ChangeLog:
>
> * Makefile.in (USER_H): Add .
> * ginclude/stdcountof.h: Add countof macro.
This is missing tests for the header.
--
Joseph S. Myers
josmy...@redhat.com
On Mon, May 12, 2025 at 11:42 AM Tobias Burnus wrote:
>
> C23 added the sinpi, cospi, etc. functions. Therefore, MPFR in 4.2.0
> added the mpfr_ counter parts. I assume that those internally use the
> mpfr_sinu, mpfr_cosu, ... functions, which are also user accessible.
>
> In any case, MPFR makes
Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the
generic
move_only_function(_Fn&&) constructor, such that when _Fn refers to selected
move_only_function instantiations, the ownership of the target object is
direclty
transfered to constructor object. This avoid cost of
On Sat, May 10, 2025 at 3:13 AM Andrew Pinski wrote:
>
> This move this canonicalization from forwprop
> (forward_propagate_into_gimple_cond)
> to gimple-fold.
> This is a step in removing forward_propagate_into_gimple_cond from forwprop.
I don't think fold_stmt should mess with the CFG, so NACK
This patch implements C++26 copyable_function as specified in P2548R6.
It also implements LWG 4255 that adjust move_only_function so constructing
from empty copyable_function, produces empty functor. This falls from
existing checks, after specializing __is_polymorphic_function_v for
copyable_functi
This patch series implements the copyable_function as specified in P2548R6.
It also modifies implementation of move_only_funtion to avoid doulbe indirection
when constructing from other function wrappers, based on provision in
C++26 [func.wrap.general] p2. Finally we rename bits/move_only_function.
On Sat, May 10, 2025 at 3:19 AM Andrew Pinski wrote:
>
> with -ftrapping-math -fnon-call-exceptions and:
> ```
> tmp = FP0 CMP FP1;
>
> if (tmp != 0) ...
> ```
> a call fold_stmt on the GIMPLE_COND will replace the above with
> a new tmp each time and we even lose the eh informatin on the
> previo
On Sun, 11 May 2025, Alejandro Colomar wrote:
> Hi,
>
> Here's the list of changes in v20:
>
> - Drop changes to support Cc tags in commit messages (but keep the
>patch to add support for Link tags).
That patch *does not belong in this series*. Keep the series to only
those patches conce
On 11/04/2025 17:36, Christophe Lyon wrote:
> The test was designed to pass with thumb2, but code generation changed
> with the introduction of Low Overhead Loops, so the test can fail if
> one overrides the flags when running the testsuite.
>
> In addition, useless subtract / extension instructio
On Mon, May 12, 2025 at 12:06 PM Jonathan Wakely wrote:
> Although was removed from C++20, it was not formally
> deprecated in C++17. In contrast, , , etc. were
> formally deprecated in C++17 before being removed in C++20.
>
> Due to the widespread convention of including to detect
> implementa
On Mon, May 12, 2025 at 12:04 PM Jonathan Wakely wrote:
> This was a regression introduced with using version.def to define
> feature test macros.
Could you add link to commit here, I think this
is r14-3248-g083b7f2833d71d.
> std::scoped_lock can be defined unconditionally
> (including for free
> > gcc/ChangeLog:
> >
> > * config/i386/i386-features.cc
> > (scalar_chain::mark_dual_mode_def): Weight
> > n_integer_to_sse/n_sse_to_integer with bb frequency.
> > (general_scalar_chain::compute_convert_gain): Ditto, and
> > adjust function prototype to ret
These registers can no-longer be allocated, so remove them from the
various tables.
gcc/ChangeLog:
* config/arm/aout.h (REGISTER_NAMES): Remove iwmmxt registers.
* config/arm/arm.h (FIRST_IWMMXT_REGNUM): Delete.
(LAST_IWMMXT_REGNUM): Delete.
(FIRST_IWMMXT_GR_REGNUM
Now that the iwmmxt extensions have been removed, clean up the
references to it in the documentation. We keep the
-mcpu/-mtune/-march references as these are still accepted by the
driver.
gcc/ChangeLog:
* doc/extend.texi: Remove the iwmmxt intrinsics.
* doc/md.texi: Remove the iw
Since we no-longer have any iwmxxt instructions, the iwmmxt-related
attributes can never be set. Consequently, the marvel-f-iwmmxt
scheduler is redundant as none of the pipes are ever used now.
gcc/ChangeLog:
* config/arm/arm.md (core_cycles): Remove iwmmxt attributes.
* config/a
Remove most of the remaining code for iWMMXT support, except for the
register allocation table entries.
gcc/ChangeLog:
* config/arm/arm-cpus.in (feature iwmmxt, feature iwmmxt2): Delete.
* config/arm/arm-protos.h (arm_output_iwmmxt_shift_immediate): Delete.
(arm_output_iw
This is the first step of removing the various builtins for iwmmxt,
removing the builtins expansion code. It leaves a lot of code
elsewhere, but we'll clean that up in subsequent patches.
I'm not sure why safe_vector_operand would unconditionally try to
expand to an iwmmxt instruction if passed (
This was a regression introduced with using version.def to define
feature test macros. std::scoped_lock can be defined unconditionally
(including for freestanding).
libstdc++-v3/ChangeLog:
PR libstdc++/120198
* include/bits/version.def (scoped_lock): Do not depend on
gthre
Remove the various checks for TARGET_IWMMXT{,2} and
TARGET_REALLY_IWMMXT{,2} from the remaining machine description files.
These flags can never be true now.
gcc/ChangeLog:
* config/arm/arm.md(attr arch): Remove iwmmxt and iwmmxt2.
Remove checks based on TARGET_REALLY_IWMMXT2 from
Although was removed from C++20, it was not formally
deprecated in C++17. In contrast, , , etc. were
formally deprecated in C++17 before being removed in C++20.
Due to the widespread convention of including to detect
implementation-specific macros (such as _GLIBCXX_RELEASE) it causes
quite a lot
Mostly this is just removing references to iWMMXT in comments, but also remove
some now unused iterators and attributes.
gcc/ChangeLog:
* config/arm/iterators.md (VMMX, VMMX2): Remove mode iterators.
(MMX_char): Remove mode iterator attribute.
---
gcc/config/arm/iterators.md | 20
These two tests were specific to iWMMXT, but we're about to remove
that code, so the tests are now redundant.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mmx-1.c: Removed.
* gcc.target/arm/mmx-2.c: Removed.
* gcc.target/arm/pr64208.c: Removed.
* gcc.target/arm/pr7914
1 - 100 of 123 matches
Mail list logo
