On Thu, 2 Feb 2023, Qing Zhao wrote:
>
>
> > On Feb 2, 2023, at 8:54 AM, Richard Biener wrote:
> >
> > On Thu, 2 Feb 2023, Qing Zhao wrote:
> >
> >>
> >>
[...]
> >> + return flexible_size_type_p (TREE_TYPE (last));
> >
> > For types with many members this can become
On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches
wrote:
>
> I'm reposting these two patches that allow GCC to build on Fedora 36 just to
> be
> clear which patches I'm talking about. The issue is that if GCC is configured
> with long double using the IEEE 128-bit representation,
On Thu, Feb 2, 2023 at 6:39 PM Michael Meissner via Gcc-patches
wrote:
>
> The new __dmr type that is being added as a possible future PowerPC
> instruction
"is being added" means this feature is already in GCC 13?
> set bumps into a structure field size issue. The size of the __dmr type is
On Thu, Feb 2, 2023 at 5:20 PM Martin Jambor wrote:
>
> Hi,
>
> when the compiled program contains type mismatches between callers and
> callees when it comes to a parameter, IPA-CP can try to propagate one
> constant from callers while IPA-SRA may try to split a parameter
> expecting a value of
Hi Richard,
While digging thru aarch64_expand_vector_init, I noticed it gives
priority to loading a constant first:
/* Initialise a vector which is part-variable. We want to first try
to build those lanes which are constant in the most efficient way we
can. */
which results in
committed, thanks!
On Wed, Feb 1, 2023 at 6:15 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: New test.
>
> ---
> .../riscv/rvv/base/shift_vx_constraint-1.c| 133 ++
> 1 file changed, 133
committed, thanks!
On Wed, Feb 1, 2023 at 6:08 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * config/riscv/predicates.md (pmode_reg_or_uimm5_operand): New
> predicate.
> * config/riscv/riscv-vector-builtins-bases.cc: New class.
> *
committed, thanks!
On Wed, Feb 1, 2023 at 9:48 AM wrote:
>
> From: Ju-Zhe Zhong
>
> Current constraint configuration will generate:
> vadd.vv v0,v24,v25,v0.t
> vsll.vx v0,v24,a5,v0.t
>
> They are incorrect according to RVV ISA.
> This patch fix this obvious issue.
>
> gcc/ChangeLog:
>
>
committed, thanks!
On Wed, Feb 1, 2023 at 6:20 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * g++.target/riscv/rvv/base/vsra_vx-1.C: New test.
> * g++.target/riscv/rvv/base/vsra_vx-2.C: New test.
> * g++.target/riscv/rvv/base/vsra_vx-3.C: New test.
>
committed, thanks!
On Wed, Feb 1, 2023 at 6:18 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * g++.target/riscv/rvv/base/vsrl_vx-1.C: New test.
> * g++.target/riscv/rvv/base/vsrl_vx-2.C: New test.
> * g++.target/riscv/rvv/base/vsrl_vx-3.C: New test.
>
committed, thanks!
On Wed, Feb 1, 2023 at 6:10 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/vsrl_vx-1.c: New test.
> * gcc.target/riscv/rvv/base/vsrl_vx-2.c: New test.
> * gcc.target/riscv/rvv/base/vsrl_vx-3.c: New test.
>
committed, thanks!
On Wed, Feb 1, 2023 at 6:11 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/vsra_vx-1.c: New test.
> * gcc.target/riscv/rvv/base/vsra_vx-2.c: New test.
> * gcc.target/riscv/rvv/base/vsra_vx-3.c: New test.
>
committed, also updated mask for ALL_REGS, thanks.
On Fri, Feb 3, 2023 at 12:59 PM Monk Chiang wrote:
>
> Avoid VL_REGS, VTYPE_REGS join register allocation.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h: Remove VL_REGS, VTYPE_REGS class.
> * config/riscv/riscv.cc: Ditto.
> ---
>
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/constraints.md (Wdm): Adjust constraint.
(Wbr): New constraint.
* config/riscv/predicates.md (reg_or_int_operand): New predicate.
* config/riscv/riscv-protos.h (emit_pred_op): Remove function.
This patch reworks how the complex multiply and divide built-in functions are
done. Previously we created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit. The old code also did not
support __ibm128 complex multiply and divide if long
This patch is a repost of a patch:
| Date: Thu, 19 Jan 2023 11:37:27 -0500
| Subject: [PATCH] PR target/107299: Fix build issue when long double is IEEE
128-bit
| Message-ID:
This patch updates the IEEE 128-bit types used in libgcc.
At the moment, we cannot build GCC when the target uses IEEE
I'm reposting these two patches that allow GCC to build on Fedora 36 just to be
clear which patches I'm talking about. The issue is that if GCC is configured
with long double using the IEEE 128-bit representation, it currently cannot
build _mulkc3 and _divkc3 in libgcc.
Note, these patches do
Avoid VL_REGS, VTYPE_REGS join register allocation.
gcc/ChangeLog:
* config/riscv/riscv.h: Remove VL_REGS, VTYPE_REGS class.
* config/riscv/riscv.cc: Ditto.
---
gcc/config/riscv/riscv.cc | 8 +---
gcc/config/riscv/riscv.h | 6 --
2 files changed, 1 insertion(+), 13
On 2023-02-02 03:33, Richard Biener wrote:
looking at PR77650 what seems missing there is the semantics of this
extension as expected/required by the glibc use. comment#5 seems
to suggest that for my example above its expected that
Y.x.data[0] aliases Y.end?! There must be a better way to
On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
wrote:
>
> Hi,
>
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
> not
On Thu, Feb 02, 2023 at 21:24:12 +0100, Harald Anlauf wrote:
> Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
> > Hi,
> >
> > This patch series adds initial support for ISO C++'s [P1689R5][], a
> > format for describing C++ module requirements and provisions based on
> > the source
On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
wrote:
>
> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > >> >> > I have attached a patch that extends the transform if one half is
> > >> >> > dup
> > >> >> > and other is set of constants.
> >
On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> >> >> > I have attached a patch that extends the transform if one half is dup
> >> >> > and other is set of constants.
> >> >> > For eg:
> >> >> > int8x16_t f(int8_t x)
> >> >> > {
> >> >> > return
That might be sufficient for this case, but temploid friends violate an
assumption of the implementation -- namely that module A cannot create an entity
that belongs in module B's symbol table. This causes a bunch of excitement,
particularly around handling (well formed) duplicatd instantions.
Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
been completed yet, but that doesn't work:
/* We can't lower this until the class is complete. */
if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
return cst;
and then this unlowered PTRMEM_CST is used
WG14 has agreed to allow equality comparisons between pointers and
nullptr_t values that are not null pointer constants (this was
previously an exceptional case where such nullptr_t values were
handled differently from null pointer constants; other places in the
standard allowed nullptr_t values,
On 1/30/23 14:10, Patrick Palka wrote:
In check_methods we're unnecessarily checking satisfaction for all
constructors and assignment operators, even those that don't look like
copy/move special members. In the testcase below this manifests as an
unstable satisfaction error because the
On 1/30/23 16:36, Patrick Palka wrote:
Here we're crashing from check_bases_and_members due to
CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning
performed by add_method, should only happen if there is no viable
destructor or the destructor is ambiguous.
This patch fixes this by
On 1/30/23 21:35, Marek Polacek wrote:
In this test case, we find ourselves evaluating 't' which is
((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)]
in cxx_eval_array_reference. ctx->object is non-null, a RESULT_DECL, so
we replace it with 't':
new_ctx.object = t; //
Pushed.
Gerald
---
htdocs/gcc-11/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 4787fc26..cc0fdc19 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -807,7 +807,7 @@ You may
On 2/2/23 13:09, Patrick Palka wrote:
Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose pruned callee is wrapped in
an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR. This ends up causing a bogus declaration
Hi!
On 2023-02-01T16:12:07+0100, Martin Jambor wrote:
> On Thu, Oct 20 2022, Richard Biener via Gcc-patches wrote:
>>> Am 20.10.2022 um 14:41 schrieb Jakub Jelinek via Gcc-patches
>>> :
>>> On Thu, Oct 20, 2022 at 12:33:28PM +, Michael Matz wrote:
> On Thu, 20 Oct 2022, Thomas Schwinge
Tested cris-elf, native x86_64-pc-linux-gnu.
Ok to commit?
--- 8< ---
These appear as regressions from a baseline before
r13-3761-ga239a63f868e29. See the PR trail.
Note that the warning for g++.dg/pr71488.C is for a *header*
file, thus we can't match the line number (sanely).
gcc/testsuite:
Hi Ben,
Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
Hi,
This patch series adds initial support for ISO C++'s [P1689R5][], a
format for describing C++ module requirements and provisions based on
the source code. This is required because compiling C++ with modules is
not
WG14 has agreed some changes (detailed at the end of N3082) to the
rules on constexpr initializers for floating types. Update GCC's
implementation to match: binary initializers are now allowed for
decimal types, and real initializers for complex types, but signaling
NaN initializers can't be used
This is PR 96088 but this time for _Rb_tree based containers.
I guess it won't go in for the moment but I wanted to submit it already
because of the changes I had to do in stl_functions.h. It sounds like
missing parts for C++11 move-semantic. I still need to run all tests to
see if they can
Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose pruned callee is wrapped in
an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR. This ends up causing a bogus declaration matching error in
the below testcase
Tested x86_64-linux, built on avr. Pushed to trunk.
I might backport this to gcc-12 too, although realistically I doubt
anybody is going to try to use the filesystem library on avr anyway, so
it doesn't matter.
-- >8 --
Because avr-libc defines most error numbers with duplicate
values it's not
Tested powerpc64le-linux. Pushed to trunk.
This could be backported to gcc-11 and gcc-12 but I have no immediate
plans to do that (it's needed on trunk because of the new stuff in
and that stuff isn't on the branches).
-- >8 --
Unlike the new str()&& members in , there is no real difficulty
in
The new __dmr type that is being added as a possible future PowerPC instruction
set bumps into a structure field size issue. The size of the __dmr type is
1024 bits.
The precision field in tree_type_common is currently 10 bits, so if you store
1,024 into field, you get a 0 back. When you get 0
On Thu, Feb 02, 2023 at 02:31:53PM +, Qing Zhao wrote:
>
> > On Feb 2, 2023, at 3:33 AM, Richard Biener wrote:
> >
> > On Wed, 1 Feb 2023, Siddhesh Poyarekar wrote:
> >
> >> On 2023-02-01 13:24, Qing Zhao wrote:
> >>>
> >>>
> On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar
>
Tested powerpc64le-linux. Pushed to trunk.
The source code changes should be backported (the linker script changes
aren't needed because those symbols aren't present on the branches).
-- >8 --
With -fkeep-inline-functions there are linker errors when including
. This happens because there are
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
This was approved at the October 2021 plenary.
libstdc++-v3/ChangeLog:
* include/std/variant (variant::operator=): Implement resolution
of LWG 3585.
* testsuite/20_util/variant/lwg3585.cc: New test.
---
Hi,
when the compiled program contains type mismatches between callers and
callees when it comes to a parameter, IPA-CP can try to propagate one
constant from callers while IPA-SRA may try to split a parameter
expecting a value of a different size on the same offset. This then
currently leads to
On 02/02/2023 14:59, Tobias Burnus wrote:
Maybe it becomes better reviewable with an attached patch ...
On 02.02.23 15:31, Tobias Burnus wrote:
Now that the stack handling has been changed for AMDGCN, this patch
enables reverse offload.
(cf. today's "[committed] amdgcn, libgomp: Manually
Prathamesh Kulkarni writes:
>> >> > I have attached a patch that extends the transform if one half is dup
>> >> > and other is set of constants.
>> >> > For eg:
>> >> > int8x16_t f(int8_t x)
>> >> > {
>> >> > return (int8x16_t) { x, 1, x, 2, x, 3, x, 4, x, 5, x, 6, x, 7, x, 8 };
>> >> > }
>> >>
> > Thank you so much. Kito helped me fix it already.
> > RVV instruction patterns can have CSE optimizations now.
> What was the issue?
VL and VTYPE isn't listed in fixed register so CSE feel that isn't
cheap (See CHEAP_REGNO in cse.cc),
but actually it's kind of mistake sett for VL and VTYPE
Maybe it becomes better reviewable with an attached patch ...
On 02.02.23 15:31, Tobias Burnus wrote:
Now that the stack handling has been changed for AMDGCN, this patch
enables reverse offload.
(cf. today's "[committed] amdgcn, libgomp: Manually allocated stacks"
patch email/commit
by Andrew).
insn_info tried to save space by storing the number of
definitions in a 16-bit bitfield. The justification was:
// ... FIRST_PSEUDO_REGISTER + 1
// is the maximum number of accesses to hard registers and memory, and
// MAX_RECOG_OPERANDS is the maximum number of pseudos that can be
//
This test was failing on aarch64 because aarch64 overrides
TARGET_CASE_VALUES_THRESHOLD. The maximum value that allows
the test to pass appears to be 6, but the default threshold
is 4 or 5 (depending on whether casesi is provided).
Going for 4 seemed safest, in case any target-specific
features
On Wed, 1 Feb 2023 at 21:56, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 12 Jan 2023 at 21:21, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
> >> > wrote:
> >> >>
> >> >> On Mon, 5 Dec 2022
We set VL/VTYPE these 2 implicit global status denpency register as fixed reg.
Then CSE can do the optimization now.
>> Yea. I'm wondering about when the right place to introduce these
>>dependencies might be. I'm still a few months out from worrying about
>>RVV, but it's not too far away.
You
> On Feb 2, 2023, at 8:54 AM, Richard Biener wrote:
>
> On Thu, 2 Feb 2023, Qing Zhao wrote:
>
>>
>>
>>> On Feb 2, 2023, at 3:07 AM, Richard Biener wrote:
>>>
>>> On Wed, 1 Feb 2023, Qing Zhao wrote:
>>>
> On Feb 1, 2023, at 6:41 AM, Richard Biener wrote:
>
>
On 2/2/23 05:35, juzhe.zh...@rivai.ai wrote:
Thank you so much. Kito helped me fix it already.
RVV instruction patterns can have CSE optimizations now.
What was the issue?
jeff
On 2/2/23 05:26, Richard Biener wrote:
On Thu, 2 Feb 2023, juzhe.zh...@rivai.ai wrote:
Yeah, Thanks. You are right. CSE should do the job.
Now I know the reason CSE failed to optimize is I include
VL_REGNUM(66)/VTYPE_RENUM(67) hard reg
as the dependency of pred_broadcast:
(insn 19 18 20 4
> On Feb 2, 2023, at 3:33 AM, Richard Biener wrote:
>
> On Wed, 1 Feb 2023, Siddhesh Poyarekar wrote:
>
>> On 2023-02-01 13:24, Qing Zhao wrote:
>>>
>>>
On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar
wrote:
On 2023-01-31 09:11, Qing Zhao wrote:
> Update
Now that the stack handling has been changed for AMDGCN, this patch enables
reverse offload.
(cf. today's "[committed] amdgcn, libgomp: Manually allocated stacks" patch
email/commit
by Andrew).
Any comments, suggestions?
Tobias
-
Siemens Electronic Design Automation GmbH;
Hi!
The recent change to undo the tree_code_type/tree_code_length
excessive duplication apparently broke building the Linux kernel
plugin. While it is certainly desirable that GCC plugins are built
with the same compiler as GCC has been built and with the same options
(at least the important
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Integration testing shows it fixes a false positive seen on qemu, and
has no other changes.
Pushed to trunk as r13-5655-gd84dc419e692d4.
gcc/analyzer/ChangeLog:
PR analyzer/108633
* sm-fd.cc
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-5654-g598e10cf415f0a.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/deref-before-check-qemu-qtest_rsp_args.c: New test.
Signed-off-by: David Malcolm
---
.../deref-before-check-qemu-qtest_rsp_args.c | 73
Found when testing AMD GCN offloading, the second issue came up with
libgomp.fortran/reverse-offload-5.f90. (But oddly not with nvptx.)
While the first one (new test: libgomp.fortran/reverse-offload-6.f90)
came up when debugging the issue.
Tobias
-
Siemens Electronic Design
On Wed, Jan 25, 2023 at 16:06:31 -0500, Ben Boeckel wrote:
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
> not embarrassingly
On Thu, 2 Feb 2023, Qing Zhao wrote:
>
>
> > On Feb 2, 2023, at 3:07 AM, Richard Biener wrote:
> >
> > On Wed, 1 Feb 2023, Qing Zhao wrote:
> >
> >>
> >>
> >>> On Feb 1, 2023, at 6:41 AM, Richard Biener wrote:
> >>>
> >>> On Tue, 31 Jan 2023, Qing Zhao wrote:
> >>>
> GCC extension
> On Feb 2, 2023, at 3:07 AM, Richard Biener wrote:
>
> On Wed, 1 Feb 2023, Qing Zhao wrote:
>
>>
>>
>>> On Feb 1, 2023, at 6:41 AM, Richard Biener wrote:
>>>
>>> On Tue, 31 Jan 2023, Qing Zhao wrote:
>>>
GCC extension accepts the case when a struct with a flexible array member
ack, just let you know reviewing this patch is on my todo list :)
My first impression is...you need to write something in your
changelog, it seems like generated by contrib/git-commit-mklog.py
without any modification.
On Thu, Feb 2, 2023 at 1:46 PM Jin Ma wrote:
>
> This patch adds the 'Zfa'
On Thu, Feb 2, 2023 at 12:41 PM Iain Sandoe wrote:
>
>
>
> > On 30 Jan 2023, at 07:48, Richard Biener wrote:
> >
> > On Sun, Jan 29, 2023 at 12:35 PM Iain Sandoe via Gcc-patches
> > wrote:
> >>
> >> Technically, this is seems to be a regression somewhere between 4.2 and
> >> 4.6 but, it seems,
Good catch! thanks for fixing that, committed to trunk :)
On Thu, Feb 2, 2023 at 7:46 PM Jin Ma wrote:
>
> MAX_MATCH_SCORE is not assigned anywhere except initialized to 0,
> causing BEST_MATCH_MULTI_LIB to always be 0 or -1, which will
> cause the result of TARGET_COMPUTE_MULTILIB hook to fail.
On Thu, Feb 02, 2023 at 12:19:56PM +0100, Tobias Burnus wrote:
> There is less new in TR11 as claimed ... 'strict' on grainsize/num_tasks is
> already
> in OpenMP 5.1, it is implemented and also listed as 'Y' under 5.1.
> Only 'num_threads(strict: int-expr)' is new in TR11.
>
> Tobias
>
Thank you so much. Kito helped me fix it already.
RVV instruction patterns can have CSE optimizations now.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-02-02 20:26
To: juzhe.zh...@rivai.ai
CC: gcc-patches; kito.cheng; richard.sandiford; jeffreyalaw; apinski
Subject: Re: Re: [PATCH]
On Thu, Feb 2, 2023 at 10:49 AM Richard Sandiford via Gcc-patches
wrote:
>
> Since rtl-ssa isn't a real/native SSA representation, it has
> to honour the constraints of the underlying rtl representation.
> Part of this involves maintaining an rpo list of definitions
> for each rtl register,
On Thu, 2 Feb 2023, juzhe.zh...@rivai.ai wrote:
> Yeah, Thanks. You are right. CSE should do the job.
> Now I know the reason CSE failed to optimize is I include
> VL_REGNUM(66)/VTYPE_RENUM(67) hard reg
> as the dependency of pred_broadcast:
> (insn 19 18 20 4 (set (reg:VNx1DI 152)
> >
On Wed, Feb 1, 2023 at 7:12 PM Andrew MacLeod via Gcc-patches
wrote:
>
> We can reset SCEV after we fold, then SCEVs cache shouldn't have
> anything in it when we go to remove ssa-names in remove_unreachable().
>
> We were resetting it later sometimes if we were processing the array
> bounds
Ping!!
From: Gcc-patches
on behalf of
Srinath Parvathaneni via Gcc-patches
Sent: 27 January 2023 17:44
To: gcc-patches@gcc.gnu.org
Cc: nd ; Richard Earnshaw ; Kyrylo
Tkachov
Subject: [PATCH][GCC] arm: Optimize arm-mlib.h header inclusion (pr108505).
Hello,
On Thu, 2 Feb 2023, Alexandre Oliva wrote:
> On Jan 27, 2023, Jakub Jelinek wrote:
>
> > Now, 1) is precondition of 2), we can only subst the VALUEs if we
> > have actually looked the address up, but as can be seen on that testcase,
> > we are relying on at least the 1) to be done because we
I've committed this patch to change the ways stacks are initialized on
amdgcn. The patch only touches GCN files, or the GCN-only portions of
libgomp files, so I'm allowing it despite stage 4 because I want the ABI
change done for GCC 13, and because it enables Tobias's reverse
offload-patch
MAX_MATCH_SCORE is not assigned anywhere except initialized to 0,
causing BEST_MATCH_MULTI_LIB to always be 0 or -1, which will
cause the result of TARGET_COMPUTE_MULTILIB hook to fail.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc:
---
gcc/common/config/riscv/riscv-common.cc | 5
> On 30 Jan 2023, at 07:48, Richard Biener wrote:
>
> On Sun, Jan 29, 2023 at 12:35 PM Iain Sandoe via Gcc-patches
> wrote:
>>
>> Technically, this is seems to be a regression somewhere between 4.2 and
>> 4.6 but, it seems, not enough for anyone to care too much. Tested on
>> various
The following fixes a problem with ! handling in genmatch which isn't
conservative enough when intermediate simplifications push to the
sequence but the final operation appears to just pick an existing
(but in this case newly defined in the sequence) operand. The easiest
fix is to disallow adding
On 01/02/2023 15:35, Paul-Antoine Arras wrote:
This patch introduces an instruction pattern for conditional shift
operations (cond_{ashl|ashr|lshr}) in the GCN machine description.
Tested on GCN3 Fiji gfx803.
OK to commit?
The changelog will need to be wrapped to 80 columns.
OK otherwise.
There is less new in TR11 as claimed ... 'strict' on grainsize/num_tasks is
already
in OpenMP 5.1, it is implemented and also listed as 'Y' under 5.1.
Only 'num_threads(strict: int-expr)' is new in TR11.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße
On Jan 27, 2023, Jakub Jelinek wrote:
> Now, 1) is precondition of 2), we can only subst the VALUEs if we
> have actually looked the address up, but as can be seen on that testcase,
> we are relying on at least the 1) to be done because we subst the values
> later on even on DEBUG_INSNs and
Ping^2
Richard Sandiford writes:
> [I posted this late in stage 4 as an RFC, but it wasn't suitable for
> GCC 12 at that point. I kind-of dropped the ball after that, sorry.]
>
> Various parts of the omp code checked whether the size of a decl
> was an INTEGER_CST in order to determine whether
Since rtl-ssa isn't a real/native SSA representation, it has
to honour the constraints of the underlying rtl representation.
Part of this involves maintaining an rpo list of definitions
for each rtl register, backed by a splay tree where necessary
for quick lookup/insertion.
However, clobbers of
On Thu, 2 Feb 2023, Jakub Jelinek wrote:
> Hi!
>
> For PR106099 I've added IFN_TRAP as an alternative to __builtin_trap
> meant for __builtin_unreachable purposes (e.g. with -funreachable-traps
> or some sanitizers) which doesn't need vops because __builtin_unreachable
> doesn't need them
Hi!
For PR106099 I've added IFN_TRAP as an alternative to __builtin_trap
meant for __builtin_unreachable purposes (e.g. with -funreachable-traps
or some sanitizers) which doesn't need vops because __builtin_unreachable
doesn't need them either. This works in various cases, but unfortunately
IPA
Hi!
When gimplifying OMP_CLAUSE_{LASTPRIVATE,LINEAR}_STMT, we wrap it always
into a GIMPLE_BIND, but when putting statements directly into
OMP_CLAUSE_{LASTPRIVATE,LINEAR}_GIMPLE_SEQ, we do it only if needed (there
are any temporaries that need to be declared in the sequence).
On Thu, 2 Feb 2023, liuhongt wrote:
> Normally when vf is not constant, it will be prevented by
> vectorizable_nonlinear_inductions, but for this case, it failed going
> into
>
> if (STMT_VINFO_RELEVANT_P (stmt_info))
> {
> need_to_vectorize = true;
> if
Hi,
this patch adds LEN_LOAD/LEN_STORE support for z14 and newer.
It defines a bias value of -1 and implements the LEN_LOAD and LEN_STORE
optabs.
It also includes various vll/vstl testcases adapted from Kewen Lin's patch
for Power.
Bootstrapped and regtested on z13-z16.
Is it OK?
Regards
On Wed, 1 Feb 2023, Siddhesh Poyarekar wrote:
> On 2023-02-01 13:24, Qing Zhao wrote:
> >
> >
> >> On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar
> >> wrote:
> >>
> >> On 2023-01-31 09:11, Qing Zhao wrote:
> >>> Update documentation to clarify a GCC extension on structure with
> >>> flexible
On Wed, 1 Feb 2023, Qing Zhao wrote:
>
>
> > On Feb 1, 2023, at 6:41 AM, Richard Biener wrote:
> >
> > On Tue, 31 Jan 2023, Qing Zhao wrote:
> >
> >> GCC extension accepts the case when a struct with a flexible array member
> >> is embedded into another struct (possibly recursively).
> >>
90 matches
Mail list logo
