On 2023/6/8 10:27, Lulu Cheng wrote:
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch prediction.
Therefore, a problem like PR110136 can cause a sign
LGTM. Let's wait for Jeff and Robin. After this patch, we can start FP16
autovec.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-08 14:29
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v8] RISC-V: Refactor requirement of ZVFH and
Sure, update it in PATCH v8.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621016.html
Pan
From: juzhe.zh...@rivai.ai
Sent: Thursday, June 8, 2023 2:09 PM
To: Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ; Li,
Pan2 ; Wang, Yanzhang
Subject: Re: [PATCH v7] RISC-V: Refactor requir
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. By default, the ZVFHMIN will enable FP16 for all the
iterators of RVV. And then the ZVFH will leverage one function as
the gate for FP16 supported or not.
Please note the ZVFH will cover the ZVFHMIN inst
Hi Jeff,
Yes that one has changed; I changed the implementation based on your feedback.
Thanks,
Manolis
On Thu, Jun 8, 2023 at 1:18 AM Jeff Law wrote:
>
>
>
> On 5/25/23 06:35, Manolis Tsamis wrote:
> > Propagation of the stack pointer in cprop_hardreg is currenty forbidden
> > in all cases, du
Rename float_point_mode_supported_p into float_mode_supported_p
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-08 14:06
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang
Subject: [PATCH v7] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.
From: Pan Li
This
Update the PATCH v7 (please help to ignore v6) for this change, thanks Juzhe
for the suggestion.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621012.html
Pan
From: Li, Pan2
Sent: Wednesday, June 7, 2023 4:43 PM
To: juzhe.zh...@rivai.ai; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ;
Wang,
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. By default, the ZVFHMIN will enable FP16 for all the
iterators of RVV. And then the ZVFH will leverage one function as
the gate for FP16 supported or not.
Please note the ZVFH will cover the ZVFHMIN inst
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
I should perhaps have remarked that, following the divide error,
gfc_simplify_expr was returning a mutilated version of
> Am 07.06.2023 um 18:59 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> We have expand_doubleword_clz for a couple of years, where we emit
> double-word CLZ as if (high_word == 0) return CLZ (low_word) + word_size;
> else return CLZ (high_word);
> We can do something similar for CTZ a
> Am 07.06.2023 um 18:52 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> I'm getting
> +FAIL: gcc.target/i386/3dnow-1.c (internal compiler error: Segmentation fault
> signal terminated program cc1)
> +FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
> +FAIL: gcc.target/i386/3d
On 5/25/23 06:35, Manolis Tsamis wrote:
Implementation of the new RISC-V optimization pass for memory offset
calculations, documentation and testcases.
gcc/ChangeLog:
* config.gcc: Add riscv-fold-mem-offsets.o to extra_objs.
* config/riscv/riscv-passes.def (INSERT_PASS_AFTER)
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. By default, the ZVFHMIN will enable FP16 for all the
iterators of RVV. And then the ZVFH will leverage one function as
the gate for FP16 supported or not.
Please note the ZVFH will cover the ZVFHMIN inst
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch prediction.
Therefore, a problem like PR110136 can cause a significant increase in branch
error
predi
From: Ju-Zhe Zhong
Co-authored-by: Richard Sandiford
Co-authored-by: Richard Biener
This patch address comments from Richard && Richi and rebase to trunk.
This patch is adding SELECT_VL middle-end support
allow target have target dependent optimization in case of
length calculation.
This patc
Hi,
This patch checks if a constant is possible left/right cleaned on a rotated
value from a negative value of "li/lis". If so, we can build the constant
through "li/lis ; rldicl/rldicr".
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeLog:
*
Hi,
This patch checks if a constant is possible to be rotated to/from a negative
value from "lis". If so, we could use "lis;rotldi" to build it.
The positive value of "lis" does not need to be analyzed. Because if a
constant can be rotated from the positive value of "lis", it also can be
rotated
Hi,
This patch checks if a constant is possible to be built by "li;rldic".
We only need to take care of "negative li", other forms do not need to check.
For example, "negative lis" is just a "negative li" with an additional shift.
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
B
Hi,
This patch checks if a constant is possible to be rotated to/from a positive
or negative value from "li". If so, we could use "li;rotldi" to build it.
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeLog:
* config/rs6000/rs6000.cc (can_be_r
Hi,
These patches are just minor changes based on previous version/comments.
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611286.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620489.html
And also update the wording for patches in this series.
For a given constant, it would b
ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619951.html
Ref:
http://patchwork.ozlabs.org/project/gcc/patch/20230323080734.423-1-ji...@linux.alibaba.com/
On 6/1/23 20:38, Vineet Gupta wrote:
Hi Jeff,
I finally got around to collecting various observations on PR/109279 -
more importantly the state of large constants in RV backend, apologies
in advance for the long email.
It seems the various commits in area have improved the original test
On Wed, Jun 7, 2023 at 4:11 PM Jeff Law wrote:
>
>
>
> On 6/7/23 17:05, Andrew Pinski wrote:
> > On Wed, Jun 7, 2023 at 3:57 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
> >>> Since there is a pattern to convert `(-zero_one) & z`
On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
This adds plus to the op list of `(zero_one == 0) ? y : z y` patterns
which currently has bit_ior and bit_xor.
This shows up now in GCC after the boolization work that Uroš has been doing.
OK? Bootstrapped and tested on x86_64-linux-gnu w
On 6/7/23 17:05, Andrew Pinski wrote:
On Wed, Jun 7, 2023 at 3:57 PM Jeff Law via Gcc-patches
wrote:
On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
already,
it is better if we don't do a secondary transform
This minor tweak to the nvptx backend switches the representation of
of the brev instruction from an UNSPEC to instead use the new BITREVERSE
rtx. This allows various RTL optimizations including evaluation (constant
folding) of integer constant arguments at compile-time.
This patch has been test
On Wed, Jun 7, 2023 at 3:57 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
> > Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
> > already,
> > it is better if we don't do a secondary transformation. This reduces the
> >
On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
already,
it is better if we don't do a secondary transformation. This reduces the extra
statements produced by match-and-simplify on the gimple level too.
gcc/Chang
Richard Sandiford was, of course, right to be warry of new code without
much test coverage. Converting the nvptx backend to use the BITREVERSE
rtx infrastructure, has resulted in far more exhaustive testing and
revealed a subtle bug in the new wi::bitreverse implementation. The
code needs to use
On 6/7/23 15:32, Andrew Pinski via Gcc-patches wrote:
This allows unsigned types if the inner type where the negation is
located has greater than or equal to precision than the outer type.
branchless-cond.c needs to be updated since now we change it to
use a multiply rather than still having
On 5/25/23 06:35, Manolis Tsamis wrote:
Propagation of the stack pointer in cprop_hardreg is currenty forbidden
in all cases, due to maybe_mode_change returning NULL. Relax this
restriction and allow propagation when no mode change is requested.
gcc/ChangeLog:
* regcprop.cc (maybe_m
On 5/31/23 06:15, Manolis Tsamis wrote:
On Thu, May 25, 2023 at 4:38 PM Jeff Law wrote:
On 5/25/23 06:35, Manolis Tsamis wrote:
Propagation of the stack pointer in cprop_hardreg is currenty forbidden
in all cases, due to maybe_mode_change returning NULL. Relax this
restriction and allow
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Now that we support NRV from an inner block, we can also support non-NRV
returns from other blocks, since once the NRV is out of scope a later return
expression can't possibly alias it.
This fixes 58487 and half-fixes 53637: now one of the
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Are you suggesting to use identifier directly as the argument of the
> attribute?
> I tried this in the beginning, however, the current parser for the attribute
> argument can not identify that this identifier is a field identifier inside
>
This adds plus to the op list of `(zero_one == 0) ? y : z y` patterns
which currently has bit_ior and bit_xor.
This shows up now in GCC after the boolization work that Uroš has been doing.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/97711
Since there is a pattern to convert `(-zero_one) & z` into `zero_one * z`
already,
it is better if we don't do a secondary transformation. This reduces the extra
statements produced by match-and-simplify on the gimple level too.
gcc/ChangeLog:
* match.pd (`zero_one ==/!= 0) ? y : z y`):
This allows unsigned types if the inner type where the negation is
located has greater than or equal to precision than the outer type.
branchless-cond.c needs to be updated since now we change it to
use a multiply rather than still having (-a)&c in there.
OK? Bootstrapped and tested on x86_64-lin
> On Jun 7, 2023, at 4:53 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Hi, Joseph,
>>
>> A question here: can an identifier in C be a wide char string?
>
> Identifiers and strings are different kinds of tokens; an identifier can't
> be a string of
The patterns match more than just `a & 1` so change the comment
for these two patterns to say that.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd: Fix comment for the
`(zero_one ==/!= 0) ? y : z y` patterns.
---
gcc/match.pd | 4 ++--
On 6/7/23 08:06, Andrew Pinski wrote:
On Sun, Jun 4, 2023 at 10:43 AM Jeff Law via Gcc-patches
wrote:
With Vlad's recent LRA fix to the elimination code, the H8 can be
converted to LRA.
Could you update the h8300 entry on https://gcc.gnu.org/backends.html
for this change?
Thanks for the r
On 6/7/23 08:43, Jeff Law wrote:
On 6/7/23 08:13, Kito Cheng wrote:
I would like vendor cpu name start with vendor name, like
ventana-veyron-v1 which is consistent with all other vendor cpu, and
llvm are using same convention too.
Fair enough. Better to get it right now than have this stu
On 6/6/23 14:29, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
In the second testcase of PR110122, during regeneration of the generic
lambda with V=Bar{}, substitution followed by coerce_template_parms for
A's template argument nat
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Hi, Joseph,
>
> A question here: can an identifier in C be a wide char string?
Identifiers and strings are different kinds of tokens; an identifier can't
be a string of any kind, wide or narrow. It just so happens that the
proposed inte
On 6/7/23 13:15, Dimitar Dimitrov wrote:
On Tue, Jun 06, 2023 at 08:38:14PM -0600, Jeff Law wrote:
Regression tested for riscv32-none-elf. No changes in gcc.sum and
g++.sum. I don't have setup to test riscv64.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_print_operand): Calcula
On 5/24/23 17:14, Jivan Hakobyan via Gcc-patches wrote:
Subject:
[RFC] RISC-V: Eliminate extension after for *w instructions
From:
Jivan Hakobyan via Gcc-patches
Date:
5/24/23, 17:14
To:
gcc-patches@gcc.gnu.org
`This patch tries to prevent generating unnecessary sign extension
after *w inst
On Wed, 7 Jun 2023 at 18:26, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023, 18:17 Jakub Jelinek via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
>
>> Hi!
>>
>> This test apparently contains 3 problematic floating point constants,
>> 1e126, 4.91e-6 and 5.547e-6. These constants suffer from doub
Hi, Joseph,
A question here: can an identifier in C be a wide char string?
Qing
> On May 26, 2023, at 2:15 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>>> What if the string is a wide string? I don't expect that to work (either
>>> as a matter of in
Andrew Stubbs writes:
> On 30/05/2023 07:26, Richard Biener wrote:
>> On Fri, May 26, 2023 at 4:35 PM Andrew Stubbs wrote:
>>>
>>> Hi all,
>>>
>>> I want to implement a vector DIVMOD libfunc for amdgcn, but I can't just
>>> do it because the GCC middle-end models DIVMOD's return value as
>>> "com
On Tue, Jun 06, 2023 at 08:38:14PM -0600, Jeff Law wrote:
>
>
> > Regression tested for riscv32-none-elf. No changes in gcc.sum and
> > g++.sum. I don't have setup to test riscv64.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.cc (riscv_print_operand): Calculate
> > memmodel only
On Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote:
> Hi FX,
>
> On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > Hi,
> >
> > > I cannot see if there is proper support for kind=17 in your patch;
> > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> >
Hi Paul!
On 6/7/23 18:10, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the .diff
Hi FX,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously w
On Wed, 7 Jun 2023, 18:17 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi!
>
> This test apparently contains 3 problematic floating point constants,
> 1e126, 4.91e-6 and 5.547e-6. These constants suffer from double rounding
> when -fexcess-precision=standard evaluates double con
Hi!
This test apparently contains 3 problematic floating point constants,
1e126, 4.91e-6 and 5.547e-6. These constants suffer from double rounding
when -fexcess-precision=standard evaluates double constants in the precision
of Intel extended 80-bit long double.
As written in the PR, e.g. the firs
On Jun 7, 2023, at 8:01 AM, Thomas Schwinge wrote:
> On 2020-12-08T13:46:32-0700, Martin Sebor via Gcc-patches
> wrote:
>> The attached changes [...]
>
> ... eventually became commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
> "Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++
On Jun 7, 2023, at 7:54 AM, Thomas Schwinge wrote:
>
> On 2020-11-03T16:56:48-0700, Martin Sebor via Gcc-patches
> wrote:
>> Attached is a simple middle end implementation of detection of
>> mismatched pairs of calls to C++ new and delete, along with
>> a substantially enhanced implementation o
On Jun 7, 2023, at 1:12 AM, Alexandre Oliva wrote:
>
> Several tests are timing out when targeting x86-*-vxworks with qemu.
>
> Bump their timeout factor.
Ok. I think these are obvious to people that have to work with simulators and
the testsuite so if you want to self approve you can.
Hi!
We have expand_doubleword_clz for a couple of years, where we emit
double-word CLZ as if (high_word == 0) return CLZ (low_word) + word_size;
else return CLZ (high_word);
We can do something similar for CTZ and FFS IMHO, just with the 2
words swapped. So if (low_word == 0) return CTZ (high_wor
Hi!
I'm getting
+FAIL: gcc.target/i386/3dnow-1.c (internal compiler error: Segmentation fault
signal terminated program cc1)
+FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
+FAIL: gcc.target/i386/3dnow-2.c (internal compiler error: Segmentation fault
signal terminated program cc1)
+FAI
On 6/7/23 12:20, Jeff Law wrote:
On 6/7/23 09:35, Vladimir Makarov via Gcc-patches wrote:
The following patch fixes
-ENOPATCH
Sorry, here is the patch.
commit 08ca31fb27841cb7f3bff7086be6f139136be1a7
Author: Vladimir N. Makarov
Date: Wed Jun 7 09:51:54 2023 -0400
RA: Constrain c
On 6/7/23 09:35, Vladimir Makarov via Gcc-patches wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
The patch was successfully bootstrapped and tested on x86-64, aarcha64,
and ppc64le.
-ENOPATCH
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the .diff + ChangeLog suffice
to explain them. 'rankguessed' was made redundant b
"Andre Vieira (lists)" writes:
> Hi,
>
> This patch fixes an issue introduced by
> g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0, where a subtype was beeing
> passed to vect_widened_op_tree, when no subtype was to be used. This
> lead to an errorneous use of IFN_VEC_WIDEN_MINUS.
>
> gcc/ChangeLog:
On Wed, 7 Jun 2023 at 16:19, Andreas Schwab wrote:
> On Jun 07 2023, Jonathan Wakely via Gcc-patches wrote:
>
> > Let's just revert it then. The manual says we should use AS_IF, but what
> we
> > had previously was working well enough. I'll figure out what happened
> here
> > later.
>
> I think AS
On Wed, 7 Jun 2023 at 12:51, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023 at 10:08, Thomas Schwinge
> wrote:
>
>> Hi!
>>
>> On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote:
>> > On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
>> >> On 2023-06-06T20:31:21+0100, Jonathan Wakely
>> wrot
On Wed, 7 Jun 2023 at 09:06, Jonathan Wakely wrote:
> On Wed, 7 Jun 2023 at 05:43, François Dumont wrote:
>
>>
>> On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
>> > Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
>> >
>> > -- >8 --
>> >
>> > Add the recently added CXXABI_1
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
In r14-1583-g192665feef7129 I meant to add CXXABI_1.3.15 but instead I
replaced CXXABI_1.3.14 with it. This restores the CXXABI_1.3.14 version.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc (che
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/18_support/nested_exception/rethrow_if_nested-term.cc:
Require effective target exceptions_enabled instead of using
dg-skip-if.
* testsuite/23_cont
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/duration/cons/2.cc: Use values that aren't
affected by rounding.
* testsuite/20_util/from_chars/5.cc: Cast arithmetic result to
double befo
Alex Coplan writes:
> Hi,
>
> This patch series fixes various defects with the FEAT_LS64 ACLE
> implementation in the AArch64 backend.
>
> The series is organised as follows:
>
> - Patch 1/3 fixes whitespace errors in the existing code.
> - Patch 2/3 fixes PR110100 where we generate wrong code f
On Wed, 2023-06-07 at 13:38 +0200, Benjamin Priour wrote:
> On Tue, Jun 6, 2023 at 8:37 PM David Malcolm
> wrote:
> >
> > On Tue, 2023-06-06 at 18:05 +0200, Benjamin Priour wrote:
>
> [...]
>
> > [Looks like you droppped the mailing list from the recipients; was
> > that
> > intentional?]
> >
Hi Di,
The compile options I use are: "-march=native -Ofast -funroll-loops -flto"
I re-ran 503, 507, and 527 on two neoverse-n1 machines, and found that one
machine fluctuated greatly, and the score was only 70% of the other machine. I
also couldn't reproduce the gain on the stable machine. For
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
The patch was successfully bootstrapped and tested on x86-64, aarcha64,
and ppc64le.
Hi all,
This patch removes UNSPEC_SQXTUN and uses organic RTL codes to represent the
operation.
SQXTUN is an odd one. It's described in the architecture as "Signed saturating
extract Unsigned Narrow".
It's not a straightforward ss_truncate nor a us_truncate.
It is a sort of truncating signed cla
Hi all,
Similar to the ADDLP instructions the non-widening ADDP ones can be
represented by adding the odd lanes with the even lanes of a vector.
These instructions take two vector inputs and the architecture spec
describes the operation as concatenating them together before going
through it with p
On Jun 07 2023, Jonathan Wakely via Gcc-patches wrote:
> Let's just revert it then. The manual says we should use AS_IF, but what we
> had previously was working well enough. I'll figure out what happened here
> later.
I think AS_IF is doing its job here: moving the expansion of
AC_REQUIRE'd macr
Hi!
On 2020-12-08T13:46:32-0700, Martin Sebor via Gcc-patches
wrote:
> The attached changes [...]
... eventually became commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
"Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111, PR
middle-end/98160)".
> * c-c++-common/Wf
On Wed, 7 Jun 2023 at 15:54, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023 at 15:42, Hans-Peter Nilsson wrote:
>
>> > Date: Tue, 6 Jun 2023 16:30:12 +0100
>> > From: Jonathan Wakely via Gcc-patches
>>
>> > On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
>> > libstd...@gcc.gnu.org
On Wed, 7 Jun 2023 at 15:42, Hans-Peter Nilsson wrote:
> > Date: Tue, 6 Jun 2023 16:30:12 +0100
> > From: Jonathan Wakely via Gcc-patches
>
> > On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
> > libstd...@gcc.gnu.org> wrote:
> >
> > > Tested x86_64-linux. I'd appreciate a second se
Hi!
On 2020-11-03T16:56:48-0700, Martin Sebor via Gcc-patches
wrote:
> Attached is a simple middle end implementation of detection of
> mismatched pairs of calls to C++ new and delete, along with
> a substantially enhanced implementation of -Wfree-nonheap-object.
This eventually became commit d
Recent changes in the hoisting code change the optimized gimple for the
shadd-3 testcase on the PA. That in turn changes the number of expected
shadd instructions.
I'm not entirely sure the test is actually testing what we want anymore
since I don't see a CSE for postreload to discover. But
On 6/7/23 08:13, Kito Cheng wrote:
I would like vendor cpu name start with vendor name, like
ventana-veyron-v1 which is consistent with all other vendor cpu, and
llvm are using same convention too.
Fair enough. Better to get it right now than have this stuff be
inconsistent. It'll be a lit
> Date: Tue, 6 Jun 2023 16:30:12 +0100
> From: Jonathan Wakely via Gcc-patches
> On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
> > Tested x86_64-linux. I'd appreciate a second set of eyeballs on this
> > before I push it.
> >
>
> Pushed to trunk
Thanks Jiawei, v2 patch set are LGTM, but I would like to defer this until
binutils part has merged, I know you guys already implement that for a
while, so I think it’s almost there :)
Jiawei 於 2023年6月7日 週三，20:57寫道：
> RISC-V Code Size Reduction(ZC*) extensions is a group of extensions
> which def
On Tue, Jun 6, 2023 at 11:53 AM Florian Weimer via Gcc-patches
wrote:
>
> The eh_frame value is only used by linear_search_fdes, not the binary
> search directly in find_fde_tail, so the bug is not immediately
> apparent with most programs.
>
> Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de
Hi,
This patch fixes an issue introduced by
g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0, where a subtype was beeing
passed to vect_widened_op_tree, when no subtype was to be used. This
lead to an errorneous use of IFN_VEC_WIDEN_MINUS.
gcc/ChangeLog:
* tree-vect-patterns.cc (vect_reco
I would like vendor cpu name start with vendor name, like ventana-veyron-v1
which is consistent with all other vendor cpu, and llvm are using same
convention too.
Raphael Moreira Zinsly 於 2023年6月7日 週三，21:18寫道：
> gcc/ChangeLog:
>
> * config/riscv/riscv-cores.def: Add veyron-v1
> co
On Sun, Jun 4, 2023 at 10:43 AM Jeff Law via Gcc-patches
wrote:
>
> With Vlad's recent LRA fix to the elimination code, the H8 can be
> converted to LRA.
Could you update the h8300 entry on https://gcc.gnu.org/backends.html
for this change?
Thanks,
Andrew
>
> This patch has two changes of note.
This patch refactors the ls64 builtins to allow the compiler to define them
directly instead of having wrapper functions in arm_acle.h. This should be not
only easier to maintain, but it makes two important correctness fixes:
- It fixes PR110132, where the builtins ended up getting declared with
The st64b pattern incorrectly had an output constraint on the register
operand containing the destination address for the store, leading to
wrong code. This patch fixes that.
gcc/ChangeLog:
PR target/110100
* config/aarch64/aarch64-builtins.cc (aarch64_expand_builtin_ls64):
Hi,
This patch series fixes various defects with the FEAT_LS64 ACLE
implementation in the AArch64 backend.
The series is organised as follows:
- Patch 1/3 fixes whitespace errors in the existing code.
- Patch 2/3 fixes PR110100 where we generate wrong code for the st64b
builtin.
- Patch 3/
gcc/ChangeLog:
* config/riscv/riscv-cores.def: Add veyron-v1
core and tune info.
* config/riscv/riscv-opts.h
(riscv_microarchitecture_type): Add veyron-v1.
* config/riscv/riscv.cc (veyron_v1_tune_info): New.
* config/riscv/riscv.md: Include veyron-v1
Oh OK, thanks for the clarification.
Costas
On Wed, 7 Jun 2023 at 13:59, Jeff Law wrote:
>
>
> On 6/7/23 04:21, Costas Argyris via Gcc-patches wrote:
> > I saw this while working on something else:
> >
> > pex_unix_cleanup signature doesn't always match the
> > body of the function in terms of
On 6/7/23 01:12, Jakub Jelinek via Gcc-patches wrote:
+/* zero_one_valued_p will match when a value is known to be either
+ 0 or 1 including the constant 0. */
(match zero_one_valued_p
@0
(if (INTEGRAL_TYPE_P (type) && tree_nonzero_bits (@0) == 1)))
So perhaps instead change th
On 6/7/23 04:21, Costas Argyris via Gcc-patches wrote:
I saw this while working on something else:
pex_unix_cleanup signature doesn't always match the
body of the function in terms of ATTRIBUTE_UNUSED.
If the conditional code in the body is compiled, then
ATTRIBUTE_UNUSED isn't correct.
This
Add ZC* extensions march args tests for error input cases.
Co-Authored by: Nandni Jamnadas
Co-Authored by: Jiawei
Co-Authored by: Mary Bennett
Co-Authored by: Simon Cook
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-22.c: New test.
* gcc.target/riscv/arch-23.c: New test.
This patch enables the compressible features with ZC* extensions.
Since all ZC* extension depends on the Zca extension, it's sufficient to only
add the target Zca to extend the target RVC.
Co-Authored by: Mary Bennett
Co-Authored by: Nandni Jamnadas
Co-Authored by: Simon Cook
gcc/ChangeLog:
This patch is the minimal support for ZC* extensions, include the extension
name, mask and target defination. Also define the dependencies with Zca
and Zce extension. Notes that all ZC* extensions depend on the Zca extension.
Zce includes all relevant ZC* extensions for microcontrollers using. Zce
RISC-V Code Size Reduction(ZC*) extensions is a group of extensions
which define subsets of the existing C extension (Zca, Zcd, Zcf) and new
extensions(Zcb, Zcmp, Zcmt) which only contain 16-bit encodings.[1]
The implementation of the RISC-V Code Size Reduction extension in GCC is
an important st
Hi, Richi. I have fixed data reference pointer part following your comments
Could you take a look at it ?
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620916.html
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-07 19:04
To: juzhe.zh...@rivai.ai
CC: gcc-patches; richard.
1 - 100 of 136 matches
Mail list logo
