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 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
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
Ping?
在 2025/5/9 上午10:14, Lulu Cheng 写道:
From: ChengLulu
PR target/99217
gcc/ChangeLog:
* config/mips/mips.cc (mips_start_function_definition):
Implements the functionality of '-fpatchable-function-entry='.
(mips_print_patchable_function_entry): Define empty f
Hehe, you are late a little bit, let rewrite this with riscv-ext.def
On Tue, May 13, 2025 at 11:56 AM Jiawei wrote:
>
> The augmented hypervisor series extensions 'sha'[1] is a new profile-defined
> extension series that captures the full set of features that are mandated to
> be supported along
We forgot to initialize m_allow_adding_dup in the constructor of
riscv_subset_list, then that will be a random value...that will lead
to a random behavior of the -march may accpet duplicate extension.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::riscv_s
From: Lili Cui
Hi,
This patch is to enale separate shrink wrapping for x86.
Bootstrapped & regtested on x86-64-pc-linux-gnu.
Ok for trunk?
This commit implements the target macros (TARGET_SHRINK_WRAP_*) that
enable separate shrink wrapping for function prologues/epilogues in
x86.
When perfo
If you have a patch that works for you, by all means, push it.
As for the philosophy and reasons for logging...I have to defer to Jim to
come up with a cogent response. I personally wouldn't have bothered with
any logging code. There may be some delays in his responding. There
recently was a de
The augmented hypervisor series extensions 'sha'[1] is a new profile-defined
extension series that captures the full set of features that are mandated to
be supported along with the 'H' extension.
[1]
https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc#rva23s64-profile
gcc/C
pushed
On Mon, May 12, 2025 at 10:18 PM Kito Cheng wrote:
>
> I guess this patch set is not interesting to most people, so I will commit
> that once CI green :P
>
> On Mon, May 12, 2025 at 10:17 PM Kito Cheng wrote:
>>
>> Adding a new ISA extension to RISC-V GCC requires modifying several place
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.
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 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
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
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
> 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
---
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
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
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
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
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
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 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 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’?
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.
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
Okay, thanks!
在 2025/5/12 21:32, Kito Cheng 写道:
This patch is somewhat corrupt...but anyway, fixed and pushed to trunk
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
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
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
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 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
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
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 +++
> -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
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
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
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
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
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
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
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:
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
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
> > Instructions with latency info are those really different.
> > So the uncoverted code has sum of latencies 4 and real latency 3.
> > Converted code has sum of latencies 4 and real latency 3
> > (vmod+vpmaxsd+vmov).
> > So I do not quite see it should be a win.
>
> Note this was historically d
The flattened logic of these functions and the complexity of the
numerous clauses makes it very difficult to understand what's written
in these macros. Additionally, SECONDARY_INPUT_RELOAD_CLASS was not
laid out with the correct formatting.
Add some parenthesis and re-indent to make the logic cle
TARGET_IWMMXT, TARGET_IWMMXT2 and their _REALLY_ equivalents are never
true now, so the code using them can be simplified.
gcc/ChangeLog:
* config/arm/arm.cc (arm_option_check_internal): Remove
IWMMXT check.
(arm_options_perform_arch_sanity_checks): Likewise.
(use_
This patch deletes the patterns relating to iwmmxt and iwmmxt2 and
updates the relevant dependencies.
gcc/ChangeLog:
* config/arm/arm.md: Don't include iwmmxt.md.
* config/arm/t-arm (MD_INCLUDES): Remove iwmmxt*.md.
* config/arm/iwmmxt.md: Removed.
* config/arm/iwm
Treat options that select iwmmxt variants as we would for xscale. We
leave the feature bits in for now, since they are still needed
elsewhere, but they are never enabled.
Also remove the remaining testsuite framework support for iwmmxt,
since this will never trigger now.
gcc/
* config/a
The header file for the Arm implementation of mmintrin.h was changed in GCC-15
to disable access to the intrinsics. This patch removes the internal code
as well.
We still allow -mcpu/-march options for the wmmx cpus, but they are now treated
in exactly the same way as XScale - generating code for
The iwmmxt ABI is a variant of the ABI that supported passing certain
parameters and results in iwmmxt registers. But since we no-longer
support the instructions that can read and write these registers, the
ABI variant can no-longer be used.
gcc/ChangeLog:
* config.gcc (arm, --with-abi):
Since we no-longer enable iWMMXT, these predefines are no-longer enabled
when preprocessing C. Remove them.
gcc/ChangeLog:
* config/arm/arm-c.cc (arm_cpu_builtins): Remove predefines
for __IWWMXT__, __IWMMXT2__ and __ARM_WMMX.
---
gcc/config/arm/arm-c.cc | 7 ---
1 file cha
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
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
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
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
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 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
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
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 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, 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 5/12/25 17:26, Jeff Law wrote:
>>test_float_point_frm_static:
>>1: frrma5 <--
>> 2: fsrmi 2
>>3: fsrma5 <--
>> 4: callnormalize_vl
>>5: frrma5 <--
>> 6: fsrmi 3
Updated in V2
>
> Can you instead of mangling in float support use separate (match like
> for the below cases?
I tried, but reported duplicated defination since they share same pattern
like
(cond (simple_comparison@6 @0 @1) (convert@4 @2) (convert@5 @3))
No idea how to split that.
>
> > @@ -1130
REAL_CST is handled if it can be represented in different floating
point types without loss of precision or under fast math.
gcc/ChangeLog:
PR tree-optimization/103771
* match.pd (cond_expr_convert_p): Extend the match to handle
REAL_CST.
* tree-vect-patterns.cc
As usual, thanks for doing all this.
*blush*
Aldy
On Tue, May 13, 2025 at 2:15 AM Andrew MacLeod wrote:
> When there are trailing 0's in the bitmask, I previously modified
> set_range_from_bitmask () to remove the lower positive ranges which do
> not match the value to help with some optimizat
The augmented hypervisor series extensions 'sha'[1] is a new profile-defined
extension series that captures the full set of features that are mandated to
be supported along with the 'H' extension.
[1]
https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc#rva23s64-profile
Versi
101 - 173 of 173 matches
Mail list logo
