On 7/9/24 10:44, Edwin Lu wrote:
> Support for recognizing B as the collection of zba, zbb, zbs extensions
>
> https://github.com/riscv/riscv-b/tags
>
> V2: add b to riscv_combine_info
>
> Edwin Lu (2):
> RISC-V: Add support for B standard extension
> RISC-V: Update testsuite to use b
>
> g
Thanks Jeff and Edwin for my silly mistake.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, July 13, 2024 5:40 AM
To: Edwin Lu ; gcc-patches@gcc.gnu.org
Cc: Li, Pan2 ; gnu-toolch...@rivosinc.com
Subject: Re: [PATCH] RISC-V: Fix testcase for vector .SAT_SUB in zip benchmark
On 7
Changes since v3:
- Remove '*' from define_insn for fclass
- Remove the dummy expander for fclass.
- De-duplicate the expanders code by using a helper which takes fclass
val.
Changes since v2:
- fclass define_insn tightened to check op0 mode "X" with additional
expander w/o mode fo
On 7/12/24 14:52, Jeff Law wrote:
>> +(define_insn "*fclass"
>> + [(set (match_operand:X 0 "register_operand" "=r")
>> +(unspec [(match_operand:ANYF 1 "register_operand" " f")]
>> + UNSPEC_FCLASS))]
>> + "TARGET_HARD_FLOAT"
>> + "fclass.\t%0,%1";
>> + [(set_attr "type"
Pushed.
Gerald
gcc:
* doc/gm2.texi (Community): Update lists.nongnu.org and
lists.gnu.org links.
---
gcc/doc/gm2.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/gm2.texi b/gcc/doc/gm2.texi
index c532339fbb8..5bff9eb3829 100644
--- a/gcc/doc/g
On Mon, Jul 08, 2024 at 09:55:57AM -0700, Andi Kleen wrote:
> Implement a C23 clang compatible musttail attribute similar to the earlier
> C++ implementation in the C parser.
Sorry that we haven't reviewed the C parts before.
>
> PR83324
I don't think this is going to pass the pre-commit
On 7/12/24 3:12 PM, Vineet Gupta wrote:
Changes since v2:
- fclass define_insn tightened to check op0 mode "X" with additional
expander w/o mode for callers.
- builtins expander explicit mode check and FAIL if mode not appropriate.
- subreg promoted handling to elide potential ex
René's patch seems to have stalled, so here is an updated version of the
patch with the requested changes to his patch.
I'll note I have added an additional code change, which is to also emit a
".machine altivec" if Altivec is enabled. The problem this fixes is for
cpus like the G5, which is basi
On 7/12/24 12:37 PM, Edwin Lu wrote:
The following testcase was not properly testing anything due to an
uninitialized variable. As a result, the loop was not iterating through
the testing data, but instead on undefined values which could cause an
unexpected abort.
gcc/testsuite/ChangeLog:
Changes since v2:
- fclass define_insn tightened to check op0 mode "X" with additional
expander w/o mode for callers.
- builtins expander explicit mode check and FAIL if mode not appropriate.
- subreg promoted handling to elide potential extension of ret val.
- Added isinf builtin with
I am sorry for the inconvenience, a fixed version was sent just now.
This patch addresses a difference between the hash function and the equality
function for canonical types of template parameters (ctp_hasher). The equality
function uses comptypes (typeck.cc) (with COMPARE_STRUCTURAL) and checks
constraint equality for two auto nodes (typeck.cc:1586), while the has
On Tue, Jul 9, 2024 at 6:46 AM Seyed Sajad Kahani wrote:
>
> This patch addresses a difference between the hash function and the equality
> function for canonical types of template parameters (ctp_hasher). The equality
> function uses comptypes (typeck.cc) (with COMPARE_STRUCTURAL) and checks
> co
On Tue, 9 Jul 2024, Seyed Sajad Kahani wrote:
> This patch addresses a difference between the hash function and the equality
> function for canonical types of template parameters (ctp_hasher). The equality
> function uses comptypes (typeck.cc) (with COMPARE_STRUCTURAL) and checks
> constraint equa
Interesting, thanks for the detailed write-up!
On Tue, 9 Jul 2024, Seyed Sajad Kahani wrote:
> Hi.
>
> While investigating a fix for C++/PR115030 (a bug in constrained auto
> deduction), I was wondering why we are not substituting constraint args of an
> auto node in tsubst (pt.cc:16533). Instea
Hi Prathamesh,
Am 12.07.24 um 15:31 schrieb Prathamesh Kulkarni:
It seems that component references are not currently handled even for static
size arrays ?
For eg:
subroutine test_dt (dt, y)
implicit none
real :: y (10, 20, 30)
type t
real :: x(10, 20, 30)
end type t
David Binderman did a bootstrap build with ubsan enabled which triggered
a few errors in the new ext-dce.cc code. This fixes the trivial case of
shifting negative values.
Bootstrapped and regression tested on x86.
Pushing to the trunk.
Jeff
PR rtl-optimization/115876
* ext-
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/14?
-- >8 --
Here we're prematurely stripping the dependent alias template-id A to
its defining-type-id T when used as a template argument, which in turn
causes us to essentially ignore A's vector_size attribute. It s
On 7/9/24 21:36, Jeff Law wrote:
>> +;; TODO: isinf is a bit tricky as it require trimodal return
>> +;; 1 if 0x80, -1 if 0x1, 0 otherwise
[..]
>> + rtx tmp2 = gen_reg_rtx (word_mode);
>> + emit_insn (gen_ashldi3 (tmp2, rclass, GEN_INT (w)));
>> + emit_insn (gen_lshrdi3 (tmp2, tmp2
Applying to trunk as obvious.
-- >8 --
We're getting complaints from the CI system about this removed option.
I suspect I should have removed the @opindex and @itemx for it. This
patch does that.
gcc/ChangeLog:
* doc/invoke.texi: Remove @opindex and @itemx for -fconcepts-ts.
---
gcc/do
The following testcase was not properly testing anything due to an
uninitialized variable. As a result, the loop was not iterating through
the testing data, but instead on undefined values which could cause an
unexpected abort.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop
Hi Pan,
This patch appears to be tripping up our postcommit for building linux
with vector https://github.com/patrick-rivos/gcc-postcommit-ci/issues/1325.
FAIL: gcc.target/riscv/rvv/autovec/binop/vec_sat_u_sub_zip-run.c
execution test
Looking at the logs, the test fails due to the __builtin
Am 12.07.24 um 18:40 schrieb Jeff Law:
On 7/10/24 3:05 AM, Georg-Johann Lay wrote:
The previous change to avr.md was several days ago, and should not
interfere with this one. Anyway, I rebased the patch against
master and attached it below. The patch is atop the ref in the patch
file name :
On Mon, 8 Jul 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested (so far just modules.exp) on
> x86_64-pc-linux-gnu, OK for trunk/14 if full regtest succeeds?
>
> -- >8 --
>
> When importing modules, when a binding vector for a name runs out of
> slots it gets reallocated with a larger si
HI Jason,
> On 9 Jul 2024, at 22:55, Jason Merrill wrote:
>
> On 7/9/24 11:52 AM, Iain Sandoe wrote:
>> Hi Folks
>>> On 8 Jul 2024, at 20:57, Jason Merrill wrote:
>>>
>>> On 7/8/24 3:37 PM, Iain Sandoe wrote:
> On 8 Jul 2024, at 20:19, Jason Merrill wrote:
>
> On 6/17/24 8:15 AM,
On 7/10/24 3:05 AM, Georg-Johann Lay wrote:
The previous change to avr.md was several days ago, and should not
interfere with this one. Anyway, I rebased the patch against
master and attached it below. The patch is atop the ref in the patch
file name : https://gcc.gnu.org/r15-1935
I'll thr
> On 11 Jul 2024, at 04:35, David Malcolm wrote:
>
> On Wed, 2024-07-10 at 09:43 +, Daniel Bertalan wrote:
>> As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the
>> stddef.h header causes the NULL macro in C++ to be re-defined to an
>> integral constant (__null). This mak
Hi!
Nick has implemented a new .base64 directive in gas (to be shipped in
the upcoming binutils 2.43; big thanks for that).
See https://sourceware.org/bugzilla/show_bug.cgi?id=31964
The following patch adjusts default_elf_asm_output_ascii (i.e.
ASM_OUTPUT_ASCII elfos.h implementation) to use it i
On 7/9/24 9:28 AM, Richard Sandiford wrote:
Bit of a brown paper bag issue, but: due to the representation
of the insn chain, insn_info::prev_any_insn would sometimes skip
over instructions. This led to an invalid update in the PR when
adding and removing instructions.
I think one of the rea
On 7/12/24 5:35 AM, Monk Chiang wrote:
The patch add the Zihintntl instructions in the prefetch pattern.
Zicbop has prefetch instructions. Zihintntl has NTL instructions.
Insert NTL instructions before prefetch instruction, if target
has Zihintntl extension.
gcc/ChangeLog:
* config/r
libgomp/ChangeLog:
* libgomp.texi:
---
libgomp/libgomp.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 50da248b74d..a2f5897463a 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -294,8 +294,8 @@ T
This patch adds support for the `dispatch` construct and the `adjust_args`
clause to the Fortran front-end.
Handling of `adjust_args` across translation units is missing due to PR115271.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_omp_clauses): Handle novariants and nocontext
This patch adds support to the C front-end to parse the `dispatch` construct and
the `adjust_args` clause. It also includes some common C/C++ bits for pragmas
and attributes.
Additional common C/C++ testcases are in a later patch in the series.
gcc/c-family/ChangeLog:
* c-attribs.cc (c_c
This patch adds C++ support for the `dispatch` construct and the `adjust_args`
clause. It relies on the c-family bits comprised in the corresponding C front
end patch for pragmas and attributes.
Additional C/C++ common testcases are provided in a subsequent patch in the
series.
gcc/cp/ChangeLog:
This patch introduces the OMP_DISPATCH tree node, as well as two new clauses
`nocontext` and `novariants`. It defines/exposes interfaces that will be
used in subsequent patches that add front-end and middle-end support, but
nothing generates these nodes yet.
It also adds support for new OpenMP con
This patch adds middle-end support for the `dispatch` construct and the
`adjust_args` clause. The heavy lifting is done in `gimplify_omp_dispatch` and
`gimplify_call_expr` respectively. For `adjust_args`, this mostly consists in
emitting a call to `gomp_get_mapped_ptr` for the adequate device.
For
This is a respin of my patchset implementing both the `dispatch` construct and
the `adjust_args` clause to the `declare variant` directive. The original
submission can be found there:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652819.html.
Beside being rebased, this new iteration has the
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/declare-variant-2.c: Adjust dg-error directives.
* c-c++-common/gomp/adjust-args-1.c: New test.
* c-c++-common/gomp/adjust-args-2.c: New test.
* c-c++-common/gomp/dispatch-1.c: New test.
* c-c++-common/gomp/dispat
This enables proper warnings for formats like %qD.
gcc/c-family/ChangeLog:
* c-format.cc (gcc_gfc_char_table): Add formats for tree objects.
---
gcc/c-family/c-format.cc | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/c-family/c-format.cc b/gcc/c-family/c-format.cc
index 5bfd
due to code duplication from jump threading [PR109071]
Control this with a new option -fdiagnostic-explain-harder.
Compared to V1, the major difference are: (address David's comments)
1. Change the name of the option from:
-fdiagnostic-try-to-explain-harder
To
-fdiagnostic-explain-harder
2. S
> -Original Message-
> From: Harald Anlauf
> Sent: Friday, July 12, 2024 1:52 AM
> To: Prathamesh Kulkarni ; gcc-
> patc...@gcc.gnu.org; fort...@gcc.gnu.org
> Subject: Re: Lower zeroing array assignment to memset for allocatable
> arrays
>
> External email: Use caution opening links or
On Fri, Jul 12, 2024 at 3:05 PM Jakub Jelinek wrote:
>
> On Fri, Jul 12, 2024 at 02:56:53PM +0200, Richard Biener wrote:
> > Padding is only an issue for very small vectors - the obvious choice is
> > to disallow vector types that would require any padding. I can hardly
> > see where those are fa
Tested on x86_64-pc-linux-gnu, pushing to trunk.
-- >8 --
This issue was fixed by r15-2003-gd6bf4b1c932211, but seems worth adding
to the testsuite.
PR c++/115798
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-26_a.C: New test.
* g++.dg/modules/using-26_b.C: New test.
On Fri, Jul 12, 2024 at 02:56:53PM +0200, Richard Biener wrote:
> Padding is only an issue for very small vectors - the obvious choice is
> to disallow vector types that would require any padding. I can hardly
> see where those are faster than using a vector of up to 4 char elements.
> Problematic
On Fri, Jul 12, 2024 at 12:44 PM Tejas Belagod wrote:
>
> On 7/12/24 11:46 AM, Richard Biener wrote:
> > On Fri, Jul 12, 2024 at 6:17 AM Tejas Belagod wrote:
> >>
> >> On 7/10/24 4:37 PM, Richard Biener wrote:
> >>> On Wed, Jul 10, 2024 at 12:44 PM Richard Sandiford
> >>> wrote:
>
> Te
On Fri, Jul 12, 2024 at 12:09 PM Ajit Agarwal wrote:
>
> Hello Richard:
>
> On 11/07/24 2:21 pm, Richard Biener wrote:
> > On Thu, Jul 11, 2024 at 10:30 AM Ajit Agarwal
> > wrote:
> >>
> >> Hello All:
> >>
> >> Unroll factor is determined with max distance across loop iterations.
> >> The logic
The patch add the Zihintntl instructions in the prefetch pattern.
Zicbop has prefetch instructions. Zihintntl has NTL instructions.
Insert NTL instructions before prefetch instruction, if target
has Zihintntl extension.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_print_operand): Add 'L'
These are insns of the forms
(set (regA:M)
(plus:M (extend:M (regB:L))
(regA:M)))
and
(set (regA:M)
(minus:M (regA:M)
(extend:M (regB:L
where "extend" may be a sign-extend or zero-extend,
and the integer modes satisfy SImode >= M > L >= QImod
On 7/12/24 11:46 AM, Richard Biener wrote:
On Fri, Jul 12, 2024 at 6:17 AM Tejas Belagod wrote:
On 7/10/24 4:37 PM, Richard Biener wrote:
On Wed, Jul 10, 2024 at 12:44 PM Richard Sandiford
wrote:
Tejas Belagod writes:
On 7/10/24 2:38 PM, Richard Biener wrote:
On Wed, Jul 10, 2024 at 10:
On 7/12/24 03:23, Jiang, Haochen wrote:
-Original Message-
From: Hongtao Liu
Sent: Thursday, July 11, 2024 9:45 AM
To: Victor Do Nascimento
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com;
richard.earns...@arm.com
Subject: Re: [PATCH 05/10] i386: Fix dot_prod backend patterns for
Hello Richard:
On 11/07/24 2:21 pm, Richard Biener wrote:
> On Thu, Jul 11, 2024 at 10:30 AM Ajit Agarwal wrote:
>>
>> Hello All:
>>
>> Unroll factor is determined with max distance across loop iterations.
>> The logic for determining the loop unroll factor is based on
>> data dependency across l
On Fri, 12 Jul 2024 at 10:27, Jonathan Wakely wrote:
>
> On Fri, 12 Jul 2024 at 09:27, Alexandre Oliva wrote:
> >
> > On Jul 11, 2024, Jonathan Wakely wrote:
> >
> > > There's no requirement that system_error uses strerror, that's just an
> > > implementation detail.
> >
> > *nod*. I meant it w
On Thu, 11 Jul 2024, Tamar Christina wrote:
> -Original Message-
> > From: Richard Biener
> > Sent: Thursday, July 11, 2024 12:39 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com
> > Subject: RE: [PATCH][ivopts]: perform affine fold on unsigne
On Fri, Jul 12, 2024 at 07:09:37AM +0200, Stefan Schulze Frielinghaus wrote:
> On Thu, Jul 11, 2024 at 07:32:17PM +0200, Stefan Schulze Frielinghaus wrote:
> > On Thu, Jul 11, 2024 at 05:14:58PM +0200, Jakub Jelinek wrote:
> > > On Thu, Jul 11, 2024 at 05:09:41PM +0200, Stefan Schulze Frielinghaus
On Fri, 12 Jul 2024 at 09:27, Alexandre Oliva wrote:
>
> On Jul 11, 2024, Jonathan Wakely wrote:
>
> > There's no requirement that system_error uses strerror, that's just an
> > implementation detail.
>
> *nod*. I meant it was more of a libc test in the case that relied on
> strerror. But I ful
On Jun 12, 2024, Alexandre Oliva wrote:
> for gcc/ChangeLog
> PR d/115295
> * doc/sourcebuild.texi (dg-additional-sources): Add linkonly.
> for gcc/testsuite/ChangeLog
> PR d/115295
> * g++.dg/vect/pr95401.cc: Add linkonly to dg-additional-sources.
> * g++.dg/ve
On Jul 11, 2024, Jonathan Wakely wrote:
>> * testsuite/decimal/compound-assignment-memfunc.cc: Likewise.
The following file was missing from the ChangeLog. Added before pushing:
* testsuite/decimal/compound-assignment.cc: Likewise.
--
Alexandre Oliva, happy hackerhttps://FSFLA
On Jul 11, 2024, Jonathan Wakely wrote:
> There's no requirement that system_error uses strerror, that's just an
> implementation detail.
*nod*. I meant it was more of a libc test in the case that relied on
strerror. But I fully agree that testing the C++ standard API makes
perfect sense. It'
On Fri, Jul 12, 2024 at 7:20 AM Feng Xue OS wrote:
>
> Hi, Richard,
>
> Let me explain some idea that has to be chosen for lane-reducing. The key
> complication is that these ops are associated with two kinds of vec_nums,
> one is number of effective vector stmts, which is used by partial vectorza
Committed, thanks Kito.
xu...@eswincomputing.com
From: Kito Cheng
Date: 2024-07-12 15:57
To: Li Xu
CC: gcc-patches; juzhe.zhong; Robin Dapp
Subject: Re: Re: [PATCH v2] RISC-V: Disable misaligned vector access in hook
riscv_slow_unaligned_access[PR115862]
Oh, okay, my fault, I didn't read the
On Jul 11, 2024, David Malcolm wrote:
> I intended that particular test as an integration test, to try to make
> sure that -fanalyzer is silent on the result of a minimal "flex"
> script. So if we're actually getting warnings, that's undesirable, and
> I'm not sure the approach in your patch is
Ok for trunk and releases/gcc-14?
--
Overriding the -mpfu and -mfloat-abi might be incompatible with selected
multilib. As a result, verify that the current multilib is compatible
with the effective target without changing the -mfpu or -mfloat-abi
options.
gcc/testsuite/ChangeLog:
* lib
We have already upstreamed these extensions into binutils, and now we need GCC
to recognize these extensions and pass them to binutils as well. We also plan
to upstream intrinsics in the near future. :)
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_implied_info): Add xsfvcp.
Hi Mike,
on 2024/7/11 01:32, Michael Meissner wrote:
> Note, this is a repost of the 3 patches I posted on June 4th. The first two
> patches are the same. The third patch modifies the power11 tests to do a
> compile instead of assemble, and I removed the power11 specific target support
> that wa
Oh, okay, my fault, I didn't read the bugzilla, so you can go ahead :P
On Fri, Jul 12, 2024 at 3:51 PM Li Xu wrote:
>
> Sorry, I didn't understand.
>
> >>but...this seems to have discovered another bug in the current trunk?
>
> Isn't PR115862 the same bug as this one?
>
> __
On 7/2/24 15:48, Stefan Schulze Frielinghaus wrote:
Currently instructions vgm and vrepi are utilized only for constant
vectors where the element mode equals the element mode of the
corresponding instruction. This patch lifts this restriction by making
use of those instructions for constant vect
On Fri, Jul 12, 2024 at 7:24 AM liuhongt wrote:
>
> >- _5 = __atomic_fetch_or_8 (&set_work_pending_p, 1, 0);
> >- # DEBUG old => (long int) _5
> >+ _6 = .ATOMIC_BIT_TEST_AND_SET (&set_work_pending_p, 0, 1, 0,
> >__atomic_fetch_or_8);
> >+ # DEBUG old => NULL
> > # DEBUG BEGIN_STMT
> >- # D
Sorry, I didn't understand.
>>but...this seems to have discovered another bug in the current trunk?
Isn't PR115862 the same bug as this one?
xu...@eswincomputing.com
From: Kito Cheng
Date: 2024-07-12 14:33
To: Li Xu
CC: gcc-patches; juzhe.zhong; rdapp.gcc
Subject: Re: [PATCH v2] RISC-V: Di
Le 11/07/2024 à 22:49, Harald Anlauf a écrit :
Hi Mikael,
Am 11.07.24 um 21:55 schrieb Mikael Morin:
From: Mikael Morin
Hello,
I discovered this while testing the inline MINLOC/MAXLOC (aka PR90608)
patches.
Regression tested on x86_64-linux.
OK for master?
this is a nice finding! (NAG s
Hi Alexandre,
> Regstrapped on x86_64-linux-gnu. Also verified that the regression is
> cured with a i686-solaris cross compiler. Ok to install?
FWIW, I've also included the patch in last night's i386-pc-solaris2.11
bootstrap: the failures are gone, no regressions.
Thanks.
Rainer
--
On 7/1/24 10:32, Stefan Schulze Frielinghaus wrote:
This drops vcond expanders. The first patch
"s390: Emulate vec_cmp{eq,gt,gtu} for 128-bit integers" is somewhat
independent of the other two, since we run already in ICEs. However,
since after removing vcond expanders testsuite shows one addi
On Thu, 11 Jul 2024, Filip Kastl wrote:
> > > > > +/* Check that the "exponential index transform" can be applied to
> > > > > this switch.
> > > > > +
> > > > > + See comment of the exp_index_transform function for details about
> > > > > this
> > > > > + transformation.
> > > > > +
> > > >
Hi,
Currently for 128 bit floating-point ibm128 and ieee128
formats conversion, the corresponding libcalls are:
ibm128 -> ieee128 "__trunctfkf2"
ieee128 -> ibm128 "__extendkftf2"
, and generic code handling (like convert_mode_scalar) also
adopts sext_optab for ieee128 -> ibm128 while trunc_opt
Hi,
On rs6000, there are three 128 bit scalar floating point
modes TFmode, IFmode and KFmode. With some historical
reasons, we defines them with different mode precisions,
that is KFmode 126, TFmode 127 and IFmode 128. But in
fact all of them should have the same mode precision 128,
this special
74 matches
Mail list logo
