Hi Jerry,
thanks for the review. Committed as gcc-15-6383-ga25cc268846
Thanks again,
Andre
On Thu, 19 Dec 2024 11:09:20 -0800
Jerry D wrote:
> On 12/19/24 4:13 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch fixes a rather old open issue, that I stumbled upon
> > while
чт, 19 дек. 2024 г. в 21:56, Georg-Johann Lay :
>
> The "io", "io_low", and "address" attributes require to asm output
> the definition of respective symbols in a manner that was not supported
> until the introduction of the new target hook TARGET_ASM_VARIABLE.
>
> The previous implementation of th
From: Pan Li
Just notice the unalignment operand for strided load/store pattern when
bugfix the strided load/store memory alias, would like to make it align.
gcc/ChangeLog:
* config/riscv/autovec.md: Align the operand for strided
load/store pattern.
Signed-off-by: Pan Li
---
This is a ping for
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671216.html
Johann
This patch adds a new target hook that allows to chose
a non-generic named address-space for compiler generated
lookup tables.
The purpose is that there are cases (on avr namely) where
the generic ad
From: Pan Li
Like the sat alu related testcase, the dump check of strided load/store
takes the rtl dump for the standard name MASK_LEN_STRIDED_LOAD for times.
But the rtl pass expand is somehow mutable by the middle-end change or
debug information.
After that we need to adjust the dump check tim
Joseph, I am Bob Dubner, the other half of the development team for the
COBOL front end. Conceptually, I regard the front end as having a blurry
line down the middle of it; Jim primarily does parsing, I generate the
GENERIC tree.
> -Original Message-
> From: Joseph Myers
> Sent: Thursday
Commit 4ed189854eae ("Add block parameter to begin_block debug hook") changed
the definition of the begin_block function pointer to add another parameter,
but I missed a call in vmsdbgout_begin_block.
Fixes bug #118123.
gcc/
* vmsdbgout.cc (vmsdbgout_begin_block): Fix compilation error.
-
Kindly ping.
Pan
-Original Message-
From: Li, Pan2
Sent: Tuesday, December 10, 2024 2:28 PM
To: gcc-patches@gcc.gnu.org
Cc: richard.guent...@gmail.com; tamar.christ...@arm.com; juzhe.zh...@rivai.ai;
kito.ch...@gmail.com; jeffreya...@gmail.com; rdapp@gmail.com; Li, Pan2
Subject: [
On 12/19/24 1:34 PM, Harald Anlauf wrote:
Dear all,
the check for potential aliasing of lhs and rhs currently shortcuts
if the types differ. This is a problem if one is of type complex
and the other is of type real (and of the same kind parameter value),
as this ignores that F2008 inquiry refer
Consider this case of a bad call to a callback function (perhaps
due to C23 changing the meaning of () in function decls):
struct p {
int (*bar)();
};
void baz() {
struct p q;
q.bar(1);
}
Before this patch the C frontend emits:
t.c: In function 'baz':
t.c:7:5: error: too many ar
Here's an updated version of the patch.
Changed in v2:
- distinguish between "bool" and "_Bool" when determining
standard version
- more test coverage
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for trunk?
This patch attempts to provide better error messages for
code comp
I'm ok withi your patch. It seems to also catch PR113928.
You may want to give others a chance to chime in.
--
steve
On Thu, Dec 19, 2024 at 09:34:38PM +, Harald Anlauf wrote:
>
> the check for potential aliasing of lhs and rhs currently shortcuts
> if the types differ. This is a problem
On 12/19/24 3:08 PM, Palmer Dabbelt wrote:
I agree lacking B and V makes us very clearly uncompetitive in the space
where these sort of things matter (ie, binary compatible distros and
long term stability type things) -- the gap is just too big to close by
doing clever things in the hardwa
"James K. Lowden" writes:
> On Thu, 12 Dec 2024 12:56:36 -0500
> "James K. Lowden" wrote:
>
>> The following 8 patches constitute the 80 files needed to build and
>> document the COBOL front end.
> [...]
> * does not build on Darwin/macOS [Iain]
> [...]
> - 32-bit architectures are not a consid
On Wed, 18 Dec 2024 08:20:46 PST (-0800), jeffreya...@gmail.com wrote:
On 12/17/24 5:11 PM, Palmer Dabbelt wrote:
This came up on IRC this morning and we talked a bit on the patchwork
call this morning. I'm not really sure what the right answer is here,
but it seems at least reasonable to tal
On Thu, Dec 19, 2024 at 09:22:04PM +, Joseph Myers wrote:
> On Thu, 19 Dec 2024, Andrew Pinski wrote:
>
> > Maybe it is better to just use _BitInt instead of __int128. Yes the
> > number of targets that support _BitInt for C is less than __int128 but
> > in the future _BitInt will be more supp
Dear all,
the check for potential aliasing of lhs and rhs currently shortcuts
if the types differ. This is a problem if one is of type complex
and the other is of type real (and of the same kind parameter value),
as this ignores that F2008 inquiry references (%RE, %IM) could be
involved. The att
On Wed, 18 Dec 2024, James K. Lowden wrote:
> I think the issue that raised the most concern is the one I think is
> most important: diagnostics. It was unclear -- still is, to me --
> whether the COBOL front end must or should use the gcc diagnostic
> framework. (In my defense, the system goes u
On Thu, 19 Dec 2024, Andrew Pinski wrote:
> Maybe it is better to just use _BitInt instead of __int128. Yes the
> number of targets that support _BitInt for C is less than __int128 but
> in the future _BitInt will be more supported than __int128 especially
> on 32bit targets. E.g. _BitInt(128) is
On Wed, 18 Dec 2024, James K. Lowden wrote:
> * Please make sure to do all regeneration with *unmodified* versions
> [Joseph]
> - I don't understand.
You appeared to have regenerated a configure script built with a version
of autoconf from a GNU/Linux distribution that patched autoconf to add
In PR117830 a miscompilation of 464.h264ref was reported.
An analysis showed that wrong code was generated because of
unsatisfied assuptions in the code. This patch addresses
these issues.
The first assuption was that we can independently analyse the two
vec-perms at the start of a vec-perm-simpl
On Wed, 18 Dec 2024, James K. Lowden wrote:
> On Mon, 16 Dec 2024 23:36:37 + (UTC)
> Joseph Myers wrote:
>
> > > +extern "C" _Float128 __gg__float128_from_qualified_field
> >
> > I'm not entirely sure whether this is host or target code (you always
> > need to be clear about which is which
On Thu, 12 Dec 2024 12:56:36 -0500
"James K. Lowden" wrote:
> The following 8 patches constitute the 80 files needed to build and
> document the COBOL front end.
Below is a list of issues with the COBOL front end, listed in
order of priority, most important first. Each is tagged with who
raised
This patch ensures that the list of valid -mtune options
does not contain entries more than once.
The -mtune option accepts CPU identifiers as well as
tuning identifiers and there are cases where a CPU and
its tuning have the same identifier.
PR116347
gcc/ChangeLog:
* common/conf
On Thu, Dec 19, 2024 at 11:31 AM James K. Lowden
wrote:
>
> On Mon, 16 Dec 2024 23:36:37 + (UTC)
> Joseph Myers wrote:
>
> > > +extern "C" _Float128 __gg__float128_from_qualified_field
> >
> > I'm not entirely sure whether this is host or target code (you always
> > need to be clear about wh
On Mon, 16 Dec 2024 23:36:37 + (UTC)
Joseph Myers wrote:
> > +extern "C" _Float128 __gg__float128_from_qualified_field
>
> I'm not entirely sure whether this is host or target code (you always
> need to be clear about which is which in GCC), but in any case, both
> hosts and targets without
Gentle ping :)
Kind regards,
Torbjörn
On 2024-11-14 17:32, Torbjorn SVENSSON wrote:
On 2024-11-14 16:26, Christophe Lyon wrote:
On Fri, 8 Nov 2024 at 18:54, Torbjörn SVENSSON
wrote:
Ok for trunk and releases/gcc-14?
Can you describe what problem you are trying to fix?
I'm guessing it's
Gentle ping :)
Kind regards,
Torbjörn
On 2024-11-14 17:51, Torbjorn SVENSSON wrote:
On 2024-11-14 16:16, Christophe Lyon wrote:
Hi Torbjörn,
On Sun, 10 Nov 2024 at 10:09, Torbjörn SVENSSON
wrote:
Changes since v1:
- Changed from arm_neon to arm_arch_v7a for the required effective
targe
On 12/19/24 4:13 AM, Andre Vehreschild wrote:
Hi all,
attached patch fixes a rather old open issue, that I stumbled upon
while trying to figure, why a test failed on the command line but not
in the testsuite. The implementation of the STOP command in caf_single
did not hand the errorcode over to
When I try to use std::filesystem::u8path() I get a deprecation message.
It recommends replacing u8path() with path((const char8_t*)&*source)
The code it recommends is undefined behaviour (See
https://stackoverflow.com/a/57453713/14516046 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925).
On Thu, Dec 19, 2024 at 11:44:54AM -0500, Jason Merrill wrote:
> > --- gcc/cp/call.cc.jj 2024-12-19 16:10:12.977071898 +0100
> > +++ gcc/cp/call.cc 2024-12-19 16:55:40.953546502 +0100
> > @@ -4386,7 +4386,13 @@ maybe_init_list_as_array (tree elttype,
> > if (!is_xible (INIT_EXPR, elttype
"Robin Dapp" writes:
>> ...it's not clear to me that we should define the upper bits of the
>> byte to be zero. What would rely on that? Is it something that we'd
>> require for all loads and stores of such modes?
>
> Yes, I meant fewer than BITS_PER_UNIT bits in total. As opposed to SVE's
> "b
Hello,
The attached patch builds on top of the previous one, this time adding
support for C++26's std::atomic_ref::address(). Tested on x86-64 Linux.
Thank you,
--
Giuseppe D'Angelo
From 0cc16c6e0365308255e02328b0d1f52c0624f8ac Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Thu, 19 De
The "io", "io_low", and "address" attributes require to asm output
the definition of respective symbols in a manner that was not supported
until the introduction of the new target hook TARGET_ASM_VARIABLE.
The previous implementation of these attributes abused tls_common_section
which is a noswit
On Thu, Dec 19, 2024 at 11:52:33AM -0500, Jason Merrill wrote:
> Please add this paragraph as a comment.
Ok.
> > + if (!TYPE_UNSIGNED (elt_type)
> > + && (complain & tf_warning)
>
> We shouldn't check tf_warning here.
Oops, you're right. I saw the compla
This patch adds a new target hook that allows the backend to asm output
a variable definition in its own way. This hook is needed because
varasm.cc imposes a very restrictive layout for all variable definitions
which will be basically ELF style (on ELF targets as least). To date,
there is no way
On Thu, Sep 19, 2024 at 6:41 PM Arsen Arsenović wrote:
>
> Arsen Arsenović writes:
>
> > Gentle ping again. Full patch:
> > https://inbox.sourceware.org/gcc-patches/86y14ptvdi@aarsen.me/
For some reason it seems Thunderbird didn't want me to see this patch. OK.
> And again. To clarify, t
On 12/18/24 11:41 AM, Jakub Jelinek wrote:
On Tue, Dec 17, 2024 at 05:34:38PM -0500, Jason Merrill wrote:
On 9/11/24 8:26 AM, Jakub Jelinek wrote:
On Wed, Sep 11, 2024 at 10:16:18PM +1000, Nathaniel Shead wrote:
In the header_module_p case, it is valid to have internal linkage
definitions (e.g
On 12/19/24 11:07 AM, Jakub Jelinek wrote:
Hi!
The following testcases ICE due to RAW_DATA_CST not being handled where it
should be during ck_list conversions.
The last 2 testcases started ICEing with r15-6339 committed yesterday
(speedup of large initializers), the first two already with r15-5
Commit r15-6245-g4f4e13dd235b introduced new modes for MVE tuples, but
missed adding support for them in a few places.
Adding them to the list in arm_attr_length_move_neon is not sufficient
since we later face another ICE where the compiler does not know how
to split move of such data.
The patch
On 12/19/24 11:10 AM, Jakub Jelinek wrote:
Hi!
The previous patch made me look around some more and I found
maybe_init_list_as_array doesn't handle RAW_DATA_CSTs correctly either,
while the RAW_DATA_CST is properly split during finish_compound_literal,
it was using CONSTRUCTOR_NELTS as the size
On Fri, 25 Oct 2024, Patrick Palka wrote:
> On Wed, 16 Oct 2024, Patrick Palka wrote:
>
> > On Mon, 30 Sep 2024, Patrick Palka wrote:
> >
> > > This implements the C++23 container adaptors std::flat_map and
> > > std::flat_multimap from P0429R9. The implementation is shared
> > > as much as pos
Fallout from looking at the additional definition document:
I noticed that "nec" was missing from GCC's vendor trait
selector list.
That's only a minor issue as only effect is that for unknown
vendors, a warning is printed:
"unknown property ‘nec’ of ‘vendor’ selector"
Still, it makes sense to
On 12/18/24 10:53 AM, Jakub Jelinek wrote:
On Tue, Dec 17, 2024 at 05:54:36PM -0500, Jason Merrill wrote:
On 9/5/24 3:27 AM, Jakub Jelinek wrote:
When adding test coverage for maybe_unused attribute, I've run into
several things:
1) similarly to deprecated attribute, the attribute shouldn't ped
Hi!
The previous patch made me look around some more and I found
maybe_init_list_as_array doesn't handle RAW_DATA_CSTs correctly either,
while the RAW_DATA_CST is properly split during finish_compound_literal,
it was using CONSTRUCTOR_NELTS as the size of the arrays, which is wrong,
RAW_DATA_CST c
Hi!
The following testcases ICE due to RAW_DATA_CST not being handled where it
should be during ck_list conversions.
The last 2 testcases started ICEing with r15-6339 committed yesterday
(speedup of large initializers), the first two already with r15-5958
(#embed optimization for C++).
For conve
On 12/18/24 11:56 AM, Patrick Palka wrote:
On Wed, 18 Dec 2024, Jason Merrill wrote:
On 12/17/24 10:43 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk? Shall we also backport this to release branches?
It's not a regression but seems like
On Thu, Dec 19, 2024 at 10:38:09AM -0500, Jason Merrill wrote:
> On 12/18/24 9:17 AM, Nathaniel Shead wrote:
> > On Tue, Dec 17, 2024 at 03:58:38PM -0500, Jason Merrill wrote:
> > > On 11/27/24 3:53 AM, Nathaniel Shead wrote:
> > > > Gentle ping for this series:
> > > > https://gcc.gnu.org/pipermai
On 12/18/24 1:57 PM, Marek Polacek wrote:
On Tue, Dec 17, 2024 at 11:43:45AM -0500, Jason Merrill wrote:
On 12/12/24 1:42 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This ICE started with the recent prvalue optimization (r15-6052). In
cp_fold
On 12/19/24 5:00 AM, Jakub Jelinek wrote:
On Wed, Dec 18, 2024 at 04:44:55PM +0100, Jakub Jelinek wrote:
The first check would flag something that is used in the wild, e.g.
g++.dg/Wmissing-attributes.C
gcc.dg/gnu23-attrs-2.c
g++.dg/cpp0x/gen-attrs-81.C
g++.dg/warn/Wdangling-reference17.C
g++.dg/
On 12/18/24 9:17 AM, Nathaniel Shead wrote:
On Tue, Dec 17, 2024 at 03:58:38PM -0500, Jason Merrill wrote:
On 11/27/24 3:53 AM, Nathaniel Shead wrote:
Gentle ping for this series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665108.html
Most of the patches no longer applied cleanly t
Found when reviewing the metadirective/context-selector patch,
"[PATCH v5 02/10] OpenMP: Re-work and extend context selector resolution",
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671295.html
as it touches the related code (without modifying how GCC handles this).
Namely, as I wrote
On Thu, Dec 19, 2024 at 09:22:02AM -0500, Andrew MacLeod wrote:
> I have no issues. ok by me.� I clearly need a proofreader :-)
>
> Andrew
Thanks! It applies cleanly to your gcc-14 backport, so I've pushed to that
branch as well.
> On 12/18/24 11:22, Andrew Carlotti wrote:
> > I think this cou
> I wonder if LOOP_VINFO_LENS is really empty here? If not, who recorded
> the len and why did that not disable partial vectors?
It's not empty. vectorizable_operation fills it for a vectype of vector short
(4). Before (in vector_type_mode), we determined that a vector long (1) has an
integer m
> On 19 Dec 2024, at 12:24, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jennifer Schmitz writes:
>> @@ -3672,6 +3673,48 @@ gimple_folder::fold_pfalse ()
>> return nullptr;
>> }
>>
>> +/* Convert the lhs and all non-boolean vector-type operan
Hi,
Could I please have feedback on the following patches?
PR c++/109918: Unexpected -Woverloaded-virtual with virtual conversion
operators
=> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665650.html
PR c++/114292: ICE with a generic (templated) lambda capturing a
constant for VLA
I have no issues. ok by me. I clearly need a proofreader :-)
Andrew
On 12/18/24 11:22, Andrew Carlotti wrote:
I think this counts as obvious, but I'll leave it a few days before committing
in case Andrew (or anyone else) disagrees.
gcc/ChangeLog:
* tree-assume.cc: Fix comment typos.
Hello,
On 19/12/2024 13:27, Jonathan Wakely wrote:
I was about to push this and realised it's missing a Signed-off-by
tag. I assume you meant to contribute this under the DCO terms, as
with your previous patches?
Yes, of course; sorry for forgetting the line. Here's a signed patch.
--
Giusep
Hi Damian,
well F2008 Note 8.30 states:
If the stop-code is an integer, it is recommended that the value also
be used as the process exit status, if the processor supports that
concept.
and in F2018 its not even "just a note" anymore, but in 11.4 §2 same
sentence as in the note.
At least t
Tamar Christina writes:
> gcc/ChangeLog:
>
> PR target/96342
> * config/aarch64/aarch64-sve.md (vec_init): New.
> (@aarch64_pack_partial): New.
> * config/aarch64/aarch64.cc (aarch64_sve_expand_vector_init_subvector):
> New.
> * config/aarch64/iterators.md (SVE_NO2E)
I don’t think the standard requires providing the stop code to the OS, but
it recommends doing so. So this is a great idea. Thanks for working on
coarray features.
Damian
On Thu, Dec 19, 2024 at 04:14 Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes a rather old open issue, that I
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* gfortran.dg/default_format_2.f90: Don't xfail for
ppc_ieee128_ok.
> On 19 Dec 2024, at 11:14, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jennifer Schmitz writes:
>> @@ -8834,22 +8834,7 @@ vectorizable_store (vec_info *vinfo,
>> {
>>if (costing_p)
>> {
>> -
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, December 19, 2024 11:03 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH 7/7]AArch64: Implement vector concat of partial SVE
> vectors
>
> Tamar C
On Thu, 12 Dec 2024 at 14:24, Giuseppe D'Angelo
wrote:
>
> Hi,
>
> On 12/12/2024 01:04, Jonathan Wakely wrote:
> >> I'll prepare a patch to do that,
> > Et voila:
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671432.html
>
> Thanks! All done, new patch is attached.
I was about to pu
Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
to compile on arm-linux-gnueabihf with
fatal error: gnu/stubs-soft.h: No such file or directory
because they are actually compiled with
-mfloat-abi=softfp -mfpu=auto -mcpu=unset -march=armv8.3-a+fp16
Fix this by including stdint.
The test uses floats, not fp16 so it should use arm_v8_3a_complex_neon
instead of arm_v8_3a_fp16_complex_neon.
This makes it PASS on arm-linux-gnueabihf instead of being UNRESOLVED.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-float.c: Use
ar
These two testcases have twice the same dg-add-options
arm_v8_3a_complex_neon, the patch removes one of them.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/complex/complex-operations-run.c: Remove duplicate
dg-add-options arm_v8_3a_complex_neon.
* gcc.dg/vect/complex/fast-math-bb
The vect testsuite adds -mfpu=neon before the arm_v8_3a_complex_neon
flags via check_vect_support_and_set_flags, so before this change
testcases are compiled with -mfpu=neon (and no -march/-mfloat-abi
flag) with an arm-linux-gnueabihf toolchain configured using
--with-float=hard --with-fpu=vfpv3-d1
On 2024-12-19 11:46, Richard Earnshaw (lists) wrote:
On 18/12/2024 18:45, Torbjörn SVENSSON wrote:
Changes since v1:
- Split tests into two parts. One part for doing asm checkes. Another part
for doing run test as these require hardware to be available.
- Changed existing tests to be "com
Hi all,
attached patch fixes a rather old open issue, that I stumbled upon
while trying to figure, why a test failed on the command line but not
in the testsuite. The implementation of the STOP command in caf_single
did not hand the errorcode over to the OS, as does non-caf STOP and as
it is requi
On 2024-12-19 11:48, Richard Earnshaw (lists) wrote:
On 18/12/2024 19:57, Torbjörn SVENSSON wrote:
Ok for trunk?
--
Update test case to align with used function in C++26.
gcc/testsuite/ChangeLog:
* g++.dg/abi/arm_rtti1.C: Check for expected symbol in C++26.
Signed-off-by: Torbjör
On 18/12/2024 16:24, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Updated the commit message to reflect the changes (including the subject).
> - Replaced the POP/BEQ checks with chesk for {cmp,mov,orr,and}{eq,ne}.
> - Removed the size check
>
>
> Ok for trunk and releases/gcc-14?
> Should
gcc/
* config/aarch64/t-aarch64 (aarch64-builtins.o): Depend on
aarch64-simd-pragma-builtins.def.
---
gcc/config/aarch64/t-aarch64 | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/config/aarch64/t-aarch64 b/gcc/config/aarch64/t-aarch64
index dfb159d1da6..3219871e8d7 100644
-
The intrinsic type suffix for modal floating-point types is _mf8,
so it's more convenient if we use that for the simd_types as well.
gcc/
* config/aarch64/aarch64-builtins.cc (simd_types::f8): Rename to...
(simd_types::mf8): ...this.
* config/aarch64/aarch64-simd-pragma-bui
This patch tries to regularise the definitions of the new pragma
simd types. Not all of the new types are currently used, but they
will be by later patches.
gcc/
* config/aarch64/aarch64-builtins.cc (simd_types): Use one macro
invocation for each element type.
---
gcc/config/aarc
This series adds mf8 variants of what I'll loosely call the existing
"data movement" intrinsics, including the recent FEAT_LUT ones.
I think this completes the FP8 intrinsic definitions.
Sorry that the series is so late. We did make a real effort to get
it done by the end of stage 1, but there we
Jennifer Schmitz writes:
> @@ -3672,6 +3673,48 @@ gimple_folder::fold_pfalse ()
>return nullptr;
> }
>
> +/* Convert the lhs and all non-boolean vector-type operands to TYPE.
> + Pass the converted variables to the callback FP, and finally convert the
> + result back to the original typ
Tamar Christina writes:
>> > ;; 2 element quad vector modes.
>> > (define_mode_iterator VQ_2E [V2DI V2DF])
>> >
>> > @@ -1678,7 +1686,15 @@ (define_mode_attr VHALF [(V8QI "V4QI") (V16QI
>> "V8QI")
>> > (V2DI "DI")(V2SF "SF")
>> > (V4SF "V2SF") (V4HF
On 18/12/2024 19:57, Torbjörn SVENSSON wrote:
> Ok for trunk?
>
> --
>
> Update test case to align with used function in C++26.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/abi/arm_rtti1.C: Check for expected symbol in C++26.
>
> Signed-off-by: Torbjörn SVENSSON
OK.
R.
> ---
> gcc/tests
On 18/12/2024 18:45, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Split tests into two parts. One part for doing asm checkes. Another part
> for doing run test as these require hardware to be available.
> - Changed existing tests to be "compile" instead of "run".
>
> Changes since v2:
>
On Thu, Dec 19, 2024 at 6:53 AM Alexandre Oliva wrote:
>
>
> Introduce flags to disable ifcombine as a whole, or its new components.
>
> Disable the potentially quadratic noncontiguous ifcombine at -O1.
> Adjust the tests that expected it with -O to use -O2 instead.
>
> Is this of interest? I've
On Thu, Dec 19, 2024 at 3:39 AM Alexandre Oliva wrote:
>
> We don't want to indirect pointers in strub wrappers, because it
> generally isn't profitable, but if the argument is volatile, then we
> must use indirection to preserve access patterns, so amend the
> assertion check.
>
> Regstrapped on
Jennifer Schmitz writes:
> @@ -8834,22 +8834,7 @@ vectorizable_store (vec_info *vinfo,
> {
> if (costing_p)
> {
> - /* Only need vector extracting when there are more
> - than one stores. */
> -
> Am 18.12.2024 um 21:28 schrieb Jakub Jelinek :
>
> On Wed, Dec 18, 2024 at 01:19:43PM +0100, Andreas Schwab wrote:
>>> On Dez 12 2024, Jakub Jelinek wrote:
>>>
>>> The intent was to test %cN because %N doesn't DTRT on various targets.
>>> I have a patch to add %ccN support which should then
On Thu, Dec 19, 2024 at 3:36 AM Alexandre Oliva wrote:
>
>
> When we emit a sequence before a preexisting insn and naming a BB to
> store in the insns, we will attempt to store the BB even in barriers
> present in the sequence.
>
> Barriers don't expect blocks, and rtl checking catches the problem
On Wed, Dec 18, 2024 at 6:48 PM Robin Dapp wrote:
>
> Hi,
>
> in PR116351 we try to vectorize with -march=...zve32x which does not
> have 64-bit vector element sizes, don't find a proper mode and end up
> using word_mode = DImode.
>
> vect_verify_loop_lens calls get_len_load_store_mode which asser
On Wed, Dec 18, 2024 at 6:30 PM Jennifer Schmitz wrote:
>
>
>
> > On 17 Dec 2024, at 18:57, Richard Biener wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> >> Am 16.12.2024 um 09:10 schrieb Jennifer Schmitz :
> >>
> >>
> >>
> >>> On 14 Dec 2024, at 09:32, Richar
On Wed, Dec 18, 2024 at 04:44:55PM +0100, Jakub Jelinek wrote:
> The first check would flag something that is used in the wild, e.g.
> g++.dg/Wmissing-attributes.C
> gcc.dg/gnu23-attrs-2.c
> g++.dg/cpp0x/gen-attrs-81.C
> g++.dg/warn/Wdangling-reference17.C
> g++.dg/warn/Wdangling-reference20.C
> te
On 2024-12-17 22:29, Jason Merrill wrote:
On 12/17/24 1:44 PM, Torbjorn SVENSSON wrote:
Hi Jason,
Thanks for the quick feedback!
On 2024-12-16 17:11, Jason Merrill wrote:
On 12/16/24 7:16 AM, Torbjörn SVENSSON wrote:
Hi,
I've reg-tested this patch on both the trunk and the releases/gcc-14
Could you reduce the test files? just one test for each instruction is
fine, you don't need to put all tests into gcc source tree.
e.g. only pick test_sf_vc_v_xvw_u8mf4 and test_sf_vc_v_xvw_se_u16m4
for sf.vc.v.xvw
> diff --git a/gcc/config/riscv/genrvv-type-indexer.cc
> b/gcc/config/riscv/genrvv-type-indexer.cc
> index a2974269adc..e3b845d156e 100644
> --- a/gcc/config/riscv/genrvv-type-indexer.cc
> +++ b/gcc/config/riscv/genrvv-type-indexer.cc
> @@ -303,6 +303,8 @@ main (int argc, const char **argv)
>
From: yulong
This commit adds intrinsics support for Xsfvcp extension.
Co-Authored by: Jiawei Chen
Co-Authored by: Shihua Liao
Co-Authored by: Yixuan Chen
gcc/ChangeLog:
* config/riscv/constraints.md (Ou01): New constraint.
(Ou02): Ditto.
* config/riscv/generic-vecto
From: yulong
This patch implements the Sifvie vendor extension Xsfvfnrclipxfqf[1]
support to gcc. Providing support for FP32-to-int8 Ranged Clip
instrctions.
[1]
https://www.sifive.com/document-file/sifive-vector-coprocessor-interface-vcix-software
Co-Authored by: Jiawei Chen
Co-Authored by
94 matches
Mail list logo
