Enlargening the function-specific data block is not great. I've
considered changing the location of RETURN_STMT expressions to cover
everything from the return expression to input_location after parsing
the returned expr. The result of that is:
test.cc:38:3: error: a ‘return’ statement is not al
On 8/7/24 7:45 PM, Nathaniel Shead wrote:
On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote:
On 8/6/24 2:35 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Another potential approach would be to go searching for this unexported
type and l
On 8/7/24 7:22 PM, Nathaniel Shead wrote:
On Wed, Aug 07, 2024 at 04:18:47PM -0400, Jason Merrill wrote:
On 8/5/24 9:16 AM, Nathaniel Shead wrote:
Bootstrapped and regtested (so far just modules.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest passes?
OK.
@@ -11316,6 +11319,7 @@ tr
On 8/7/24 7:31 PM, Arsen Arsenović wrote:
Enlargening the function-specific data block is not great.
Indeed, I think it would be better to search DECL_SAVED_TREE for a
RETURN_STMT once we've decided to give an error.
I've
considered changing the location of RETURN_STMT expressions to cover
On 8/7/24 7:08 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This error message reads to me the wrong way around, particularly in the
context of other errors. Updated so that the ellipsis connect.
gcc/cp/ChangeLog:
* modul
On Thu, 8 Aug 2024, Nathaniel Shead wrote:
> On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote:
> > On 8/6/24 2:35 AM, Nathaniel Shead wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > Another potential approach would be to go searching for this
Jason Merrill writes:
> On 8/7/24 7:31 PM, Arsen Arsenović wrote:
>> Enlargening the function-specific data block is not great.
>
> Indeed, I think it would be better to search DECL_SAVED_TREE for a RETURN_STMT
> once we've decided to give an error.
The trouble with that is that finish_return_st
On Wed, 7 Aug 2024, Patrick Palka wrote:
> On Thu, 8 Aug 2024, Nathaniel Shead wrote:
>
> > On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote:
> > > On 8/6/24 2:35 AM, Nathaniel Shead wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > > >
> > > > Anot
Kindly ping++.
Pan
-Original Message-
From: Li, Pan2
Sent: Wednesday, July 31, 2024 9:12 AM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com;
rdapp@gmail.com
Subject: RE: [PATCH v1] RISC-V: Implement the quad and oct .SAT_TRUNC for sc
On Wed, Aug 07, 2024 at 09:12:13PM -0400, Patrick Palka wrote:
> On Wed, 7 Aug 2024, Patrick Palka wrote:
>
> > On Thu, 8 Aug 2024, Nathaniel Shead wrote:
> >
> > > On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote:
> > > > On 8/6/24 2:35 AM, Nathaniel Shead wrote:
> > > > > Bootstrap
The referenced page contains more explanation of auxname.gcda produced
by gcov profiler, which is a continuation of -fprofile-arcs's
description.
gcc/ChangeLog:
* doc/invoke.texi (Instrumentation Options): Move the cross
reference of "Cross-profiling" under the description for fla
On Aug 1, 2024, Alexandre Oliva wrote:
> Each iteration calls float_steady_clock::now() [...] an extra iteration
> will reach 5 and cause the test to fail.
> (Do we really want to use floats, that even with this tweak have
> borderline precision for sub-µs vs 1s deltas? Do we want to make sure
On Wed, Aug 07, 2024 at 08:45:03PM -0400, Jason Merrill wrote:
> On 8/7/24 7:22 PM, Nathaniel Shead wrote:
> > On Wed, Aug 07, 2024 at 04:18:47PM -0400, Jason Merrill wrote:
> > > On 8/5/24 9:16 AM, Nathaniel Shead wrote:
> > > > Bootstrapped and regtested (so far just modules.exp) on
> > > > x86_6
Currently, if a warning references a cloned function, the name of the cloned
function will be emitted in the "In function 'xyz'" part of the diagnostic,
which users aren't supposed to see. This patch follows the DECL_ORIGIN link
to get the name of the original function, so the internal compiler det
On 8/7/24 10:00 PM, Nathaniel Shead wrote:
On Wed, Aug 07, 2024 at 09:12:13PM -0400, Patrick Palka wrote:
On Wed, 7 Aug 2024, Patrick Palka wrote:
On Thu, 8 Aug 2024, Nathaniel Shead wrote:
On Wed, Aug 07, 2024 at 01:44:31PM -0400, Jason Merrill wrote:
On 8/6/24 2:35 AM, Nathaniel Shead wro
When rs1 is the immediate 0, the following ICE occurs:
error: unrecognizable insn:
(insn 8 5 12 2 (set (reg:RVVM1DI 134 [ ])
(if_then_else:RVVM1DI (unspec:RVVMF64BI [
(const_vector:RVVMF64BI repeat [
(const_int 1 [0x1])
On 8/7/24 9:00 PM, Arsen Arsenović wrote:
Jason Merrill writes:
On 8/7/24 7:31 PM, Arsen Arsenović wrote:
Enlargening the function-specific data block is not great.
Indeed, I think it would be better to search DECL_SAVED_TREE for a RETURN_STMT
once we've decided to give an error.
The trou
This patch add the vector rotate shift pattern for auto-vect.
With this patch, the scalar rotate shift can be automatically
vectorized into vector rotate shift.
gcc/ChangeLog:
* config/riscv/autovec.md (v3):
Add new define_expand pattern for vector rotate shift.
gcc/testsuite/Chan
Hello Alejandro,
On Thu, 8 Aug 2024 00:44:02 +0200, Alejandro Colomar wrote:
> +Its syntax is similar to @code{sizeof}.
For my curiosity, do you also make the same distinction that with
expressions you may omit the parenthesis?
I wouldn't be sure that we should continue that distinction from
`s
Optabs vcond{,u} will be removed for GCC 15. Since regtest shows no
fallout, dropping the expanders, now.
gcc/ChangeLog:
PR target/114189
* config/loongarch/lasx.md (vcondu): Delete.
(vcond): Likewise.
* config/loongarch/lsx.md (vcondu): Likewise.
(vcond):
We support vashr vlshr and vashl. However, in r15-1638 support optimize
x < 0 ? -1 : 0 into (signed) x >> 31 and x < 0 ? 1 : 0 into (unsigned) x >> 31.
To support this optimization, vector ashr lshr and ashl need to be implemented.
gcc/ChangeLog:
* config/loongarch/loongarch.md (insn): Ad
On Tue 2024-08-06 17:00:24, Gerald Pfeifer wrote:
> > +
> > +The following headers are used less widely in libstdc++ and may need to
> > +be included explicitly when compiling with GCC 15:
> > +
> > +
> > + (for std::int8_t, std::int32_t etc.)
> > +
>
> The text reads "headers", alas th
On Tue, 6 Aug 2024, Andrew MacLeod wrote:
>
> On 8/6/24 09:12, Richard Biener wrote:
> > Currently the forward threader isn't limited as to the search space
> > it explores and with it now using path-ranger for simplifying
> > conditions it runs into it became pretty slow for degenerate cases
> >
Am Mittwoch, dem 07.08.2024 um 01:12 +0200 schrieb Alejandro Colomar:
Hi Alex,
a coupled of comments below.
> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc
> @@ -74,7 +74,17 @@ along with GCC; see the file COPYING3. If not see
> #include "bitmap.h"
> #include "analyzer/analyzer-language.
On Wed, Aug 07, 2024 at 11:13:51AM +0800, Xiao Zeng wrote:
> gcc/ChangeLog:
>
> * builtin-types.def (BT_COMPLEX_BFLOAT16): Support BF16 node.
> (BT_BFLOAT16_PTR): Ditto.
> (BT_FN_BFLOAT16): New.
> (BT_FN_BFLOAT16_BFLOAT16): Ditto.
> (BT_FN_COMPLEX_BFLOAT16_COMPLEX_BFL
On Wed, 7 Aug 2024, Xi Ruoyao wrote:
> The check was implemented incorrectly, so vec_widen_smult_{even,odd}_M
> was never used. This is not good for targets with native even/odd
> widening multiplication but not lo/hi multiplication.
>
> The fix is actually developed by Richard Biener.
OK.
Tha
On Wed, Aug 7, 2024 at 8:57 AM Sam James wrote:
>
> Philipp Tomsich writes:
>
> Hi,
>
> > Sam, Jakub & Robin,
> >
> > We had an "OK for trunk" from Jeff for v4 (see
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656907.html) and
> > it has been two more weeks for this RESEND.
> > I'll pu
On Tue, Aug 6, 2024 at 8:50 PM Andi Kleen wrote:
>
> > - s += 16;
> > + v16qi data, t;
> > + /* Unaligned load. Reading beyond the final newline is safe, since
> > + files.cc:read_file_guts pads the allocation. */
>
> You need to change that function to use 32 byte padding as
On Tue, Aug 6, 2024 at 11:29 PM Andrew Pinski wrote:
>
> This is a small cleanup with respect to the ranger_op_table class.
> There should only ever be one instance of ranger_op_table so
> this adds a static member function which returns the instance.
> A few variables that are defined in range-op
On Wed, Aug 07, 2024 at 09:40:06AM +0200, Richard Biener wrote:
> On Tue, Aug 6, 2024 at 11:29 PM Andrew Pinski
> wrote:
> >
> > This is a small cleanup with respect to the ranger_op_table class.
> > There should only ever be one instance of ranger_op_table so
> > this adds a static member functi
On Wed, Aug 7, 2024 at 7:41 AM Alexander Monakov wrote:
>
>
> On Tue, 6 Aug 2024, Alexander Monakov wrote:
>
> > --- a/libcpp/files.cc
> > +++ b/libcpp/files.cc
> [...]
> > + pad = HAVE_AVX2 ? 32 : 16;
>
> This should have been
>
> #ifdef HAVE_AVX2
> pad = 32;
> #else
> pad = 16;
> #endif
OK
Hi Nelson,
Sounds good to me, too. Once get the approval, I will backport them to
binutils-2_43-branch :-)
Please could you ping me once you have done that.
I will make sure not to make the point release before receiving your message.
Cheers
Nick
On Wed, 2024-08-07 at 07:01 +0100, Sam James wrote:
> Xi Ruoyao writes:
>
> > The check was implemented incorrectly, so
> > vec_widen_smult_{even,odd}_M
> > was never used. This is not good for targets with native even/odd
> > widening multiplication but not lo/hi multiplication.
> >
> > The fi
On Wed, 7 Aug 2024, Richard Biener wrote:
> OK with that change.
>
> Did you think about a AVX512 version (possibly with 32 byte vectors)?
> In case there's a more efficient variant of pshufb/pmovmskb available
> there - possibly
> the load on the branch unit could be lessened with using maskin
Hi,The address david.br...@hesbynett.no is not bouncing. Its my email address,
and I'm getting the emails in this discussion just fine.However, I don't think
I have anything to contribute here, so I don't object to being removed from the
discussion. I am not a gcc developer, but as a long term
Hi!
SRA adds fancy names like offset$D94316$_M_impl$D93629$_M_start
where the numbers in there are DECL_UIDs if there are unnamed
FIELD_DECLs etc.
Because -g0 vs. -g can cause differences between the exact DECL_UID
values (add bigger gaps in between them, corresponding decls should
still be ordere
On Tue, Aug 6, 2024 at 4:38 PM Andi Kleen wrote:
>
> The gimple-if-to-switch pass converts if statements with
> multiple equal checks on the same value to a switch. This breaks
> vectorization which cannot handle switches.
>
> Teach the tree-if-conv pass used by the vectorizer to handle
> simple s
On Tue, Aug 6, 2024 at 6:19 PM Alexander Monakov wrote:
>
> Upcoming patches first drop Binutils ISA support from SSE4.2 to SSSE3,
> then bump it to AVX2. Instead of fiddling with detection, just bump
> our configure check to AVX2 immediately: if by some accident somebody
> builds GCC without AVX2
On Wed, Aug 7, 2024 at 9:42 AM Jakub Jelinek wrote:
>
> On Wed, Aug 07, 2024 at 09:40:06AM +0200, Richard Biener wrote:
> > On Tue, Aug 6, 2024 at 11:29 PM Andrew Pinski
> > wrote:
> > >
> > > This is a small cleanup with respect to the ranger_op_table class.
> > > There should only ever be one
Hi Nick,
Done for cherry-picking two patches to support riscv zimop and zcmop into
binutils-2_43-branch.
Commit bb566d7f, RISC-V: Add support for Zcmop extension
Commit 305fe5ed, RISC-V: Add support for Zimop extension
And also for gas/NEWS in the trunk, moved the entry into 2.43 section due
to t
Hi David,
On Wed, Aug 07, 2024 at 10:11:12AM GMT, david.brown wrote:
> Hi,The address david.br...@hesbynett.no is not bouncing. Its my email
> address, and I'm getting the emails in this discussion just fine.
Ahh, sorry, I didn't read the bounce notification properly; the address
is indeed reach
Hi Tobias!
On 2024-07-26T20:05:43+0200, Tobias Burnus wrote:
> The main idea of 'link' is to permit putting only a subset of a
> huge array on the device. Well, in order to make this work properly,
> it requires that one can map an array section, which does not
> start with the first element.
>
>
Richard Sandiford writes:
> Xi Ruoyao writes:
>> On Sat, 2024-07-20 at 06:52 +0100, Sam James wrote:
>>> Some distributions like Gentoo make -Wformat and -Wformat-security
>>> enabled by default. Pass -Wno-format to the test to avoid a spurious
>>> fail in such environments.
>>>
>>> gcc/testsui
Hi Andi!
On 2024-08-02T14:12:59-0700, Andi Kleen wrote:
> Andi Kleen writes:
>> This is a new attempt to fix PR116080. The previous try was reverted
>> because it just broke a bunch of tests, hiding the problem.
>
> The previous version still had one failure on powerpc because
> of a template ca
Solaris Ada bootstrap is broken as of 2024-08-06 with
s-taprop.adb:1971:23: error: "int" is not visible
s-taprop.adb:1971:23: error: multiple use clauses cause hiding
s-taprop.adb:1971:23: error: hidden declaration at s-osinte.ads:51
s-taprop.adb:1971:23: error: hidden declaration at i-c.ads:62
b
On Wed, 7 Aug 2024, Jakub Jelinek wrote:
> Hi!
>
> SRA adds fancy names like offset$D94316$_M_impl$D93629$_M_start
> where the numbers in there are DECL_UIDs if there are unnamed
> FIELD_DECLs etc.
> Because -g0 vs. -g can cause differences between the exact DECL_UID
> values (add bigger gaps in
On Wed, 7 Aug 2024, Richard Biener wrote:
> > > + data = *(const v16qi_u *)s;
> > > + /* Prevent propagation into pshufb and pcmp as memory operand. */
> > > + __asm__ ("" : "+x" (data));
> >
> > It would probably make sense to a file a PR on this separately,
> > to eventually fi
On Wed, Aug 07, 2024 at 11:03:18AM +0200, Richard Biener wrote:
> > Richi mentioned on IRC that the non-cleaned up names might make things
> > harder to feed stuff back to the GIMPLE FE, but if so, I think it should be
> > the dumping for GIMPLE FE purposes that cleans those up (but at that point
>
Hello,
Le 06/08/2024 à 22:57, Thomas Koenig a écrit :
Hi Mikael and Harald,
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion also dependent on -ffrontend-optimize?
(This was the case for rank-1 before your patch).
By the way, I disabled the min
Hi Martin,
On Wed, Aug 07, 2024 at 09:13:07AM GMT, Martin Uecker wrote:
> Am Mittwoch, dem 07.08.2024 um 01:12 +0200 schrieb Alejandro Colomar:
> > +#define c_parser_lengthof_expression(parser)
> >\
> > +(
From: Pan Li
This patch would like to support the form 1 of the scalar signed
integer .SAT_ADD. Aka below example:
Form 1:
#define DEF_SAT_S_ADD_FMT_1(T, MIN, MAX) \
T __attribute__((noinline)) \
sat_s_add_##T##_fmt_1 (T x, T y) \
{
Hello,
Le 06/08/2024 à 22:05, Harald Anlauf a écrit :
Hi Mikael,
thanks for this nice set of patches!
I've played around a bit, and it seems to look good.
I have only minor comments left (besides the nan issue raised):
- inline expansion is inhibited at -Os. But wouldn't it be good if
we
This patch add the vector rotate shift pattern for auto-vect.
With this patch, the scalar rotate shift can be automatically
vectorized into vector rotate shift.
signed-off-by: Feng Wang
gcc/ChangeLog:
* config/riscv/autovec-opt.md (v3):
Add define_expand for vector rotate
Hi Mikael, Thomas!
Am 07.08.24 um 11:11 schrieb Mikael Morin:
Hello,
Le 06/08/2024 à 22:57, Thomas Koenig a écrit :
Hi Mikael and Harald,
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion also dependent on -ffrontend-optimize?
(This was the case
Am Mittwoch, dem 07.08.2024 um 11:14 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> > > +void fix_fix (int i, char (*a)[3][5], int (*x)[__lengthof__ (*a)]);
> > > +void fix_var (int i, char (*a)[3][i], int (*x)[__lengthof__ (*a)]);
> > > +void fix_uns (int i, char (*a)[3][*], int (*x)[__length
diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index d7a3cfd4602..923122510ac 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -1607,3 +1607,19 @@
Such pattern which is natural auto-vectorization pattern should be in
autovec.md
On Wed, Aug 7, 2024 at 11:08 AM Alexander Monakov wrote:
>
>
> On Wed, 7 Aug 2024, Richard Biener wrote:
>
> > > > + data = *(const v16qi_u *)s;
> > > > + /* Prevent propagation into pshufb and pcmp as memory operand.
> > > > */
> > > > + __asm__ ("" : "+x" (data));
> > >
> > > It
On Wed, Aug 07, 2024 at 01:16:20PM +0200, Richard Biener wrote:
> Well, merging the memory operand into the pshufb would be wrong - embedded
> memory ops are always considered aligned, no?
Depends. For VEX/EVEX encoded can be unaligned, for the pre-AVX encoding
aligned except when in explicitly u
On Wed, 7 Aug 2024, Richard Biener wrote:
> > > This is probably to work around bugs in older compiler versions? If
> > > not I agree.
> >
> > This is deliberate hand-tuning to avoid a subtle issue: pshufb is not
> > macro-fused on Intel, so with propagation it is two uops early in the
> > CPU
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.
gcc/ChangeLog:
* builtin-types
This is a respin of my patchset implementing both the `dispatch` construct and
the `adjust_args` clause to the `declare variant` directive. The previous
submission can be found there:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657151.html.
Beside being rebased, this new iteration has th
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
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 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:
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 07cd75124b0..b35424c047a 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -294,8 +294,8 @@ T
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 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
My sincere apologies for not noticing that g++.dg/other/sse2-pr85572-1.C
was FAILing with my recent ashrv2di patch. I'm not sure how that happened.
Many thanks to Andrew Pinski for alerting me, and confirming that the
changes are harmless/beneficial. The following tweak to the testsuite
has bee
On Wed, Aug 7, 2024 at 1:37 PM Alexander Monakov wrote:
>
>
> On Wed, 7 Aug 2024, Richard Biener wrote:
>
> > > > This is probably to work around bugs in older compiler versions? If
> > > > not I agree.
> > >
> > > This is deliberate hand-tuning to avoid a subtle issue: pshufb is not
> > > macro-
CCed Fortran because of the first item:
This patch now uses (again like in v1) a builtin for
'omp_is_initial_device'; like in v2, it is compile-time evaluated, but
this time (new!) it also handled the case that a user wrote that routine.
Note: The omp_… namespace is owned by OpenMP, i.e. if i
On Wed, Aug 07, 2024 at 02:08:42PM +0200, Tobias Burnus wrote:
> On Aug 1, 2024, Jakub Jelinek wrote:
> > On Tue, Jul 30, 2024 at 10:51:56PM +0200, Tobias Burnus wrote:
> > > - char id[sizeof (SSDF_IDENTIFIER) + 1 /* '\0' */ + 32];
> > > + tree name;
> > > ...
> > I'd just use a single buffer her
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/thread.html#656299
patch.
Jonathan has acked the libstdc++ side thereof (I've added the
requested #undef on my side), is the c-cppbuiltin.cc side ok for trunk?
And, shall we (incrementally or right away) add some new tr
The following avoids lowering of PAREN_EXPR of vectors as unsupported
to scalars. Instead PAREN_EXPR is like a plain move or a VIEW_CONVERT.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. I plan
to push to branches, __builtin_assoc_barrier is new in GCC 12.
PR tree-optimiz
Hi All,
The optimization to generate a DI signbit constant by using fneg was relying
on nothing being able to push the constant into the negate. It's run quite
late for this reason.
However late combine now runs after it and triggers RTL simplification based on
the neg. When -fno-signed-zeros t
When rs1 is the immediate 0, the following ICE occurs:
error: unrecognizable insn:
(insn 8 5 12 2 (set (reg:RVVM1DI 134 [ ])
(if_then_else:RVVM1DI (unspec:RVVMF64BI [
(const_vector:RVVMF64BI repeat [
(const_int 1 [0x1])
This has been an active recent discussion on irc. I'll try to summarise
my position there here:
Ramana Radhakrishnan writes:
>> On 6 Aug 2024, at 4:14 PM, Richard Sandiford
>> wro>> Kyrylo Tkachov writes:
On 5 Aug 2024, at 18:00, Richard Sandiford
wro Kyrylo Tkachov writes:
>
Tamar Christina writes:
> Hi All,
>
> The optimization to generate a DI signbit constant by using fneg was relying
> on nothing being able to push the constant into the negate. It's run quite
> late for this reason.
>
> However late combine now runs after it and triggers RTL simplification based
Tested on x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
We do not support it currently, and the resulting memory can only be
used inside a single resumption, so best not confuse the user with it.
PR c++/115858 - Incompatibility of coroutines and alloca()
gcc/ChangeLog:
PR
This was supposed to go out the door yesterday, but I kept getting
interrupted.
The target bits for rtx costing can't assume the rtl they're given
actually matches a target pattern. It's just kind of inherent in how
the costing routines get called in various places.
In this particular case
Xianmiao Qu writes:
> With the increase in the number of modes and patterns for some
> backend architectures, the place_operands function becomes a
> bottleneck in the speed of genoutput, and may even become a
> bottleneck in the overall speed of building the GCC project.
> This patch aims to acce
On 8/7/24 3:42 AM, Feng Wang wrote:
This patch add the vector rotate shift pattern for auto-vect.
With this patch, the scalar rotate shift can be automatically
vectorized into vector rotate shift.
signed-off-by: Feng Wang
gcc/ChangeLog:
* config/riscv/autovec-opt.md (v3):
On 8/7/24 7:01 AM, Jin Ma wrote:
When rs1 is the immediate 0, the following ICE occurs:
error: unrecognizable insn:
(insn 8 5 12 2 (set (reg:RVVM1DI 134 [ ])
(if_then_else:RVVM1DI (unspec:RVVMF64BI [
(const_vector:RVVMF64BI repeat [
Hi!
The following patch attempts to implement DR2387 by making variable
templates including their specialization TREE_PUBLIC when at file
scope and they don't have static storage class.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-08-07 Jakub Jelinek
PR c
On 8/7/24 1:16 AM, Jakub Jelinek wrote:
This looks all wrong to me.
On all the other targets that already do support __bf16 type it is a storage
only type, so all arithmetics on it is expected to be done on float, not in
__bf16.
RISC-V has (via extensions) degrees of arithmetic/conversion s
On 8/7/24 12:27 AM, Christoph Müllner wrote:
Test file xtheadfmemidx-medany.c has been added in b79cd204c780 as a
test case that provoked an ICE when loading DFmode registers via two
SImode register loads followed by a SI->DF[63:32] move from XTheadFmv.
Since Zfa is affected in the same way as
On Wed, Aug 07, 2024 at 08:46:11AM -0600, Jeff Law wrote:
>
>
> On 8/7/24 1:16 AM, Jakub Jelinek wrote:
>
> >
> > This looks all wrong to me.
> >
> > On all the other targets that already do support __bf16 type it is a storage
> > only type, so all arithmetics on it is expected to be done on f
On Wed, 7 Aug 2024, Alejandro Colomar wrote:
> +@node Length
> +@section Determining the Length of Arrays
> +@cindex lengthof
> +@cindex length
> +@cindex array length
> +
> +The keyword @code{__lengthof__} determines the length of an array operand,
> +that is, the number of elements in the array.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
When a partial specialization is deemed erroneous at parse time, we
currently flag the primary template as erroneous instead. Later
at instantiation time we check if the primary template is erroneous
rather
On 8/7/24 12:27 AM, Christoph Müllner wrote:
We have a huge amount of optimization patterns (insn_and_split) for
XTheadMemIdx and XTheadFMemIdx that attempt to do something, that can be
done more efficient by generic GCC passes, if we have proper support code.
A key function in eliminating th
From: Saurabh Jha
This patch series is a respin of a previous patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/658984.html
The AArch64 FEAT_FAMINMAX is optional from Armv9.2-a and mandatory from
Armv9.5-a. It introduces instructions for computing the floating point
absolute maxi
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
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 does two things:
1. Introduces AdvSIMD faminmax intrinsics.
2. Move rep
On 8/7/24 12:27 AM, Christoph Müllner wrote:
When enabling XTheadFmv/Zfa and XThead(F)MemIdx, we might end up
with the following insn (registers are examples, but of correct class):
(set (reg:DF a4)
(mem:DF (plus:SI (mult:SI (reg:SI a0)
(const_int 8))
On 8/7/24 8:55 AM, Jakub Jelinek wrote:
On Wed, Aug 07, 2024 at 08:46:11AM -0600, Jeff Law wrote:
On 8/7/24 1:16 AM, Jakub Jelinek wrote:
This looks all wrong to me.
On all the other targets that already do support __bf16 type it is a storage
only type, so all arithmetics on it is expec
> > Okay for trunk? I would like to check that one in to avoid the noise
> > in the regression reports.
>
> I've tested this version in a few trees.
Thanks Thomas.
> That's because of effective-target 'struct_musttail' for '-m32'
> reporting:
>
> struct_musttail1494739.cc: In function 'foo
On 8/6/24 12:36 AM, Liao Shihua wrote:
在 2024/8/6 12:34, Jeff Law 写道:
On 8/5/24 10:23 AM, Patrick O'Neill wrote:
On 8/5/24 01:23, Liao Shihua wrote:
PR 116150: Zvk* and Zvb* extensions requires v or zve*
extension, but on gcc v is implied.
gcc/ChangeLog:
* common/co
Hi
Am 7. August 2024 17:05:48 MESZ schrieb Joseph Myers :
> On Wed, 7 Aug 2024, Alejandro Colomar wrote:
>
> > +@node Length
> > +@section Determining the Length of Arrays
> > +@cindex lengthof
> > +@cindex length
> > +@cindex array length
> > +
> > +The keyword @code{__lengthof__} determines the
On 8/7/24 11:09 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
When a partial specialization is deemed erroneous at parse time, we
currently flag the primary template as erroneous instead. Later
at instantiation time we
On 8/7/24 10:40 AM, Jakub Jelinek wrote:
Hi!
The following patch attempts to implement DR2387 by making variable
templates including their specialization TREE_PUBLIC when at file
scope and they don't have static storage class.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Tested on x86_64-darwin21, OK for trunk?
thanks
Iain
--- 8< ---
Bootstrap on Darwin, and likely any other targets using the posix
implementation of s-taprop was broken by commits between r15-2743
and r15-2747:
s-taprop.adb:297:15: error: "size_t" is not visible
s-taprop.adb:297:15: error: multipl
1 - 100 of 139 matches
Mail list logo
