another
> mode instead of re-loading the value in the other mode and for SRA to
> decide whether MODE is suitable as container holding a value to be
> used in different modes.
>
> ...
>
> +@deftypefn {Target Hook} bool TARGET_MODE_CAN_TRANSFER_BITS (machine_mode
> @va
On 7/30/24 7:01 AM, Lulu Cheng wrote:
在 2024/7/26 下午8:43, Xi Ruoyao 写道:
We already had "si3_extend" insns and we hoped the fwprop or combine
passes can use them to remove unnecessary sign extensions. But this
does not always work: for cases like x << 1 | y, the compiler
tends to do
On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
wrote:
>
> Hello!
>
> The attached patch implements adds support for P2591R5 in libstdc++
> (concatenation of strings and string_views, approved in Tokyo for C++26).
Thanks for this patch as well. This was on my TODO list so I'll be
happy to not
On Mon, 29 Jul 2024 at 21:58, Giuseppe D'Angelo wrote:
>
> Hi,
>
> And this is the corresponding change libstdc++.
Thanks for the patch. Do you have a copyright assignment for GCC in
place, or are you covered by a corporate assignment for KDAB?
If not, please complete that process, or contribute
On Tue, Jul 30, 2024 at 03:00:49PM +0200, Richard Biener wrote:
> As Jakub said the padding is already dealt with in the caller
> though I only added that there for convenience since padding is
> problematic in general.
>
> If you think XFmode is safe to transfer 10 bytes we could enable it,
> I
在 2024/7/26 下午8:43, Xi Ruoyao 写道:
We already had "si3_extend" insns and we hoped the fwprop or combine
passes can use them to remove unnecessary sign extensions. But this
does not always work: for cases like x << 1 | y, the compiler
tends to do
(sign_extend:DI
(ior:SI (ashift:SI
On Tue, 30 Jul 2024, Alexander Monakov wrote:
>
> On Tue, 30 Jul 2024, Richard Biener wrote:
>
> > > Oh, and please add a small comment why we don't use XFmode here.
> >
> > Will do.
> >
> > /* Do not enable XFmode, there is padding in it and it suffers
> >from
On Tue, 30 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 30, 2024 at 03:43:25PM +0300, Alexander Monakov wrote:
> >
> > On Tue, 30 Jul 2024, Richard Biener wrote:
> >
> > > > Oh, and please add a small comment why we don't use XFmode here.
> > >
> > > Will do.
> > >
> > > /* Do not
On Tue, Jul 30, 2024 at 03:43:25PM +0300, Alexander Monakov wrote:
>
> On Tue, 30 Jul 2024, Richard Biener wrote:
>
> > > Oh, and please add a small comment why we don't use XFmode here.
> >
> > Will do.
> >
> > /* Do not enable XFmode, there is padding in it and it suffers
> >
On Tue, 30 Jul 2024, Richard Biener wrote:
> > Oh, and please add a small comment why we don't use XFmode here.
>
> Will do.
>
> /* Do not enable XFmode, there is padding in it and it suffers
>from normalization upon load like SFmode and DFmode when
>not using
On Tue, 30 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 30, 2024 at 02:26:05PM +0200, Richard Biener wrote:
> > > > (Which implies that we should introduce TARGET_I387_MATH to parallel
> > > > TARGET_SSE_MATH some day...)
> > > >
> > > > > + default:
> > > > > + return false;
> > > >
>
Prathamesh Kulkarni wrote:
Thanks for your suggestions on RFC email, the attached patch adds support for
streaming of poly_int when it's degree <= accel's NUM_POLY_INT_COEFFS.
First, thanks a lot for your patch!
Secondly, it seems as if this patch is indented to fully or partially
fix the
On Tue, Jul 30, 2024 at 02:26:05PM +0200, Richard Biener wrote:
> > > (Which implies that we should introduce TARGET_I387_MATH to parallel
> > > TARGET_SSE_MATH some day...)
> > >
> > > > + default:
> > > > + return false;
> > >
> > > We don't want to enable HFmode for transfers?
>
>
On Tue, 30 Jul 2024, Filip Kastl wrote:
> > > > Ah, I see you fix those up. Then 2.) is left - the final block. Iff
> > > > the final block needs adjustment you know there was a path from
> > > > the default case to it which means one of its predecessors is dominated
> > > > by the default
On Tue, 30 Jul 2024, Uros Bizjak wrote:
> On Tue, Jul 30, 2024 at 1:07 PM Uros Bizjak wrote:
> >
> > On Tue, Jul 30, 2024 at 12:18 PM Richard Biener wrote:
> > >
> > > The following implements the hook, excluding x87 modes for scalar
> > > and complex float modes.
> > >
> > > Bootstrapped and
> Meanwhile I'll look into source code of the rest of the switch conversion
> pass.
> Switch conversion pass inserts conditions similar to what I'm doing so someone
> before me may have already solved how to properly fix dominators in this
> situation.
Oh nevermind. Switch conversion
> > > Ah, I see you fix those up. Then 2.) is left - the final block. Iff
> > > the final block needs adjustment you know there was a path from
> > > the default case to it which means one of its predecessors is dominated
> > > by the default case? In that case, adjust the dominator to cond_bb,
Jennifer Schmitz writes:
> As suggested in
> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658249.html,
> this patch changes the instruction attribute of "*and_compare0" (TST)
> from
> alus_imm to logics_imm.
>
> The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression.
Hi Jennifer,
> On 30 Jul 2024, at 09:47, Jennifer Schmitz wrote:
>
> Dear Richard,
> Thanks for the feedback. Great to see this patch approved! I made the changes
> as suggested.
> Best,
> Jennifer
> <0001-SVE-intrinsics-Add-strength-reduction-for-division-b.patch>
Thanks, I’m okay with the
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, July 30, 2024 3:16 PM
> To: Richard Biener
> Cc: Richard Sandiford ; Prathamesh Kulkarni
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it'
On Tue, Jul 30, 2024 at 1:07 PM Uros Bizjak wrote:
>
> On Tue, Jul 30, 2024 at 12:18 PM Richard Biener wrote:
> >
> > The following implements the hook, excluding x87 modes for scalar
> > and complex float modes.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > OK?
> >
> >
Richard Biener writes:
> The following adds a target hook to specify whether regs of MODE can be
> used to transfer bits. The hook is supposed to be used for value-numbering
> to decide whether a value loaded in such mode can be punned to another
> mode instead of re-loadi
Jakub Jelinek writes:
> On Tue, Jul 30, 2024 at 11:25:42AM +0200, Richard Biener wrote:
>> Only "relevant" stuff should be streamed - the offload code and all
>> trees refered to.
>
> Yeah.
>
>> > > I think all current issues are because of poly-* leaking in for cases
>> > > where a non-poly
On Tue, Jul 30, 2024 at 12:18 PM Richard Biener wrote:
>
> The following implements the hook, excluding x87 modes for scalar
> and complex float modes.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> * i386.cc (TARGET_MODE_CAN_TRANSFER_BITS):
On Sat, Jul 27, 2024 at 4:29 AM Andrew Pinski wrote:
>
> While working on isel, I found that the current way of doing
> current_properties
> in function can easily make a mistake and having to do stuff like `(a & b )
> == 0`
> and `a |= b;` and `a &= ~b;` is not so obvious what was going on.
>
On Tue, Jul 30, 2024 at 12:22:01PM +0200, Richard Biener wrote:
> On Mon, Jul 29, 2024 at 5:15 PM Alejandro Colomar wrote:
> >
> > The old name was misleading.
> >
> > While at it, also rename some temporary variables that are used with
> > this function, for consistency.
> >
> > Link:
> >
but need
gcc/cp/ChangeLog:
etc.
The changes look good to me, please leave the frontend maintainers time to
chime in. Also Jakub had reservations with the renaming because of
branch maintainance. I think if that proves an issue we could backport the
renaming as well, or make sure that array_t
On Tue, 30 Jul 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, July 18, 2024 10:00 AM
> > To: Tamar Christina
> > Cc: GCC Patches ; Richard Sandiford
> >
> > Subject: RE: [RFC][middle-end
On Tue, Jul 30, 2024 at 11:25:42AM +0200, Richard Biener wrote:
> Only "relevant" stuff should be streamed - the offload code and all
> trees refered to.
Yeah.
> > > I think all current issues are because of poly-* leaking in for cases
> > > where a non-poly would have worked fine, but I have
gt;> >>
> >> >> > -Original Message-
> >> >> > From: Richard Sandiford
> >> >> > Sent: Monday, July 29, 2024 9:43 PM
> >> >> > To: Richard Biener
> >> >> > Cc: Prathamesh Kul
; >> > From: Richard Sandiford
>> >> > Sent: Monday, July 29, 2024 9:43 PM
>> >> > To: Richard Biener
>> >> > Cc: Prathamesh Kulkarni ; gcc-
>> >> > patc...@gcc.gnu.org
>> >> > Subject: Re: Support streami
On Sun, 24 Mar 2024 at 21:34, Björn Schäpers wrote:
>
> From: Björn Schäpers
>
> This fixes i.e. https://github.com/msys2/MSYS2-packages/issues/1937
> I don't know if I picked the right way to do it.
>
> When acceptable I think the declaration should be moved into
> ops-common.h, since then we
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 18, 2024 10:00 AM
> To: Tamar Christina
> Cc: GCC Patches ; Richard Sandiford
>
> Subject: RE: [RFC][middle-end] SLP Early break and control flow support in GCC
>
> On Wed, 17 Jul
uly 29, 2024 9:43 PM
> >> > To: Richard Biener
> >> > Cc: Prathamesh Kulkarni ; gcc-
> >> > patc...@gcc.gnu.org
> >> > Subject: Re: Support streaming of poly_int for offloading when it's
> >> > degree <= accel's NUM_POLY_INT_COEFFS
&g
On Tue, Jul 30, 2024 at 5:08 AM wrote:
>
> From: Pan Li
>
> For some target like target=amdgcn-amdhsa, we need to take care of
> vector bool types prior to general vector mode types. Or we may have
> the asm check failure as below.
>
> gcc.target/gcn/cond_smax_1.c scan-assembler-times
Richard Biener writes:
> On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
>
>>
>>
>> > -Original Message-
>> > From: Richard Sandiford
>> > Sent: Monday, July 29, 2024 9:43 PM
>> > To: Richard Biener
>> > Cc: Prathamesh Kul
On Mon, Jul 29, 2024 at 9:26 PM Tobias Burnus wrote:
>
> The problem is code like:
>
>MEM [(c_char * {ref-all})]
>
> where arr2 is the value expr '*arr2$13$linkptr'
> (i.e. indirect ref + decl name).
>
> Insidepass_omp_target_link::execute, there is a call to
> gimple_regimplify_operands but
Richard Biener writes:
> On Mon, 29 Jul 2024, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Mon, 29 Jul 2024, Jakub Jelinek wrote:
>> >> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL
>> >> vectors,
>> >> I think those should be considered as true by the hook,
On Tue, 30 Jul 2024, 06:21 Ehrnsperger, Markus,
wrote:
> On 2024-07-29 12:16, Jonathan Wakely wrote:
>
> > On Mon, 29 Jul 2024 at 10:45, Jonathan Wakely
> wrote:
> >> On Mon, 29 Jul 2024 at 09:42, Ehrnsperger, Markus
> >> wrote:
> >>> Hi,
> >>>
> >>>
> >>> I'm attaching two files:
> >>>
> >>>
Dear Richard,
Thanks for the feedback. Great to see this patch approved! I made the changes
as suggested.
Best,
Jennifer
0001-SVE-intrinsics-Add-strength-reduction-for-division-b.patch
Description: Binary data
> On 29 Jul 2024, at 22:55, Richard Sandiford wrote:
>
> External email: Use
On Tue, 30 Jul 2024, Prathamesh Kulkarni wrote:
>
>
> > -Original Message-
> > From: Richard Sandiford
> > Sent: Monday, July 29, 2024 9:43 PM
> > To: Richard Biener
> > Cc: Prathamesh Kulkarni ; gcc-
> > patc...@gcc.gnu.org
>
On Mon, 29 Jul 2024, Filip Kastl wrote:
> Hi Richard,
>
> > > Sorry, I'm not sure if I understand. Are you suggesting something like
> > > this?
> > >
> > > if (idom(default bb) == cond bb)
> > > {
> > > if (exists a path from default bb to final bb)
> > > {
> > > idom(final bb) =
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, July 30, 2024 2:57 PM
> To: Hongtao Liu
> Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
> Liu, Hongtao ; ubiz...@gmail.com
> Subject: Re: [PATCH v2] i386: Add non-optimize prefetchi intrins
>
> On
On Mon, 29 Jul 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> >> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
> >> I think those should be considered as true by the hook, not false
> >> because maybe_ne.
> >
On Tue, Jul 30, 2024 at 09:28:46AM +0800, Hongtao Liu wrote:
> On Tue, Jul 30, 2024 at 9:27 AM Hongtao Liu wrote:
> >
> > On Fri, Jul 26, 2024 at 4:55 PM Haochen Jiang
> > wrote:
> > >
> > > Hi all,
> > >
> > > I added related O0 testcase in this patch.
> > >
> > > Ok for trunk and backport to
Committed, thanks Robin.
Pan
-Original Message-
From: Robin Dapp
Sent: Tuesday, July 30, 2024 2:28 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; Robin
Dapp
Subject: Re: [PATCH v1] RISC-V: Take Xmode instead of Pmode
OK.
--
Regards
Robin
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, July 29, 2024 9:43 PM
> To: Richard Biener
> Cc: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_PO
On Tue, Jul 23, 2024 at 5:52 PM Takayuki 'January June' Suwa
wrote:
>
> According to the implemented pipeline model, this cost can be assumed to be
> 1 clock cycle.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xtensa_insn_cost):
> Add a case statement for TYPE_FARITH.
On Tue, Jul 23, 2024 at 5:52 PM Takayuki 'January June' Suwa
wrote:
>
> We would like to implement the following to store a single-precision FP
> constant in a hardware FP register:
>
> - Load the bit-exact integer image of the pooled single-precision FP
>constant into an address (integer)
On Fri, Jul 19, 2024 at 1:35 PM Takayuki 'January June' Suwa
wrote:
>
> It is not wrong but also not optimal to specify that sibcalls require
> register A0 in RTX generation pass, by misleading DFA into thinking it
> is being used in function body.
> It would be better to specify it in
On 2024-07-29 12:16, Jonathan Wakely wrote:
On Mon, 29 Jul 2024 at 10:45, Jonathan Wakely wrote:
On Mon, 29 Jul 2024 at 09:42, Ehrnsperger, Markus
wrote:
Hi,
I'm attaching two files:
1.: to_chars10.h:
This is intended to be included in libstdc++ / gcc to achieve performance
Richard Biener 于2024年7月26日周五 19:45写道：
>
> On Fri, Jul 26, 2024 at 10:50 AM Hongyu Wang wrote:
> >
> > Hi,
> >
> > When introducing munroll-only-small-loops, the option was marked as
> > Target Save and added to -O2 default which makes attribute(optimize)
> > resets target option and causing
LGTM, thanks :)
On Tue, Jul 30, 2024 at 10:53 AM Patrick O'Neill wrote:
>
> This patch removes the zabha configure check since it's not a breaking change
> and updates the existing zaamo/zalrsc comment.
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc
>
;
richard.guent...@gmail.com; tamar.christ...@arm.com; jeffreya...@gmail.com;
rdapp@gmail.com
Subject: Re: [PATCH v1] Internal-fn: Handle vector bool type for type strict
match mode [PR116103]
pan2...@intel.com writes:
> From: Pan Li
>
> For some target like target=amdgcn-amdhsa,
on 2024/7/29 23:47, Peter Bergner wrote:
> On 7/29/24 5:21 AM, Kewen.Lin wrote:
>> on 2024/7/27 06:37, Carl Love wrote:
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/powerpc/vec-shift-double-runnable-int128.c
>>> @@ -0,0 +1,358 @@
>>> +/* { dg-do run { target power10_hw } } */
>>> +/* {
On Tue, Jul 30, 2024 at 9:27 AM Hongtao Liu wrote:
>
> On Fri, Jul 26, 2024 at 4:55 PM Haochen Jiang wrote:
> >
> > Hi all,
> >
> > I added related O0 testcase in this patch.
> >
> > Ok for trunk and backport to GCC 14 and GCC 13?
> Ok.
I mean for trunk, and it needs jakub's approval to backport
On Fri, Jul 26, 2024 at 4:55 PM Haochen Jiang wrote:
>
> Hi all,
>
> I added related O0 testcase in this patch.
>
> Ok for trunk and backport to GCC 14 and GCC 13?
Ok.
>
> Thx,
> Haochen
>
> ---
>
> Changes in v2: Add testcases.
>
> ---
>
> Under -O0, with the "newly" introduced intrins, the
On Jul 29, 2024, Alexandre Oliva wrote:
> - auto status = f1.wait_for(wait_time);
> + auto status __attribute__ (__unused__) = f1.wait_for(wait_time);
Sorry, it looks like I posted the patch before refreshing it. Make it:
+ auto status __attribute__ ((__unused__)) =
On Sun, Jul 14, 2024 at 4:05 AM Takayuki 'January June' Suwa
wrote:
>
> They were once mistakenly removed with
> "xtensa: Remove old broken tweak for leaf function", but caused unwanted
> register spills.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.h (LEAF_REGISTERS, LEAF_REG_REMAP):
>
On Sun, Jul 14, 2024 at 4:05 AM Takayuki 'January June' Suwa
wrote:
>
> [U]FLOAT.S machine instruction in Xtensa ISA, which converts an integer to
> a hardware single-precision FP register, has the ability to divide the
> result by power of two (0 to 15th).
>
> Similarly, [U]TRUNC.S instruction,
On Sun, Jul 14, 2024 at 4:05 AM Takayuki 'January June' Suwa
wrote:
>
> No functional changes.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc
> (gen_int_relational, gen_float_relational): Replace tempvar-based
> value-swapping codes with std::swap.
> *
Jason Merrill writes:
> I don't know what all-caps BUILTIN_SOURCE_LOCATION refers to specifically (it
> doesn't match CP_BUILT_IN_SOURCE_LOCATION, for instance); let's just refer to
> source_location.
ACK - will reword.
> On 7/29/24 8:20 AM, Arsen Arsenović wrote:
>> This fixes the value of
Jason Merrill writes:
> On 7/29/24 8:18 AM, Arsen Arsenović wrote:
>> When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it
>> fails to account for the fact that FUNCTION_DECLs might be present, and
>> later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check
>>
On 7/29/24 4:18 PM, Marek Polacek wrote:
On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote:
On 7/17/24 5:33 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
Hmm, I thought I had replied to this already.
-- >8 --
Unfortunately, my r15-1946
On 7/29/24 2:13 PM, Richard Sandiford wrote:
Sorry for the slow reply!
Slow?!? I think I sent that Thu/Fri last week. Nothing to be sorry
about at all in my mind!
No, I agree it looks like a bug. Seems like:
if (outermode == innermostmode
&& known_eq (byte, 0U)
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote:
> > On Fri, 26 Jul 2024, Jakub Jelinek wrote:
> >
> > > On Fri, Jul 26, 2024 at 04:42:36PM -0400, Patrick Palka wrote:
> > > > > // P2963R3 - Ordering of constraints involving fold
Thanks for doing this.
Jennifer Schmitz writes:
> [...]
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/div_s32.c
> b/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/div_s32.c
> index c49ca1aa524..6500b64c41b 100644
> --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/asm/div_s32.c
>
Sorry for the slow review.
Pengxuan Zheng writes:
> This patch improves the Advanced SIMD popcount expansion by using SVE if
> available.
>
> For example, GCC currently generates the following code sequence for V2DI:
> cnt v31.16b, v31.16b
> uaddlp v31.8h, v31.16b
> uaddlp v31.4s,
On 30/01/24 17:00 -0500, Lennox Ho wrote:
std::filesystem::hard_link_count() always returns 1 on
mingw-w64ucrt-11.0.1-r3 on Windows 10 19045
hard_link_count() queries _wstat64() on MinGW-w64
The MSFT documentation claims _wstat64() will always return 1 *non*-NTFS volumes
On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote:
> On 7/17/24 5:33 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> Hmm, I thought I had replied to this already.
>
> > -- >8 --
> > Unfortunately, my r15-1946 fix broke the attached
Sorry for the slow reply!
Jeff Law writes:
> We don't really have a good place for discussions anymore other than
> gcc-patches, but this really isn't a patch.. Oh well.
>
>
> I'm debugging a failure of ext-dce on a big endian target (m68k) and I
> can't help but think it's actually exposed a
On 7/29/24 8:18 AM, Arsen Arsenović wrote:
This is a partial fix for PR115906. Per [expr.await] 2s3, "An
await-expression shall not appear in a default argument
([dcl.fct.default])". This patch introduces the diagnostic in that
case, and in the case of a co_yield (as co_yield is defined in
On 7/29/24 8:18 AM, Arsen Arsenović wrote:
When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it
fails to account for the fact that FUNCTION_DECLs might be present, and
later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check
failure in DECL_HAS_VALUE_EXPR_P:
Am 29.07.2024 um 19:58 schrieb Eli Zaretskii:
From: Ian Lance Taylor
Date: Mon, 29 Jul 2024 09:46:46 -0700
Cc: Eli Zaretskii , gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
Date: Tue, 9 Jan 2024
I don't know what all-caps BUILTIN_SOURCE_LOCATION refers to
specifically (it doesn't match CP_BUILT_IN_SOURCE_LOCATION, for
instance); let's just refer to source_location.
On 7/29/24 8:20 AM, Arsen Arsenović wrote:
This fixes the value of current_function in compiler generated coroutine
On 7/29/24 11:38 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk and perhaps 14.3? It should only make a differenc
for C++20 code where lambdas are permitted as template arguments.
OK for both.
-- >8 --
Here we're rejecting the
On Fri, 2024-03-15 at 13:02 +, Jonathan Wakely wrote:
> OK for trunk?
LGTM, thanks
Dave
>
> -- >8 --
>
> The hyphen can be misunderstood to mean "emitted to -" i.e. stdout.
> Refer to both forms by name, rather than using "the former" for one
> and
> referring to the other by name.
>
>
On 7/29/24 07:42, Will Hawkins wrote:
> If the user provides a kind value that is more than 5 bits, the
> BTF_KIND_INFO macro would emit incorrect values for info (by clobbering
> values of the kind flag).
>
> Tested on x86_64-redhat-linux.
OK, thanks.
>
> include/ChangeLog:
>
> *
> From: Ian Lance Taylor
> Date: Mon, 29 Jul 2024 09:46:46 -0700
> Cc: Eli Zaretskii , gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
>
> On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
> >
> > Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> > >> Date: Tue, 9 Jan 2024 21:02:44 +0100
> > >> Cc:
I'm going to revert the patch for now. There are two problems:
- The new tests don't have a unique name so the caching confuses
the results.
- To test with -O2 we need explicit musttail checks because tail call doesn't
run with -O0 w/o musttail.
On Fri, Mar 15, 2024 at 1:41 PM Björn Schäpers wrote:
>
> Am 10.01.2024 um 13:34 schrieb Eli Zaretskii:
> >> Date: Tue, 9 Jan 2024 21:02:44 +0100
> >> Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> >> From: Björn Schäpers
> >>
> >> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
Richard Biener writes:
> On Mon, 29 Jul 2024, Jakub Jelinek wrote:
>> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors,
>> I think those should be considered as true by the hook, not false
>> because maybe_ne.
>
> I don't think relevant modes will have size/precision
Richard Biener writes:
> On Mon, 29 Jul 2024, Prathamesh Kulkarni wrote:
>
>> Hi Richard,
>> Thanks for your suggestions on RFC email, the attached patch adds support
>> for streaming of poly_int when it's degree <= accel's NUM_POLY_INT_COEFFS.
>> The patch changes streaming of poly_int as
ments to file-io-diff"
> > +}
> > +if { $nargs == 1 } {
> > + set file1 [lindex $args 0]
> > + set file2 "${file1}.txt"
> > + append file1 ".tst"
> > +} else {
> > + set file1 [lindex $args 0]
> > +
pan2...@intel.com writes:
> From: Pan Li
>
> For some target like target=amdgcn-amdhsa, we need to take care of
> vector bool types prior to general vector mode types. Or we may have
> the asm check failure as below.
>
> gcc.target/gcn/cond_smax_1.c scan-assembler-times \\tv_cmp_gt_i32\\tvcc,
> ..., that means that a number of the new test cases are UNSUPPORTED, for
> example, x86_64 GNU/Linux:
>
> +UNSUPPORTED: c-c++-common/musttail1.c -Wc++-compat
> +UNSUPPORTED: c-c++-common/musttail12.c -Wc++-compat
> +PASS: c-c++-common/musttail13.c -Wc++-compat (test for
On 7/29/24 5:21 AM, Kewen.Lin wrote:
> on 2024/7/27 06:37, Carl Love wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/vec-shift-double-runnable-int128.c
>> @@ -0,0 +1,358 @@
>> +/* { dg-do run { target power10_hw } } */
>> +/* { dg-do link { target { ! power10_hw } } } */
>> +/*
Hi Richard,
> > Sorry, I'm not sure if I understand. Are you suggesting something like
> > this?
> >
> > if (idom(default bb) == cond bb)
> > {
> > if (exists a path from default bb to final bb)
> > {
> > idom(final bb) = cond bb;
> > }
> > else
> > {
> > idom(final bb) =
Kewen:
On 7/29/24 3:21 AM, Kewen.Lin wrote:
index 0d3e0a24e11..75d95ccfb47 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -26,7 +26,8 @@
;; Vector int modes
(define_mode_iterator VEC_I [V16QI V8HI V4SI V2DI])
-;; Vector int modes for comparison, shift and
On Mon, Jul 29, 2024 at 11:20 AM Jeff Law wrote:
>
>
>
> On 7/29/24 6:18 AM, Raphael Zinsly wrote:
> > On Fri, Jul 26, 2024 at 6:48 PM Jeff Law wrote:
> >>
> >>
> >>
> >> On 7/24/24 12:00 PM, Raphael Moreira Zinsly wrote:
> >>> Adds basic support to vector stack-clash protection using a loop to
On 7/29/24 6:18 AM, Raphael Zinsly wrote:
On Fri, Jul 26, 2024 at 6:48 PM Jeff Law wrote:
On 7/24/24 12:00 PM, Raphael Moreira Zinsly wrote:
Adds basic support to vector stack-clash protection using a loop to do
the probing and stack adjustments.
gcc/ChangeLog:
*
On 7/29/24 06:12, Tobias Burnus wrote:
I recently stumbled over omp_get_default_device returning -1 (=
omp_initial_device)
vs. returning omp_get_num_devices(). Thus, it makes sense to document
this properly.
I also updated some wording and made a tiny step to documenting the
missing functions
Dear Richard,
I revised the patch according to your comments and also implemented the
transform for unsigned division; more comments inline below.
The new patch was bootstrapped and tested again.
Looking forward to your feedback.
Thanks,
Jennifer
On 17 Jul 2024, at 09:29, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jennifer Schmitz writes:
>> This patch series is part of an ongoing effort to replace the SVE intrinsic
>> svdiv
>> by lower-strength instructions for division by constant.
> > This API is intended to provide the capability to query minimal common
> > available extensions on the system.
> >
> > Proposal in riscv-c-api-doc:
> > https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74
>
> That's not merged, but I'm not sure what the rules are on stability for
> the C
On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote:
> On Fri, 26 Jul 2024, Jakub Jelinek wrote:
>
> > On Fri, Jul 26, 2024 at 04:42:36PM -0400, Patrick Palka wrote:
> > > > // P2963R3 - Ordering of constraints involving fold expressions
> > > > // { dg-do compile { target c++20 } }
> >
LGTM, although I said no binutils check for zacas and zabha, but B is
a different situation since GCC will add that if zba, zbb and zbs are
all present.
On Thu, Jul 25, 2024 at 7:51 AM Edwin Lu wrote:
>
> Binutils 2.42 and before don't recognize the B extension in the march
> strings even
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > > mode = GET_MODE_INNER (mode);
> > > ?
> >
> > I specifically wanted to avoid this (at least for the purpose of the
> > hook).
> >
> > > I mean say XCmode has similar problems as
On Mon, Jul 29, 2024 at 02:59:58PM +0200, Jakub Jelinek wrote:
> On Mon, Jul 29, 2024 at 02:52:24PM +0200, Richard Biener wrote:
> > > mode = GET_MODE_INNER (mode);
> > > ?
> >
> > I specifically wanted to avoid this (at least for the purpose of the
> > hook).
> >
> > > I mean say XCmode has
1 - 100 of 224463 matches
Mail list logo
