When I did r16-1067-gaa935ce40a7, I thought it would be
enough to mark the decl as mergable to get it to merge on
all targets. Turns out a few things needed to be changed
to support it being mergable on all targets.
The first thing is improve the selecting of the mergable
section and instead of bas
On 7/24/25 1:53 AM, Andreas Schwab wrote:
From: Alexey Merzlyakov
Fixes incorrect SP-addresses used in CFA notes for the stack probes
unrelative to the frame's top. It applied to the RISC-V targets code
generation when the stack-clash protection is enabled.
PR target/120714
gcc/Chan
On Fri, Jul 25, 2025 at 8:50 PM Bill Wendling wrote:
>
> On Thu, Jul 24, 2025 at 3:20 PM Martin Uecker wrote:
> > Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling:
> > > > constexpr size_t size = 4;
> > > > struct foo {
> > > > char (*buf)[size] __counted_by(size); // two diff
On Thu, Jul 24, 2025 at 3:20 PM Martin Uecker wrote:
> Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling:
> > > constexpr size_t size = 4;
> > > struct foo {
> > > char (*buf)[size] __counted_by(size); // two different "size"!
> > > int size;
> > > };
> >
> > VLAs within struc
On Thu, Jul 24, 2025 at 2:53 PM Martin Uecker wrote:
> Am Donnerstag, dem 24.07.2025 um 14:25 -0700 schrieb Bill Wendling:
> > On Thu, Jul 24, 2025 at 8:03 AM Martin Uecker wrote:
> > > Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > > > On Wed, Jul 23, 2025 at 8:38 PM Mar
On Fri, Jul 25, 2025 at 08:58:47AM -0400, Patrick Palka wrote:
> On Fri, 25 Jul 2025, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > I noticed that C++26 trivial relocation didn't work in modules yet, and
> > there are a cou
Richard, this message of yours about changes for 15.2 RC has been
percolating in my head since I first saw it.
So, today I gave it a shot.
A significant amount of COBOL development has occurred in the four months
since GCC-15 was released.
I just built a patch that brought changes in COBOL from
On Wed, Jul 23, 2025 at 08:01:38PM +, Qing Zhao wrote:
> This is the 7th version of the patches for fixing PR109071.
>
> Adding -fdiagnotics-show-context=N into GCC to provide context information
> to the end users on how the warnings come from, in order to help the user
> to locate the exact
On Mon, Jul 21, 2025 at 11:29:22AM -0400, Jason Merrill wrote:
> On 7/18/25 5:17 PM, Marek Polacek wrote:
> > On Thu, Jul 17, 2025 at 05:20:31PM -0400, Jason Merrill wrote:
> > > On 7/16/25 5:59 PM, Marek Polacek wrote:
> > > > On Mon, Jul 14, 2025 at 12:52:41PM -0400, Jason Merrill wrote:
> > > >
On Thu, Jul 17, 2025 at 05:20:31PM -0400, Jason Merrill wrote:
> On 7/16/25 5:59 PM, Marek Polacek wrote:
> > On Mon, Jul 14, 2025 at 12:52:41PM -0400, Jason Merrill wrote:
> > > On 7/11/25 5:49 PM, Marek Polacek wrote:
> > > > On Thu, Jul 10, 2025 at 02:13:06PM -0400, Jason Merrill wrote:
> > > >
That would definitely be nice to have for both gather and stride loads
I'm not sure I like the direction that's heading ;)
So the loop I'm targeting is x264's satd:
for( int i = 0; i < 4; i++, pix1 += i_pix1, pix2 += i_pix2 )
{
a0 = (pix1[0] - pix2[0])...
a1 = (pix1[1] -
On Wed, 2025-07-23 at 20:01 +, Qing Zhao wrote:
> Hi,
>
> This is the 7th version of the patches for fixing PR109071.
I just pushed a big reorganization of GCC's diagnostics subsystem to
trunk as r16-2520-g6d9152659f4f6a through r16-2553-gbae1f7e29816b9:
[PATCH 00/34] Introduce "gcc/diagnos
On Fri, 25 Jul 2025, 17:41 Nathan Myers, wrote:
> Changed in v3:
> * Rely on std/bitset's string_view ctor for bounds checking.
>
> This adds the new bitset constructor from string_view
> defined in P2697 to the debug version of the type.
>
> libstdc++-v3/Changelog:
> PR libstdc++/119742
No functional change intended.
gcc/ChangeLog:
* diagnostic.h: Use TextOrHtml rather than Sink for template
params.
* diagnostics/context.h: Likewise.
* diagnostics/selftest-context.cc: Use "html_or_text" rather than
"sink".
* diagnostics/source-print
No functional change intended.
gcc/ChangeLog:
* diagnostics/selftest-paths.cc: Don't include "demangle.h"
and "backtrace.h".
* diagnostics/source-printing.cc: Likewise.
* diagnostics/state-graphs.cc: Don't include "graphviz.h",
"xml.h", "xml-printer.h", or "
On Tue, Jul 22, 2025 at 04:52:53PM -0400, Jason Merrill wrote:
> On 7/21/25 6:28 PM, Marek Polacek wrote:
> > On Mon, Jul 21, 2025 at 11:26:08AM -0400, Jason Merrill wrote:
> > > On 7/18/25 5:11 PM, Marek Polacek wrote:
> > > > On Thu, Jul 17, 2025 at 06:44:08PM -0400, Jason Merrill wrote:
> > > >
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Replace diagnostics/changes.o with
diagnostics/edit-context.o.
* diagnostic.cc: Update for move of diagnostics/edit-context.h to
diagnostics/changes.h.
(diagnostics::context::initi
No functional change intended.
gcc/ChangeLog:
* diagnostics/context.cc: Eliminate digraphs::lazy_digraph in
favor of lazily_created template.
* diagnostics/context.h: Likewise.
* diagnostics/digraphs.cc: Likewise, also digraphs::lazy_digraphs.
* diagnostics/
This has GCC-specific stuff in it (options and "GTY"), and so should
not be in the "diagnostics/" subdir, and should avoid a "diagnostics"
prefix in its name.
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Replace diagnostic-spec.o with
gcc-diagnosti
No functional change intended.
gcc/c-family/ChangeLog:
* c-common.cc: Update usage of "diagnostic_info" to explicitly
refer to "diagnostics::diagnostic_info".
* c-opts.cc: Likewise.
gcc/c/ChangeLog:
* c-errors.cc: Update usage of "diagnostic_info" to explicitly
No functional change intended.
gcc/ada/ChangeLog:
* gcc-interface/misc.cc: Make
diagnostics::context::m_source_printing private.
gcc/analyzer/ChangeLog:
* program-point.cc: Make diagnostics::context::m_source_printing
private.
gcc/c-family/ChangeLog:
* c-c
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Add diagnostics/file-cache.o.
* diagnostics/changes.cc: Update for file_cache and char_span
moving from input.h to diagnostics/file-cache.h and into the
"diagnostics::" namespace.
No functional change intended.
gcc/c-family/ChangeLog:
* c-common.cc: Update for renaming of diagnostic_option_id to
diagnostics::option_id.
* c-common.h: Likewise.
* c-cppbuiltin.cc: Likewise.
* known-headers.cc: Likewise.
* known-headers.h: Likewis
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Replace diagnostic-color.o with
diagnostics/color.o.
(PLUGIN_HEADERS): Remove diagnostic-color.h in favor of glob.
* common.opt: Update for move of diagnostic-color.h to
diagnostic
No functional change intended.
gcc/c-family/ChangeLog:
* c-opts.cc (c_diagnostic_text_finalizer): Add "m_" prefix to
fields of diagnostic_info.
gcc/c/ChangeLog:
* c-errors.cc: Update to add "m_" prefix to fields of
diagnostic_info throughout.
gcc/cp/ChangeLog:
Move more diagnostic-specific code from gcc/ to gcc/diagnostics/
No functional change intended.
contrib/ChangeLog:
* filter-clang-warnings.py: Update for move of
diagnostic-path-output.cc to diagnostics/paths-output.cc.
gcc/ChangeLog:
* Makefile.in (OBJS): Replace lazy-di
Move diagnostic-show-locus.cc to diagnostics/source-printing.cc
Move diagnostic-label-effects.h to diagnostics/source-printing-effects.h
Move selftest-diagnostic-show-locus.h
to diagnostics/selftest-source-printing.h
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS):
No functional change intended.
gcc/ChangeLog:
* diagnostic.h (struct diagnostic_info): Move to
diagnostics/diagnostic-info.h as diagnostics::diagnostic_info.
Add typedef bringing it back into root namespace, for now.
* diagnostics/diagnostic-info.h: New file, based
No functional change intended.
gcc/ChangeLog:
* diagnostic.h (enum diagnostics_column_unit): Move to
diagnostics/context-options.h.
(enum diagnostics_escape_format): Likewise.
(enum diagnostics_output_format): Likewise.
(enum diagnostic_path_format): Likewis
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Replace diagnostic.o with
diagnostics/context.o.
gcc/c-family/ChangeLog:
* c-common.cc (c_family_tests): Add include of
"diagnostics/diagnostics-selftests.h". Replace
c_diagnosti
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Replace selftest-diagnostic.o with
diagnostics/selftest-context.o.
* diagnostic.cc: Update for move of selftest-diagnostic.h to
diagnostics/selftest-context.h.
* diagnostics/html-s
renamed: gcc/diagnostic-metadata.h -> gcc/diagnostics/metadata.h
No functional change intended.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc: Update for move of diagnostic_metadata to
diagnostics::metadata.
* kf.cc: Likewise.
* pending-diagnostic.h: Likewise; al
No functional change intended.
gcc/ChangeLog:
* diagnostic.h: Move include of "unique-argv.h"
and various forward decls into...
* diagnostics/context.h: ...here.
---
gcc/diagnostic.h | 37 ++---
gcc/diagnostics/context.h | 35 ++
No functional change intended.
Note that the tree-*.cc implementations are *not* moved into namespace
diagnostics.
gcc/ChangeLog:
* diagnostic-format-html.cc: Update #include for move of
diagnostic-client-data-hooks.h to diagnostics/client-data-hooks.h.
* diagnostic-format
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS): Move diagnostics/lazy-paths.o to...
(OBJS-libcommon): ...here. Add
diagnostics/diagnostics-selftests.o.
* diagnostic.cc: Update for move of
selftest::test_diagnostic_context to
diag
No functional change intended.
gcc/ChangeLog:
* common.opt: Update for move of diagnostic-url.h to
diagnostics/url.h.
* diagnostic.cc: Likewise.
* diagnostics/color.cc: Likewise.
* diagnostics/text-sink.cc: Likewise.
* diagnostic-url.h: Move to...
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Add diagnostics/buffering.o.
* diagnostic.cc (diagnostics::context::set_diagnostic_buffer): Move to
diagnostics/buffering.cc.
(diagnostics::context::clear_diagnostic_buffer): Likewise.
The "gcc" subdirectory of our source tree currently contains a total
of almost 1000 .cc and .h files, enough to hit rate-limiting in some
git web UIs, and obscuring the logical relationships between subsystems.
In r16-2211-ga5d9debedd2f46 I started introducing a
"namespace diagnostics" so it makes
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Add
diagnostics/option-classifier.o.
* diagnostic.cc (diagnostics::option_classifier::init): Move to
diagnostics/option-classifier.cc.
(diagnostics::option_classifier::fini): Likew
No functional change intended.
gcc/ChangeLog:
* diagnostic-format-html.cc: Update #include for move of
diagnostic-output-file.h to diagnostics/output-file.h. Update for
move of diagnostic_output_file to diagnostics::output_file.
* diagnostic-format-html.h: Likewise
This patch moves gcc/logical-locations.h into gcc/diagnostics
and moves the classes into "namespace diagnostics", to better
indicate that this is part of the shared diagnostics code.
The type "logical_location" becomes diagnostics::logical_locations::key,
the class logical_location_manager becomes
gcc/ChangeLog:
* Makefile.in (OBJS): Replace diagnostic-macro-unwinding.o with
diagnostics/macro-unwinding.o.
* diagnostic-macro-unwinding.cc: Move to...
* diagnostics/macro-unwinding.cc: ...here, moving content into
namespace diagnostics.
* diagnosti
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Replace diagnostic-output-spec.o
with diagnostics/output-spec.o.
* diagnostic-output-spec.cc: Move to...
* diagnostics/output-spec.cc: ...here. Update #include for
move of diagnos
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Replace edit-context.o with
diagnostics/edit-context.o.
* diagnostic-format-html.cc: Update #include for move
of edit-context.h to diagnostics subdir.
* diagnostic.cc: Likewise. U
No functional change intended.
gcc/analyzer/ChangeLog:
* bounds-checking.cc: Update #include for move of
"diagnostic-diagram.h" to "diagnostics/diagram.h". Update for
move of diagnostic_diagram to diagnostics::diagram.
gcc/ChangeLog:
* diagnostic-format-html.cc: Up
The "gcc" subdirectory of our source tree currently contains a total
of almost 1000 .cc and .h files, enough to hit rate-limiting in some
git web UIs, and obscuring the logical relationships between subsystems.
In r16-2211-ga5d9debedd2f46 I started introducing a
"namespace diagnostics" so it makes
Cherry picked from LLVM commit c99b1bcd505064f2e086e6b1034ce0b0c91ea5b9.
The termio ioctls are no longer used after commit 59978b21ad9c
("[sanitizer_common] Remove interceptors for deprecated struct termio
(#137403)"), remove them. Fixes this build error:
../../../../libsanitizer/sanitizer_commo
On Fri, 25 Jul 2025, Patrick Palka wrote:
> After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
> comparison operator expressed as a built-in acting on an operator<=>
> call, e.g. operator<=>(x, y) < 0. This is because operator<=> always
> returns a class type (std::strong/wea
After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
comparison operator expressed as a built-in acting on an operator<=>
call, e.g. operator<=>(x, y) < 0. This is because operator<=> always
returns a class type (std::strong/weak/partial_ordering), so the < will
necessarily resolv
The riscv-c-api-doc defines a group ID and and a bit position for some
extension. Most of them are set in riscv-ext.def, but some are missing
and one bit position (for Zilsd) is wrong.
This patch replaces the `BITMASK_NOT_YET_ALLOCATED` value for the actual
allocated value wherever possible and f
On 23/07/2025 16:23, Richard Biener wrote:
That said, the hook is a bit black/white - whether the target prefers
a gather/scatter over N piecewise operations with equal stride depends
at least on the vector mode. On x86_64 for V2DImode definitely no
gather, for V16SFmode it probably depends (V64
> Am 25.07.2025 um 17:16 schrieb Robin Dapp :
>
>
>>
>> I'm not sure whether handling this case as part of VMAT_STRIDED_SLP is
>> wise. IIRC we do already choose VMAT_GATHER_SCATTER for some
>> strided loads, so why not do strided load/store handling as part of
>> gather/scatter handling?
>
Changed in v3:
* Rely on std/bitset's string_view ctor for bounds checking.
This adds the new bitset constructor from string_view
defined in P2697 to the debug version of the type.
libstdc++-v3/Changelog:
PR libstdc++/119742
* include/debug/bitset: Add new ctor.
---
libstdc++-v3
Changes in v2:
* The second, size argument to the base class constructor needs
to be more careful about overflowing the string_view argument,
because the base class has no independent information about the
actual bounds of the array passed.
This adds the new bitset constructor from string_
I'm not sure whether handling this case as part of VMAT_STRIDED_SLP is
wise. IIRC we do already choose VMAT_GATHER_SCATTER for some
strided loads, so why not do strided load/store handling as part of
gather/scatter handling?
Now that we can deal with gather/scatter misalignment I think we can c
On Fri, 25 Jul 2025, Tomasz Kaminski wrote:
>
>
> On Fri, Jul 25, 2025 at 4:57 PM Tomasz Kaminski wrote:
>
>
> On Fri, Jul 25, 2025 at 4:49 PM Patrick Palka wrote:
> On Fri, 25 Jul 2025, Tomasz Kamiński wrote:
>
> > PR libstdc++/121196
> >
> > libstdc++-v3/Chan
On Fri, Jul 25, 2025 at 4:57 PM Tomasz Kaminski wrote:
>
>
> On Fri, Jul 25, 2025 at 4:49 PM Patrick Palka wrote:
>
>> On Fri, 25 Jul 2025, Tomasz Kamiński wrote:
>>
>> > PR libstdc++/121196
>> >
>> > libstdc++-v3/ChangeLog:
>> >
>> > * include/std/inplace_vector (std::erase): Provid
On Fri, Jul 25, 2025 at 4:49 PM Patrick Palka wrote:
> On Fri, 25 Jul 2025, Tomasz Kamiński wrote:
>
> > PR libstdc++/121196
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/inplace_vector (std::erase): Provide default argument
> > for _Up parameter.
> > * testsuite/2
On Fri, 25 Jul 2025, Tomasz Kamiński wrote:
> PR libstdc++/121196
>
> libstdc++-v3/ChangeLog:
>
> * include/std/inplace_vector (std::erase): Provide default argument
> for _Up parameter.
> * testsuite/23_containers/inplace_vector/erasure.cc: Add test for
> using bra
Hi all,
The optimization options are deliberately passed through to the LTO compiler,
but when the same mechanism is reused for offloading it ends up forcing the
host compiler settings onto the device compiler. Maybe this should be removed
completely, but this patch just fixes a few of them. In
Based on Joseph’s review comments on May 30, 2025.
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/685211.html
I will push this patch to GCC15 if no further concern in a day.
Qing
> On Jul 24, 2025, at 09:36, Qing Zhao wrote:
>
> Ping.
>
> The patch has been committed to trunk 2 months ago
Based on Joseph’s review comment on May 30, 2025:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/685211.html
I will push this patch to GCC15.
Qing
> On Jul 24, 2025, at 09:36, Qing Zhao wrote:
>
> Ping.
>
> The patch has been committed to trunk 2 months ago.
>
> Okay for committing to GC
From: Pan Li
Like Robin's fix for vf combine f16.c run tests, there is still
another failures similar. This patch would like to fix it as
previous.
will commit it directly if the CI agrees.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwnmacc-run-1-f16.c:
Ping on this patch.
Thanks.
Qing
> On Jun 25, 2025, at 10:07, Qing Zhao wrote:
>
> Hi,
>
> This is the 3rd version of the patch for:
>
> Evaluate the object size by the size of the pointee type when the type
> is a structure with flexible array member which is annotated with
> counted_by.
On Fri, Jul 25, 2025 at 1:05 AM Uros Bizjak wrote:
>
> On Thu, Jul 24, 2025 at 9:30 PM H.J. Lu wrote:
> >
> > On x86-64, __tls_get_addr is a normal function which doesn't preserve
> > vector registers. On i386, ___tls_get_addr preserve vector registers
> > only with the commit:
>
> Can you pleas
On Fri, 18 Jul 2025, Jonathan Wakely wrote:
> When the C++98 std::distance and std::advance functions (and C++11
> std::next and std::prev) are used with C++20 iterators there can be
> unexpected results, ranging from compilation failure to decreased
> performance to undefined behaviour.
>
> An i
On Fri, Jul 18, 2025 at 8:03 PM Jonathan Wakely wrote:
> This adds a check when incrementing the shared count and weak count and
> will trap if it overflows. This also double the effective range of the
> counts for most 64-bit targets.
>
> The counter type, _Atomic_word, is usually a signed 32-bi
On Fri, Jul 18, 2025 at 9:50 PM Jonathan Wakely wrote:
> On Fri, 18 Jul 2025 at 19:18, Tomasz Kaminski wrote:
> >
> >
> >
> > On Fri, Jul 18, 2025 at 8:03 PM Jonathan Wakely
> wrote:
> >>
> >> This adds a check when incrementing the shared count and weak count and
> >> will trap if it overflows
On Fri, Jul 18, 2025 at 8:03 PM Jonathan Wakely wrote:
> The standard requires that std::atomic::fetch_add does
> not have undefined behaviour for signed overflow, instead it wraps like
> unsigned integers. The compiler ensures this is true for the atomic
> built-ins that std::atomic uses, but it
On Fri, 25 Jul 2025, Robin Dapp wrote:
> > I've folded the "vectorizer status" into the beginning of the BoF,
> > so "only" two slots from my side.
>
> Do you still need/want some status from the riscv vector side for the BoF?
> If so, what would that entail? Rather a look back on what has been
I've folded the "vectorizer status" into the beginning of the BoF,
so "only" two slots from my side.
Do you still need/want some status from the riscv vector side for the BoF?
If so, what would that entail? Rather a look back on what has been done or an
outlook of what we're looking at?
--
R
From: Pan Li
Add asm check to make sure vx combine of vaadd.vx will not pollute
the vxrm.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-fixed-vxrm-1-i16.c: New test.
* gcc.target/riscv/rvv/autovec/vx_vf/vx-fixed-vxrm-1-i32.c: New test.
* gcc.target/ris
From: Pan Li
Add asm dump check test for vec_duplicate + vaadd.vv combine to
vaadd.vx, with the GR2VR cost is 0, 1 and 2
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i16.c: Add asm check.
* gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i32.c: Ditto.
* gcc
From: Pan Li
This patch would like to combine the vec_duplicate + vaadd.vv to the
vaadd.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR. Then the late-combine will
take action if the cost of GR2VR is zero, and reject the combination
if th
From: Pan Li
Add asm dump check and run test for vec_duplicate + vaadd.vv
combine to vaadd.vx, with the GR2VR cost is 0, 2 and 15
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Add asm check.
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i32.c: Ditto.
From: Pan Li
This patch would like to introduce the combine of vec_dup + vaadd.vv
into vaadd.vx on the cost value of GR2VR. The late-combine will take
place if the cost of GR2VR is zero, or reject the combine if non-zero
like 1, 2, 15 in test. There will be two cases for the combine:
Case 0:
The following removes the vect_get_vec_defs overload receiving
a vector type to be used for the possibly constant/invariant
operand. This was used for non-SLP code generation as there
constants/invariants are generated on the fly. It also elides
the stmt_vec_info and ncopies argument which are no
On Fri, 25 Jul 2025, Robin Dapp wrote:
> > OK, so actually generating code with that vector(1) is bad (slower
> > than using scalar code)? Was that the same for PR121048?
>
> The general situation is similar but IIRC we had a real vector mode there.
> There the code didn't look terrible apart fr
The following removes one vect_is_simple_use overload that shouldn't
be used anymore after removing the single remaining use related
to gather handling in get_group_load_store_type. It also removes
the dual-purpose of the overload getting both SLP node and
stmt_vec_info and removes the latter argu
There's no longer any call without SLP node so we don't need dts.
I also figured based on the callers that some expect to cost
more than one stmt but still N times so this changes what we cost.
* tree-vect-stmts.cc (vect_model_simple_cost): Removed code
when no SLP node is passed,
On 7/24/25 10:07 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu. Also verified that
it fixes the regression on an mcore-elf cross. OK for trunk?
OK.
-- >8 --
The assertion failure on ASM_OUTPUT_WEAKREF targets since my r16-1738
was caused because the 'TREE_CHA
OK, so actually generating code with that vector(1) is bad (slower
than using scalar code)? Was that the same for PR121048?
The general situation is similar but IIRC we had a real vector mode there.
There the code didn't look terrible apart from using very small vectors
(2 elements). Here I gu
On Fri, 25 Jul 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> I noticed that C++26 trivial relocation didn't work in modules yet, and
> there are a couple of other flags that seem potentially useful we
> weren't streaming. This s
I was a bit concerned about the stmt_vec_info -> slp_tree hash map at
first, but I realized that it’s just a temporary hack, so LGTM :)
Thanks, going to commit in a while. Of course you know:
"There is nothing more permanent than a temporary solution." :)
--
Regards
Robin
PR libstdc++/121196
libstdc++-v3/ChangeLog:
* include/std/inplace_vector (std::erase): Provide default argument
for _Up parameter.
* testsuite/23_containers/inplace_vector/erasure.cc: Add test for
using braces-init-list as arguments to erase_if and use func
From: Tuur Martens
The unordered_map header incorrectly refers to a non-existent template parameter
_Value in default template argument descriptions. They should refer to _Key
instead.
This patch fixes these descriptions to match the actual template parameters.
libstdc++-v3/ChangeLog:
On Tue, Jul 22, 2025 at 10:04 AM wrote:
> From: Tuur Martens
>
> The unordered_map header incorrectly refers to a non-existent template
> parameter _Value in default template argument descriptions. They should
> refer to _Key instead.\n\nThis patch fixes these descriptions to match the
> actual
This patch adds a new tuning model for the NVIDIA Olympus core.
The values used here are based on the Software Optimization Guide
that will be published imminently.
Bootstrapped and tested on aarch64-linux-gnu, no regression.
OK for trunk?
OK to backport to GCC 15?
Signed-off-by: Jennifer Schmit
The following adjusts uses of STMT_VINFO_VECTYPE to look elsewhere
where obvious.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-loop.cc (vect_analyze_loop_2): Get vectype
from the SLP node.
(vectorize_fold_left_reduction): Likewise.
(vect
The following removes an unused accessor to data that should go away.
* target.h (stmt_vectype): Remove.
* tree-vect-stmts.cc (stmt_vectype): Likewise.
---
gcc/target.h | 1 -
gcc/tree-vect-stmts.cc | 8
2 files changed, 9 deletions(-)
diff --git a/gcc/target.h
> On 24 Jul 2025, at 17:52, Iain Sandoe wrote:
>> On 24 Jul 2025, at 17:46, Jason Merrill wrote:
>>
>> On 7/24/25 12:39 PM, Iain Sandoe wrote:
On 24 Jul 2025, at 17:31, Jason Merrill wrote:
On 7/24/25 10:24 AM, Iain Sandoe wrote:
>>
The patch is OK without the assert, we
On 25/07/2025 11:54, Tobias Burnus wrote:
There are still issues with MI300, some which get resolved by adding s_nop.
One case where it is exactly known where the s_nop fixes a fail is for
libgomp.c-c++-common/task-detach-10.c, where libgomp/single.c's
GOMP_single_start() never returns 1, such t
HI Robin:
I was a bit concerned about the stmt_vec_info -> slp_tree hash map at
first, but I realized that it’s just a temporary hack, so LGTM :)
On Thu, Jul 24, 2025 at 9:09 PM Richard Biener
wrote:
>
> On Tue, Jul 22, 2025 at 11:46 AM Robin Dapp wrote:
> >
> > Hi,
> >
> > This patch prepares
LGTM :)
On Fri, Jul 25, 2025 at 5:30 PM Christoph Müllner <
christoph.muell...@vrull.eu> wrote:
> There was once a RISC-V extension draft ("N"), which introduced
> user-level interrupts. However, it was never ratified and the
> specification draft has been removed from the RISC-V ISA manual
> in
On Fri, 25 Jul 2025, Robin Dapp wrote:
> > So what was prevailing_mode then?
>
> RVVM2SI, so != word_mode, and basically two glued 32-bit vector regs.
> We get that from the first call with innermode SI.
>
> >
> > But
> >
> > /* Fall back to using mode_for_vector, mostly in the hope of bei
There are still issues with MI300, some which get resolved by adding s_nop.
One case where it is exactly known where the s_nop fixes a fail is for
libgomp.c-c++-common/task-detach-10.c, where libgomp/single.c's
GOMP_single_start() never returns 1, such that 'omp single' is
never executed. Adding
So what was prevailing_mode then?
RVVM2SI, so != word_mode, and basically two glued 32-bit vector regs.
We get that from the first call with innermode SI.
But
/* Fall back to using mode_for_vector, mostly in the hope of being
able to use an integer mode. */
if (known_eq
Please ignore, send to the list by accident.
On Fri, Jul 25, 2025 at 11:59 AM Tomasz Kamiński
wrote:
> Instead of using "::__overflow" using "__fwritable" and handle
> flushing empty writebuf in constructor.
> ---
> This removes unconditional flushing in _File constructor, and
> replace it with
Instead of using "::__overflow" using "__fwritable" and handle
flushing empty writebuf in constructor.
---
This removes unconditional flushing in _File constructor, and
replace it with writeability check only. The flush is performed
conditionally in _File_sink constructor, only if the _M_writebuf
i
There was once a RISC-V extension draft ("N"), which introduced
user-level interrupts. However, it was never ratified and the
specification draft has been removed from the RISC-V ISA manual
in commit `b6cade07034` with the comment "it'll likely need to
be redesigned".
Support for a N extension ne
1 - 100 of 125 matches
Mail list logo
