From: Pan Li
In previous, we have some specially handling for both the .SAT_ADD and
.SAT_SUB for unsigned int. There are similar to take care of SImode
in RV64 for zero extend. Thus refactor these two helper function
into one for possible code duplication.
The below test suite are passed for t
From: Deepthi Hemraj
For excessively long environment variables i.e >128KB
Store the arguments in a temporary file and collect them back together in
collect2.
This commit patches for COLLECT_GCC_OPTIONS issue:
GCC should not limit the length of command line passed to collect2.
https://gcc.gnu.o
The following emulates classical interleaving for SLP load permutes
that we are unlikely handling natively. This is to handle cases
where interleaving (or load/store-lanes) is the optimal choice for
vectorizing even when we are doing that within SLP. An example
would be
void foo (int * __restric
The following emulates classical interleaving for SLP load permutes
that we are unlikely handling natively. This is to handle cases
where interleaving (or load/store-lanes) is the optimal choice for
vectorizing even when we are doing that within SLP. An example
would be
void foo (int * __restric
The following is a prototype for how to represent load/store-lanes
within SLP. I've for now settled with having a single load node
with multiple permute nodes acting as selection, one for each loaded lane
and a single store node fed from all stored lanes. For
for (int i = 0; i < 1024; ++i)
Thank you, Richard, for your feedback. I have removed the FILE_GCC_OPTION and
used COLLECT_GCC_OPTION exclusively to manage the long command line option. The
revised V2 patch has been posted and can be found at the following link:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661842.html
With recent SLP vectorization patches I see RISC-V divison by zero
for gfortran.dg/matmul_10.f90 and others in get_group_load_store_type
which does
&& can_div_trunc_p (group_size
* LOOP_VINFO_VECT_FACTOR (loop_vinfo) - gap,
Hello,
On 31/07/2024 00:49, Giuseppe D'Angelo wrote:
On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
Hi,
The attached patch is a stab at adding the necessary compiler builtin to
support std::is_virtual_base_of (P2985R0, approved for C++26). The name
of the builtin matches the one just merged int
Richard Biener writes:
> With recent SLP vectorization patches I see RISC-V divison by zero
> for gfortran.dg/matmul_10.f90 and others in get_group_load_store_type
> which does
>
> && can_div_trunc_p (group_size
> * LOOP_VINFO_VECT_FACTOR (loop_vinfo
From: Pan Li
This patch would like to support the vector signed ssadd pattern
for the RISC-V backend. Aka
Form 1:
#define DEF_VEC_SAT_S_ADD_FMT_1(T, UT, MIN, MAX) \
void __attribute__((noinline)) \
vec_sat_s_add_##T##_fmt_1 (T *out, T *x, T *y, unsign
On Fri, 30 Aug 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > With recent SLP vectorization patches I see RISC-V divison by zero
> > for gfortran.dg/matmul_10.f90 and others in get_group_load_store_type
> > which does
> >
> > && can_div_trunc_p (group_size
> >
On Wed, Aug 28, 2024 at 9:21 AM Richard Biener
wrote:
>
> On Wed, Aug 28, 2024 at 12:43 AM Edwin Lu wrote:
> >
> > On 8/22/2024 5:35 AM, Richard Biener wrote:
> > > On Thu, Aug 22, 2024 at 1:03 AM Edwin Lu wrote:
> > >>
> > >> Hi,
> > >>
> > >> Just wanted to ping this for more guidance.
> > >
>
With recent SLP vectorization patches I see RISC-V divison by zero
for gfortran.dg/matmul_10.f90 and others in get_group_load_store_type
which does
&& can_div_trunc_p (group_size
* LOOP_VINFO_VECT_FACTOR (loop_vinfo) - gap,
Currently we do SLP CSE after permute optimization using a single map across
all SLP instances. These SLP instances can affect many different basic blocks
and the cache may replace a statement in one block with one from another block.
Because there are no further limitations and the blocks may be v
It just clutters the dump files and takes up compile-time.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (vect_build_slp_tree_2): Disable SLP
reassociation for single-lane.
---
gcc/tree-vect-slp.cc | 2 ++
1 file changed, 2 insertions(+)
diff --
For more context please see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352#c11.
I've sent this as an RFC because it's hard to be sure that this was
just uncovered by r15-2820-gab18785840d7b8 rather than being
introduced by it.
Still, to the best of my knowledge after reading through the code,
Hello,
This patch completes the fix for PR108846, extending it to range-based
copy/move algorithms, and also fixes a faulty static_assert in them
(PR116471).
It's a minor improvement over the patch I've attached to PR116471 (I've
fixed the constraints of __assign_one).
Thank you,
--
Giuseppe
Hi,
As it stands, the pretty printing of GCC's vecs by gdbhooks.py only
handles vectors with vl_embed layout. As such, when encountering a vec
with vl_ptr layout, GDB would print a diagnostic like:
gdb.error: There is no member or method named m_vecpfx.
when (e.g.) any such vec occurred in a
The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
mandatory from Armv9.5-a. It introduces instructions for computing the
floating point absolute maximum and minimum of the two vectors element-wise.
This patch introduces AdvSIMD faminmax intrinsics. The intrinsics of
this extensio
From: Saurabh Jha
This patch series is a respin of
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661757.html.
The major refactorings suggested in the reviews to previous version will
be done separately to keep the scope of this series small. I'll create a
new series for that refactoring.
The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
mandatory from Armv9.5-a. It introduces instructions for computing the
floating point absolute maximum and minimum of the two vectors
element-wise.
This patch adds code generation support for famax and famin in terms of
existing R
On Fri, 30 Aug 2024, Manolis Tsamis wrote:
> For more context please see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352#c11.
>
> I've sent this as an RFC because it's hard to be sure that this was
> just uncovered by r15-2820-gab18785840d7b8 rather than being
> introduced by it.
> Still, t
This patch implements constant folding of binary operations for SVE intrinsics
by calling the constant-folding mechanism of the middle-end for a given
tree_code.
In fold-const.cc, the code for folding vector constants was moved from
const_binop to a new function vector_const_binop. This function ta
This patch implements constant folding for svdiv. If the predicate is
ptrue or predication is _x, it uses vector_const_binop with
aarch64_const_binop as callback and tree_code TRUNC_DIV_EXPR to fold constant
integer operands.
In aarch64_const_binop, a case was added for TRUNC_DIV_EXPR to return 0
f
This patch implements constant folding for svmul. If the predicate is
ptrue or predication is _x, it uses vector_const_binop with
aarch64_const_binop as callback and tree_code MULT_EXPR to fold constant
integer operands.
Tests were added to check the produced assembly for different
predicates, sign
writes:
> The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
> mandatory from Armv9.5-a. It introduces instructions for computing the
> floating point absolute maximum and minimum of the two vectors element-wise.
>
> This patch introduces AdvSIMD faminmax intrinsics. The intrinsics
Jennifer Schmitz writes:
> This patch implements constant folding of binary operations for SVE intrinsics
> by calling the constant-folding mechanism of the middle-end for a given
> tree_code.
> In fold-const.cc, the code for folding vector constants was moved from
> const_binop to a new function
There are cases, where opportunities to use POST_INC addressing
only occur very late in the compilation process. Take for example
the following function from AVR-LibC's qsort:
void swapfunc (char *a, char *b, int n)
{
do
{
char t = *a;
*a++ = *b;
*b++ = t;
} w
Jennifer Schmitz writes:
> This patch implements constant folding for svdiv. If the predicate is
> ptrue or predication is _x, it uses vector_const_binop with
> aarch64_const_binop as callback and tree_code TRUNC_DIV_EXPR to fold constant
> integer operands.
> In aarch64_const_binop, a case was ad
Jennifer Schmitz writes:
> This patch implements constant folding for svmul. If the predicate is
> ptrue or predication is _x, it uses vector_const_binop with
> aarch64_const_binop as callback and tree_code MULT_EXPR to fold constant
> integer operands.
> Tests were added to check the produced ass
On Thu, Aug 29, 2024 at 9:16 PM Richard Sandiford
wrote:
>
> Manolis Tsamis writes:
> > On Fri, Aug 16, 2024 at 5:33 PM Richard Sandiford
> > wrote:
> >> Manolis Tsamis writes:
> >> > +}
> >> > +
> >> > + virtual unsigned int execute (function *) override;
> >> > +}; // class pass_rtl_avoi
On Fri, Aug 30, 2024 at 2:10 PM Georg-Johann Lay wrote:
>
> There are cases, where opportunities to use POST_INC addressing
> only occur very late in the compilation process. Take for example
> the following function from AVR-LibC's qsort:
>
> void swapfunc (char *a, char *b, int n)
> {
> do
We currently do not expect comdat group of the guarded function to
be set at the time of generating pre and post check function.
However, in the case of an explicit instantiation, the guarded
function has been added to a comdat group before generating contract
check functions, which causes the obse
Hi,
I messed up the return value in check_effective_target_rvv_zvl256b_ok and
check_effective_target_rvv_zvl512b_ok. This fixes it and also just uses
the current march for the check.
Going to commit as obvious.
Regards
Robin
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Fix eff
On Fri, Aug 30, 2024 at 2:24 PM Richard Biener wrote:
>
> On Fri, 30 Aug 2024, Manolis Tsamis wrote:
>
> > For more context please see
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352#c11.
> >
> > I've sent this as an RFC because it's hard to be sure that this was
> > just uncovered by r15-
Am 30.08.24 um 14:46 schrieb Richard Biener:
On Fri, Aug 30, 2024 at 2:10 PM Georg-Johann Lay wrote:
There are cases, where opportunities to use POST_INC addressing
only occur very late in the compilation process. Take for example
the following function from AVR-LibC's qsort:
void swapfunc (
On Fri, Aug 30, 2024 at 3:28 PM Georg-Johann Lay wrote:
>
> Am 30.08.24 um 14:46 schrieb Richard Biener:
> > On Fri, Aug 30, 2024 at 2:10 PM Georg-Johann Lay wrote:
> >>
> >> There are cases, where opportunities to use POST_INC addressing
> >> only occur very late in the compilation process. Tak
Manolis Tsamis writes:
>> > I could have some help with that, because after the new changes a
>> > subreg related ICE also happens within store_bit_field when a DI ->
>> > V4SI case is hit. Afaik store_bit_field should just return NULL if it
>> > can't handle something so I don't really know how t
On Fri, 30 Aug 2024, Manolis Tsamis wrote:
> On Fri, Aug 30, 2024 at 2:24 PM Richard Biener wrote:
> >
> > On Fri, 30 Aug 2024, Manolis Tsamis wrote:
> >
> > > For more context please see
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352#c11.
> > >
> > > I've sent this as an RFC because i
30_threads/future/members/poll.cc has calibration code that, on
systems with very low clock resolution, may spuriously fail to run.
Even when it does run, low resolution and reasonable
timeouts limit severely the viability of increasing the loop counts so
as to reduce measurement noise, so we end
The following emulates classical interleaving for SLP load permutes
that we are unlikely handling natively. This is to handle cases
where interleaving (or load/store-lanes) is the optimal choice for
vectorizing even when we are doing that within SLP. An example
would be
void foo (int * __restric
Am 30.08.24 um 15:31 schrieb Richard Biener:
On Fri, Aug 30, 2024 at 3:28 PM Georg-Johann Lay wrote:
Am 30.08.24 um 14:46 schrieb Richard Biener:
On Fri, Aug 30, 2024 at 2:10 PM Georg-Johann Lay wrote:
There are cases, where opportunities to use POST_INC addressing
only occur very late in
The following is a prototype for how to represent load/store-lanes
within SLP. I've for now settled with having a single load node
with multiple permute nodes acting as selection, one for each loaded lane
and a single store node fed from all stored lanes. For
for (int i = 0; i < 1024; ++i)
The following removes the code cancelling SLP if we can use
load/store-lanes from the main loop vector analysis code and
re-implements it as re-discovering the SLP instance with
forced single-lane splits so SLP load/store-lanes scheme can be
used.
This is now done after SLP discovery and SLP patte
On Fri, 2024-08-30 at 12:08 +0100, Alex Coplan wrote:
> Hi,
>
> As it stands, the pretty printing of GCC's vecs by gdbhooks.py only
> handles vectors with vl_embed layout. As such, when encountering a
> vec
> with vl_ptr layout, GDB would print a diagnostic like:
>
> gdb.error: There is no mem
On Wed, Aug 21, 2024 at 04:00:23PM +, Joseph Myers wrote:
> On Thu, 1 Aug 2024, Jakub Jelinek wrote:
>
> > +Unsequenced functions without pointer or reference arguments are similar
> > +to functions with the @code{const} attribute, except that @code{const}
> > +attribute also requires finitnes
On Fri, Aug 30, 2024 at 12:34 AM wrote:
>
> From: Deepthi Hemraj
>
> For excessively long environment variables i.e >128KB
> Store the arguments in a temporary file and collect them back together in
> collect2.
>
> This commit patches for COLLECT_GCC_OPTIONS issue:
> GCC should not limit the len
On 30/08/2024 10:12, David Malcolm wrote:
> On Fri, 2024-08-30 at 12:08 +0100, Alex Coplan wrote:
> > Hi,
> >
> > As it stands, the pretty printing of GCC's vecs by gdbhooks.py only
> > handles vectors with vl_embed layout. As such, when encountering a
> > vec
> > with vl_ptr layout, GDB would pr
Jeff Law writes:
> On 8/29/24 10:13 AM, John David Anglin wrote:
>> Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11.
>> Committed to trunk.
>>
>> Dave
>> ---
>>
>> hppa: Fix handling of unscaled index addresses on HP-UX
>>
>> The PA-RISC architecture uses the top two bits of memory poi
Hi Harald,
The patch is good for mainline.
The PDT testcase is invalid because the component has a fixed length
initializer, while its length is a len parameter. One of the fixes that I
will have to do in the PDT revamp. Ignore it for now.
Thanks for the patch.
Paul
On Thu, 29 Aug 2024 at 2
> "Richard" == Richard Biener writes:
Richard> Honoring DECL_NAMELESS is obvious enough to me that I'd approve
Richard> such a change
Ok, how about the appended?
thanks,
Tom
commit 01ce41f7e0b023b7f67b48d85ead11cea1c96205
Author: Tom Tromey
Date: Thu Aug 29 13:23:18 2024 -0600
Chec
Hi Paul,
Am 30.08.24 um 18:09 schrieb Paul Richard Thomas:
Hi Harald,
The patch is good for mainline.
The PDT testcase is invalid because the component has a fixed length
initializer, while its length is a len parameter. One of the fixes that I
will have to do in the PDT revamp. Ignore it for
On Thu, Aug 29, 2024 at 10:05:35PM +0200, Harald Anlauf wrote:
>
> Am 29.08.24 um 21:53 schrieb Steve Kargl:
> > Thanks for the patch. If you have not already opened a new PR for the
> > other issue with C8107, I'll open one later today. It's likely that
> > we need to check the namelist-group-n
Am 30.08.24 um 18:33 schrieb Steve Kargl:
On Thu, Aug 29, 2024 at 10:05:35PM +0200, Harald Anlauf wrote:
Am 29.08.24 um 21:53 schrieb Steve Kargl:
Thanks for the patch. If you have not already opened a new PR for the
other issue with C8107, I'll open one later today. It's likely that
we need
On Fri, Aug 30, 2024 at 06:46:47PM +0200, Harald Anlauf wrote:
> Am 30.08.24 um 18:33 schrieb Steve Kargl:
> > On Thu, Aug 29, 2024 at 10:05:35PM +0200, Harald Anlauf wrote:
> > >
> > >
> > > Should we downgrade this extension to GFC_STD_LEGACY?
> >
> > I would support such a downgrade. In fact
Noticed that -save-tmp is ignored for parallel LTO. With this patch, the
result is now:
make -f ./a.ltrans.mk -j2 all
[Leaving LTRANS ./a.ltrans.mk]
instead of
make -f /tmp/ccXgtcjJ.mk -j2 all
[Leaving LTRANS /tmp/ccXgtcjJ.mk]
OK for mainline?
Tobias
lto-wrapper: Honor -save-temps for ltrans
Hi,
vec.h has this method:
template
inline T *
vec_safe_push (vec *&v, const T &obj CXX_MEM_STAT_INFO)
where v is a reference to a pointer to vec. This matches the regex for
VecPrinter, so gdbhooks.py attempts to print it but chokes on the reference.
I see the following:
#1 0x
On Fri, 30 Aug 2024, Jakub Jelinek wrote:
> Here is the full updated patch.
This patch is OK.
--
Joseph S. Myers
josmy...@redhat.com
On Fri, Aug 16, 2024 at 04:05:52PM +, Joseph Myers wrote:
> > > > + if (CPP_PEDANTIC (pfile))
> > > > +{
> > > > + if (CPP_OPTION (pfile, cplusplus))
> > > > + cpp_error (pfile, CPP_DL_PEDWARN,
> > > > + "#%s is a GCC extension", "embed");
> > > > + else if
On Fri, Aug 16, 2024 at 04:58:58PM +, Joseph Myers wrote:
> On Thu, 15 Aug 2024, Jakub Jelinek wrote:
>
> > + else
> > + {
> > + if (res > INTTYPE_MAXIMUM (off_t))
> > + cpp_error_with_line (pfile, CPP_DL_ERROR, loc, 0,
> > +"too larg
On Tue, Aug 20, 2024 at 05:23:04PM +, Joseph Myers wrote:
> On Thu, 15 Aug 2024, Jakub Jelinek wrote:
>
> > +#embed __FILE__ gnu::base64(1) prefix() suffix() /* { dg-error "expected
> > character string literal" } */
> > +#embed __FILE__ gnu::base64() prefix() suffix() /* { dg-error "expected
Hi!
As the following testcase shows, cp_parser_decl_specifier_seq
was calling warn_misplaced_attr_for_class_type only for class types
and not for enum types, while check_tag_decl calls them for both
class and enum types.
Enum types are really the same case here, the attribute needs to go
before th
Hi!
The following testcase shows another issue where we just ignored
attributes without telling user we did that.
If there are any declarators, the ignoring of the attribute
are diagnosed in grokdeclarator etc., but if there is none
(and we don't error such as on
int;
), the following patch emits
On Mon, Aug 19, 2024 at 05:05:51PM -0400, Jason Merrill wrote:
> > I've tried to compile it also with latest clang and there is agreement in
> > most of the diagnostics, just at block scope (inside of foo) it doesn't
> > diagnose
> >auto e = new int [n] [[deprecated]];
> >auto e2 = new int
On Wed, Aug 21, 2024 at 02:08:16PM -0400, Jason Merrill wrote:
> I was concerned about the use of a single boolean to guard the destruction
> of multiple objects, suspecting that it would break in obscure EH cases.
> When I finally managed to construct a testcase that breaks, I was surprised
> to s
Hi!
I'd like to ping 2 patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660046.html
c++: Implement C++23 P2718R0 - Wording for P2644R1 Fix for Range-based for
Loop [PR107637]
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659836.html
c++: Attempt to implement C++26 P303
> Am 30.08.2024 um 18:21 schrieb Tom Tromey :
>
>
>>
>> "Richard" == Richard Biener writes:
>
> Richard> Honoring DECL_NAMELESS is obvious enough to me that I'd approve
> Richard> such a change
>
> Ok, how about the appended?
Ok
Richard
> thanks,
> Tom
>
> commit 01ce41f7e0b023b
With HAVE_WORKING_FORK unset, I get an unused by set compile error.
That's fixed with the attached patch.
Tobias
PS: And if someone wonders what I am doing, see https://gcc.gnu.org/PR116535
lto/lto.cc: Fix build with not HAVE_WORKING_FORK
gcc/lto/ChangeLog:
* lto.cc: Add missing HAVE_WORKING
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here limit_bad_template_recursion avoids instantiating foo, and then we
wrongly warn that it isn't defined, because as a non-template (but
templated) friend DECL_TEMPLATE_INSTANTIATION is false.
gcc/cp/ChangeLog:
* decl2.cc (c_pars
Hi Steve, all,
the attached patch downgrades this feature from a GNU extension (silent
per default) to a legacy extension (warning by default).
The feature is tested in at least 4 gfortran testcases. I adjusted
the pattern of one of these tests to check for the downgrade.
Regtested on x86_64-p
On 8/26/24 10:45 AM, Segher Boessenkool wrote:
> On Thu, Aug 22, 2024 at 08:48:19PM -0500, Peter Bergner wrote:
>> I agree, there probably is code in the backend that currently handles TImode
>> that should probably be changed to handle both by using your new macro.
>
> That is what mode classes a
Harald,
I'm fine with the patch. You may want to wait to see
if anyone has a rasonable objection.
--
steve
On Fri, Aug 30, 2024 at 09:25:23PM +0200, Harald Anlauf wrote:
> Hi Steve, all,
>
> the attached patch downgrades this feature from a GNU extension (silent
> per default) to a legacy ext
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Redeclaration such as
void f(void);
consteval void f(void);
is invalid. In a namespace scope, we detect the collision in
validate_constexpr_redeclaration, but not when one declaration is
at block scope.
When we have
v
On 8/26/24 10:39 AM, Segher Boessenkool wrote:
> On Thu, Aug 22, 2024 at 05:39:36PM +0800, Kewen.Lin wrote:
>>> - if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode)
>>> + if (ALTIVEC_OR_VSX_VECTOR_MODE (mode) || mode == TImode
>>> + || mode == PTImode)
>>
>> Maybe
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
This got fixed by r15-2120.
PR c++/115616
gcc/testsuite/ChangeLog:
* g++.dg/template/friend83.C: New test.
---
gcc/testsuite/g++.dg/template/friend83.C | 24
1 file changed, 24 insertions(+)
creat
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
-fconcepts-ts is no longer supported so this can't be made to ICE
anymore.
PR c++/101099
gcc/testsuite/ChangeLog:
* g++.dg/concepts/pr101099.C: New test.
---
gcc/testsuite/g++.dg/concepts/pr101099.C | 6 ++
1 file chan
r14-575-g6d6c17e45f62cf changed the debug dump message but the testcase
pr66726-2.c was not updated for the change. The testcase was searching to
make sure we didn't factor out a conversion but the testcase was no longer
testing that so we needed to update what was being searched for.
Tested on x8
As GCC now treating implicit declaration of function as an error instead of
warning, compilation of libssp has been broken on some operating systems. The
following error is from an x86_64-unknown-freebsd11 system:
libssp/ssp.c: In function 'fail':
libssp/ssp.c:134:17: error: implic
As GCC now treating implicit declaration of function as an error instead of
warning, compilation of libssp has been broken on some operating systems.
The following error is from an x86_64-unknown-freebsd11 system:
libssp/ssp.c: In function 'fail':
libssp/ssp.c:134:17: error: implic
The heurstics that was added for PR71016, try to search to see
if the conversion was being moved away from its definition. The problem
is the heurstics would stop if there was a non GIMPLE_ASSIGN (and already
ignores
debug statements) and in this case we would have a GIMPLE_LABEL that was not
bein
As GCC now treating implicit declaration of function as an error instead of
warning, compilation of libssp has been broken on some operating systems.
The following error is from an x86_64-unknown-freebsd11 system:
libssp/ssp.c: In function 'fail':
libssp/ssp.c:134:17: error: implic
81 matches
Mail list logo
