On Fri, Jun 06, 2025 at 10:07:54PM -0700, Andrew Pinski wrote:
> > --- gcc/expr.cc.jj 2025-06-05 10:36:06.545069723 +0200
> > +++ gcc/expr.cc 2025-06-05 19:14:45.601489036 +0200
> > @@ -9885,14 +9885,68 @@ expand_expr_real_2 (const_sepops ops, rt
> > op0 = gen_rtx_fmt_e (TYPE_UNSIGNED
Hi Ricjard,
> On 7 Jun 2025, at 1:12 am, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jan Hubicka writes:
>>> Should I go with:
>>>
>>> +autofdo_target
>>>
>>> +autofdo_target="i386"
>>> +case "${target}" in
>>> + aarch64-*-*)
>>> +autofdo
On Fri, Jun 6, 2025 at 6:41 AM Jakub Jelinek wrote:
>
> Hi!
>
> On top of the just posted patch, the following patch attempts to
> use value range to see if MSB is known to be false and for scalar integral
> extension in that case tries to expand both sign and zero extension and
> chooses based on
The problem here is opindex should not include the `-` part of the option.
But Wmusttail-local-addr and Wno-maybe-musttail-local-addr currently do.
This deletes them.
Pushed as obvious after building the html.
PR tree-optimization/120572
gcc/ChangeLog:
* doc/invoke.texi (Wmusttai
Hi everyone,
Thank you so much for your support, it really means a lot to me. I look forward
to contributing much more meaningfully beyond this small gitignore update.
Best regards,
Arijit
On Sat, Jun 7, 2025 at 3:49 AM Sam James wrote:
>
> Thomas Schwinge writes:
>
> > Hi!
> >
> > On 2025-06
So here's the next chunk of conditional move work from Shreya.
It's been a long standing wart that the conditional move expander does
not support sub-word operands in the comparison. Particularly since we
have support routines to handle the necessary extensions for that case.
This patch adju
So currently cselim is limited to targets which have conditional move
and also happens later in the pipeline. This adds the limited form of cselim;
where there is only one store in the two sides and no loads after the store.
This fixes phiprop-2.c for gcn target and now can match the MIN in phiopt
So the current code iterates through the uses of the vdef of the store to see
if there
is an use of the vdef inside the bb. Except in this case we know the only usage
will
be a phi node, so change the loop into calling single_imm_use and then checking
if the
usage statement was the PHI node.
Bo
Thomas Schwinge writes:
> Hi!
>
> On 2025-06-02T22:01:44+0530, Arijit Kumar Das
> wrote:
>>> Umm, I don't think so. I've been building crosses with gcc for decades.
>>> It should not be necessary, though it may sometimes be convenient.
>
> Right. Similarly to how it's, for example, documented
On 6/5/25 4:17 PM, Thomas Schwinge wrote:
Hi!
On 2025-06-02T22:01:44+0530, Arijit Kumar Das
wrote:
Umm, I don't think so. I've been building crosses with gcc for decades.
It should not be necessary, though it may sometimes be convenient.
Right. Similarly to how it's, for example, docu
cobol: Diagnostic messages, Flex build, and some cppcheck reports.
[PR120328, PR119695]
Remove %0x and similar from diagnostic framework messages. Remove %zu
from printf messages because it is not supported on some
platforms. Corrections in response to cppcheck. Sundry small fixes.
gcc/cobol/C
On Fri, Jun 06, 2025 at 11:31:00PM +0300, Dimitar Dimitrov wrote:
> On Fri, Jun 06, 2025 at 06:12:13PM +0100, Stafford Horne wrote:
> > On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote:
> > > On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote:
> > > > Stafford Horne wr
On Fri, Jun 06, 2025 at 06:12:13PM +0100, Stafford Horne wrote:
> On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote:
> > On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote:
> > > Stafford Horne writes:
> > > > Hello,
> > > >
> > > > This seems to be causing a build regr
On Fri, 6 Jun 2025, Jonathan Wakely wrote:
> Including behaves differently depending on whether you have
> the TBB headers installed or not. Without them installed, the modules
> tests PASS, but with TBB headers installed they FAIL with:
>
> gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: inte
On 06/06/25 20:28 +0100, Jonathan Wakely wrote:
Including behaves differently depending on whether you have
the TBB headers installed or not. Without them installed, the modules
tests PASS, but with TBB headers installed they FAIL with:
gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: internal
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here since r15-4120 we were prematurely complaining about the use of func
within its own definiton, which is fine at instantiation time. So don't
require this for function templates that are currently being defined.
But keep the error for
Including behaves differently depending on whether you have
the TBB headers installed or not. Without them installed, the modules
tests PASS, but with TBB headers installed they FAIL with:
gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: internal compiler error: in
core_vals, at cp/module.cc:66
Built on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
release branches?
-- >8 --
Jonathan noticed this flag isn't documented in the manual.
gcc/ChangeLog:
* doc/invoke.texi: Add -fconcepts-diagnostics-depth.
---
gcc/doc/invoke.texi | 8 +++-
1 file changed, 7 insert
libstdc++-v3/ChangeLog:
* testsuite/30_threads/semaphore/1.cc: Check type properties and
max() values.
* testsuite/30_threads/semaphore/3.cc: New test.
* testsuite/30_threads/semaphore/cons_neg.cc: New test.
---
Tested x86_64-linux and sparc-solaris. Pushed to trun
The lambda expression causes testsuite failures such as:
FAIL g++.dg/modules/xtreme-header-2_b.C -std=c++26 (test for excess errors)
libstdc++-v3/ChangeLog:
* include/bits/semaphore_base.h (_Select_semaphore_impl): Rename
to _Semaphore_impl and use std::conditional_t instead of an
I once was involved in a dinner party where three different people dumped
"a little bit" of salt into the soup while it was cooking.
This feels like that.
I'll be taking care of this.
> -Original Message-
> From: James K. Lowden
> Sent: Friday, June 6, 2025 14:51
> To: gcc-patches@gcc.g
On Thu, Jun 5, 2025 at 11:39 PM Richard Biener
wrote:
>
> On Fri, Jun 6, 2025 at 12:14 AM Andrew Pinski
> wrote:
> >
> > Currently we expand `{}` and store zeros to the stack and then do a full
> > mode load back. This is a waste, instead we should just use the zero cst
> > in the mode that fits
On Fri, 6 Jun 2025 15:48:27 +0200
Jakub Jelinek wrote:
> In any case, the class doesn't have any constexpr constructors, so
> it isn't a literal type, one can't construct those objects in constant
> expressions and so using constexpr keyword for the defaulted copy
> assignment operator can't help
On 6/6/25 11:58 AM, Robin Dapp wrote:
Note it’s far from obvious to me whether for stride and gather loads
the alignment of the elements loaded falls under the scalar or vector
load restriction. Is this explicitly spelled out for risc-v or is
that your interpretation?
We have the followin
This improves copy prop for aggregates by working over statements that don't
modify the access
just like how it is done for copying zeros.
To speed up things, we should only have one loop back on the vuse instead of
doing it twice for
each load/store assignments.
PR tree-optimization/142
We are taking care of this separately, as part of a larger set of changes.
So, please don't apply the patch; we're likely to trip over each other.
Thanks!
> -Original Message-
> From: Jakub Jelinek
> Sent: Friday, June 6, 2025 09:48
> To: Robert Dubner ; James K. Lowden
>
> Cc: gcc-pat
Note it’s far from obvious to me whether for stride and gather loads the
alignment of the elements loaded falls under the scalar or vector load
restriction. Is this explicitly spelled out for risc-v or is that your
interpretation?
We have the following in the vector spec:
If an element acces
As further generalization of XML support during prototyping of new
features, don't hardcode the HTML DTD.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1269-gd5050287acd28c.
gcc/ChangeLog:
* diagnostic-format-html.cc (struct html_doctypedecl): New.
While prototyping new features I'm finding it helpful to use XML
beyond the "experimental-html" diagnostics sink. Move the
implementation of the xml classes to their own file.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-126
During prototyping a feature I found it useful for
text_art::wrapper_widget to be able to not have a child.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1266-gcda7145fa9e97f.
gcc/ChangeLog:
* text-art/widget.cc (selftest::test_empty_wrapper_widget)
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1267-g0401957b86fa29.
gcc/ChangeLog:
* selftest.h: Fix the sorting of the various *_cc_tests decls.
---
gcc/selftest.h | 14 +++---
1 file changed, 7 insertions(+)
On 6/6/25 5:34 AM, FX Coudert wrote:
Hi,
In commit 5e918a4db9e4a5bdbeafec6881fa8b22a55d3789, regenerated files
were not included in the commit as they should have been. Therefore, a
whitespace fix was not propagated. Sync generated files now, as obtained
from a run with --enable-maintainer-mode.
> Am 06.06.2025 um 17:42 schrieb Robin Dapp :
>
>
>>
>> At first I thought if we only cared about element misalignment checking the
>> first element/pointer should be sufficient. But riscv's gathers as well as
>> strided loads allow byte offsets rather than element-sized offsets so there
On Fri, Jun 06, 2025 at 04:41:21PM +0100, Stafford Horne wrote:
> On Fri, Jun 06, 2025 at 04:20:10PM +0100, Richard Sandiford wrote:
> > Stafford Horne writes:
> > > Hello,
> > >
> > > This seems to be causing a build regression on the or1k port.
> > >
> > > I have not quite figured it out yet but
On Fri, Jun 06, 2025 at 02:34:09PM +0200, FX Coudert wrote:
>
> In commit 5e918a4db9e4a5bdbeafec6881fa8b22a55d3789, regenerated files
> were not included in the commit as they should have been. Therefore, a
> whitespace fix was not propagated. Sync generated files now, as obtained
> from a run wit
Hi!
While the
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#c03-compatibility-changes-for-annex-c-diff.cpp03.dcl.dcl
hunk dropped because
struct C {}; struct C {} final {};
is actually not valid C++98 (which didn't have list initialization), we
actually also reject
struct
No problem. That should be it included below. Github diff for convenience:
https://github.com/gcc-mirror/gcc/compare/e37eb85...pkeir:gcc:1b7c7c1a
Signed-off-by: Paul Keir
Tested on x86_64-linux.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr.h: Added owner_equal and owner_hash memb
On Fri, Jun 06, 2025 at 04:51:33PM +0200, Tobias Burnus wrote:
> Most builtins in omp-builtins.def is marked as LEAF. At a glance,
> that's surprising but looking at the functions, it turns out
> that most of them just call 'gomp_thread ()' which is a simple
> inline function such that no function
Hi all,
This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this patch, we
add intrinsic documentation for the newly added trig functions with
half-revolutions. We also reorder the documentation for `atand` to place it in
correct alphabetical order.
BR,
Yuao
0001-fortran-add-intrin
At first I thought if we only cared about element misalignment checking the
first element/pointer should be sufficient. But riscv's gathers as well as
strided loads allow byte offsets rather than element-sized offsets so there
could be 16-bit loads with a stride of e.g. 1 byte.
Wait, no that
On 6/6/25 14:12, Tomasz Kaminski wrote:
On Thu, Jun 5, 2025 at 4:31 PM Luc Grosheintz
wrote:
libstdc++-v3/ChangeLog:
* include/std/mdspan (default_accessor): New class.
* src/c++23/std.cc.in: Register default_accessor.
* testsuite/23_containers/mdspan/default_acc
At least on aarch64, the gathers and scatters use (mem:BLK (scratch:P)),
i.e. a wildcard memory access. There's no good way in RTL to represent
multiplie distinct locations in a single reference.
(unspec on its own doesn't imply a memory access)
At first I thought if we only cared about elemen
On 6/6/25 11:07, Jakub Jelinek wrote:
On Fri, Jun 06, 2025 at 10:54:55AM -0400, Andrew MacLeod wrote:
I don't remember details about the order of things... Is there any chance
that you might query an SSA_NAME whose DEF was in a block which has been
converted to RTL? Ranger will query all t
Richard Biener writes:
> On Fri, Jun 6, 2025 at 1:26 PM Robin Dapp wrote:
>>
>> > In case the riscv strided vector load instruction has additional
>> > requirements
>> > on the loaded (scalar) element alignment then we'd have to implement this.
>> > For the moment the vectorizer will really emit
On 6/6/25 00:44, Jan Beulich wrote:
As per documentation, even 4.7 ought to suffice. At least 4.13 objects
to there being nothing ahead of the first comma in @xref{}.
---
The text inserted it merely a guess; I'm open to better suggestions.
Noticed with gcc15, so may want backporting.
--- a/gcc/
I have committed a change to the master branch in my local repository
with the following message. Since it's my first time, before pushing,
I would like to know if there's any problem with the message itself.
I have tried to follow patterns I've seen elsewhere.
It's a bit of a hodgepodge bec
Stafford Horne writes:
> Hello,
>
> This seems to be causing a build regression on the or1k port.
>
> I have not quite figured it out yet but I have bisected to this commit.
>
> The failure is as below, this seems to be caused by the cstoresi4 instruction
> produced by
> or1k.md. So I think its
Jan Hubicka writes:
>> Should I go with:
>>
>> +autofdo_target
>>
>> +autofdo_target="i386"
>> +case "${target}" in
>> + aarch64-*-*)
>> +autofdo_target="aarch64"
>> +;;
>> +esac
>>
>> As in the first version? I can test and send a patch for review if there is
>> no other better alt
I think the spotted correctness issues wrt alignment/aliasing should be
addressed up-front. In the end the gather/stride-load is probably an
UNSPEC, so there's no MEM RTX with wrong info? How would we
query the target on whether it can handle the alignment here? Usually
we go through vect_suppo
On Fri, Jun 06, 2025 at 10:54:55AM -0400, Andrew MacLeod wrote:
> I don't remember details about the order of things... Is there any chance
> that you might query an SSA_NAME whose DEF was in a block which has been
> converted to RTL? Ranger will query all the way back to the def block,
> acces
Spencer Abson writes:
> This patch extends the expander for fma, fnma, fms, and fnms to support
> partial SVE FP modes.
>
> We add the missing BF16 tests, which we can now trigger for having
> implemented the conditional expander.
>
> We also add tests for the 'merging with multiplicand' case, whi
Spencer Abson writes:
> Extend the ternary op/UNSPEC_SEL combiner patterns from SVE_FULL_F/
> SVE_FULL_F_BF to SVE_F/SVE_F_BF, where the strictness value is
> SVE_RELAXED_GP.
>
> We can only reliably test the 'merging with the third input' (addend)
> and 'independent value' patterns at this stage
Spencer Abson writes:
> This patch extends the expander for unconditional fma, fnma, fms, and
> fnms, so that it supports partial SVE FP modes.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sve.md (4): Extend from
> SVE_FULL_F_B16B16 to SVE_F_B16B16. Use sve_fp_pred instead
>
Interesting.
I don't remember details about the order of things... Is there any
chance that you might query an SSA_NAME whose DEF was in a block which
has been converted to RTL? Ranger will query all the way back to the
def block, accessed via gimple_bb (SSA_NAME_DEF_STMT (name)), or top
Spencer Abson writes:
> @@ -8165,20 +8169,25 @@
> ;;
> ;; For unpacked vectors, it doesn't really matter whether SEL uses the
> ;; the container size or the element size. If SEL used the container size,
> -;; it would ignore undefined bits of the predicate but would copy the
> -;; upper (undef
Most builtins in omp-builtins.def is marked as LEAF. At a glance,
that's surprising but looking at the functions, it turns out
that most of them just call 'gomp_thread ()' which is a simple
inline function such that no function call remains.
However, that's not true for all - and omp_get_mapped_p
Jakub's recent changes for pr120231 compromised this arc port specific
test. Essentially we collapse the entire FMA sequence down to a
constant and thus never emit the FMA instruction the test wants to see.
If we make "a" an extern so that we don't know its value the optimizers
can't collapse
I have now pushed those patches as:
r16-1262-g387209938d2c47
OpenMP: Add omp_get_initial_device/omp_get_num_devices builtins
r16-1261-g214b5d66c54613
builtins.def: Enable OpenMP/OpenACC builtins also with -fno-nonansi-builtins
Tobias
Current GCC uses either peeling or versioning, but not in combination,
to handle unaligned data references (DRs) during vectorization. This
limitation causes some loops with early break to fall back to scalar
code at runtime.
Consider the following loop with DRs in its early break condition:
Hi!
As the following testcase shows, during expansion we use value range info
in lots of places, but sadly currently use only the global ranges.
It is mostly through get_range_pos_neg function, which uses
get_global_range_query ()->range_of_expr (arg1, arg2)
but other spots use it directly.
On th
Simplfy dg-options in format/debug.cc, by not configuring wide encoding.
Address TODO in format_kind.cc, by adding test for format_kind::map.
libstdc++-v3/ChangeLog:
* testsuite/std/format/ranges/format_kind.cc: Add test for
range_format::map.
* testsuite/std/format/debug.
> On 2025-06-06 12:42, Jan Hubicka wrote:
> > > Hi,
> > > also after fixing this issue my bootstrap failes with:
> > >
> > > Permission error mapping pages.
> > > Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
> > > or try again with a smaller value of -m/--mmap_pages.
> > > (current va
Hi!
The just posted second PR120434 patch causes
+FAIL: gcc.target/i386/pr78103-3.c scan-assembler m(leaq|addq|incq)M
+FAIL: gcc.target/i386/pr78103-3.c scan-assembler-not mmovlM+
+FAIL: gcc.target/i386/pr78103-3.c scan-assembler-not msubqM
+FAIL: gcc.target/i386/pr78103-3.
Hi!
As mentioned in the PR, this code is likely only valid in C++23 and
later and not really useful in that case and it might be a GCC bug
that it fails to diagnose the bug in C++14 to C++20 modes (it diagnoses
it in C++11 mode).
In any case, the class doesn't have any constexpr constructors, so
Yes. Note I don't see we guarantee element alignment for gather/scatter
either, nor do the IFNs seem to have encoding space for alignment. The
effective type for TBAA seems also missing there ...
Regarding vector_vector_composition_type I had a try and attached a preliminary
V3. I'm not reall
Hi!
On top of the just posted patch, the following patch attempts to
use value range to see if MSB is known to be false and for scalar integral
extension in that case tries to expand both sign and zero extension and
chooses based on RTX costs the cheaper one (if the costs are the same
uses what it
On 6/6/25 4:14 AM, Stafford Horne wrote:
Hello,
This seems to be causing a build regression on the or1k port.
I have not quite figured it out yet but I have bisected to this commit.
The failure is as below, this seems to be caused by the cstoresi4 instruction
produced by
or1k.md. So I thi
On Fri, Jun 6, 2025 at 3:13 PM Jonathan Wakely wrote:
> These features depend on __cpp_lib_atomic_wait which is not available
> for freestanding, and is available when either gthreads is supported, or
> the target is linux (for futex support).
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/3
Spencer Abson writes:
> Extend the binary op/UNSPEC_SEL combiner patterns from SVE_FULL_F/
> SVE_FULL_F_B16B16 to SVE_F/SVE_F_B16B16, where the strictness value
> is SVE_RELAXED_GP.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sve.md (*cond__2_relaxed):
> Extend from SVE_FULL_F_B16B
These features depend on __cpp_lib_atomic_wait which is not available
for freestanding, and is available when either gthreads is supported, or
the target is linux (for futex support).
libstdc++-v3/ChangeLog:
* testsuite/30_threads/barrier/1.cc: Require hosted. Only
require gthread
On 2025-06-06 12:42, Jan Hubicka wrote:
Hi,
also after fixing this issue my bootstrap failes with:
Permission error mapping pages.
Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
or try again with a smaller value of -m/--mmap_pages.
(current value: 4294967295,0)
Permission error mappin
The following removes the non-SLP path from get_group_load_store_type
and get_load_store_type.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vect-stmts.cc (get_group_load_store_type): Remove
non-SLP path.
(get_load_store_type): Likewise.
---
gcc/tree-v
Prune unreachable paths
* tree-vect-stmts.cc (vectorizable_store): Remove non-SLP
paths.
---
gcc/tree-vect-stmts.cc | 591 +
1 file changed, 192 insertions(+), 399 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
in
Eliminate the toplevel ncopies and loops that become non-loops.
Eliminate use of STMT_VINFO_VECTYPE.
Bootstrapped and tested on x86_64-unknown-linux-gnu, will squash
and push.
* tree-vect-stmts.cc (vectorizable_store): Remove non-SLP
paths.
---
gcc/tree-vect-stmts.cc | 524 ++
replace slp_node/slp checks with 1
* tree-vect-stmts.cc (vectorizable_store): Prune non-SLP paths.
---
gcc/tree-vect-stmts.cc | 78 +-
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
in
On Fri, Jun 6, 2025 at 1:26 PM Robin Dapp wrote:
>
> > In case the riscv strided vector load instruction has additional
> > requirements
> > on the loaded (scalar) element alignment then we'd have to implement this.
> > For the moment the vectorizer will really emit scalar loads here, so that's
>
On Thu, Jun 5, 2025 at 4:31 PM Luc Grosheintz
wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan (default_accessor): New class.
> * src/c++23/std.cc.in: Register default_accessor.
> * testsuite/23_containers/mdspan/default_accessor.cc: New test.
>
> Signed-off-by: L
Spencer Abson writes:
> This patch extends the unpredicated FP division expander to support
> partial FP modes. It extends the existing patterns used to implement
> UNSPEC_COND_FDIV and it's approximation as needed.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sve.md: (@aarch64_sve_):
>
Spencer Abson writes:
> This patch extends the expanders for unpredicated smax, smin, add, sub,
> mul, min, and max, so that they support partial SVE FP modes.
>
> The relevant insn/split patterns have also been updated.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sve.md (3): Extend from
On 23/05/25 17:55 +, Paul Keir wrote:
This patch implements C++26 "Enabling the Use of weak_ptr as Keys in Unordered
Associative Containers", as specified in P1901R2.
I don't have write access.
Signed-off-by: Paul Keir
Tested on x86_64-linux.
libstdc++-v3/ChangeLog:
* include/bi
In case the riscv strided vector load instruction has additional requirements
on the loaded (scalar) element alignment then we'd have to implement this.
For the moment the vectorizer will really emit scalar loads here, so that's
fine (though eventually inefficient). For the strided vector load th
On 28/05/25 09:00 -0400, Patrick Palka wrote:
On Wed, 28 May 2025, Tomasz Kaminski wrote:
On Tue, May 27, 2025 at 7:08 PM Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
The 'volatile' issue from that PR Will be fixed in a separate patch as
In contrast to other calendar types if empty chron-spec is used for duration
we are required to format it (and it's representation type) via ostream.
Handling this case was now moved to be part of the format function
for duration. To facilitate that __formatter_chrono::_M_format_to_ostream
function
On Thu, 5 Jun 2025 at 10:09, Tomasz Kaminski wrote:
>
>
>
> On Thu, Jun 5, 2025 at 12:10 AM Jonathan Wakely wrote:
>>
>> These overloads should never be used for proxy waits, so add assertions
>> to ensure that they aren't used accidentally.
>>
>> The reason they can't be used is that they don't
This patch change implementation of the formatters for the calendar types,
so they no longer delegate to operator<< for ostream in case of empty
chrono-spec.
Instead of that, we define the behavior of the in terms of format specifiers,
that format specifiers are supplied by each formatter as argum
This patch change implementation of the formatters for sys_info and local_info,
so they no longer delegate to operator<< for ostream in case of empty spec.
As this types may be only formatted with empty chrono-spec (with padding), they
now
use a separate __formatter_chrono_info formatter.
The __f
This patch change implementation of the formatters for time points and hh_mm_ss,
so they no longer delegate to operator<< for ostream in case of empty
chrono-spec.
As in case of calendar types, the formatters for specific type now provide
__formatter_chrono with default _ChronoSpec that are used i
This patch series reworks the handling of the empty chron-spec when
formatting calendar types. For all types except duration with custom
representation, the implementation no-longer delegates to operator<<,
and instead configures formatter _M_chron_spec accordingly, and follows
with normal format r
> Hi,
> also after fixing this issue my bootstrap failes with:
>
> Permission error mapping pages.
> Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
> or try again with a smaller value of -m/--mmap_pages.
> (current value: 4294967295,0)
> Permission error mapping pages.
> Consider increa
Hello,
This seems to be causing a build regression on the or1k port.
I have not quite figured it out yet but I have bisected to this commit.
The failure is as below, this seems to be caused by the cstoresi4 instruction
produced by
or1k.md. So I think its likely something we are doing funny in
This patch fixes ICE seen when building spec2k17 with autofdo and enable
checking compiler. Bause we special case 0 of autofdo to be kind of 1 in IPA
scalling, we can now end up with function heving global0 profile but producing
inline clone with nonzero profile.
I think correct way is to extend
Now that create_tmp_reg_or_ssa_name just calls make_ssa_name replace
all of its uses.
Bootstrapped on x86_64-unknown-linux-gnu, built a cross to ppc64le,
pushed.
* gimple-fold.h (create_tmp_reg_or_ssa_name): Remove.
* gimple-fold.cc (create_tmp_reg_or_ssa_name): Likewise.
From: Eric Botcazou
At library level the object must be allocated statically and with its bounds
when its nominal subtype is an unconstrained array type.
gcc/ada/ChangeLog:
* exp_ch4.adb (Insert_Conditional_Object_Declaration): Make sure the
object is allocated properly by the c
From: Yunze Zhu
This commit add support for xtheadvector-specific strided segment load/store
intrinsics with b/h/w suffix. We also defined enum to be used in
thead-vector-builtins-bases.cc
https://github.com/XUANTIE-RV/thead-extension-spec/pull/66
gcc/ChangeLog:
* config/riscv/riscv-vec
Spencer Abson writes:
> This patch extends the compare/and splitting patterns for FP comparisons
> from SVE_FULL_F to SVE_F.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sve.md (*fcm_and_combine):
> Extend to SVE_F.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/sve/unp
From: Yunze Zhu
This commit add support for xtheadvector-specific unit-stride segment
load/store intrinsics with b/h/w suffix. We also defined enum to be used
in thead-vector-builtins-bases.cc
https://github.com/XUANTIE-RV/thead-extension-spec/pull/66
gcc/ChangeLog:
* config.gcc: Add ne
Spencer Abson writes:
> diff --git a/gcc/config/aarch64/aarch64-sve.md
> b/gcc/config/aarch64/aarch64-sve.md
> index 399d147c9a5..1a705e153cb 100644
> --- a/gcc/config/aarch64/aarch64-sve.md
> +++ b/gcc/config/aarch64/aarch64-sve.md
> @@ -3762,13 +3762,28 @@
>
> ;; Unpredicated floating-point
From: Yunze Zhu
This commit add support for xtheadvector-specific indexed segment load/store
intrinsics with b/h/w suffix. We also defined enum to be used in
thead-vector-builtins-bases.cc
https://github.com/XUANTIE-RV/thead-extension-spec/pull/66
gcc/ChangeLog:
* config/riscv/riscv-vec
From: Yunze Zhu
This series add xtheadvector-specific segment load/store intrinsics support,
including:
[1/4] xtheadvector unit stride segment load/store intrinsics,
[2/4] xtheadvector stride segment load/store intrinsics,
[3/4] xtheadvector indexed stride segment load/store intrinsics,
[4/4] xt
Hi,
also after fixing this issue my bootstrap failes with:
Permission error mapping pages.
Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
or try again with a smaller value of -m/--mmap_pages.
(current value: 4294967295,0)
Permission error mapping pages.
Consider increasing /proc/sys/ker
1 - 100 of 164 matches
Mail list logo
