On Thu, Jun 26, 2025 at 2:17 PM H.J. Lu wrote:
>
> On Thu, Jun 26, 2025 at 2:11 PM Hongtao Liu wrote:
> >
> > On Thu, Jun 26, 2025 at 1:59 PM H.J. Lu wrote:
> > >
> > > Use the inner scalar mode of vector broadcast source in:
> > >
> > > (set (reg:V8DF 394)
> > >(vec_duplicate:V8DF (re
On Jun 26, 2025, Vladimir Makarov wrote:
> This patch is ok for me. I am a big fan of asserts. They helped to
> catch so many bugs on early stages.
That makes it two of us ;-)
Thanks a lot for the reviews.
Since this PR is now presumed solved, I've filed PR120838 for the
remaining issue with
Hi Honza,
> On 27 Jun 2025, at 1:03 am, Jan Hubicka wrote:
>
> External email: Use caution opening links or attachments
>
>
>>
>>
>>> On 24 Jun 2025, at 7:43 pm, Jan Hubicka wrote:
>>>
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Hi,
>>> this pass removes earl
LGTM, but please add some words to indicate what you have done for changelog.
You can find the examples from the previous PATCH(es) I bet.
> * gcc.target/riscv/sat/sat_arith.h:
Pan
-Original Message-
From: Ciyan Pan
Sent: Tuesday, June 24, 2025 11:13 AM
To: gcc-patches@gcc.gnu.o
Hi Honza,
> On 24 Jun 2025, at 4:37 pm, Jan Hubicka wrote:
>
> External email: Use caution opening links or attachments
>
>
>>>
>>> With part suffixes we also may want to merge specially, since the
>>> entry_count of the split part does not correspond to entry_count of the
>>> original function.
Hi,
I'm bumping this patch.
Jeremy
On Mon, Jun 9, 2025 at 8:00 PM Jeremy Rifkin wrote:
>
> Hi,
> This fixes PR c/82134 which concerns gcc emitting an incorrect unused
> result diagnostic for empty types. This diagnostic is emitted from
> tree-cfg.cc because of a couple code paths which attempt t
On Thu, May 8, 2025 at 11:11 AM H.J. Lu wrote:
>
> Conditional and unconditional branch targets can be either a label or
> a symbol. For conditional jump:
>
> (jump_insn 7 6 14 2 (set (pc)
> (if_then_else (eq (reg:CCZ 17 flags)
> (const_int 0 [0]))
> (label_ref
On Thu, 26 Jun 2025, Richard Biener wrote:
> The following prototypes diagnostics for conversions to/from time_t
> where the source/destination does not have sufficient precision for it.
> I've lumped this into -Wconversion for the moment and didn't bother
> fixing up the testcase for !ilp32 or th
On Mon, May 5, 2025 at 7:32 AM H.J. Lu wrote:
> Here is the v2 patch. ix86_get_small_integer_argument_value was moved to
> calls.cc. I added a target hook, TARGET_SAME_FUNCTION_ARGUMENT_ORDER_P,
> to verify that caller and callee have the same incoming argument
> order. The default returns
>
On 26/06/2025 21:47, Jonathan Wakely wrote:
On 26/06/25 19:30 +0200, François Dumont wrote:
I find it quite convenient so maybe you'll accept it.
Note that looking for existence of this macro I noticed that
ChangeLog-2024 is wrongly talking about
_GLIBCXX_USE_ALLOC_PTR_FOR_LIST in header.
On Wed, Jun 25, 2025 at 03:13:25PM -0400, Jason Merrill wrote:
> On 6/25/25 1:28 PM, Marek Polacek wrote:
> > @@ -24604,7 +24604,7 @@ resolve_nondeduced_context (tree orig_expr,
> > tsubst_flags_t complain)
> > }
> > if (good == 1)
> > {
> > - mark_used (goodfn);
> > + mark
On 26/06/25 19:30 +0200, François Dumont wrote:
I find it quite convenient so maybe you'll accept it.
Note that looking for existence of this macro I noticed that
ChangeLog-2024 is wrongly talking about
_GLIBCXX_USE_ALLOC_PTR_FOR_LIST in header. Should it be
fixed ?
No, I don't see any poi
The 64-bit register-to-register moves on PRU are implemented with two
instructions moving 32-bit registers. Defining a split for the 64-bit
moves allows this to be described in RTL, and thus one of the 32-bit
moves to be eliminated if the destination register is dead.
Also, split the loading of n
On Wed, Jun 25, 2025 at 1:37 PM Bill Wendling wrote:
>
> I posted this on the LLVM Discourse forum[1] and got some traction, so
> I want to get the GCC community's input. (My initial proposal is
> replicated here.)
>
> I had already mentioned this in previous emails in this thread, so
> it's nothi
On Thu, 2025-06-26 at 17:45 +, Yuao Ma wrote:
> Hi all,
>
> This patch, a follow-up to r16-1652-g0606d2b979f401, implements
> middle-end
> optimizations (e.g., constant folding) for our trigonometric pi-based
> function
> built-ins.
>
> This patch is part of
> https://gcc.gnu.org/pipermail/fo
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1715-g0e7296540be358.
gcc/ChangeLog:
PR analyzer/120809
* diagnostic-format-html.cc
(html_builder::maybe_make_state_diagram): Bulletproof against the
SVG generation failing.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1716-gc4d211bba2a86b.
gcc/ada/ChangeLog:
* gcc-interface/misc.cc (gnat_init): Use
diagnostic_context::set_internal_error_callback.
gcc/c-family/ChangeLog:
Ping for the series
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686373.html
Thanks
On 6/10/25 14:41, David Faust wrote:
> [v3: https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html
> Changes v3->v4:
> - Only patch 2 (DWARF generation) is changed; update based on Richard's
>
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1714-g5bf213d4ad648f.
gcc/ChangeLog:
* diagnostic-output-spec.cc (sarif_scheme_handler::make_sink):
Split out creation of sarif_generation_options and
sarif
Hi all,
This patch, a follow-up to r16-1652-g0606d2b979f401, implements middle-end
optimizations (e.g., constant folding) for our trigonometric pi-based function
built-ins.
This patch is part of
https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj
Please take a look
Hi all,
This patch, a follow-up to r16-1652-g0606d2b979f401, implements middle-end
optimizations (e.g., constant folding) for our trigonometric pi-based function
built-ins.
This patch is part of
https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj
Please take a look
Hi Jerry,
for the moment only the static library is configured in the build scripts.
Therefore only that is build named libcaf_shmem.a That's completely correct
and desired.
I have asked the same question about performance or stress tests and got
only the coarray_icar (link in the 0/6 mail).
No chance to just answer to the question below about how conservative I
should be ?
Thanks
On 02/06/2025 07:07, François Dumont wrote:
Hi
It would be nice if someone got some time to review this PR.
Compared to other containers for which support of fancy allocator
pointer type have been add
I find it quite convenient so maybe you'll accept it.
Note that looking for existence of this macro I noticed that
ChangeLog-2024 is wrongly talking about _GLIBCXX_USE_ALLOC_PTR_FOR_LIST
in header. Should it be fixed ?
libstdc++: Add _GLIBCXX_USE_ALLOC_PTR macro to rule them all
Pro
On Thu, Jun 26, 2025 at 01:33:08PM +0200, Jakub Jelinek wrote:
> I get some regressions (which I didn't get with the earlier patch, but
> it isn't obvious by what it has been caused):
It ICEs were caused by the canonicalize_obj_off change and indeed
> The ICEs are all in the same spot:
>
On 6/26/25 12:22 AM, Andre Vehreschild wrote:
Hi Jerry,
thanks for testing. I have fixed IMO most of the whitespace issues in the
patch attached to this mail:
https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html
About the 32 vs. 64 bit versions of the libraries: I never got in touch with
On Sat, Jun 21, 2025 at 09:18:43AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > This implements error handling for hard register constraints including
> > potential conflicts with register asm operands.
> >
> > In contrast to register asm operands, hard
On Mon, Jun 23, 2025 at 07:12:58PM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > Currently a register asm already materializes during expand. This
> > means, a hard register is allocated for the very first access of a
> > register asm as e.g. in an assig
On Sat, Jun 21, 2025 at 09:06:42AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > Implement hard register constraints of the form {regname} where regname
> > must be a valid register name for the target. Such constraints may be
> > used in asm statements
On Fri, Jun 20, 2025 at 10:17:20AM -0400, Vladimir Makarov wrote:
>
> On 5/20/25 3:22 AM, Stefan Schulze Frielinghaus wrote:
> > Implement hard register constraints of the form {regname} where regname
> > must be a valid register name for the target. Such constraints may be
> > used in asm statem
On 6/26/25 1:51 AM, Alexandre Oliva wrote:
On Jun 25, 2025, Vladimir Makarov wrote:
This patch is ok for me. I am a big fan of asserts. They helped to
catch so many bugs on early stages.
Thank you, Alex.
for gcc/ChangeLog
PR rtl-optimization/120424
* lra-elimination
On 2025-04-30 16:37, Joseph Myers wrote:
> On Sat, 26 Apr 2025, Florian Weimer wrote:
>
>> Builtins defined with BT_FN_INT_VAR etc. show as functions without
>> a prototype and trigger the warning.
>>
>> gcc/c/
>>
>> PR c/119950
>> * c-typeck.cc (convert_arguments): Check for built-in
Hi!
[ Please don't say "patch v1", it's just clutter. ]
The point of the patch is to improve some code that evokes undefined
behaviour. The sanitizer for that is how these problems were found,
you can remark that somewhere later in the message, but ubsan is not
what this patch is about, it does
On 6/23/25 12:00 AM, Alexandre Oliva wrote:
And here's a followup to clean up the mess I made in
lra_update_fp2sp_elimination, without any functional changes.
The various recent additions to lra_update_fp2sp_elimination rendered
it somewhat confusing, with intermixed groups of statements pert
Hi,
I found a bug in the module cleanup expression at the end of the test. In the
attached patch it is corrected.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
On Wed, 25 Jun 2025 15:48:11 +0200
Andre Vehreschild wrote:
> Hi,
>
> Antony Lewis reported this
On 6/23/25 12:01 AM, Alexandre Oliva wrote:
When attempting to bootstrap arm-linux-gnueabihf with
{BOOT_C,T}FLAGS='-g -O2 -fnon-call-exceptions
-fstack-clash-protection', gmp fails to build in stage2: gen-fac's
mpz_and gets miscompiled.
A pseudo is initialized before a loop and used in a PRE_I
>
>
> > On 24 Jun 2025, at 7:43 pm, Jan Hubicka wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi,
> > this pass removes early-inlining from afdo pass since all inlining
> > should now happen from early inliner. I tedted this on spec and there
> > are 3 i
On 6/22/25 11:59 PM, Alexandre Oliva wrote:
On Jun 13, 2025, Vladimir Makarov wrote:
* lra-eliminations.cc (lra_update_fp2sp_elimination):
Inactivate the unused fp2sp elimination right away.
Alas, this seems to cause trouble on arm-linux-gnueabihf bootstraps.
This is OK. In many cases It is
On 6/22/25 11:54 PM, Alexandre Oliva wrote:
Regstrapped on x86_64-linux-gnu, bootstrapped on arm-linux-gnueabihf
(arm and thumb modes), also tested with gcc-14 on arm-vx7r2 and
arm-linux-gnueabihf. Ok to install?
It is OK for me. Thank you, Alex
for gcc/ChangeLog
PR rtl-optimiza
On Thu, 26 Jun 2025 at 15:38, Jonathan Wakely wrote:
>
> On Thu, 26 Jun 2025 at 11:33, Jakub Jelinek wrote:
> >
> > On Wed, Jun 25, 2025 at 10:58:59PM +0200, Maciej Cencora wrote:
> > > update of std module is missing.
> >
> > Here is an updated patch which adds the std module part and while I wa
This pattern enables the combine pass (or late-combine, depending on the case)
to merge a vec_duplicate into a (possibly negated) minus-mult RTL instruction.
Before this patch, we have two instructions, e.g.:
vfmv.v.fv6,fa0
vfnmacc.vv v2,v6,v4
After, we get only one:
vfnmacc.vf
On 21/06/2025 12:35, Filip Kastl wrote:
> On Fri 2025-06-20 10:46:08, Alex Coplan wrote:
> > Hi,
> >
> > This adds a main() function to mklog.py (like e.g. check_GNU_style.py
> > has), which makes it easier to import and invoke from another python
> > script. This is useful when using a wrapper s
On Thu, 26 Jun 2025 at 11:33, Jakub Jelinek wrote:
>
> On Wed, Jun 25, 2025 at 10:58:59PM +0200, Maciej Cencora wrote:
> > update of std module is missing.
>
> Here is an updated patch which adds the std module part and while I was
> changing the patch, I've also added value_type/type and the 2 op
On Wed, Jun 25 2025, Martin Jambor wrote:
> Hi,
>
> when compiling
> gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc
> with clang, it emits the following warning:
>
> gcc/rust/checks/errors/borrowck/rust-borrow-checker-diagnostics.cc:145:46:
> warning: non-constant-expression
Hello Piyush.
I have a few high-level comments and questions, inlined below.
Thanks!
> This patch adds the vmtest-tool subdirectory under contrib which tests
> BPF programs under a live kernel using a QEMU VM. It automatically
> builds the specified kernel version with eBPF support enabled
> a
Hi Kito,
This patch adds a comment to the riscv.md file to clarify the purpose of
the file and reorders the include files for better organization.
this seems to have broken the build. I believe that's due to
-(include "vector.md")
(include "vector-crypto.md")
because vector crypto depend
Hello Piyush.
Sorry for the delay in reviewing. It's been quite a busy week at
work...
> This patch adds initial version of vmtest-tool script to test BPF
> programs on live kernel
>
> For now, the tool is standalone, but it is intended to be integrated with the
> DejaGnu testsuite to run BPF
I guess I missed it when I first ran the testsuite before sending the patch
for review. I rebased and re-ran the testsuite after getting approved and saw
the regression. But at that point I realised Jeff had already merged it.
Anyway, I'll regtest more carefully next time!
The CI helps with th
Introduce crc_revsi4 expanders to generate CRC32 instruction when using
__builtin_rev_crc32_data* builtins with 0x1EDC6F41 poylnomial and -mcrc32.
PR target/120719
gcc/ChangeLog:
* config/i386/i386.md (crc_revsi4): New expander.
gcc/testsuite/ChangeLog:
* gcc.target/i386/crc-builti
The CFI output for when we do stack probing in a loop were not
accounting for the first sp adjustments, we can fix that by using the
frame's total size.
This is already being tested by g++.dg/torture/pr119610.C.
gcc/ChangeLog:
gcc/config/riscv/riscv.cc
(riscv_allocate_and_probe_sta
On 26/06/2025 15:35, Robin Dapp wrote:
This is a followup to 92e1893e0 "RISC-V: Add patterns for vector-scalar
multiply-(subtract-)accumulate" that caused an ICE in some cases where
the mult
operands were wrongly swapped.
This patch ensures that operands are not swapped in the vector-scalar
ca
On 6/13/25 12:40, 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/accessors/default.cc: New test.
Signed-off-by: Luc Grosheintz
---
This patch converts the fold-mem-offsets pass from DF to RTL-SSA.
Along with this conversion, the way the pass collects information
was completely reworked. Instead of visiting each instruction multiple
times, this is now down only once.
Most significant changes are:
* The pass operates mainly on
This is a followup to 92e1893e0 "RISC-V: Add patterns for vector-scalar
multiply-(subtract-)accumulate" that caused an ICE in some cases where the mult
operands were wrongly swapped.
This patch ensures that operands are not swapped in the vector-scalar case.
This looks reasonable, so OK for the
On Thu, 26 Jun 2025 at 14:19, Tomasz Kamiński wrote:
>
> This patch extract calls to _M_locale_fmt and construction of the struct tm,
> from the functions dedicated to each specifier, to main format loop in
> _M_format_to functions. This removes duplicated code repeated for specifiers.
>
> To allo
This patch extract calls to _M_locale_fmt and construction of the struct tm,
from the functions dedicated to each specifier, to main format loop in
_M_format_to functions. This removes duplicated code repeated for specifiers.
To allow _M_locale_fmt to only be called if localized formatting is enab
This patch reworks the formatting for the chrono types, such that they are all
formatted in terms of _ChronoData class, that includes all required fields.
Populating each required field is performed in formatter for specific type,
based on the chrono-spec used.
To facilitate above, the _ChronoSpec
Currently, GCC accepts an allocate clause (to use a specific memory
allocator and alignment) on the OpenMP target construct, but it has no
effect - memory is always allocated with the defaults.
This patch causes memory for privatized variables (i.e. variables in
private and firstprivate clause
On Thu, 26 Jun 2025 at 13:52, Tomasz Kaminski wrote:
>
>
>
> On Thu, Jun 26, 2025 at 2:26 PM Jonathan Wakely wrote:
>>
>> On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
>> >This patch reworks the formatting for the chrono types, such that they are
>> >all
>> >formatted in terms of _ChronoData c
On Thu, Jun 26, 2025 at 2:52 PM Jonathan Wakely wrote:
> On Thu, 26 Jun 2025 at 13:30, Tomasz Kaminski wrote:
> >
> >
> >
> > On Thu, Jun 26, 2025 at 2:13 PM Tomasz Kaminski
> wrote:
> >>
> >>
> >>
> >> On Thu, Jun 26, 2025 at 2:09 PM Jonathan Wakely
> wrote:
> >>>
> >>> On 26/06/25 11:39 +020
On Thu, 26 Jun 2025 at 11:35, Jakub Jelinek wrote:
>
> On Wed, Jun 25, 2025 at 08:20:55PM +0100, Jonathan Wakely wrote:
> > This won't work for -fno-rtti
>
> I've missed the || __cpp_exceptions part in there, thought it is &&.
>
> Here is an updated patch which uses just one definition of
> std::e
On Thu, 26 Jun 2025 at 13:30, Tomasz Kaminski wrote:
>
>
>
> On Thu, Jun 26, 2025 at 2:13 PM Tomasz Kaminski wrote:
>>
>>
>>
>> On Thu, Jun 26, 2025 at 2:09 PM Jonathan Wakely wrote:
>>>
>>> On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
>>> >This patch extract calls to _M_locale_fmt and constr
On Thu, 26 Jun 2025 at 11:33, Jakub Jelinek wrote:
>
> On Wed, Jun 25, 2025 at 10:58:59PM +0200, Maciej Cencora wrote:
> > update of std module is missing.
>
> Here is an updated patch which adds the std module part and while I was
> changing the patch, I've also added value_type/type and the 2 op
+ bool is_misaligned = scalar_align < inner_vectype_sz;
+ bool is_packed = scalar_align > 1 && is_misaligned;
+
+ *misalignment = !is_misaligned ? 0 : inner_vectype_sz -
scalar_align;
+
+ if (targetm.vectorize.support_vector_misalignment
+ (TYPE_MODE (vectype), inner_
Hi @Jeff Lawand all,
Please have a look at the below changes that were suggested and tested.
Thank you
~U
On Fri, Jun 13, 2025 at 8:31 PM Umesh Kalappa
wrote:
> Addressed the most of comments and tried to refactor the
> riscv_expand_conditional_move() to some extent.
>
> No regressions are
On Thu, Jun 26, 2025 at 2:13 PM Tomasz Kaminski wrote:
>
>
> On Thu, Jun 26, 2025 at 2:09 PM Jonathan Wakely
> wrote:
>
>> On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
>> >This patch extract calls to _M_locale_fmt and construction of the struct
>> tm,
>> >from the functions dedicated to each
On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
This patch reworks the formatting for the chrono types, such that they are all
formatted in terms of _ChronoData class, that includes all required fields.
Populating each required field is performed in formatter for specific type,
based on the chron
On Thu, Jun 26, 2025 at 12:31 PM Tomasz Kamiński
wrote:
> This patch extract calls to _M_locale_fmt and construction of the struct
> tm,
> from the functions dedicated to each specifier, to main format loop in
> _M_format_to functions. This removes duplicated code repeated for
> specifiers.
>
> T
Hi Andre,
I used a clean build directory but don't recall if I reconfigured. I was 10
minutes away from leaving for the airport! I'll try again when I am back at
base.
Please, everyone else, don't hesitate to review and test.
Regards
Paul
On Tue, 24 Jun 2025, 23:47 Andre Vehreschild, wrote:
On Thu, Jun 26, 2025 at 2:09 PM Jonathan Wakely wrote:
> On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
> >This patch extract calls to _M_locale_fmt and construction of the struct
> tm,
> >from the functions dedicated to each specifier, to main format loop in
> >_M_format_to functions. This remo
On 26/06/25 11:39 +0200, Tomasz Kamiński wrote:
This patch extract calls to _M_locale_fmt and construction of the struct tm,
from the functions dedicated to each specifier, to main format loop in
_M_format_to functions. This removes duplicated code repeated for specifiers.
Great, this is exactl
On Wed, Jun 25, 2025 at 04:29:41PM -0400, Jason Merrill wrote:
> > (and
> > whether perhaps cp_build_addr_expr isn't undesirable for that case, because
> > that can make vars odr-used etc.; are are odr uses in unevaluated context
> > also supposed to make vars odr-used?).
>
> That's fine, mark_use
Richard Biener writes:
> The following fixes the computation of supports_partial_vectors which
> is used to prune the set of modes to iterate over for epilog
> vectorization. The used partial_vectors_supported_p predicate
> only looks for while_ult while also support predication when
> mask modes
Richard Biener writes:
> The following avoids re-analyzing the loop as epilogue when not
> using partial vectors and the mode is the same as the autodetected
> vector mode and that has a too high VF for a non-predicated loop.
> This situation occurs almost always on x86 and saves us one
> re-analy
On Wed, Jun 25, 2025 at 08:20:55PM +0100, Jonathan Wakely wrote:
> This won't work for -fno-rtti
I've missed the || __cpp_exceptions part in there, thought it is &&.
Here is an updated patch which uses just one definition of
std::exception_ptr_cast and additionally exports it from std.cc.in as we
On Wed, Jun 25, 2025 at 10:58:59PM +0200, Maciej Cencora wrote:
> update of std module is missing.
Here is an updated patch which adds the std module part and while I was
changing the patch, I've also added value_type/type and the 2 operators
to std::type_order.
Interdiff from the last patch is:
Hi,
fold_ctor_reference already punts on a CONSTRUCTOR whose type has reverse
storage order, but it can be invoked in a couple of places on a CONSTRUCTOR
with native storage order that has been wrapped in a VIEW_CONVERT_EXPR to a
type with reverse storage order; this would require a post adjust
This patch extract calls to _M_locale_fmt and construction of the struct tm,
from the functions dedicated to each specifier, to main format loop in
_M_format_to functions. This removes duplicated code repeated for specifiers.
To allow _M_locale_fmt to only be called if localized formatting is enab
This is now series of two patches, that aim to reduce compilation times
for chrono formatting:
* first patch implements formatting of chrono types in terms of single
_ChronoData type, instead of instantiating it for all calendar types
* second patch deduplicates localized chrono formatting code,
This patch reworks the formatting for the chrono types, such that they are all
formatted in terms of _ChronoData class, that includes all required fields.
Populating each required field is performed in formatter for specific type,
based on the chrono-spec used.
To facilitate above, the _ChronoSpec
> On 24 Jun 2025, at 7:43 pm, Jan Hubicka wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
> this pass removes early-inlining from afdo pass since all inlining
> should now happen from early inliner. I tedted this on spec and there
> are 3 inlines happening here
Thanks for spotting this.
Filip
On Wed 2025-06-25 16:03:20, Martin Jambor wrote:
> Hi,
>
> It is customary to mark the gate and execute functions of the classes
> representing passes as final override but this is missing in
> pass_sccopy. This patch adds it which also silences clang warnings
>
The following avoids re-analyzing the loop as epilogue when not
using partial vectors and the mode is the same as the autodetected
vector mode and that has a too high VF for a non-predicated loop.
This situation occurs almost always on x86 and saves us one
re-analysis unless --param vect-partial-ve
The following fixes the computation of supports_partial_vectors which
is used to prune the set of modes to iterate over for epilog
vectorization. The used partial_vectors_supported_p predicate
only looks for while_ult while also support predication when
mask modes are integer modes as for AVX512.
This patch adds a comment to the riscv.md file to clarify the purpose of
the file and reorders the include files for better organization.
gcc/ChangeLog:
* config/riscv/riscv.md: Add comment and reorder include
files.
---
gcc/config/riscv/riscv.md | 19 +++
1 file
Hi,
On Thu, Jun 26 2025, Michal Jireš wrote:
> On 6/25/25 4:14 PM, Martin Jambor wrote:
>> Hi,
>>
>> when building GCC with clang, it warns that the private member suffix
>> in class ltrans_file_cache (defined in lto-ltrans-cache.h) is not used
>> which indeed looks like it is the case. This pat
Pipeline checker utility for RISC-V architecture that validates processor
pipeline models. This tool analyzes machine description files to ensure all
instruction types are properly handled by pipeline scheduling models.
I write this tool since I am implment vector pipeline stuff for SiFive
core, b
Hi Harald,
thanks for the review. Pushed all three parts as gcc-16-1698-g24940ad1534.
A backport to gcc-15 of the first part of the patch, aka this one, seems to be
feasible. I'd like to give the patch a bit time to mature here in gcc-16 and
backport in about a week, when I do not forget it.
Tha
On 6/25/25 4:14 PM, Martin Jambor wrote:
Hi,
when building GCC with clang, it warns that the private member suffix
in class ltrans_file_cache (defined in lto-ltrans-cache.h) is not used
which indeed looks like it is the case. This patch therefore removes
it along with its initialization in the
The following prototypes diagnostics for conversions to/from time_t
where the source/destination does not have sufficient precision for it.
I've lumped this into -Wconversion for the moment and didn't bother
fixing up the testcase for !ilp32 or the -Wconversion diagnostics that
happen.
Would -Wtim
Hi Thomas,
> I have a few questions.
>
> First, I see that your patch series does not use gfortran's descriptors
> for accessing coarrays via shared memory, as the original work by
> Nicolas did. Can you comment on that?
The ABI for invoking coarray functionality is sufficient for doing the job
Hi All,
The following patch has been bootstrapped and regtested on powerpc64le-linux.
While building GCC with --with-build-config=bootstrap-ubsan on
powerpc64le-unknown-linux-gnu, multiple UBSAN runtime errors were
encountered in rs6000.cc and rs6000.md due to undefined behavior
involving left sh
Hi Jerry,
thanks for testing. I have fixed IMO most of the whitespace issues in the
patch attached to this mail:
https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html
About the 32 vs. 64 bit versions of the libraries: I never got in touch with
that. I am doing the same as for caf_single. In
dfp.exp tests for dfprt before deciding whether to default to run or
compile, and the PR120631 tests override that without checking for
dfprt. Rework them to avoid attempting to link and run programs
when dfp runtime support isn't available.
Tested on x86_64-linux-gnu, and, with gcc-14, on aarc
Hi,
This patch fixes some of cases where we lose profile info because we do not
perform inlining that happened at train run before AFDO annotation is done.
This is a common problem with LTO in the case cross-module inlining happened.
I added afdo_offline pass that does two things:
1) collect set
95 matches
Mail list logo
