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
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):
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
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
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
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 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
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 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
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
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 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
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, 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
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 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
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 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: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: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
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 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 load it, either with a new LO
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.
>
> > -- >8 --
> >
> > Currently name lookup generally seem
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This patch goes through all .cc files in gcc/cp and adds in any
auto_diagnostic_groups that seem to be missing by looking for any
'inform' calls that aren't grouped with their respective error/warning.
Now with SARIF output
On Linux/x86_64,
f1bfba3a9b3f31e3e06bfd1911c9f223869ea03f is the first bad commit
commit f1bfba3a9b3f31e3e06bfd1911c9f223869ea03f
Author: Tobias Burnus
Date: Wed Aug 7 19:31:19 2024 +0200
OpenMP: Constructors and destructors for "declare target" static aggregates
caused
FAIL: libgomp.c++
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >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:
* module.cc (trees_in::read_enum_def): Clarify error.
gcc
Hi Jens, Joseph,
On Wed, Aug 07, 2024 at 05:30:13PM GMT, Jens Gustedt wrote:
> 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
> > > +@c
On 7/3/24 10:37 AM, Jakub Jelinek wrote:
Hi!
With the PR115754 fix in, constexpr placement new mostly just works,
so this patch just adds constexpr keyword to the placement new operators
in , adds FTMs and testsuite coverage.
There is one accepts-invalid though, the
new (p + 1) int[]{2, 3};
On 8/7/24 12:28, Jeff Law wrote:
> On 8/7/24 11:47 AM, Richard Sandiford wrote:
>> I should probably start by saying that the "model" heuristic is now
>> pretty old and was originally tuned for an in-order AArch32 core.
>> The aim wasn't to *minimise* spilling, but to strike a better balance
>> bet
This is a small C++11-ificiation for the use of vect_vect_recog_func_ptrs.
Changes the loop into a range based loop which then we can remove the variable
definition of NUM_PATTERNS. Also uses const reference instead of a pointer.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
Hi Martin,
On Wed, Aug 07, 2024 at 12:07:00PM GMT, Martin Uecker wrote:
> > > void foo(char (*a)[*], int x[*]);
> > > void foo(char (*a)[*], int x[__lengthof__(*a)]);
> >
> > But [*] is a VLA. Do we want to return a constexpr for it?
>
> No, my point is only that we could have a test for not
>
This patch to the Go frontend avoids assuming that ATTRIBUTE_UNUSED is
defined. While it is defined when building the Go frontend as part of
GCC, it is meant to work with other compilers as well. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
e89ddb749517ea
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.
-- >8 --
Currently name lookup generally seems to assume that all entities
declared within a named module (partition) are attached t
The attach patch is specific to the RTEMS RISC-V architecture multilib which is
controlled by the t-rtems file in the gcc/config/riscv/ directory. The patch
file was created from the gcc-13.3.0 branch. It was successfully tested within
RTEMS Source Builder.
gcc-13.3.0-RTEMS-riscv-multilib.pa
> > + /* Create chain of switch tests for each case. */
> > + tree switch_cond = NULL_TREE;
> > + tree index = gimple_switch_index (sw);
> > + for (unsigned i = 1; i < gimple_switch_num_labels (sw); i++)
> > + {
> > + tree label = gimple_switch
Tested on x86_64-darwin21, pushed to trunk, thanks
Iain
--- 8< ---
XCode compilers recognise the weak_framework linker option in the driver
and forward it. This patch makes GCC adopt the same behaviour.
PR target/116237
gcc/ChangeLog:
* config/darwin.h (SUBTARGET_DRIVER_SELF_S
On 8/7/24 11:47 AM, Richard Sandiford wrote:
I should probably start by saying that the "model" heuristic is now
pretty old and was originally tuned for an in-order AArch32 core.
The aim wasn't to *minimise* spilling, but to strike a better balance
between parallelising with spills vs. sequent
On top of what Jonathan said, Teju Jagua yields a smaller binary size since
it needs fewer look-up tables.
Regarding performance and correctness:
1) My patch passes all the tests.
2) The GitHub project of the reference implementation (*) scans all floats
and the results of Teju Jagua, Ryu and Dr
On Linux/x86_64,
5b97d1a2102dca57918947d7e40a6ca68871 is the first bad commit
commit 5b97d1a2102dca57918947d7e40a6ca68871
Author: Richard Biener
Date: Wed Aug 7 13:54:53 2024 +0200
tree-optimization/116258 - do not lower PAREN_EXPR of vectors
caused
FAIL: gcc.target/i386/pr116258
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, August 7, 2024 11:27 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; Richard Sandiford
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_CO
On Wed, Aug 07, 2024 at 11:10:37AM +0200, Jakub Jelinek wrote:
> > In any case how about the simpler
> >
> > if (!DECL_NAME (object) || DECL_NAMELESS (object))
> > DECL_NAME (object) = create_tmp_var_name ("C");
> >
> > ?
>
> This is what I had in my first version, but I was wo
On Wed, Aug 07, 2024 at 05:53:00PM +, Prathamesh Kulkarni wrote:
> > Two spaces after . rather than just one, and because of that move in
> > on the next line.
> >
> > > + host_num_poly_int_coeffs. */
> >
> > Otherwise LGTM.
> Thanks, I have adjusted the formatting of the comment and a typ
> -Original Message-
> From: Jakub Jelinek
> Sent: Monday, August 5, 2024 8:01 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; Richard Sandiford
> ; gcc-patches@gcc.gnu.org
> Subject: Re: Support streaming of poly_int for offloading when it's
> degree <= accel's NUM_POLY_INT_COEFFS
I should probably start by saying that the "model" heuristic is now
pretty old and was originally tuned for an in-order AArch32 core.
The aim wasn't to *minimise* spilling, but to strike a better balance
between parallelising with spills vs. sequentialising. At the time,
scheduling without taking
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 load it, either with a new LOOK_want::ANY_REACHABLE flag or by
expanding on the lookup_imported_temploid_fri
The following test was failing when building on 32 bit targets
due to not overwriting the mabi arg. This resulted in dejagnu
attempting to run the test with -mabi=ilp32d -march=rv64gcv_zvl256b
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr116202-run-1.c: Add mabi arg
Signed-off-
Steve, Peter, Kewen:
Yes, it does look like supporting signed and unsigned char would be
consistent with the vec_cmpeq built-in.n I have played around with
adding both and it looks to be reasonable.
Per your second response:
On 8/7/24 9:25 AM, Steven Munroe wrote:
This Message Is From an
On Mon, Jul 29, 2024 at 2:14 PM David Faust wrote:
>
>
> On 7/29/24 07:42, Will Hawkins wrote:
> > If the user provides a kind value that is more than 5 bits, the
> > BTF_KIND_INFO macro would emit incorrect values for info (by clobbering
> > values of the kind flag).
> >
> > Tested on x86_64-redh
GCC maintainers:
The following patch fixes errors in the definition of the
__builtin_vsx_uns_floate_v2di, __builtin_vsx_uns_floato_v2di and
__builtin_vsx_uns_float2_v2di built-ins. The arguments should be
unsigned but are listed as signed.
Additionally, there are a number of test cases
GCC maintainers:
The patch removed the built-in __builtin_vsx_xvcvuxwdp as it is covered
by the overloaded vec_doubleo built-in.
The patch has been tested on Power 10 LE and BE with no regressions.
Please let me know if it is acceptable for mainline. Thanks.
Carl
---
GCC maintainers:
The following patch removes two redundant built-ins
__builtin_vsx_vperm_8hi and __builtin_vsx_vperm_8hi_uns. The built-ins
are covered by the overloaded vec_perm built-in.
The patch has been tested on Power 10 LE and BE with no regressions.
Please let me know if it is acc
GCC maintainers:
The following patch adds missing test cases for the overloaded vec_perm
built-in. It also fixes and issue with printing the 128-bit values in
the DEBUG section that was noticed when adding the additional test cases.
The patch has been tested on Power 10 LE and BE with no r
I forgot to state what changed in the v2. Now, following the DECL_ORIGIN
is done in lhd_print_error_function instead of lhd_decl_printable_name
because lhd_decl_printable_name was used in other circumstances, like
dumping RTL. This caused test failures.
Currently, if a warning references a cloned function, the name of the cloned
function will be emitted in the "In function %qs" 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.
gcc/ChangeLog:
PR dia
GCC maintainers:
The following series of patches for PowerPC removes some built-ins that
are covered by existing overloaded built-ins. Additionally, there are
patches to add missing testcases and documentation.
The patch series has been tested on Power 10 LE and BE with no regressions.
Pl
On Wed, Aug 07, 2024 at 06:58:23PM +0200, Jakub Jelinek wrote:
> > For Fortran, this plus into gfc_get_extern_function_decl, i.e. that name
> > appears as external declaration. While the user could mess around, it checks
> > that it is a function and the return type is the expected on (i.e. logical
On Wed, Aug 07, 2024 at 05:57:05PM +0200, Tobias Burnus wrote:
> for C/C++, -fno-builtin-omp_is_initial_device already disabled the
> expansion.
Good idea.
> RFC: Should be document this new built-in some where? If so, where? As part
> of the routine description in libgomp.texi? Or in extend.texi
The commit for PR 116258, added a x86_64 specific testcase,
I thought it would be a good idea to add an aarch64 testcase too.
And since it also fixed VLA vectors too so add a SVE testcase.
Pushed as obvious after a test for aarch64-linux-gnu.
PR middle-end/116258
PR middle-end/116
Hi Thomas,
Thomas Schwinge wrote:
The new test case 'libgomp.c-c++-common/target-link-2.c' generally PASSes
on one-GPU systems, but on a multi-GPU system (tested nvidia5):
After having debugged it, it became glaringly obvious, but could
otherwise be missed …
The testcase checks that mapping
Hi Jakub,
for C/C++, -fno-builtin-omp_is_initial_device already disabled the
expansion.
I added it also for Fortran. Plus added a C and a Fortran testcase for
the disable flag.
* * *
Wording wise, it failed before for Fortran with:
f951: Warning: command-line option ‘-fno-builtin-omp_is_i
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
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?
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
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/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
> > 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/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
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))
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
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
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
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
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 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.
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 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 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
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 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 [
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):
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
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
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
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
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:
>
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])
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
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!
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
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
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 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-
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
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
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 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:
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 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 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
1 - 100 of 139 matches
Mail list logo
