Hi Thomas, hi all,
On 08.02.23 00:26, Thomas Schwinge wrote:
On 2023-02-02T22:13:20+0100, I wrote:
I'd offer to co-mentor, but I'd rather not be the only one.
Still looking for someone to join, please! :-)
As kind of mentioned before, I am willing to co-mentor :-)
Here it is:
Hi,
The logical operations for TImode is split after reload pass right now. Some
potential optimizations miss as the split is too late. This patch removes
TImode from "AND", "IOR", "XOR" and "NOT" expander so that these logical
operations can be split at expand pass. The new test case
On Tue, Feb 7, 2023 at 6:08 AM Vladimir Makarov via Gcc-patches
wrote:
>
> The following patch solves
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
>
> The patch was successfully bootstrapped and tested on x86-64, aarch64,
> and ppc64le.
What languages did you test? Because I think I
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Fix indent.
---
gcc/config/riscv/vector-iterators.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/riscv/vector-iterators.md
b/gcc/config/riscv/vector-iterators.md
index
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-protos.h (simm5_p): Add vadc/vsbc support.
* config/riscv/riscv-v.cc (simm32_p): Ditto.
* config/riscv/riscv-vector-builtins-bases.cc (class vadc): New class.
(class vsbc): Ditto.
(BASE): Ditto.
On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
> Then, this routine (flexible_array_type_p) is mainly for diagnostic purpose.
> It cannot be used to determine whether the structure/union type recursively
> include a flexible array member at the end.
>
> Is my understanding correct?
My
Hi!
On 2023-02-02T22:13:20+0100, I wrote:
> 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
Hi Tobias!
On 2023-02-06T12:52:11+0100, Tobias Burnus wrote:
> Seems as if I missed a GOMP_MAP_TO_PSET issue before. As nvptx is
> XFAILed before, I only found it when testing on AMDGCN.
>
> For an array-descriptor 'ai' variable, omplower has:
>map(tofrom:MEM [(integer(kind=4)[0:] *)D.4346]
Hi Tobias!
On 2023-02-03T11:38:29+0100, Tobias Burnus wrote:
> Now committed as obvious as
> r13-5680-g0b1ce70a813b98ef2893779d14ad6c90c5d06a71.
I see:
FAIL: libgomp.fortran/reverse-offload-6.f90 -O (test for excess errors)
... due to:
nvptx mkoffload: warning: 'omp requires
My integration testing shows many false positives from
-Wanalyzer-use-of-uninitialized-value.
One cause turns out to be that as of r13-1404-g97baacba963c06
fd_state_machine::on_stmt recognizes calls to "read", and returns true,
so that region_model::on_call_post doesn't call
This patch adds a check in match_simplify_replacement to make sure the middlebb
does not have any phi-nodes as we don't currently move those.
This was just a thinko from before.
Committed on the GCC 12 branch after a bootstrap/test on x86_64-linux-gnu.
PR tree-optimization/108582
On 2023-01-25 22:32, Siddhesh Poyarekar wrote:
Instead of using TREE_OPERAND (expr, 2) directly, use
component_ref_field_offset instead, which does scaling for us. The
function also substitutes PLACEHOLDER_EXPRs, which is probably what we
want anyway but I'm not sure if it's relevant for
> On Feb 7, 2023, at 2:17 PM, Joseph Myers wrote:
>
> On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> 1. Structure with flexible array member embedded into other structures
>> recursively, for example:
>>
>> struct A {
>> int n;
>> char data[];
>> };
>>
>> struct B {
>> int
Dear all,
the attached trivial patch by Steve fixes a NULL pointer dereference
that occurs when an error shall be emitted for a global entity that
conflicts with a symbol appearing in a COMMON block, but the symbol's
location is not set. This may happen e.g. in the testcase in the PR,
where the
On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
> 1. Structure with flexible array member embedded into other structures
> recursively, for example:
>
> struct A {
> int n;
> char data[];
> };
>
> struct B {
> int m;
> struct A a;
> };
>
> struct C {
> int q;
> struct B b;
>
Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
also hacked to switch to LRA).
Ok to commit?
--- 8< ---
The LRA target list is incomplete. Rather than syncing it with actual
LRA targets, better use existing infrastructure and look for a
LRA-specific pattern in the reload dump (which
> From: Aldy Hernandez
> Date: Tue, 7 Feb 2023 17:52:02 +0100
> Up to the release managers, but I have no objections.
I take it that's for both patches. Thanks!
(Potential reviewers: these patches are local to the testsuite.)
brgds, H-P
>
> Aldy
>
> On 2/7/23 17:50, Hans-Peter Nilsson
Up to the release managers, but I have no objections.
Aldy
On 2/7/23 17:50, Hans-Peter Nilsson wrote:
(sort-of-ping:) Aldy, I missed CC:ing you on the similar
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611206.html
would you mind having a look?
Tested native x86_64-pc-linux-gnu
(sort-of-ping:) Aldy, I missed CC:ing you on the similar
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611206.html
would you mind having a look?
Tested native x86_64-pc-linux-gnu (w/wo. -m32) and cris-elf.
Ok to commit?
8<
There was a commit r13-2082-gbf13a13c65bd06 "c++:
Since C++20 P2513R4, char8_t Compatibility and Portability Fix it is
no longer true that
char ca[] = u8"xx";
causes an error so adjust the example for -fchar8_t.
Applied.
gcc/ChangeLog:
* doc/invoke.texi: Update -fchar8_t documentation.
---
gcc/doc/invoke.texi | 2 --
1 file
On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote:
> On 1/24/23 17:49, Marek Polacek wrote:
> > On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
> > > On 1/19/23 21:03, Marek Polacek wrote:
> > > > On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote:
> > > > >
On Tue, 7 Feb 2023 at 09:25, Jakub Jelinek wrote:
>
> Hi!
>
> On Mon, Feb 06, 2023 at 02:26:01PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > With the recent change to deprecate std::aligned_storage and
> > std::aligned_union we need to adjust some tests that now fail with
> > -std=c++23.
Updated ping email as some patches have been reviewed. [Thanks! I still
need to revised three of them: for Fortran, the parallel + loop issue
and the non-rect-loop issue - and for C/C++, the allocate's align patch.]
I think it would be very good to get (some of) Julian's mapping patches
in as it
> On Feb 7, 2023, at 10:28 AM, Siddhesh Poyarekar wrote:
>
> On 2023-02-06 18:14, Joseph Myers wrote:
>> On Mon, 6 Feb 2023, Qing Zhao via Gcc-patches wrote:
>>> In GCC14:
>>>
>>> 1. Include this new warning -Wgnu-varaible-sized-type-not-at-end to -Wall
>>> 2. Deprecate this extension from
On 2023-02-06 18:14, Joseph Myers wrote:
On Mon, 6 Feb 2023, Qing Zhao via Gcc-patches wrote:
In GCC14:
1. Include this new warning -Wgnu-varaible-sized-type-not-at-end to -Wall
2. Deprecate this extension from GCC. (Or delay this to next release?).
Any deprecation, or inclusion in -Wall,
Hi, Joseph,
> On Feb 6, 2023, at 6:14 PM, Joseph Myers wrote:
>
> On Mon, 6 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> In GCC14:
>>
>> 1. Include this new warning -Wgnu-varaible-sized-type-not-at-end to -Wall
>> 2. Deprecate this extension from GCC. (Or delay this to next release?).
>
Hello,
Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606450.html
Thanks,
Lorenzo Salvadore
> From f8e2c2ee89a7d8741bb65163d1f1c20edcd546ac Mon Sep 17 00:00:00 2001
> From: Lorenzo Salvadore develo...@lorenzosalvadore.it
>
> Date: Wed, 16 Nov 2022 11:27:38 +0100
> Subject:
On Tue, Feb 07, 2023 at 03:22:41PM +0100, Richard Biener via Gcc-patches wrote:
> > He did not specify --with=cpu= or --with-tune=, which means he got
> > power8 defaults for both of those. It's hard for me to believe that
> > --with-tune=power9 could hide the issue, but we'll try that
On Mon, Feb 6, 2023 at 7:28 PM Peter Bergner wrote:
>
> On 2/3/23 1:42 AM, Richard Biener wrote:
> > 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
On Tue, Feb 07, 2023 at 02:08:35PM +0100, Andreas Schwab wrote:
> On Feb 07 2023, Vít Kabele wrote:
>
> > diff --git a/gcc/testsuite/gcc.dg/Wpadded.c b/gcc/testsuite/gcc.dg/Wpadded.c
> > index 70fcd79a6d4..357e7f61e4a 100644
> > --- a/gcc/testsuite/gcc.dg/Wpadded.c
> > +++
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit f661c0bb6371f355966a67b5ce71398e80792948
Author: Vladimir N. Makarov
Date: Tue Feb 7 08:27:36 2023 -0500
RA:
With the compiler.i testcase from the PR one can see bitmap_set_bit
very high in the profile, originating from SSA update and alias
stmt walking. For SSA update mark_block_for_update essentially
performs redundant bitmap_set_bits and is called via
insert_updated_phi_nodes_for as
The following addresses
tree forward propagate : 12.41 ( 9%)
seen with the compile.i testcase of this PR which points at
the has_use_on_stmt function which, for SSA names with many
uses is slow. The solution is to instead of immediate uses,
look at stmt operands to identify
Hi,
For code:
```
u64
test_rlwinm_lowpart_mask (u32 v)
{
u32 v1 = ((v << N) | (v >> (32 - N))) & 0xf00;
return (u64)v1;
}
```
We generate "rlwinm 3,3,4,4,23; rldicl 3,3,0,32" instead of "rlwinm 3,3,4,4,23".
Here the "rlwinm" cleans high32 bits already, so "rldicl" is reductant.
On Feb 07 2023, Vít Kabele wrote:
> diff --git a/gcc/testsuite/gcc.dg/Wpadded.c b/gcc/testsuite/gcc.dg/Wpadded.c
> index 70fcd79a6d4..357e7f61e4a 100644
> --- a/gcc/testsuite/gcc.dg/Wpadded.c
> +++ b/gcc/testsuite/gcc.dg/Wpadded.c
> @@ -10,5 +10,5 @@
>
> struct foo {
>char bar;
> - long
Announce the size of introduced padding when compiling
with -Wpadded.
gcc/ChangeLog:
* stor-layout.cc (place_field): Change warning message format
gcc/testsuite/ChangeLog:
* c-c++-common/Wpadded.c: Add new testcase
* gcc.dg/Wpadded.c: Update the expected warning message
In this PR we had a write to one vector of a 4-vector tuple.
The vector had mode V1DI, and the target doesn't provide V1DI
moves, so this was converted into:
(clobber (subreg:V1DI (reg/v:V4x1DI 92 [ b ]) 24))
followed by a DImode move. (The clobber isn't really necessary
or helpful for a
Hi Jeff,
Can you please confirm if the patch is Ok?
Thanks,
Cupertino
> Cupertino Miranda via Gcc-patches writes:
>
>> Thank you for the comments and suggestions.
>> I have changed the patch.
>>
>> Unfortunately in case of rx target I could not make
>> scan-assembler-symbol-section to match.
> Am 07.02.2023 um 09:37 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase ICEs, because we determine only in late pure const
> pass that bar is const (the content of the function loses a store to a
> global var during dse3 and read from it during cddce2) and local-pure-const2
>
> Am 07.02.2023 um 09:42 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> As discussed in the PR, returns_twice functions are rare/special beasts
> that need special treatment in the cfg, and inside of their bodies
> we don't know which part actually works the weird returns twice way
>
Hi!
On Mon, Feb 06, 2023 at 02:26:01PM +, Jonathan Wakely via Gcc-patches wrote:
> With the recent change to deprecate std::aligned_storage and
> std::aligned_union we need to adjust some tests that now fail with
> -std=c++23.
The g++.dg/warn/Wstrict-aliasing-bogus-union-2.C test is also
Hi!
As discussed in the PR, returns_twice functions are rare/special beasts
that need special treatment in the cfg, and inside of their bodies
we don't know which part actually works the weird returns twice way
(either in the fork/vfork sense, or in the setjmp) and aren't updating
ab edges to
Hi!
The following testcase ICEs, because we determine only in late pure const
pass that bar is const (the content of the function loses a store to a
global var during dse3 and read from it during cddce2) and local-pure-const2
makes it const. The cgraph ordering is that post IPA (in late IPA simd
On Mon, 6 Feb 2023 at 20:14, Roger Sayle wrote:
>
>
> Perhaps I'm missing something (I'm not too familiar with SVE semantics), but
> is there
> a reason that the solution for PR96473 uses a VEC_PERM_EXPR and not just a
> VEC_DUPLICATE_EXPR? The folding of sv1d1rq (svptrue_..., ...) doesn't seem
44 matches
Mail list logo
