On Fri, Aug 09, 2024 at 04:35:32PM +0100, Richard Sandiford wrote:
>
> But what I mean is: the code could just be:
>
> od = lookup_operand_data (&d->operand[0]);
> /* Brute force substring search. */
> for (; od; od = od->eq_next)
> {
> i = 1;
> while (1)
> {
>
On Fri, Aug 9, 2024 at 8:11 PM Xi Ruoyao wrote:
>
> On Fri, 2024-08-09 at 17:55 -0400, Vladimir Makarov wrote:
>
> > Still, for GCC developer novice, I think it is important to test all
> > major targets and aarch64 (one target on which bootstrap was broken) is
> > the 2nd most important target.
>
On Fri, 2024-08-09 at 17:55 -0400, Vladimir Makarov wrote:
> Still, for GCC developer novice, I think it is important to test all
> major targets and aarch64 (one target on which bootstrap was broken) is
> the 2nd most important target.
Linaro CI will complain (via off-list email) if a patch po
Hi Raphael,
On 8/8/24 10:10, Raphael Moreira Zinsly wrote:
> From: Raphael Zinsly
>
> Improve handling of constants where its upper and lower 32-bit
> halves are the same and Zbkb is not available in riscv_move_integer.
> riscv_split_integer already handles this but the changes in
> riscv_build_i
On 8/9/24 12:31 PM, Jeff Law wrote:
So Patrick's fuzzer found an interesting little buglet in the Zbs
improvements I added a couple months back.
Specifically when we have masked bit position for a Zbs instruction. If
the mask has extraneous bits set we'll generate an unrecognizable insn
du
On 8/9/24 17:00, Peter Bergner wrote:
On 8/9/24 12:02 PM, Vladimir Makarov wrote:
I believe your should reverse the original patch and all the patches you
submitted to fix the issues with the original patch.
I agree this commit should be reverted and Kyrill has pushed that already,
so bootstr
On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote:
> On 8/9/24 12:54 PM, Segher Boessenkool wrote:
> >> --- a/gcc/config/rs6000/altivec.md
> >> +++ b/gcc/config/rs6000/altivec.md
> >> @@ -623,7 +623,7 @@ (define_insn "altivec_eqv1ti"
> >>[(set (match_operand:V1TI 0 "altivec_register
On 8/9/24 3:30 PM, Patrick Palka wrote:
On Fri, 9 Aug 2024, Jason Merrill wrote:
On 8/9/24 2:32 PM, Patrick Palka wrote:
On Fri, 9 Aug 2024, Patrick Palka wrote:
On Fri, 9 Aug 2024, Jason Merrill wrote:
On 8/8/24 1:00 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-
On 8/9/24 4:21 PM, Marek Polacek wrote:
On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote:
On 8/8/24 1:37 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
The problem in this PR is that we ended up with
{.rows=(&)->n,
.outer_s
On 8/9/24 12:02 PM, Vladimir Makarov wrote:
> I believe your should reverse the original patch and all the patches you
> submitted to fix the issues with the original patch.
I agree this commit should be reverted and Kyrill has pushed that already,
so bootstrap should be restored now. Thank you K
On 8/9/24 12:54 PM, Segher Boessenkool wrote:
>> --- a/gcc/config/rs6000/altivec.md
>> +++ b/gcc/config/rs6000/altivec.md
>> @@ -623,7 +623,7 @@ (define_insn "altivec_eqv1ti"
>>[(set (match_operand:V1TI 0 "altivec_register_operand" "=v")
>> (eq:V1TI (match_operand:V1TI 1 "altivec_register
On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote:
> On 8/8/24 1:37 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > The problem in this PR is that we ended up with
> >
> >{.rows=(&)->n,
> > .outer_stride=(&)->rows}
On 8/6/24 7:12 AM, 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
like compiling insn-emit.cc for RISC-V esp. when compili
> On 9 Aug 2024, at 19:02, Vladimir Makarov wrote:
>
> External email: Use caution opening links or attachments
>
>
> On 8/9/24 08:58, Surya Kumari Jangala wrote:
>> I am looking into this failure.
>>
> Sorry for delay with this email. I was on vacation.
>
> I believe your should reverse t
On Fri, 9 Aug 2024, Jason Merrill wrote:
> On 8/9/24 2:32 PM, Patrick Palka wrote:
> > On Fri, 9 Aug 2024, Patrick Palka wrote:
> >
> > > On Fri, 9 Aug 2024, Jason Merrill wrote:
> > >
> > > > On 8/8/24 1:00 PM, Patrick Palka wrote:
> > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, do
On 8/7/24 03:13, Richard Biener wrote:
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 s
The other place a lot of time is being spent is in the recomputation
section. We have a depth limit parameter (ranger-recompuation-depth)
which defaults to 5, and specifies the number of statements back we will
look to recompute.. this allows us to recompute some relatively
complicated things.
Range_from_dom () fills the cache as it search so that subsequent
searches do not have to follow the full dominator chain and can pick up
values from the cache. This makes it self limiting from a cost point of
view. Normally. The exception was during equivalence processing when
the cache doe
> Am 09.08.2024 um 19:19 schrieb Richard Sandiford :
>
> This patch is an attempt to gauge opinion on one way of fixing PR30920.
>
> The PR points out that the libiberty splay tree implementation does
> not implement the algorithm described by Sleator and Tarjan and has
> unclear complexity b
On 8/9/24 2:32 PM, Patrick Palka wrote:
On Fri, 9 Aug 2024, Patrick Palka wrote:
On Fri, 9 Aug 2024, Jason Merrill wrote:
On 8/8/24 1:00 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk/14?
-- >8 --
This implements the inherited vs non
Hi!
The following patch implements the C++23 P2718R0 paper
- Wording for P2644R1 Fix for Range-based for Loop.
As all the temporaries from __for_range initialization should have life
extended until the end of __for_range scope, this patch disables (for C++23
and later only and if !processing_templ
On Fri, 9 Aug 2024, Patrick Palka wrote:
> On Fri, 9 Aug 2024, Jason Merrill wrote:
>
> > On 8/8/24 1:00 PM, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > > look OK for trunk/14?
> > >
> > > -- >8 --
> > >
> > > This implements the inherited vs non-
So Patrick's fuzzer found an interesting little buglet in the Zbs
improvements I added a couple months back.
Specifically when we have masked bit position for a Zbs instruction. If
the mask has extraneous bits set we'll generate an unrecognizable insn
due to an invalid constant.
More concre
On Fri, 9 Aug 2024, Jason Merrill wrote:
> On 8/8/24 1:00 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > look OK for trunk/14?
> >
> > -- >8 --
> >
> > This implements the inherited vs non-inherited guide tiebreaker
> > specified by P2582R1. In ord
Am 05.08.24 um 12:28 schrieb Stefan Schulze Frielinghaus:
This is a follow-up of
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654013.html
Hi Stefan,
as an addition, maybe a built-in macro is useful that tells the target
code whether the feature is available.
Similar to __GXX_CONSTEXPR_
Richard Sandiford writes:
> [...]
> /* Perform a shift right by CRC_SIZE as an extraction of lane 1. */
> machine_mode crc_vmode = aarch64_vq_mode (crc_mode).require ();
> a0 = (crc_size > data_size ? gen_reg_rtx (crc_mode) : operands[0]);
> emit_insn (gen_aarch64_get_lane (crc_vmode, a0,
Hi!
On Fri, Aug 09, 2024 at 05:50:18PM +0800, Kewen.Lin wrote:
> As PR116266 shows, we miss TARGET_P10_VECTOR to guard those
> Power10 related vector instructions as well as their
> according built-in functions. This patch is to introduce
> TARGET_P10_VECTOR which is actually TARGET_POWER10 &&
>
On 8/9/24 05:49, Kewen.Lin wrote:
Hi,
Commit r15-2084 exposes one ICE in LRA. Firstly, before
r15-2084 KFmode has 126 bit precision while V1TImode has 128
bit precision, so the subreg (subreg:V1TI (reg:KF 131) 0) is
paradoxical_subreg_p, which stops some passes from doing
some optimization.
Ok and thanks.
On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild wrote:
> Ping!
>
> And the last ping in the series. I have a "bigger" patch in the queue and
> want
> the pending ones done beforehand.
>
> Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> - Andre
>
> On Mon, 22 J
This patch is an attempt to gauge opinion on one way of fixing PR30920.
The PR points out that the libiberty splay tree implementation does
not implement the algorithm described by Sleator and Tarjan and has
unclear complexity bounds. (It's also somewhat dangerous in that
splay_tree_min and splay
On 8/8/24 11:30 AM, Patrick Palka wrote:
DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P templates can only appear as part
of a template friend declaration, and in turn get partially instantiated
only from tsubst_friend_function or tsubst_friend_class. So rather than
having tsubst_template_decl clear the
On 8/8/24 11:31 AM, Patrick Palka wrote:
The predicates for checking an IDENTIFIER node's cp_identifier_kind
currently directly test the three flag bits that encode the kind. This
patch instead makes the checks first reconstruct the cp_identifier_kind
in its entirety and then compare that.
OK.
On 8/8/24 1:00 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk/14?
-- >8 --
This implements the inherited vs non-inherited guide tiebreaker
specified by P2582R1. In order to track inherited-ness of a guide
it seems natural to reuse the la
On Sat, Jul 20, 2024 at 02:42:21PM -0600, Sandra Loosemore wrote:
> --- a/gcc/cgraph.h
> +++ b/gcc/cgraph.h
> @@ -900,6 +900,7 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node :
> public symtab_node
>ipcp_clone (false), declare_variant_alt (false),
>calls_declare_variant_alt (f
On 8/9/24 08:58, Surya Kumari Jangala wrote:
I am looking into this failure.
Sorry for delay with this email. I was on vacation.
I believe your should reverse the original patch and all the patches you
submitted to fix the issues with the original patch.
This is a standard procedure in s
On 8/8/24 1:37 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
The problem in this PR is that we ended up with
{.rows=(&)->n,
.outer_stride=(&)->rows}
that is, two PLACEHOLDER_EXPRs for different types on the same level
in one { }. That sh
On Fri, Aug 09, 2024 at 05:12:00PM +0100, Alex Coplan wrote:
> > > I suppose I was just concerned about any other properties of
> > > ANNOTATE_EXPRs that might be inherited from the operand (that could be
> > > affected by such a change).
> > >
> > > It looks like TREE_{READONLY,THIS_VOLATILE,SIDE
On Sat, Jul 20, 2024 at 02:42:20PM -0600, Sandra Loosemore wrote:
> +static tree
> +omp_encode_kind_arch_isa_props (tree props)
> +{
> + if (!props)
> +return NULL_TREE;
> + size_t length = 1;
> + for (tree p = props; p; p = TREE_CHAIN (p))
> +length += strlen (omp_context_name_list_prop
On 8/9/24 6:58 AM, Surya Kumari Jangala wrote:
I am looking into this failure.
Also note that it appears that this change is causing either an infinite
loop or severe compile-time regression for Wrestrict.
Build a cross for xstormy16-elf. You don't need a full toolchain, just
compiler shou
On 09/08/2024 17:56, Jakub Jelinek wrote:
> On Fri, Aug 09, 2024 at 04:46:55PM +0100, Alex Coplan wrote:
> > On 09/08/2024 17:34, Jakub Jelinek wrote:
> > > On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote:
> > > > Hmm, good spot, I didn't realise that convert_from_reference could
> > >
On Fri, Aug 09, 2024 at 11:03:24AM +1000, Nathaniel Shead wrote:
> On Thu, Aug 08, 2024 at 03:16:24PM -0400, Marek Polacek wrote:
> > On Thu, Aug 08, 2024 at 09:13:05AM +1000, Nathaniel Shead wrote:
> > > diff --git a/gcc/cp/error.cc b/gcc/cp/error.cc
> > > index 6c22ff55b46..03c19e4a7e4 100644
> >
> Hi Jin Ma,>
> Precommit has flagged a large number of ICEs with this patch on vector
> targets when applied to yesterday's daily bump[1]:
> https://github.com/ewlu/gcc-precommit-ci/issues/2037#issuecomment-2277469412
>
> Thanks,
> Patrick
>
> [1]
> https://github.com/gcc-mirror/gcc/commit/77cc
On 8/7/24 10:19, Will Hawkins wrote:
> 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 t
Gcc maintainers:
Version 2, based on discussion additional overloaded instances of the
vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins has been
added. The additional instances are for arguments of vector signed char
and vector bool char. The patch has been tested on Power 10
On Fri, Aug 09, 2024 at 04:46:55PM +0100, Alex Coplan wrote:
> On 09/08/2024 17:34, Jakub Jelinek wrote:
> > On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote:
> > > Hmm, good spot, I didn't realise that convert_from_reference could
> > > change the type of the condition like this.
> > >
On Fri, Aug 09, 2024 at 03:59:19PM GMT, Alejandro Colomar wrote:
> This operator is similar to sizeof but can only be applied to an array,
> and returns its length (number of elements).
>
> FUTURE DIRECTIONS:
>
> - We should make it work with array parameters to functions,
>and somehow magic
On 09/08/2024 17:34, Jakub Jelinek wrote:
> On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote:
> > Hmm, good spot, I didn't realise that convert_from_reference could
> > change the type of the condition like this.
> >
> > In that case I suppose the only thing to do is to construct a stac
Xianmiao Qu writes:
> On Wed, Aug 07, 2024 at 03:17:24PM +0100, Richard Sandiford wrote:
>> Looks like a nice speed-up thanks.
>>
>> A couple of general points:
>>
>> * Could you try using the more type-safe hash-table.h, instead of hashtab.h?
>> Similarly inchash.h for the hashing.
>>
>> * A
On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote:
> Hmm, good spot, I didn't realise that convert_from_reference could
> change the type of the condition like this.
>
> In that case I suppose the only thing to do is to construct a stack of
> ANNOTATE_EXPRs on the way down and re-build t
Hi Jin Ma,
Precommit has flagged a large number of ICEs with this patch on vector
targets when applied to yesterday's daily bump[1]:
https://github.com/ewlu/gcc-precommit-ci/issues/2037#issuecomment-2277469412
Thanks,
Patrick
[1]
https://github.com/gcc-mirror/gcc/commit/77ccfa6ac8d6e4dfefdea
Sorry again for the slow review. :(
I only really looked at the unreversed version earlier, on the basis
that the comments would apply to both versions. But I've got a couple
of comments about the reversed version below:
Mariam Arutunian writes:
> [...]
> diff --git a/gcc/config/aarch64/aarch64
On 09/08/2024 17:08, Jakub Jelinek wrote:
> On Fri, Aug 09, 2024 at 11:01:22AM -0400, Jason Merrill wrote:
> > > The CLEANUP_POINT_EXPR gets added by the following call chain:
> > >
> > > finish_while_stmt_cond
> > > -> maybe_convert_cond
> > > -> condition_conversion
> > > -> fold_build_cle
On 8/9/24 4:19 AM, Simon Martin wrote:
We have been accepting the following invalid code since revision 557831a91df
=== cut here ===
template struct S {
enum E { a };
enum E { b };
};
S s;
=== cut here ===
The problem is that start_enum will set OPAQUE_ENUM_P to true even if it
retrieves
On Fri, Aug 09, 2024 at 11:01:22AM -0400, Jason Merrill wrote:
> > The CLEANUP_POINT_EXPR gets added by the following call chain:
> >
> > finish_while_stmt_cond
> > -> maybe_convert_cond
> > -> condition_conversion
> > -> fold_build_cleanup_point_expr
> >
> > this patch chooses to fix the i
On 8/9/24 5:26 AM, Alex Coplan wrote:
For the testcase added with this patch, we would end up losing the:
#pragma GCC unroll 4
and emitting "warning: ignoring loop annotation". That warning comes
from tree-cfg.cc:replace_loop_annotate, and means that we failed to
process the ANNOTATE_EXPR i
This pass detects cases of expensive store forwarding and tries to avoid them
by reordering the stores and using suitable bit insertion sequences.
For example it can transform this:
strbw2, [x1, 1]
ldr x0, [x1] # Expensive store forwarding to larger load.
To:
ldr
On Wed, Aug 07, 2024 at 03:17:24PM +0100, Richard Sandiford wrote:
> Looks like a nice speed-up thanks.
>
> A couple of general points:
>
> * Could you try using the more type-safe hash-table.h, instead of hashtab.h?
> Similarly inchash.h for the hashing.
>
> * Although this wasn't always the
On 8/9/24 4:50 AM, Kewen.Lin wrote:
> As PR116266 shows, we miss TARGET_P10_VECTOR to guard those
> Power10 related vector instructions as well as their
> according built-in functions. This patch is to introduce...
LGTM.
The only change I would suggest is s/according/associated/ in
the sentence
Ping!
And the last ping in the series. I have a "bigger" patch in the queue and want
the pending ones done beforehand.
Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
- Andre
On Mon, 22 Jul 2024 16:35:28 +0200
Andre Vehreschild wrote:
> Hi all, hi Paul,
>
> you asked me to h
Ping!
@Paul, you already had a look at this patch, but I made some changes. Or they
ok?
- Andre
On Fri, 19 Jul 2024 13:26:21 +0200
Andre Vehreschild wrote:
> Hi Paul,
>
> thanks for the review.
>
> > While I realise that this is not your doing, should we not
> > check DECL_LANG_SPECIFIC ()) be
Ping!
On Wed, 17 Jul 2024 15:15:51 +0200
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes an ICE in coarray code, where the coarray expression
> already was a pointer, which confused the compiler. Furthermore have I removed
> a rewrite to a caf_send late in the trans-phase. This is no
Ping!
On Wed, 17 Jul 2024 15:11:33 +0200
Andre Vehreschild wrote:
> Hi all,
>
> and the last ping.
>
> Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> Regards,
> Andre
>
> On Thu, 11 Jul 2024 16:05:09 +0200
> Andre Vehreschild wrote:
>
> > Hi all,
> >
> > the attached
"Kewen.Lin" writes:
> Hi,
>
> As PR116148#c7 shows, fam-in-union-alone-in-struct-2.c still
> fails on hppa which is a BE environment, but by checking more
> (also confirmed by John in PR116148#c12), it's due to that
> signedness of plain char on hppa is signed therefore the value
> of with_fam_3_
There were two identical definitions, and none of them are available
where they are needed for implementing __lengthof__. Merge them, and
provide the single definition in gcc/tree.{h,cc}, where it's available
for __lengthof__, which will be added in the following commit.
gcc/ChangeLog:
*
This operator is similar to sizeof but can only be applied to an array,
and returns its length (number of elements).
FUTURE DIRECTIONS:
- We should make it work with array parameters to functions,
and somehow magically return the length designator of the array,
regardless of it being reall
The old name was misleading.
While at it, also rename some temporary variables that are used with
this function, for consistency.
Link:
https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120
Cc: Gabriel Ravier
Cc: Marti
Hi!
v6:
- Note that support for 0-length arrays is slightly broken.
- Improve readability of is_top_array_vla(), without changing behavior.
- Doc: Clarify that both types and expressions are accepted, and
provide an example. [Joseph]
- Doc: Wording improvements. [Joseph, Jens]
- Tests:
Hi, Kewen,
Thanks for the patch, LGTM.
Qing
> On Aug 9, 2024, at 05:50, Kewen.Lin wrote:
>
> Hi,
>
> As PR116148#c7 shows, fam-in-union-alone-in-struct-2.c still
> fails on hppa which is a BE environment, but by checking more
> (also confirmed by John in PR116148#c12), it's due to that
> si
The addition of -Wtemplate-body in r15-2774-g596d1ed9d40b10 means
we need to regenerate c.opt.urls.
gcc/c-family/ChangeLog:
* c.opt.urls: Regenerate.
---
gcc/c-family/c.opt.urls | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls
index
On Thu, Aug 08, 2024 at 04:48:38PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > The availability of tme intrinsics was previously gated at both
> > initialisation time (using global target options) and usage time
> > (accounting for function-specific target options). This patch r
I am looking into this failure.
Thanks,
Surya
On 09/08/24 2:37 am, Andrew Pinski wrote:
> On Fri, Aug 2, 2024 at 7:30 AM Jeff Law wrote:
>>
>>
>>
>> On 8/1/24 4:12 AM, Surya Kumari Jangala wrote:
>>> lra: emit caller-save register spills before call insn [PR116028]
>>>
>>> LRA emits insns to sav
Am Thu, Aug 08, 2024 at 02:06:44PM +0200 schrieb Richard Biener:
> On Mon, Aug 5, 2024 at 4:02 PM Juergen Christ wrote:
> >
> > Am Mon, Aug 05, 2024 at 01:00:31PM +0200 schrieb Richard Biener:
> > > On Fri, Aug 2, 2024 at 2:43 PM Juergen Christ
> > > wrote:
> > > >
> > > > Do not convert floats
On 09/08/2024 07:53, Thomas Schwinge wrote:
Hi Andrew!
On 2024-08-08T13:50:17+, Andrew Stubbs wrote:
Previously, trampolines worked on GCN3 devices, but the newer GCN5
devices had different permissions on the stack memory space we were
using.
That changed when we added the reverse-offload
This avoids a -Wpadded warning (testcase gcc.dg/20050607-1.c).
gcc/ChangeLog:
* config/gcn/gcn.cc (gcn_asm_trampoline_template): Add .align.
* config/gcn/gcn.h (TRAMPOLINE_SIZE): Increase to 40.
---
gcc/config/gcn/gcn.cc | 1 +
gcc/config/gcn/gcn.h | 2 +-
2 files changed, 2 ins
Hello,
and ping please.
Martin
On Fri, Jul 26 2024, Martin Jambor wrote:
> Hi,
>
> when looking at PR 115815 we realized that it would make sense to make
> calls to functions originally declared static constructors and
> destructors created by pass_ipa_cdtor_merge visible to IPA-SRA. This
> pat
Hello,
and ping please.
Martin
On Fri, Jul 26 2024, Martin Jambor wrote:
> Hi,
>
> in PR 115815, IPA-SRA thought it had control over all invocations of a
> (recursive) static destructor but it did not see the implied
> invocation which led to the original being left behind and the
> clean-up cod
Paul-Antoine Arras wrote:
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` f
On 09/08/2024 13:12, Richard Biener wrote:
>
>
> > Am 09.08.2024 um 11:30 schrieb Alex Coplan :
> >
> > When #pragma GCC unroll is processed in
> > tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll
> > field (which is currently streamed out and back in during LTO) but als
> Am 09.08.2024 um 11:30 schrieb Alex Coplan :
>
> When #pragma GCC unroll is processed in
> tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll
> field (which is currently streamed out and back in during LTO) but also
> the cfun->has_unroll flag.
>
> cfun->has_unroll, ho
Hi!
On 2024-08-07T14:08:42+0200, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.c++/static-aggr-constructor-destructor-1.C
> +// { dg-additional-options -foffload-options=-fdump-tree-optimized { target
> { offload_device_nvptx || offload_target_amdgcn } } }
Note here: '
On Fri, Aug 9, 2024 at 9:29 AM Jakub Jelinek wrote:
>
> Hi!
>
> The GENERIC folding of these builtins have cases where it folds to a
> constant regardless of the value of the first operand. If so, we need
> to use omit_one_operand to avoid throwing away side-effects in the first
> operand if any.
Applied the patchlet below.
Johann
--
AVR: Tidy up code for __[x]load insns.
gcc/
* config/avr/avr.md (*load__libgcc, *xload__libgcc):
Tidy up code.commit a90c74ab161eab09802920fbd894bf55bc4fa797
Author: Georg-Johann Lay
Date: Fri Aug 9 12:15:28 2024 +0200
AVR: Tidy up
Hi,
On Thu, Aug 08, 2024 at 02:07:50PM -0700, Andrew Pinski wrote:
> On Fri, Aug 2, 2024 at 7:30 AM Jeff Law wrote:
> > > 2024-08-01 Surya Kumari Jangala
> > >
> > > gcc/
> > > PR rtl-optimization/PR116028
> > > * lra-constraints.cc (split_reg): Spill register before call
> > >
Hi,
Gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html
BR,
Kewen
>> on 2024/7/12 00:15, Martin Jambor wrote:
>>> Hi,
>>>
>>> can I add myself to the bunch of people who are pinging this?
>>> Having
>>> this in will make our life easier.
>>>
>>> Thanks a lot,
> On 9 Aug 2024, at 11:03, Arsen Arsenović wrote:
>
> Jason Merrill writes:
>
>> On 8/8/24 4:29 PM, Arsen Arsenović wrote:
>>> Tested on x86_64-pc-linux-gnu. I have blinking tsan test results again,
>>> but I think they're bogus (I'll re-test on physical hardware before
>>> pushing if neede
Hi Carl,
on 2024/8/8 01:15, Carl Love wrote:
>
> 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 acce
Hi Carl,
on 2024/8/8 01:15, Carl Love wrote:
>
> 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 a
Hi Carl,
on 2024/8/8 01:15, Carl Love wrote:
>
> 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.
>
Jason Merrill writes:
> On 8/8/24 4:29 PM, Arsen Arsenović wrote:
>> Tested on x86_64-pc-linux-gnu. I have blinking tsan test results again,
>> but I think they're bogus (I'll re-test on physical hardware before
>> pushing if needed).
>> I'm somewhat curious of we should do a similar change WRT
Hi,
As PR116148#c7 shows, fam-in-union-alone-in-struct-2.c still
fails on hppa which is a BE environment, but by checking more
(also confirmed by John in PR116148#c12), it's due to that
signedness of plain char on hppa is signed therefore the value
of with_fam_3_v.a[7] "8f" get sign extended as "f
Hi,
As PR116266 shows, we miss TARGET_P10_VECTOR to guard those
Power10 related vector instructions as well as their
according built-in functions. This patch is to introduce
TARGET_P10_VECTOR which is actually TARGET_POWER10 &&
TARGET_VSX underlying, it updates many places that should
adopt TARGE
Hi,
Commit r15-2084 exposes one ICE in LRA. Firstly, before
r15-2084 KFmode has 126 bit precision while V1TImode has 128
bit precision, so the subreg (subreg:V1TI (reg:KF 131) 0) is
paradoxical_subreg_p, which stops some passes from doing
some optimization. After r15-2084, KFmode has the same mo
Hi,
Similar to r15-710-g458b23bc8b3e2b which removed all uses of
powerpc-*-linux*paired*, this patch is to remove the remaining
powerpc-*paired* uses which I missed to catch with "*linux*"
in search keyword.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and
powerpc64le-linux-gnu P9 and
> When compiling an interface for rounding of type 'vfloat16*' without using
> zvfh
> or zvfhmin, it is not enough to use FLOAT_MODE_P because the type does not
> support
> it. Although the subsequent riscv_validate_vector_type checks will still fail
> and throw exceptions, I don't think we shoul
When #pragma GCC unroll is processed in
tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll
field (which is currently streamed out and back in during LTO) but also
the cfun->has_unroll flag.
cfun->has_unroll, however, is not currently streamed during LTO, so this
patch attempt
Together with the preparatory compiler patches, this patch restores
unrolling in std::__find_if, but this time relying on the compiler to do
it by using:
#pragma GCC unroll 4
which should restore the majority of the regression relative to the
hand-unrolled version while still being vectorizable
For the testcase added with this patch, we would end up losing the:
#pragma GCC unroll 4
and emitting "warning: ignoring loop annotation". That warning comes
from tree-cfg.cc:replace_loop_annotate, and means that we failed to
process the ANNOTATE_EXPR in tree-cfg.cc:replace_loop_annotate_in_bl
I noticed while working on a test that uses LTO and requests a dump
file, that we are failing to cleanup ltrans dump files in the testsuite.
E.g. the test I was working on compiles with -flto
-fdump-rtl-loop2_unroll, and we end up with the following file:
./gcc/testsuite/g++/pr116140.ltrans0.ltra
This extends the scan-ltrans-tree* helpers to create RTL variants. This
is needed to check the behaviour of an RTL pass under LTO.
In particular it's used by a later patch in the series to check that
RTL unrolling is applied under LTO.
Tested as a series on aarch64-linux-gnu, OK for trunk?
gcc/
This patch series aims to address PR116140. The regression in xalancbmk
(both in SPEC 2006 and SPEC 2017) occurred when removing the
hand-unrolling in std::__find_if in libstdc++.
Keeping the loop re-rolled in the source is desirable as it allows the
function to be vectorized with WIP vectorizer
1 - 100 of 110 matches
Mail list logo
