On Thu, 29 May 2025, 03:00 Patrick Palka, wrote:
> std::erase_if for flat_map / flat_multimap is implemented via
> ranges::erase_if over a zip_view of the keys and values, the value_type
> of which is a tuple, but the given predicate needs to be called with a
> pair. So use a projection to conve
This patch adjust the passing of parameters for the move_only_function,
copyable_function and function_ref. For types that are declared as being passed
by value in signature template argument, they are passed by value to the
invoker,
when they are small (at most two pointers), trivially move const
On Wed, May 28, 2025 at 9:20 PM Patrick Palka wrote:
> Change in this version:
>
> * Add test using an integer-class distance type, based on views::iota.
>
> -- >8 --
>
> This implements ranges::starts_with and ranges::ends_with from the C++23
> paper P1659R3. The logic of these algorithms is
On Tue, Apr 22, 2025 at 01:27:34PM +0200, Richard Biener wrote:
> This is OK for trunk after we've released GCC 15.1.
This change broke build on non-USING_MMAP hosts.
I don't have access to one, so I've just added #undef USING_MMAP
before first use of that macro after the definitions.
There were
On Thu, May 29, 2025 at 4:01 AM Patrick Palka wrote:
> std::erase_if for flat_map / flat_multimap is implemented via
> ranges::erase_if over a zip_view of the keys and values, the value_type
> of which is a tuple, but the given predicate needs to be called with a
> pair. So use a projection to c
Hi Honza,
> On 26 May 2025, at 5:28 pm, Jan Hubicka wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>> Ping?
> Sorry for the delay. I think I finally got auto-fdo running on my box
> and indeed I see that if function is cloned later, the profile is lost.
> There a
pushed to trunk :)
On Thu, May 29, 2025 at 1:19 PM Jiawei wrote:
>
> Add support of double trap extension [1], enabling GCC
> to recognize the following extensions at compile time.
>
> New extensions:
> - ssdbltrp
> - smdbltrp
>
> [1]
> https://github.com/riscv/riscv-double-trap/releases
`--enable-default-pie` is an option to specify whether to enable
position-independent executables by default for `target`.
However c++tools is build for `host`, so it should just follow
`--enable-host-pie` option to determine whether to build with
position-independent executables or not.
NOTE:
I
Separate the build rules to compile and link stage to make sure
BUILD_LINKERFLAGS and BUILD_LDFLAGS are applied correctly.
We hit this issue when we try to build GCC with non-system-default g++,
and it use newer libstdc++, and then got error from using older libstdc++ from
system, that should not
This commit implements a full-featured iterator for the
riscv_subset_list, that it able to use range-based-for-loop.
That could simplfy the code in the future, and make it more readable,
also more compatible with standard C++ containers.
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_cp
On Mon, May 26, 2025 at 1:40 PM Andrew Pinski wrote:
> > Note this is redundant store removal - I'm not sure operand_equal_p
> > is good enough to catch all cases of effective type changes done?
> > Esp. as infering the old effective type from the read side (src2)
> > is impossible in principle.
Add support of double trap extension [1], enabling GCC
to recognize the following extensions at compile time.
New extensions:
- ssdbltrp
- smdbltrp
[1]
https://github.com/riscv/riscv-double-trap/releases/download/v1.0/riscv-double-trap.pdf
gcc/ChangeLog:
* config/riscv/riscv-ext
This patch fixes the typo in the test case `param-autovec-mode.c` in the
RISC-V autovec testsuite.
The option `autovec-mode` is changed to `riscv-autovec-mode` to match the
expected parameter name.
OK of course :)
--
Regards
Robin
Hi All,
The following patch has been bootstrapped and regtested on powerpc64le-linux.
Changes from V2:
Replaced eight consecutive spaces with tabs in amo6.c and amo7.c.
Changes from V1:
Corrected the ISA version in the test cases.
Changes to amo.h include the addition of the following load atom
Hi Tobias and Harald,
I sincerely apologize for the breakage! I did test both preprocessor branches,
but I tested against the same MPFR version (4.2.2, which is the latest on Arch
Linux). Going forward, I will test against versions both above and below 4.2.0
to ensure this type of breakage doesn't
Add support of double trap extension [1], enabling GCC
to recognize the following extensions at compile time.
New extensions:
- ssdbltrp
- smdbltrp
[1]
https://github.com/riscv/riscv-double-trap/releases/download/v1.0/riscv-double-trap.pdf
gcc/ChangeLog:
* config/riscv/riscv-ext.d
在 2025/5/29 0:13, Jeff Law 写道:
On 5/28/25 4:23 AM, Jiawei wrote:
This patch adds a peephole2 optimization that combines a 'bclr'
followed by
a 'binv' into a single 'bset' instruction when the Zbs extension is
enabled.
The motivation for this patch is that PR116398 limits 2→2 RTL
combinat
std::erase_if for flat_map / flat_multimap is implemented via
ranges::erase_if over a zip_view of the keys and values, the value_type
of which is a tuple, but the given predicate needs to be called with a
pair. So use a projection to convert the tuple into the corresponding
pair type.
PR
This patch fixes the typo in the test case `param-autovec-mode.c` in the RISC-V
autovec testsuite.
The option `autovec-mode` is changed to `riscv-autovec-mode` to match the
expected parameter name.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/param-autovec-mode.c: Change
On Wed, May 21, 2025, at 8:59 PM, Pietro Monteiro wrote:
> Autoreconf -Wall complains about obsolete macros, so replace them according to
> the autoconf documentation[0].
>
> This patch doesn't fully fix all warnings because I focused on doing simple
> fixes and keeping the changes to the generated
Looks good.
Eugene
-Original Message-
From: Kugan Vivekanandarajah
Sent: Wednesday, May 28, 2025 3:59 PM
To: gcc-patches@gcc.gnu.org
Cc: Jan Hubicka ; Eugene Rozenfeld
Subject: [EXTERNAL] [PATCH] [AUTOFDO] Enable autofdo tests for aarch64
Hi,
autofdo tests are now running only for x8
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Typically "does this class have a trivial destructor" is the wrong question
to ask, we rather want "can I destroy this class trivially", thus the
std::is_trivially_destructible standard trait. Let's provide a builtin for
it, and complain ab
The patch looks good to me.
Thanks,
Eugene
From: Kugan Vivekanandarajah
Sent: Sunday, May 25, 2025 9:48 PM
To: Andrew Pinski
Cc: Richard Sandiford ; Andi Kleen
; gcc-patches@gcc.gnu.org; Eugene Rozenfeld
Subject: [EXTERNAL] Re: [AUTOFDO][AARCH64] Add support for profilebootstrap
> On 26
On Fri, May 23, 2025 at 10:12 PM Andrew Pinski wrote:
>
> 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
Hi,
autofdo tests are now running only for x86. This patch makes it
run for aarch64 too. Verified that perf and create_gcov are running
as expected.
gcc/ChangeLog:
* config/aarch64/gcc-auto-profile: Make script executable.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Enab
Hi,
since uses of addss for other purposes then modelling FP addition/subtraction
should
be gone now, this patch sets addss cost back to 2.
Bootsrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
PR target/119298
* config/i386/x86-tune-costs.h (struct processor_costs): Set
Hi Tobias,
On 5/28/25 22:46, Tobias Burnus wrote:
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3:
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3: error: 'mpfr_fmod_ui'
was not declared in this scop
On Mon, May 26, 2025 at 1:40 PM Andrew Pinski wrote:
>
> On Mon, May 26, 2025 at 5:36 AM Richard Biener
> wrote:
> >
> > On Sun, May 18, 2025 at 10:58 PM Andrew Pinski
> > wrote:
> > >
> > > This implements a simple copy propagation for aggregates in the similar
> > > fashion as we already do f
Change in this version:
* Add test using an integer-class distance type, based on views::iota.
-- >8 --
This implements ranges::starts_with and ranges::ends_with from the C++23
paper P1659R3. The logic of these algorithms is contained in an _S_impl
member function that takes optional size par
On 5/28/25 19:51, Tobias Burnus wrote:
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_e
On 5/28/25 10:09 AM, Steve Kargl wrote:
On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Yes, with one question.
commit 845768cbead03f76265e491bcf5ea6de7020
On Sat, 24 May 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
LGTM FWIW
>
> -- >8 --
>
> When emitting a primary module interface, we must re-stream any TU-local
> entities that we saw in a partition. This patch adds the missing
> members fr
On Thu, 22 May 2025, Nathaniel Shead wrote:
> This patch series adds support for streaming some internal declarations
> in C++20 modules that we previously would ICE on.
I like this patch series a lot, thanks for working on it! I can't
approve but it looks pretty good to me.
>
> The series h
On Tue, 27 May 2025, Nathaniel Shead wrote:
> On Wed, Nov 27, 2024 at 11:45:40AM -0500, Patrick Palka wrote:
> > On Fri, 8 Nov 2024, Nathaniel Shead wrote:
> >
> > > Does this approach seem reasonable? I'm pretty sure that the way I've
> > > handled the templating here is unideal but I'm not sur
This patch would like to introduce the combine of vec_dup + vmul.vv into
vmul.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, 15
in test. There will be two cases for the combine:
OK.
--
Regards
Robin
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
Give the `define_insn` rules used in lowering `cbranch4` to RTL
more descriptive and consistent names: from now on, each rule is named
after the AArch64 instruction that it generates. Also add comments to
document each rule.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): Rename to
Extract the hardcoded values for the minimum PC-relative displacements
into named constants and document them.
gcc/ChangeLog:
* config/aarch64/aarch64.md (BRANCH_LEN_P_128MiB): New constant.
(BRANCH_LEN_N_128MiB): Likewise.
(BRANCH_LEN_P_1MiB): Likewise.
(BRANCH_LE
The CB family of instructions does not support using the CS or CC
condition codes; instead the synonyms HS and LO must be used. GCC has
traditionally used the CS and CC names. To work around this while
avoiding test churn, add new `j` and `J` format specifiers and use them
when generating CB instru
Move the rules for CBZ/TBZ to be above the rules for
CBB/CBH/CB. We want them to have higher priority
because they can express larger displacements.
gcc/ChangeLog:
* config/aarch64/aarch64.md (aarch64_cbz1): Move
above rules for CBB/CBH/CB.
(*aarch64_tbz1): Likewise.
gcc/
Hi Jerry!
On 5/28/25 17:11, Jerry D wrote:
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
This LGTM.
Thanks for the patch!
Harald
Regards,
Jerry
The rules for conditional branches were spread throughout `aarch64.md`.
Group them together so it is easier to understand how `cbranch4`
is lowered to RTL.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): Move.
(*compare_condjump): Likewise.
(aarch64_cb1): Likewise.
The `far_branch` attribute only ever takes the values 0 or 1, so make it
a `no/yes` valued string attribute instead.
gcc/ChangeLog:
* config/aarch64/aarch64.md (far_branch): Replace 0/1 with
no/yes.
(aarch64_bcond): Handle rename.
(aarch64_cbz1): Likewise.
Add rules for lowering `cbranch4` to CBB/CBH/CB when
CMPBR extension is enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.md (BRANCH_LEN_P_1Kib): New constant.
(BRANCH_LEN_N_1Kib): Likewise.
(cbranch4): Emit CMPBR instructions if possible.
(cbranch4): New expand rul
Add the `+cmpbr` option to enable the FEAT_CMPBR architectural
extension.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (cmpbr): New
option.
* config/aarch64/aarch64.h (TARGET_CMPBR): New macro.
* doc/invoke.texi (cmpbr): New option.
---
gcc/config
Commit the test file `cmpbr.c` before rules for generating the new
instructions are added, so that the changes in codegen are more obvious
in the next commit.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add `cmpbr` to the list of extensions.
* gcc.target/aarch64/cmpbr.c: N
Yes, Steve I have it backward. I will fix it before commit.
On Wed, May 28, 2025, 10:15 AM Steve Kargl
wrote:
> On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
> > The attached patch is simple and self explanatory in the git log entry.
> >
> > Regression tested on X86_64-linux-gnu.
> >
Make the formatting of the RTL templates in the rules for branch
instructions more consistent with each other.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): Reformat.
(cbranchcc4): Likewise.
(condjump): Likewise.
(*compare_condjump): Likewise.
(aar
* Added a commit to use HS/LO instead of CS/CC mnemonics.
* Rewrite the range checks for immediate RHSes in aarch64.cc: CBGE,
CBHS, CBLE and CBLS have different ranges of allowed immediates than
the other comparisons
Karl Meakin (10):
AArch64: place branch instruction rules together
AArch
Sorry for the slow reply, had a few days off.
Xi Ruoyao writes:
> If we see a promoted subreg and TRULY_NOOP_TRUNCATION says the
> truncation is not a noop, then all bits of the inner reg are live. We
> cannot reduce the live mask to that of the mode of the subreg.
>
> gcc/ChangeLog:
>
> P
On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote:
> The attached patch is simple and self explanatory in the git log entry.
>
> Regression tested on X86_64-linux-gnu.
>
> OK for trunk?
>
Yes, with one question.
> commit 845768cbead03f76265e491bcf5ea6de7020ff39
> Author: Jerry DeLisle
>
Sandra Loosemore wrote:
The new testcase included in this patch used to ICE in gcc after
diagnosing the first error, and in g++ it only diagnosed the error in
the first metadirective, ignoring the second one. The solution is to
make error recovery in the C front end more like that in the C++ fro
Richard Biener writes:
> On Thu, May 22, 2025 at 12:19 PM Richard Sandiford
> wrote:
>>
>> As the rtl.texi documentation of RTX_AUTOINC expressions says:
>>
>> If a register used as the operand of these expressions is used in
>> another address in an insn, the original value of the register i
Sandra Loosemore wrote:
It's not clear whether a metadirective in a loop nest is supposed to
be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it
as an error.
gcc/c/ChangeLog
PR c/120180
* c-parser.cc (c_parser_omp_metadirective): Only consume the
token i
On 5/28/25 4:23 AM, Jiawei wrote:
This patch adds a peephole2 optimization that combines a 'bclr' followed by
a 'binv' into a single 'bset' instruction when the Zbs extension is enabled.
The motivation for this patch is that PR116398 limits 2→2 RTL combinations,
which prevents certain simplif
On Mai 28 2025, John Paul Adrian Glaubitz wrote:
> Shouldn't the #undef in linux.h undefine DEFAULT_PCC_STRUCT_RETURN and not
> PCC_STATIC_STRUCT_RETURN?
No, they are separate target options. PCC_STATIC_STRUCT_RETURN is no
longer defined by default, so this is redundant now.
> And, secondly, sh
Hi Tobias,
> you will notice that the PR is not recognized. The format as mentioned before
> is "PR component/number". Namely:
Thanks for the reminder! I'll use `-p` to double-check PR numbers going
forward.
> The second part is not what you are doing, you are actually changing the
> call from
On Wed, 28 May 2025, Tomasz Kaminski wrote:
>
>
> On Wed, May 28, 2025 at 4:53 PM Patrick Palka wrote:
> On Wed, 28 May 2025, Tomasz Kamiński wrote:
>
> > This patch adjust the passing of parameters for the
> move_only_function,
> > copyable_function and function_ref. For ty
This patch adjust the passing of parameters for the move_only_function,
copyable_function and function_ref. For types that are declared as being passed
by value in signature template argument, they are passed by value to the
invoker,
when they are small (at most two pointers), trivially move const
On Wed, May 28, 2025 at 4:53 PM Patrick Palka wrote:
> On Wed, 28 May 2025, Tomasz Kamiński wrote:
>
> > This patch adjust the passing of parameters for the move_only_function,
> > copyable_function and function_ref. For types that are declared as being
> passed
> > by value in signature template
On Wed, May 28, 2025 at 5:14 PM Tomasz Kaminski wrote:
>
>
> On Wed, May 28, 2025 at 4:53 PM Patrick Palka wrote:
>
>> On Wed, 28 May 2025, Tomasz Kamiński wrote:
>>
>> > This patch adjust the passing of parameters for the move_only_function,
>> > copyable_function and function_ref. For types th
From: Pan Li
Add asm dump check test for vec_duplicate + vmul.vv combine to vmul.vx,
with the GR2VR cost is 0, 1 and 2.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-4-i16.c: Add as
From: Pan Li
Add asm dump check test for vec_duplicate + vmul.vv combine to vmul.vx,
with the GR2VR cost is 0, 2 and 15.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vx-1-i16.c: Add a
The attached patch is simple and self explanatory in the git log entry.
Regression tested on X86_64-linux-gnu.
OK for trunk?
Regards,
Jerrycommit 845768cbead03f76265e491bcf5ea6de7020ff39
Author: Jerry DeLisle
Date: Wed May 28 07:56:12 2025 -0700
Fortran: Adjust handling of optional com
From: Pan Li
This patch would like to combine the vec_duplicate + vmul.vv to the
vmul.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 the
From: Pan Li
This patch would like to introduce the combine of vec_dup + vmul.vv into
vmul.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, 15
in test. There will be two cases for the combine:
Case 0:
| .
The new testcase included in this patch used to ICE in gcc after
diagnosing the first error, and in g++ it only diagnosed the error in
the first metadirective, ignoring the second one. The solution is to
make error recovery in the C front end more like that in the C++ front
end, and remove the cod
This group of patches are for some lingering problems with
metadirective, which was a relatively late addition to GCC 15. The
first two address ICE-after-invalid problems in the C and C++ front
ends, and I think are suitable for backport to the GCC 15 branch as
well as trunk. The third patch addr
It's not clear whether a metadirective in a loop nest is supposed to
be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it
as an error.
gcc/c/ChangeLog
PR c/120180
* c-parser.cc (c_parser_omp_metadirective): Only consume the
token if it is the expected ')'.
Tobias had noted that the C front end was not treating C23 constexprs
as constant in the user/condition selector property, which led to
missed opportunities to resolve metadirectives at parse time.
Additionally neither C nor C++ was permitting the expression to have
pointer or floating-point type -
On Wed, 28 May 2025, Tomasz Kamiński wrote:
> This patch adjust the passing of parameters for the move_only_function,
> copyable_function and function_ref. For types that are declared as being
> passed
> by value in signature template argument, the are passed by value to the
> invoker,
they
>
On Wed, May 28, 2025 at 4:27 PM Patrick Palka wrote:
>
> >
> >
> > On Tue, May 20, 2025 at 6:32 PM Patrick Palka wrote:
> > On Tue, 20 May 2025, Tomasz Kaminski wrote:
> >
> > > I think I do not have any more suggestions for cases to check,
> so the impl LGTM.
> >
> > It's cool
I have reviewed and posted feedback up to, but not including layout_stride
today.
Will try to finish tomorrow.
Thank you again for continuous work on the patches.
On Tue, May 27, 2025 at 4:40 PM Tomasz Kaminski wrote:
>
>
> On Tue, May 27, 2025 at 4:32 PM Luc Grosheintz
> wrote:
>
>> Since, I b
On Mon, May 26, 2025 at 4:13 PM Luc Grosheintz
wrote:
> Adds tests for layout_right and for the parts of layout_left that depend
> on layout_right.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
> tests for layout_stride.
>
>
>
> On Tue, May 20, 2025 at 6:32 PM Patrick Palka wrote:
> On Tue, 20 May 2025, Tomasz Kaminski wrote:
>
> > I think I do not have any more suggestions for cases to check, so the
> impl LGTM.
>
> It's cool how many optimizations we came up with for this algorithm :)
>
>
On Mon, May 26, 2025 at 4:15 PM Luc Grosheintz
wrote:
> Implement the parts of layout_left that depend on layout_right; and the
> parts of layout_right that don't depend on layout_stride.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan (layout_right): New class.
> * src/c++23
This is just a rebase of the v1 patch, currently waiting on a conclusion
of the discussion here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682033.html
Tested as a series on aarch64-linux-gnu and x86_64-linux-gnu. OK for
trunk?
Thanks,
Alex
-- >8 --
This adjusts scale_profile_for_vec
This is a v2. v1 was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.html
Changes since v1:
- Made epilog profile update code more resilient against
already-inconsistent profiles (e.g. PR120065), avoid ICEing in such a
situation.
Bootstrapped/regtested as a seri
Hi!
This is a v2 of the patch originally posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
It addresses Honza's feedback in this mail:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681119.html
It was approved with the requested changes above, but it only real
On Wed, May 28, 2025 at 3:00 PM 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 f
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
> operator[] isn't the only opera
We somehow missed to implement these OpenACC 2.6 functions (the
Fortran routines are newer: 3.3). It is actually used, at least,
by two SPEC hpc/accel (soma + lbm) tests (and OpenACC_VV) - and
it was trivial to implement, which was my workaround to make them
compile.
Besides adding the same-devic
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest reply on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Tuesday, April 22, 2025 9:34 PM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Djordje Todoro
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest reply on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Tuesday, April 22, 2025 9:00 PM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Djordje Todoro
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest reply on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Wednesday, April 23, 2025 1:08 PM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Djordje Todo
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest reply on this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Wednesday, May 14, 2025 3:55 PM
To: Jeff Law; gcc-patches@gcc.gnu.org
Cc: Djordje Todoro
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest version of this patch?
Kind regards,
Aleksandar Rakic
From: Aleksandar Rakic
Sent: Wednesday, May 14, 2025 4:06 PM
To: Sam James; Xi Ruoyao
Cc: Jeff Law; gcc-patches@gcc
On Wed, 28 May 2025, Icen Zeyada wrote:
> Hi Richard,
> I've implemented some of your suggested changes, but I'm not entirely sure
> there's an elegant way to handle the second one:
> > "So here you'd want to verify we can to LT_EXPR for the types involved, and
> > the cases which simplify to co
Hi Richard,
I've implemented some of your suggested changes, but I'm not entirely sure
there's an elegant way to handle the second one:
> "So here you'd want to verify we can to LT_EXPR for the types involved, and
> the cases which simplify to constant_boolean_node do not need any such check.
>
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Jan Hubicka
> Sent: Wednesday, May 28, 2025 3:52 PM
> To: Gorantla, Pranav
> Cc: gcc-patches@gcc.gnu.org; Kumar, Venkataramanan
> ; ubiz...@gmail.com
> Subject: Re: [PATCH] i386: Use Shuffles instead of
Hi,
with normal profile feedback checking entry block count to be non-zero is quite
reliable check for presence of non-0 profile in the body since the function
body can only be executed if the entry block was executed. With autofdo this
is not true, since the entry block may just execute too few t
On Mon, May 26, 2025 at 4:15 PM Luc Grosheintz
wrote:
> Implements the parts of layout_left that don't depend on any of the
> other layouts.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan (layout_left): New class.
> * src/c++23/std.cc.in: Add layout_left.
>
> Signed-off-by:
> I thought this issue should be fixed when we implement those
> implication rules correctly? Does march=rv32imaf_zca/mabi=ilp32 still
> not able select march=rv32imac/mabi=ilp32 still happen after this[1]
> patch?
>
> [1]
> https://github.com/gcc-mirror/gcc/commit/42ce61eaefc4db70e2e7ea2d8ef091d
On Mon, May 26, 2025 at 4:06 PM Luc Grosheintz
wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan(__mdspan::_ExtentsStorage): Change name
> of private member _M_dynamic_extens to _M_dyn_exts.
> * include/std/mdspan(extents): Change name of private member
> f
Hi Yuta-san
> On 23 May 2025, at 07:49, Yuta Mukai (Fujitsu) wrote:
>
> Hello,
>
> We would like to enable features for FUJITSU-MONAKA that were implemented in
> GCC after we added support for FUJITSU-MONAKA.
> As the features were implemented in GCC15, we also want to backport it to
> GCC15.
This patch adjust the passing of parameters for the move_only_function,
copyable_function and function_ref. For types that are declared as being passed
by value in signature template argument, the are passed by value to the invoker,
when they are small (at most two pointers), trivially move constru
These are needed to correctly mangle FMV declarations.
gcc/ChangeLog:
* cgraph.h (struct cgraph_node): Add dispatcher_resolver_function and
is_target_clone.
---
gcc/cgraph.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
Alejandro Colomar writes:
> [...]
> diff --git a/gcc/testsuite/gcc.dg/countof-vla.c
> b/gcc/testsuite/gcc.dg/countof-vla.c
> new file mode 100644
> index ..cc225df20689
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/countof-vla.c
> @@ -0,0 +1,35 @@
> +/* { dg-do compile } */
> +/* { dg
On Wed, 28 May 2025, Thomas Schwinge wrote:
> Hi!
>
> On 2025-05-28T09:18:29+0200, Richard Biener wrote:
> > On Tue, 27 May 2025, Thomas Schwinge wrote:
> >> "'GIMPLE_RETURN' vs. 'RESULT_DECL' if 'aggregate_value_p'" isn't actually
> >> a GIMPLE semantics invariant, thanks. I conclude that in c
1 - 100 of 136 matches
Mail list logo
