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
> 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
> 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:
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
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
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
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
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
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?
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
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
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) &
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
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
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
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.
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
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
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
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) in there.
OK? Bootstrapped and tested on
> 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
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
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
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
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):
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
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
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
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
>>>
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
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
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
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
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
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
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
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
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)
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
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
"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.
>
>
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
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
>>
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
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
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.
*
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
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
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
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
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
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)".
> *
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++ <
>> >
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
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
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
> 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
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
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
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
>
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
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
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
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
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.
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
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;
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
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
> wrote:
> >> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge >
> >> >
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?]
>
Not at all, just me missing the reply all button.
> >
> > I indeed bootstrapped
This patch fixes a corner case issue (missing list items in a map clause)
and ensures that such an issue is caught.
Committed to mainline as https://gcc.gnu.org/r14-1605-gdd958667821e38
It is a forward port of Thomas' OG12 then OG13 commit which fixed
a run-time issue which the mainline version
This patch fixes a corner case issue (missing list items in a map clause)
and ensures that such an issue is caught.
Committed to mainline as https://gcc.gnu.org/r14-1605-gdd958667821e38
It is a forward port of Thomas' OG12 then OG13 commit which fixed
a run-time issue which the mainline version
On Wed, 7 Jun 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi. Since SELECT_VL only apply on single-rgroup (ncopies == 1 &&
> vec_num == 1)
> Should I make SELECT_VL stuff out side the loop?
>
> for (i = 0; i < vec_num; i++)
> for (j = 0; j < ncopies; j++)
>
No, but please put assertions
Hi, Richi. Since SELECT_VL only apply on single-rgroup (ncopies == 1 && vec_num
== 1)
Should I make SELECT_VL stuff out side the loop?
for (i = 0; i < vec_num; i++)
for (j = 0; j < ncopies; j++)
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-07 15:41
To: Ju-Zhe Zhong
I see what you mean now, so I've made adjustment in order for testcase to work
on assembly. Following is the updated patch.
Regards,
Jovan
>From 2744357b5232c61bf1f780c4915d47b19d71f993 Mon Sep 17 00:00:00 2001
From: Jovan Dmitrovic
Date: Fri, 19 May 2023 12:36:55 +0200
Subject: [PATCH] mips:
1 - 100 of 135 matches
Mail list logo
