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
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
> -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!
>
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
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).
>>>
>>>
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
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() {
>>
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 +
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
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
-
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 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/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) {}
};
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 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 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
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
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
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 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
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
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
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
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
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 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
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 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 patch changes -Wno-narrowing t
On Mon, Sep 23, 2024 at 5:48 AM Andrew Pinski wrote:
>
> This was commented out since r0-125500-g80560f9521f81a and a new
> defition was added at the same time. Let's remove the commented
> out version.
OK
> gcc/ChangeLog:
>
> * tree-ssa-operands.h (PHI_ARG_DEF): Remove definition.
>
> S
On Mon, Sep 23, 2024 at 5:48 AM Andrew Pinski wrote:
>
> Since r11-2700-g22dc89f8073cd0, type_traits has been included via system.h so
> we don't need a custom version for gimple.h.
>
> Note a small C++14 cleanup is to use remove_pointer_t directly here instead
> of remove_pointer::type.
>
> boots
On Mon, Sep 23, 2024 at 5:48 AM Andrew Pinski wrote:
>
> The implementation of gimple_seq_nondebug_singleton_p
> was convoluted on how to determine if the sequence
> was a singleton (which could contain debug statements).
>
> This simplifies the function into two calls. One to get the start
> afte
Hi Tobias,
to my eye this looks fine. I would appreciate, if you could add some tests for
errors on the fortran side, esp. where modules are involved. But no must.
Ok for mainline. Thanks for the patch.
- Andre
On Sat, 21 Sep 2024 23:37:33 +0200
Tobias Burnus wrote:
> Add support of the 'sel
On Sun, Sep 22, 2024 at 08:45:40AM -0600, Sandra Loosemore wrote:
> On 9/21/24 22:52, Jakub Jelinek wrote:
> > On Sat, Sep 21, 2024 at 08:08:29PM -0600, Sandra Loosemore wrote:
> > > On 9/20/24 01:41, Jakub Jelinek wrote:
> > > > > +
> > > > > + /* Check for unknown properties. */
> > > > >
On Sun, Sep 22, 2024 at 12:50 PM wrote:
>
> From: Pan Li
>
> This patch would like to fix one ICE when try to match the binary
> phi for below cfg. We check the first edge of the Phi block comes
> from b0, instead of check the only one edge of b1 comes from the
> b0 too. Thus, it will result in
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
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
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
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
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,
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
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);
>
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
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
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
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 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
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
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
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
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
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
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 <:
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
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
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 __
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
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,
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
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
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
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:
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
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 --
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
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.
> > >
>
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
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
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/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/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 -> ..
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 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.
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].
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 -
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
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
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 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 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 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
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 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
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
> -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
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
> 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 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
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
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
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
1 - 100 of 107 matches
Mail list logo
