On Tue, 24 Sep 2024, Prathamesh Kulkarni wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, September 9, 2024 7:24 PM
> > To: Prathamesh Kulkarni
> > Cc: Richard Sandiford ; Thomas Schwinge
> > ; gcc-patches@gcc.gnu.org
> > Subject: RE: Re-compute TYPE_MODE an
On Thu, Sep 19, 2024 at 2:08 PM Richard Biener
wrote:
>
> On Wed, Sep 18, 2024 at 7:55 PM Richard Sandiford
> wrote:
> >
> > Richard Biener writes:
> > > On Thu, Sep 12, 2024 at 4:50 PM Hongtao Liu wrote:
> > >>
> > >> On Wed, Sep 11, 2024 at 4:21 PM Hongtao Liu wrote:
> > >> >
> > >> > On We
> Can you explain how you get to see constant/external defs with
> astmt_vec_info? That's somehow a violation of some inherentinvariant in the
> vectorizer.
I'm not sure I actually get any. It could be the condition is never hit with a
stmt_vec_info. I had assumed however since the condition i
On Tue, Sep 24, 2024 at 09:44:48AM +1000, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> This fixes some inconsistencies with what kinds of linkage various
> entities are assumed to have. This also fixes handling of exported
> using-dec
Got it and thanks, let me rerun to make sure it works well as expected.
Pan
-Original Message-
From: Uros Bizjak
Sent: Tuesday, September 24, 2024 2:33 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; richard.guent...@gmail.com;
tamar.christ...@arm.com; juzhe.zh...@rivai.ai; kito.ch...@gm
On Mon, 23 Sep 2024, Tamar Christina wrote:
> I had made the condition to strict before, here's an updated patch:
>
> Hi All,
>
> The previous check if a value was external was checking
> !vect_get_internal_def (vinfo, var) but this of course isn't completely right
> as they could reductions etc
On Tue, 24 Sept 2024, 00:44 Nathaniel Shead,
wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
OK, thanks
> -- >8 --
>
> This makes the declarations internal linkage, which is an ODR issue, and
> causes a future modules patch to fail regtest as it now detects attempte
Part of the problem in PR114855 is high update_ssa time. When one fixes
the backward jump threading issue tree SSA incremental is at
439.91s ( 26%), mostly doing bitmap element searches for
blocks_with_phis_to_rewrite. The following turns that bitmap to tree
view noticing the two-dimensional vect
On Mon, Sep 23, 2024 at 3:41 PM Jason Merrill wrote:
>
> On 9/23/24 9:05 AM, Richard Biener wrote:
> > On Sat, Sep 21, 2024 at 2:49 AM Jason Merrill wrote:
> >>
> >> Tested x86_64-pc-linux-gnu. OK for trunk?
> >>
> >> -- 8< --
> >>
> >> We've been using -Wno-narrowing since gcc 4.7, but at this
On Tue, Sep 24, 2024 at 8:24 AM Li, Pan2 wrote:
>
> Thanks Uros for comments.
>
> > This is not "target", but "middle-end" component. Even though the bug
> > is exposed on x86_64 target, the fix is in the middle-end code, not in
> > the target code.
>
> Sure, will rename to middle-end.
>
> > Pleas
Thanks Uros for comments.
> This is not "target", but "middle-end" component. Even though the bug
> is exposed on x86_64 target, the fix is in the middle-end code, not in
> the target code.
Sure, will rename to middle-end.
> Please remove -m32 and use "{ dg-do compile { target ia32 } }" instead.
Here's a general approach to handle PR116701. I considered
adding manual deletions as quoted below and mentioned in the
PR, but seeing the handling of "integer 8" in
fortran-torture-execute I decided to follow that example:
better scan the source for open-statements than relying on
manual annotati
On Mon, Sep 23, 2024 at 4:58 PM wrote:
>
> From: Pan Li
>
> This patch would like to fix the following ICE for -O2 -m32 of x86_64.
>
> during RTL pass: expand
> JackMidiAsyncWaitQueue.cpp.cpp: In function 'void DequeueEvent(unsigned
> int)':
> JackMidiAsyncWaitQueue.cpp.cpp:3:6: internal compiler
> -Original Message-
> From: Richard Biener
> Sent: Monday, September 9, 2024 7:24 PM
> To: Prathamesh Kulkarni
> Cc: Richard Sandiford ; Thomas Schwinge
> ; gcc-patches@gcc.gnu.org
> Subject: RE: Re-compute TYPE_MODE and DECL_MODE while streaming in for
> accelerator
>
> External emai
Currently, we vectorize CTZ for SVE by using the following operation:
.CTZ (X) = (PREC - 1) - .CLZ (X & -X)
Instead, this patch expands CTZ to RBIT + CLZ for SVE, as suggested in PR109498.
The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression.
OK for mainline?
Signed-off-b
On Mon, Sep 23, 2024 at 10:12 AM Yangyu Chen
wrote:
>//>/The comment of the final endif in hosthooks.h is wrong, it should be
/>/GCC_HOST_HOOKS_H instead of GCC_LANG_HOOKS_H. /
This looks obvious to me. Do you have push access or do you need
someone to push this change for you?
Thanks,
Andrew
On Tue, Sep 24, 2024 at 09:45:37AM +1000, Nathaniel Shead wrote:
> I feel like there should be a way to make use of LAMBDA_TYPE_EXTRA_SCOPE to
> avoid the need for the new TYPE_DEFINED_IN_INITIALIZER_P flag, perhaps once
> something like my patch here[1] is accepted (but with further embellishments
From: Pan Li
This patch would like to fix one incorrect test macro usage for
form 2 of signed scalar SAT_ADD run test. It should leverage the
_FMT_2 instead of _FMT_1 for form 2.
The below test are passed for this patch.
* The rv64gcv fully regression test.
It is test only patch and obvious up
This patch enables vectorization of the popcount operation for V2QI, V4QI,
V8QI, V2HI, V4HI, and V2SI modes.
gcc/ChangeLog:
* config/i386/mmx.md:
(VQI_16_32_64): New mode iterator for 8-byte, 4-byte, and 2-byte QImode.
(popcount2): New pattern for popcount of V2QI/V4QI/V8Q
For generic, `a != 0 ? a * b : 0` would match where `b` would be an expression
which trap (in the case of the testcase, it was an integer division but it
could be any).
This adds a new helper function, expr_no_side_effects_p which tests if there is
no side effects
and the expression is not trapp
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
A header unit may contain anonymous namespaces, and those declarations
are exported (as with any declaration in a header unit). This patch
ensures that such declarations are correctly handled.
The change to 'make_namespac
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
[module.import] p6 says "A header unit shall not contain a definition of
a non-inline function or variable whose name has external linkage."
This patch implements this requirement, and cleans up some issues in the
testsuit
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
By [module.interface] p3, if an exported declaration is not within a
header unit, it shall not declare a name with internal linkage.
Unfortunately we cannot just do this within set_originating_module,
since at the location
I feel like there should be a way to make use of LAMBDA_TYPE_EXTRA_SCOPE to
avoid the need for the new TYPE_DEFINED_IN_INITIALIZER_P flag, perhaps once
something like my patch here[1] is accepted (but with further embellishments
for concepts, probably), but I wasn't able to work it out. Since curre
Currently I just stream DECL_NAME in TU_LOCAL_ENTITYs for use in diagnostics,
but this feels perhaps insufficient. Are there any better approached here?
Otherwise I don't think it matters too much, as which entity it is will also
be hopefully clear from the 'declared here' notes.
I've put the new
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Currently the streaming code uses TREE_CONSTANT to determine whether an
entity will have a definition that is interesting to stream out. This
is not sufficient, however; we also need to write the definition of
references,
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fixes some inconsistencies with what kinds of linkage various
entities are assumed to have. This also fixes handling of exported
using-decls binding to GM entities and type aliases to better align with
the standard's
I don't currently have any testcases where this changes something, but I felt
it to be a valuable cleanup.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This avoids any possible inconsistencies (current or future) about
whether a declaration is internal or not.
gcc/c
This patch intends no change in functionality apart from the mangling
difference noted; more tests are in patch 4 of this series, which adds a
way to actually check what the linkage of decl_linkage provides more
directly.
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This makes the declarations internal linkage, which is an ODR issue, and
causes a future modules patch to fail regtest as it now detects attempted
uses of TU-local entities in module CMIs.
libstdc++-v3/ChangeLog:
This patch series implements most of the changes made by P1815. It also
cleans up a few bugs found along the way that impacted tests I wrote.
The whole patch series was bootstrapped on x86_64-pc-linux-gnu with no
regressions.
Nathaniel Shead (10):
libstdc++: Remove unnecessary 'static' from __
a523c2ba5862' > .bunsen.source.gitdescribe &&
echo 'a523c2ba58621c3630a1cd890d6db82879f92c90' > .bunsen.source.gitname &&
echo 'git://gcc.gnu.org/git/gcc.git' > .bunsen.source.gitrepo &&
(find . -name '*.log' -o -name '*.sum' -o -n
On 9/23/24 2:32 AM, Artemiy Volkov wrote:
Implement a match.pd pattern for C1 - X cmp C2, where C1 and C2 are
integer constants and X is of a UB-on-overflow type. The pattern is
simplified to X rcmp C1 - C2 by moving X and C2 to the other side of the
comparison (with opposite signs). If C1 -
On Mon, Sep 23, 2024 at 01:59:04PM -0700, Andrew Pinski wrote:
> On Mon, Sep 23, 2024 at 12:57 PM Andrew Kreimer wrote:
> >
> > On Mon, Sep 23, 2024 at 12:47:28PM -0700, Andrew Pinski wrote:
> > > On Fri, Sep 20, 2024 at 1:41 AM Andrew Kreimer wrote:
> > > >
> > > > Fix typos in comments.
> > >
>
On 9/21/24 1:54 PM, Arsen Arsenović wrote:
convert_to_void has, so far, when converting a co_await expression to
void altered the await_resume expression of a co_await so that it is
also converted to void. This meant that the type of the await_resume
expression, which is also supposed to be the
On 9/21/24 1:54 PM, Arsen Arsenović wrote:
Okay, these patch should work correctly in all cases, at least all I
could think of. The first patch is unchanged, the second one is simpler
than it was before, I think.
-- >8 --
If such a diagnostic is necessary, it has already been emi
Hi all,
I have now downloaded the file at
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663534.html (by
copying it from the browser, not the source code to avoid '>
This file had had to fix spurious line breaks like:
@@ -5171,7 +5171,7 @@ index_interchange (gfc_code **c, int
*wal
On Mon, Sep 23, 2024 at 12:57 PM Andrew Kreimer wrote:
>
> On Mon, Sep 23, 2024 at 12:47:28PM -0700, Andrew Pinski wrote:
> > On Fri, Sep 20, 2024 at 1:41 AM Andrew Kreimer wrote:
> > >
> > > Fix typos in comments.
> >
> > OK. Do you have push access or need someone to push it for you?
> >
>
> Hi
On Mon, Sep 23, 2024 at 10:12 AM Yangyu Chen
wrote:
>
> The comment of the final endif in hosthooks.h is wrong, it should be
> GCC_HOST_HOOKS_H instead of GCC_LANG_HOOKS_H.
This looks obvious to me. Do you have push access or do you need
someone to push this change for you?
Thanks,
Andrew
>
> g
On Mon, Sep 23, 2024 at 12:47:28PM -0700, Andrew Pinski wrote:
> On Fri, Sep 20, 2024 at 1:41 AM Andrew Kreimer wrote:
> >
> > Fix typos in comments.
>
> OK. Do you have push access or need someone to push it for you?
>
Hi, I need someone to push to.
On Fri, Sep 20, 2024 at 1:41 AM Andrew Kreimer wrote:
>
> Fix typos in comments.
OK. Do you have push access or need someone to push it for you?
Thanks,
Andrew
>
> Signed-off-by: Andrew Kreimer
> ---
> libobjc/Makefile.in | 2 +-
> libobjc/configure| 2 +-
> libob
On 9/23/24 9:24 PM, Jakub Jelinek wrote:
On Mon, Sep 23, 2024 at 11:32:59AM -0400, Jason Merrill wrote:
On 8/9/24 9:06 PM, Jakub Jelinek wrote:
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
I had made the condition to strict before, here's an updated patch:
Hi All,
The previous check if a value was external was checking
!vect_get_internal_def (vinfo, var) but this of course isn't completely right
as they could reductions etc.
This changes the check to just explicitly look at extern
Hi Andre,
Am 19.09.24 um 14:19 schrieb Andre Vehreschild:
Hi all,
the attached patch fixes an ICE when compiling with -fcoarray=lib and using
(proc_-)pointer component in a coarray. The code was looking at the wrong
location for the caf-token.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok
On Mon, Sep 23, 2024 at 11:32:59AM -0400, Jason Merrill wrote:
> On 8/9/24 9:06 PM, Jakub Jelinek wrote:
> > 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
Hi Andre,
Am 19.09.24 um 16:01 schrieb Andre Vehreschild:
Hi all,
in PR84870 an ICE was reported, that has been fixed in the meantime by some
other patch. Nevertheless did a testcase reveal that the memory handling still
was not correct. I.e. the test case in the patch was answering 2 for both
On 9/23/24 9:08 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We don't detect an explicit object parameter in a requires expression.
We can get there by way of requires-expression -> requirement-parameter-list
-> parameter-declaration-clause -> ..
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We don't detect an explicit object parameter in a requires expression.
We can get there by way of requires-expression -> requirement-parameter-list
-> parameter-declaration-clause -> ... -> parameter-declaration with
this[opt].
Hi Anuj,
thanks for your work!
I am unable to apply the patch, so I only looked at the testcases.
Generally speaking, runtime tests should verify that they work as
expected. Just printing a result does not. Use a comparison
against an expected result and do e.g. STOP 123 on failure.
Also, ne
Andreas Schwab writes:
> It's only about the @opindex. The vast majority have those variable
> parts removed from the index entry.
We can probably do both at the same time, either via makeinfos -D option
and some special macro, or by emitting a machine-generated index, maybe.
How would a flag
On Sep 23 2024, Mikael Morin wrote:
> For options where the variable is not a separate argument, I think it's
> preferable to keep the variable.
>
> For example, -ffree-line-length-@var{n} looks better on the index page as
> "-ffree-line-length-n" (with the n having a different formatting), than a
The comment of the final endif in hosthooks.h is wrong, it should be
GCC_HOST_HOOKS_H instead of GCC_LANG_HOOKS_H.
gcc/ChangeLog:
* hosthooks.h (struct host_hooks): Fix GCC_HOST_HOOKS_H typo.
Signed-off-by: Yangyu Chen
---
gcc/hosthooks.h | 2 +-
1 file changed, 1 insertion(+), 1 delet
On 9/18/2024 4:28 PM, saurabh@arm.com wrote:
From: Saurabh Jha
This is a revised version of this patch series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663204.html
The only new thing in both patches of this series are fixing directives
in test cases, replace /* { dg-do a
On 8/9/24 9:06 PM, Jakub Jelinek wrote:
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++
ChangeLog:
* MAINTAINERS: Fix sort order and add username.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0ea4db20f88..3b4cf9d20d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -554,10 +554,10 @@ Sam James
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
c++config needs to be compilable as C, in which mode we complain about the
-Wc++ pragmas.
libstdc++-v3/ChangeLog:
* include/bits/c++config: Don't try to disable -Wc++??-extensions
when compiling as C.
---
libstd
From: Pan Li
This patch would like to fix the following ICE for -O2 -m32 of x86_64.
during RTL pass: expand
JackMidiAsyncWaitQueue.cpp.cpp: In function 'void DequeueEvent(unsigned
int)':
JackMidiAsyncWaitQueue.cpp.cpp:3:6: internal compiler error: in
expand_fn_using_insn, at internal-fn.cc:263
Hi All,
The previous check if a value was external was checking
!vect_get_internal_def (vinfo, var) but this of course isn't completely right
as they could reductions etc.
This changes the check to just explicitly look at externals and constants.
Note that reductions remain unhandled here, but we
Hi Prathamesh!
On 2024-09-23T08:24:36+, Prathamesh Kulkarni wrote:
> Thanks for the review and sorry for late reply.
No worries. My replies often are way more delayed... ;'-|
> The attached patch addresses the above suggestions.
> Does it look OK ?
ACK, thanks!
> (Also, could you please
Hi,
I'd like to ping my patch. You can find it here
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662744.html
Btw I forgot to include [PR116616] in the subject. Hope I didn't confuse
people. I will take care to include the tag in the git commit message.
Thanks,
Filip Kastl
Am 23.09.24 um 11:02 schrieb Paul Richard Thomas:
Hi All,
The moment I saw the DIN4 proposal for "Generic processing of assumed
rank objects", I thought that this was a highly intuitive and
implementable proposal. I implemented a test version in June and had
some correspondence with Reinhold
On Sep 23 2024, Claudiu Zissulescu wrote:
> diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc
> index c800226b179..a225adeff57 100644
> --- a/gcc/config/arc/arc.cc
> +++ b/gcc/config/arc/arc.cc
> @@ -721,7 +721,7 @@ static rtx arc_legitimize_address_0 (rtx, rtx,
> machine_mode mode);
>
Now committed as r15-3799-gcdb9aa0f623ec7 /
https://gcc.gnu.org/r15-3799-gcdb9aa0f623ec7
Tobias
Am 21.09.24 um 01:33 schrieb Tobias Burnus:
Hi Thomas, hello all,
the attached follow-up patch does:
* It fixes an issue (thinko) related to Fortran and \0 terminated,
which fails for at least s
The target dependent mlra option was designed to be able to quickly
switch between LRA and reload. The reload register allocator step is
scheduled for retirement, thus, remove the functionality of mlra,
keeping it for backward compatibility.
PR target/113954
gcc/ChangeLog:
* con
Now committed as r15-3797-ga030fcad4f9f49 /
https://gcc.gnu.org/r15-3797-ga030fcad4f9f49 as obvious.
Tobias
Am 21.09.24 um 00:52 schrieb Tobias Burnus:
See attached patch for adding the include lines:
+ if (gcn_stack_size)
+ {
+ fprintf (cfile, "#include \n");
+ fprintf (cfile,
On 9/23/24 9:05 AM, Richard Biener wrote:
On Sat, Sep 21, 2024 at 2:49 AM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. OK for trunk?
-- 8< --
We've been using -Wno-narrowing since gcc 4.7, but at this point narrowing
diagnostics seem like a stable part of C++ and we should adjust.
This
When not doing SLP and we end up with VMAT_ELEMENTWISE we consider
using strided loads, aka VMAT_GATHER_SCATTER. The following moves
this logic down to also apply to SLP where we now can end up
using VMAT_ELEMENTWISE as well.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR
Hello Andre and everybody else?
Any more comments on the matmul patch? The other ones depend on
it, so I would like to commit (unless there are further
questions, of course).
Best regards
Thomas
On 9/23/24 12:58 PM, Simon Martin wrote:
Hi Jason,
On 20 Sep 2024, at 18:06, Jason Merrill wrote:
On 9/16/24 4:07 PM, Simon Martin wrote:
Hi Jason,
On 14 Sep 2024, at 18:44, Simon Martin wrote:
Hi Jason,
On 14 Sep 2024, at 18:11, Jason Merrill wrote:
On 9/13/24 11:06 AM, Simon Martin wr
On 9/23/24 10:44 AM, Simon Martin wrote:
Hi Jason,
On 20 Sep 2024, at 18:01, Jason Merrill wrote:
On 9/20/24 5:21 PM, Simon Martin wrote:
The following code triggers an ICE
=== cut here ===
class base {};
class derived : virtual public base {
public:
template constexpr derived(Arg) {}
};
Hi all,
just pinging this thread in case it got lost in the shuffle.
Best,
Nina
On Fri, 30 Aug 2024 at 13:49, Nina Dinka Ranns
wrote:
> We currently do not expect comdat group of the guarded function to
> be set at the time of generating pre and post check function.
> However, in the case of a
On 9/20/2024 10:51 AM, Christophe Lyon wrote:
Hi Saurabh,
On 9/18/24 21:53, Saurabh Jha wrote:
Hi Wilco,
Thanks for the patch. This mostly looks good. Just added a couple
clarifications.
On 9/18/2024 8:17 PM, Wilco Dijkstra wrote:
v2: Add more testcase fixes.
The current copysign pattern
ChangeLog:
* MAINTAINERS: Add myself to write after approval.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e9fafaf45a7..0ea4db20f88 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -557,6 +557,7 @@ Andrew Jenner andrew
Hi Andre,
Andre Vehreschild wrote:
Could you also please specify the commit SHA your patch is supposed to apply
to? At current mainline's HEAD it has several rejects which makes reviewing
harder.
I just tried and here it applies cleanly on mainline, except that I get
a bunch of:
Hunk #1 suc
Hi Jason,
On 20 Sep 2024, at 18:06, Jason Merrill wrote:
> On 9/16/24 4:07 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 14 Sep 2024, at 18:44, Simon Martin wrote:
>>
>>> Hi Jason,
>>>
>>> On 14 Sep 2024, at 18:11, Jason Merrill wrote:
>>>
On 9/13/24 11:06 AM, Simon Martin wrote:
> Hi Ja
Hi Paul,
Am 23.09.24 um 10:26 schrieb Paul Richard Thomas:
In addition to Andre's remarks, could you please tell us, when you
resubmit, if this is a complete F2023 implementation of do concurrent.
If not, what is missing?
Regarding missing parts: still to do is actually privatizing (with or
wi
The following makes sure to apply forced splitting of groups for
firced single-lane SLP only when the group being analyzed has more
than one lane. This avoids an out-of-bound access to matches[].
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/116810
When the unroller unloops loops it tracks whether it changes any
nesting relationship of remaining loops but when scanning a loops
preheader it fails to pass down the LC-SSA-invalidated bitmap, losing
the fact that an unrolled formerly inner loop can now be placed on
an exit of its outer loop. The
On 30/08/2024 18:11, Alex Coplan wrote:
> Hi,
>
> vec.h has this method:
>
> template
> inline T *
> vec_safe_push (vec *&v, const T &obj CXX_MEM_STAT_INFO)
>
> where v is a reference to a pointer to vec. This matches the regex for
> VecPrinter, so gdbhooks.py attempts to print it but cho
Hi,
As the PR shows, pair-fusion was tricking memory_modified_in_insn_p into
returning false when a common base register (in this case, x1) was
modified between the mem and the store insn. This lead to wrong code as
the accesses really did alias.
To avoid this sort of problem, this patch avoids
Thomas Schwinge writes:
> Hi Andrew, Sam!
>
> On 2024-09-20T14:21:33-0700, Andrew Pinski wrote:
>> On Fri, Sep 20, 2024 at 1:53 AM Thomas Schwinge
>> wrote:
>>> On 2024-09-20T05:12:19+0100, Sam James wrote:
>>> > In this case, they were all harmless in reality (no diff in test logs).
>>>
>>>
The following restricts the elementwise SLP vectorization to the
single-lane case which is the reason I enabled it to avoid regressions
with non-SLP. The PR shows that multi-line SLP loads with elementwise
accesses require work, I'll open a new bug to track this for the
future.
Bootstrapped and t
The gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c testcase shows
that we sometimes fail to use store-lanes even though it should be
profitable. We're currently relying on vect_slp_prefer_store_lanes_p
at the point we run into the first SLP discovery mismatch with obviously
limited informatio
Hi All,
The moment I saw the DIN4 proposal for "Generic processing of assumed rank
objects", I thought that this was a highly intuitive and implementable
proposal. I implemented a test version in June and had some correspondence
with Reinhold Bader about it shortly before he passed away.
Malcolm
Hi Jason,
On 20 Sep 2024, at 18:01, Jason Merrill wrote:
> On 9/20/24 5:21 PM, Simon Martin wrote:
>> The following code triggers an ICE
>>
>> === cut here ===
>> class base {};
>> class derived : virtual public base {
>> public:
>>template constexpr derived(Arg) {}
>> };
>> int main() {
>>
Implement a match.pd pattern for C1 - X cmp C2, where C1 and C2 are
integer constants and X is of a UB-on-overflow type. The pattern is
simplified to X rcmp C1 - C2 by moving X and C2 to the other side of the
comparison (with opposite signs). If C1 - C2 happens to overflow,
replace the whole expr
Implement a match.pd transformation inverting the sign of X in
C1 - X cmp C2, where C1 and C2 are integer constants and X is
of a wrapping signed type, by observing that:
(a) If cmp is == or !=, simply move X and C2 to opposite sides of
the comparison to arrive at X cmp C1 - C2.
(b) If cmp is <:
Whenever C1 and C2 are integer constants, X is of a wrapping type, and
cmp is a relational operator, the expression X +- C1 cmp C2 can be
simplified in the following cases:
(a) If cmp is <= and C2 -+ C1 == +INF(1), we can transform the initial
comparison in the following way:
X +- C1 <= C2
-
Implement a match.pd transformation inverting the sign of X in
C1 - X cmp C2, where C1 and C2 are integer constants and X is
of an unsigned type, by observing that:
(a) If cmp is == or !=, simply move X and C2 to opposite sides of the
comparison to arrive at X cmp C1 - C2.
(b) If cmp is <:
Hi,
sending a v3 of
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661066.html with
the following changes since v2:
- Split one big patch into 4 smaller ones, each corresponding to a
specific new match.pd (sub-)pattern.
- Clarified the logic of each transformation in inline comments as w
> -Original Message-
> From: Thomas Schwinge
> Sent: Wednesday, September 4, 2024 3:15 PM
> To: Prathamesh Kulkarni ; Jan Hubicka
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [nvptx] Fix code-gen for alias attribute
>
> External email: Use caution opening links or attachments
>
>
> Hi!
>
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656541.html
Best Regards
Abdul Basit
-Original Message-
From: Ijaz, Abdul B
Sent: Sunday, July 7, 2024 9:45 PM
To: Ijaz, Abdul B
Subject: [PATCH 1/1] config: Handle dash in library name for
AC_LIB_LINKAGEFLAGS_BODY
From: "Ijaz, Abdu
Le 23/09/2024 à 00:01, Andreas Schwab a écrit :
On Sep 22 2024, Arsen Arsenović wrote:
Andreas Schwab writes:
On Sep 22 2024, Jakub Jelinek wrote:
On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
On Sep 22 2024, Mikael Morin wrote:
@@ -370,7 +370,7 @@ Set the default acce
Hi Anuj,
please check the code style of your patch using:
contrib/check_GNU_style.py
It reports several errors with line length and formatting.
Could you also please specify the commit SHA your patch is supposed to apply
to? At current mainline's HEAD it has several rejects which makes reviewi
From: Aldy Hernandez
ChangeLog:
* MAINTAINERS: Update email and add myself to DCO.
---
MAINTAINERS | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cfd96c9f33e..e9fafaf45a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -116,7 +
Hi all,
as a background – Anuj, did this as part of his Google Summer of Code
project (thanks!).
As I looked as various drafts, I would be happy if someone else could
have a look as well, as I probably start skipping over things and,
hence, as miss potential issues …
A bit hidden in the patch i
ping
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, September 10, 2024 8:57 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> Subject: RE: [PATCH 2/2]middle-end: use two's complement equality when
> comparing IVs during
ping
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, September 10, 2024 8:57 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> Subject: RE: [PATCH 1/2]middle-end: refactor type to be explicit in
> operand_equal_p [PR11493
On Mon, 23 Sep 2024, Tamar Christina wrote:
> Hi All,
>
> The new invariant statements should be inserted before the current
> statement and not after. This goes fine 99% of the time but when the
> current statement is a gcond the control flow gets corrupted.
>
> Bootstrapped Regtested on aarch
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-09-23 13:43
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: RISC-V: Add testcases for form 4 of signed vector
SAT_ADD
From: Pan Li
Form 4:
#define DEF_VEC_SAT_S_ADD_FMT_4(T, UT, MIN
1 - 100 of 107 matches
Mail list logo
