On Wed, 2023-10-04 at 23:19 +0100, Roger Sayle wrote:
>
> The recent patch to remove poly_int_pod triggers a bug in g++ 4.8.5's
> C++ 11 support which mistakenly believes poly_uint16 has a non-trivial
> constructor. This in turn prohibits it from being used as a member in
> a union (rtxunion) tha
Hi,
Currently, we have the pattern "movsf_from_si2" which was trying
to support moving high part DI to SF.
But current pattern only accepts "ashiftrt":
XX:SF=bitcast:SF(subreg(YY:DI>>32),0), but actually "lshiftrt" should
also be ok.
And current pattern only supports BE.
This patch updats the pa
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU insns
Hi,
As mentioned in PR108338, on p9, we could use mtvsrws to implement
the bitcast from SI to SF (or lowpart DI to SF).
For example:
*(long long*)buff = di;
float f = *(float*)(buff);
"sldi 9,3,32 ; mtvsrd 1,9 ; xscvspdpn 1,1" is generated.
A better one would be "mtvsrws 1,3 ; xscvspdpn 1,1"
On Wed, Oct 4, 2023 at 5:08 PM Maciej W. Rozycki wrote:
>
> On Tue, 3 Oct 2023, Martin Jambor wrote:
>
> > > SSA graph may be deep so this may cause stack overflow, so I think we
> > > should use worklist here (it is also easy to do).
> > >
> > > OK with that change.
> > > Honza
> >
> > I have jus
On Tue, 3 Oct 2023, Martin Jambor wrote:
> > SSA graph may be deep so this may cause stack overflow, so I think we
> > should use worklist here (it is also easy to do).
> >
> > OK with that change.
> > Honza
>
> I have just committed the following after a bootstrap and testing on
> x86_64-linux.
Since r14-4358-g9464e72bcc9 riscv_v targets use vector instructions to
perform a memcpy. We no longer expect memcpy for riscv_v targets.
gcc/testsuite/ChangeLog:
* gcc.dg/pr90263.c: Skip riscv_v targets.
* gcc.target/riscv/rvv/base/pr90263.c: New test.
Signed-off-by: Patrick O'Ne
On 10/4/23 16:21, Patrick O'Neill wrote:
On 10/4/23 15:14, Jeff Law wrote:
On 10/4/23 15:57, Patrick O'Neill wrote:
Since r14-4358-g9464e72bcc9 riscv_v targets use vector instructions to
perform a memcpy. We no longer expect memcpy for riscv_v targets.
gcc/testsuite/ChangeLog:
* gcc
On 10/4/23 15:14, Jeff Law wrote:
On 10/4/23 15:57, Patrick O'Neill wrote:
Since r14-4358-g9464e72bcc9 riscv_v targets use vector instructions to
perform a memcpy. We no longer expect memcpy for riscv_v targets.
gcc/testsuite/ChangeLog:
* gcc.dg/pr90263.c: xfail riscv_v targets.
Or rat
The recent patch to remove poly_int_pod triggers a bug in g++ 4.8.5's
C++ 11 support which mistakenly believes poly_uint16 has a non-trivial
constructor. This in turn prohibits it from being used as a member in
a union (rtxunion) that constructed statically, resulting in a (fatal)
error during st
On 10/4/23 15:57, Patrick O'Neill wrote:
Since r14-4358-g9464e72bcc9 riscv_v targets use vector instructions to
perform a memcpy. We no longer expect memcpy for riscv_v targets.
gcc/testsuite/ChangeLog:
* gcc.dg/pr90263.c: xfail riscv_v targets.
Or rather than XFAIL skip the test? X
On 10/3/23 05:45, Manolis Tsamis wrote:
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
Since r14-4358-g9464e72bcc9 riscv_v targets use vector instructions to
perform a memcpy. We no longer expect memcpy for riscv_v targets.
gcc/testsuite/ChangeLog:
* gcc.dg/pr90263.c: xfail riscv_v targets.
Signed-off-by: Patrick O'Neill
Co-authored-by: Joern Rennecke
---
gcc/testsuite/
On 10/4/23 12:19, Joern Rennecke wrote:
On Wed, 4 Oct 2023 at 18:38, Patrick O'Neill wrote:
Hi Joern,
I'm seeing new failures introduced by this patch
(9464e72bcc9123b619215af8cfef491772a3ebd9).
On rv64gcv:
FAIL: gcc.dg/pr90263.c scan-assembler memcpy
My testing didn't flag this because I u
On 10/4/23 12:14, Vineet Gupta wrote:
On 10/4/23 10:59, Jeff Law wrote:
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit
registers,
meaning incoming SI function args
>> I think the "max poly value" is the LMUL 1 mode coeffs[1]
>>
>> See int vlenb = BYTES_PER_RISCV_VECTOR.coeffs[1];
>>
>> So I think bump max_power to exact_log2 (64); is not enough.
>> since we adjust the LMUL 1 mode size according to TARGET_MIN_VLEN.
>>
>> I suspect the testcase you append in th
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
After the previous patch, we currently have two tsubst entry points
for expression trees: tsubst_copy_and_build and tsubst_expr. But the
latter is just a superset of the former that also handles statement
tr
On Wed, 4 Oct 2023 at 18:38, Patrick O'Neill wrote:
>
> Hi Joern,
>
> I'm seeing new failures introduced by this patch
> (9464e72bcc9123b619215af8cfef491772a3ebd9).
>
> On rv64gcv:
> FAIL: gcc.dg/pr90263.c scan-assembler memcpy
My testing didn't flag this because I used elf targets. The
expected
On 10/3/23 10:45, Jonathan Wakely wrote:
We have a long history of INVALID bugs about std functions being
available in the global namespace (PRs 27846, 67566, 82619, 99865,
110602, 111553, probably others). Let's document it.
Also de-prioritize the C++98-only bugs, which are unlikely to affect
a
On 10/4/23 03:07, Florian Weimer wrote:
* Jason Merrill:
@@ -6159,6 +6153,18 @@ errors by @option{-pedantic-errors}. For instance:
-Wwrite-strings @r{(C++11 or later)}
}
+@opindex fpermissive
+@item -fpermissive
+Downgrade some required diagnostics about nonconformant code from
+errors
On 2023-10-04 11:49, Alexander Monakov wrote:
On Thu, 28 Sep 2023, Siddhesh Poyarekar wrote:
Define a security process and exclusions to security issues for GCC and
all components it ships.
Some typos and wording suggestions below.
I've incorporated all your and David's suggestions and
Hi,
This patch implements pex_unix_exec_child using posix_spawn when
available.
This should especially benefit recent macOS (where vfork just calls
fork), but should have equivalent or faster performance on all
platforms.
In addition, the implementation is substantially simpler than the
vfork+exe
I have reverted the change upstream (
https://github.com/llvm/llvm-project/commit/7d21086d0ca4a680e96e0f4cd3e2597ebe027a48
).
On Wed, Oct 4, 2023 at 10:00 AM Pranav Kant wrote:
> I will revert the commit while I work on this. Thanks for the pointers.
>
> On Wed, Oct 4, 2023 at 9:57 AM Jakub Jeli
On 10/4/23 10:59, Jeff Law wrote:
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit
registers,
meaning incoming SI function args need not be explicitly sign extended
(so d
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU insns
Hi Joern,
I'm seeing new failures introduced by this patch
(9464e72bcc9123b619215af8cfef491772a3ebd9).
On rv64gcv:
FAIL: gcc.dg/pr90263.c scan-assembler memcpy
FAIL: gfortran.fortran-torture/execute/intrinsic_count.f90 execution,
-O2 -fomit-frame-pointer -finline-functions -funroll-loops
D
s/atomic-exchange/atomic-cmpxchg-word/g.
Tested as v1.
Ok to commit?
-- >8 --
These tests actually use a form of atomic compare and exchange
operation, not just atomic loading and storing. Some targets (not
supported by e.g. libatomic) have atomic loading and storing, but not
compare and exchange
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 17:15:28 +0200
> New version coming up.
Using pointer-sized int instead of int,
__atomic_compare_exchange instead of __atomic_exchange,
renamed to atomic-cmpxchg-word from atomic-exchange, and
updating a comment that already seemed reasonably we
I will revert the commit while I work on this. Thanks for the pointers.
On Wed, Oct 4, 2023 at 9:57 AM Jakub Jelinek wrote:
> On Wed, Oct 04, 2023 at 09:47:34AM -0700, Pranav Kant wrote:
> > Thanks for bringing this to my attention. I am working on a fix. Will
> keep
> > this thread posted.
> >
This changes libstdc++ to use the 'black' Python formatter. This
formatter is somewhat standard and fairly comprehensive. FWIW we use
this in gdb, mainly because it means we don't have to review Python
code for formatting style.
This patch also runs 'isort', which handles sorting the imports.
A
flake8 is a Python linter. This patch adds a .flake8 configuration
file (flake8 does not use pyproject.toml for some reason) and fixes a
few trivial flake8 warnings.
After this patch, the only remaining flake8 warnings are about unused
imports (there are two - but they are not completely trivial
This short series adds configuration files for black ("opinionated"
code formatter), isort (import sorter) and flake8 (Python lint) to
libstdc++.
I marked it as RFC since sometimes people don't like black's output.
In gdb we use it -- at first I found some of its decisions a little
odd, but overal
On Wed, Oct 04, 2023 at 09:47:34AM -0700, Pranav Kant wrote:
> Thanks for bringing this to my attention. I am working on a fix. Will keep
> this thread posted.
>
> Clang *does* define this macro only when float128 type is available. But
> the problem seems to be that clang doesn't define _Float128
Thanks for bringing this to my attention. I am working on a fix. Will keep
this thread posted.
Clang *does* define this macro only when float128 type is available. But
the problem seems to be that clang doesn't define _Float128 alias type
which is what's being used here. It only defines __float128
On Tue, 3 Oct 2023, Jason Merrill wrote:
> On 10/3/23 08:41, Patrick Palka wrote:
> > On Mon, 2 Oct 2023, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
> > >
> > > The relationship between tsubst_copy_an
On Wed, 4 Oct 2023 at 16:15, Hans-Peter Nilsson wrote:
>
> > From: Jonathan Wakely
> > Date: Wed, 4 Oct 2023 09:29:43 +0100
>
> > The new dg-require proc checks for __atomic_exchange, which is not the
> > same as compare-exchange, and not the same as test-and-set on
> > atomic_flag. Does it just
On Wed, 4 Oct 2023 at 16:54, Stephan Bergmann wrote:
>
> On 8/17/23 22:32, Jonathan Wakely via Libstdc++ wrote:
> > Tested x86_64-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > The extended floating-point types such as _Float32 are supported by GCC
> > prior to C++23, you just can't use the stan
On 8/17/23 22:32, Jonathan Wakely via Libstdc++ wrote:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The extended floating-point types such as _Float32 are supported by GCC
prior to C++23, you just can't use the standard-conforming names from
to refer to them. This change defines the speciali
On 10/3/23 16:26, Patrick O'Neill wrote:
I vaugely recall some discussion about backporting the Ztso mappings
along with the RVWMO mappings. Now that the RVWMO mappings have been
backported for 13.3, is there interest in also backporting the Ztso
mappings?
Tested using for regressions using r
On Thu, 28 Sep 2023, Siddhesh Poyarekar wrote:
> Define a security process and exclusions to security issues for GCC and
> all components it ships.
Some typos and wording suggestions below.
> --- /dev/null
> +++ b/SECURITY.txt
> @@ -0,0 +1,205 @@
> +What is a GCC security bug?
> +=
On 10/4/23 09:06, Robin Dapp wrote:
I'm currently in the process of removing some unused @s.
This is OK.
Agreed. And if you or Juzhe have other @ cases that are unused, such
changes should be considered pre-approved.
Jeff
On 04/10/2023 21:39, Jørgen Kvalsvik wrote:
A check was missing for is-single when contracting, so if a
multi-successor node that was not a condition node (e.g. a switch) a
random edge would be picked and contracted into.
---
gcc/testsuite/gcc.misc-tests/gcov-23.c | 48 +
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU insns
On 04/10/2023 21:39, Jørgen Kvalsvik wrote:
Depth first order is insufficient to process expressions in the right
order when there are setjmps in optimized builds. This would create
complex paths from the root past conditions and into the middle of
boolean expressions. Traversing the graph in top
> From: Jonathan Wakely
> Date: Wed, 4 Oct 2023 09:29:43 +0100
> The new dg-require proc checks for __atomic_exchange, which is not the
> same as compare-exchange, and not the same as test-and-set on
> atomic_flag. Does it just happen to be true for arm that the presence
> of __atomic_exchange al
Hi, Siddhesh
Thanks for working on this and fine-tuning the original proposed text. It
looks good to me. Minor grammatical nit below.
Thanks, David
On Thu, Sep 28, 2023 at 7:59 AM Siddhesh Poyarekar
wrote:
> On 2023-09-28 12:55, Siddhesh Poyarekar wrote:
> > Define a security process and exc
Hi Robin,
> -Original Message-
> From: Robin Dapp
> Sent: Wednesday, October 4, 2023 8:54 AM
> To: Tamar Christina ; gcc-patches patc...@gcc.gnu.org>; Richard Biener
> Cc: rdapp@gmail.com
> Subject: Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar
> reduction.
>
> Hi Ta
On Wed, 4 Oct 2023 at 16:10, Tom Tromey wrote:
>
> flake8 points out that the new call to _string_types from
> StdExpAnyPrinter.__init__ is not correct -- it needs to be qualified.
OK, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * python/libstdcxx/v6/printers.py
> (StdExpAnyPrinter.
flake8 points out that the new call to _string_types from
StdExpAnyPrinter.__init__ is not correct -- it needs to be qualified.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py
(StdExpAnyPrinter.__init__): Qualify call to
_string_types.
---
libstdc++-v3/python/li
LGTM, will commit if nobody commit that tomorrow :p
Christoph Müllner 於 2023年10月4日 週三,23:04寫道:
> On Wed, Oct 4, 2023 at 9:49 AM Xianmiao Qu
> wrote:
> >
> > From: quxm
> >
> > When generating CFI directives for the store-pair instruction,
> > if we add two parallel REG_FRAME_RELATED_EXPR expr_l
I'm currently in the process of removing some unused @s.
This is OK.
Regards
Robin
On Wed, Oct 4, 2023 at 9:49 AM Xianmiao Qu wrote:
>
> From: quxm
>
> When generating CFI directives for the store-pair instruction,
> if we add two parallel REG_FRAME_RELATED_EXPR expr_lists like
> (expr_list:REG_FRAME_RELATED_EXPR (set (mem/c:DI (plus:DI (reg/f:DI 2 sp)
> (const_int 8 [0x8
gcc/ChangeLog:
* config/riscv/autovec.md (@vec_series): Remove @.
(vec_series): Ditto.
* config/riscv/riscv-v.cc (expand_const_vector): Ditto.
(shuffle_decompress_patterns): Ditto.
---
gcc/config/riscv/autovec.md | 2 +-
gcc/config/riscv/riscv-v.cc | 6 +++---
2 f
Ping!
On 2023-09-28 07:55, Siddhesh Poyarekar wrote:
Define a security process and exclusions to security issues for GCC and
all components it ships.
Signed-off-by: Siddhesh Poyarekar
---
SECURITY.txt | 205 +++
1 file changed, 205 insertions(
OK. But could you add a MACRO define
Something like:
#define MAX_POLY_VARIANT 64
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-10-04 21:32
To: 钟居哲
CC: Jeff Law; gcc-patches; kito.cheng; palmer; rdapp
Subject: Re: [PATCH] RISC-V: Fix the riscv_legitimize_poly_move issue on
targets where th
committed to trunk, got approval from Jeff in another mail thread:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631873.html :)
On Mon, Oct 2, 2023 at 4:03 PM Kito Cheng wrote:
>
> Multidimensional arrary is gawk extension, and we accidentally
> introduced that in recent commit[1].
>
> [
钟居哲 於 2023年10月4日 週三,20:20寫道:
>
> I think the "max poly value" is the LMUL 1 mode coeffs[1]
>
> See int vlenb = BYTES_PER_RISCV_VECTOR.coeffs[1];
>
> So I think bump max_power to exact_log2 (64); is not enough.
> since we adjust the LMUL 1 mode size according to TARGET_MIN_VLEN.
>
> I suspect the te
> + gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB);
I forgot to add the other IFN_CONDs here before sending. So with
- gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB);
+ gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB
+ || code == IF
We have a long history of INVALID bugs about std functions being
available in the global namespace (PRs 27846, 67566, 82619, 99865,
110602, 111553, probably others). Let's document it.
Also de-prioritize the C++98-only bugs, which are unlikely to affect
anybody nowadays.
OK for wwwdocs?
-- >8 --
Depth first order is insufficient to process expressions in the right
order when there are setjmps in optimized builds. This would create
complex paths from the root past conditions and into the middle of
boolean expressions. Traversing the graph in topological order restores
the expectation that e
When there was no candidate set reduction phase this was not necessary,
as every neighbor's predecessor would always be in the reachable set.
Now that the graph cut is refined multiple times this may not hold,
which would lead to incorrect termination of the ancestors search when a
node in the cand
---
gcc/testsuite/g++.dg/gcov/gcov-18.C | 36 +++--
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/gcc/testsuite/g++.dg/gcov/gcov-18.C
b/gcc/testsuite/g++.dg/gcov/gcov-18.C
index 310ed5297c0..b58f8450e44 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov-18.C
+++
Some expressions create CFGs isomorphic to those with multi-term
expressions, e.g. if (a) if (b) {} is equivalent to if (a && b) {}, and
there is no real recovery for this. The test is added to 1. document the
behaviour and 2. detect if the cfg generation changes in a way that
(correctly) splits th
It always felt odd that the expression candidate set refinement were in
two more-or-less identical phases. It turns out that this is not
necessary and the neighborhood, ancestor filtering, update candidate set
steps can all be done inside a single loop, which terminates when
|NG| == |Outcomes| == 2
Search for reachable conditions without limiting the search to the nodes
dominated by the left-most term in the expression. Right operands are
conceptually still always dominated by the left-most term, but in
arbitrary programs there may be complex edges that breaks this.
As it turns out, it is no
The presence of gotos already makes this iffy, but it is already not
necessary as reducing by refining the G should cover it.
---
gcc/tree-profile.cc | 19 ---
1 file changed, 19 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index f329be84ad2..d1d7265cd1c 100
When the coverage and branch profiling preprocessing happens it can
choose to split certain nodes with labels to accuractely track coverage.
These shapes were recongized, but this causes some expressions to be
counted wrong as this graph may be isomorphic with graphs that have not
been split, for e
---
gcc/tree-profile.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index ce679130ca0..f329be84ad2 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -784,8 +784,8 @@ isolate_expression (conds_ctx &ctx, basic_block p,
From: Jørgen Kvalsvik
---
gcc/gcov.cc | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 95e0a11bc08..62eac76a971 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -3045,6 +3045,10 @@ accumulate_line_counts (source_info *src)
}
}
+/* Output information
A check was missing for is-single when contracting, so if a
multi-successor node that was not a condition node (e.g. a switch) a
random edge would be picked and contracted into.
---
gcc/testsuite/gcc.misc-tests/gcov-23.c | 48 ++
gcc/tree-profile.cc| 4
In complex control flow graphs where gotos and returns escape the inner
then-blocks and the right else-blocks are omitted, inner conditions
would erroneously be considered a part of the outer. By using the
observation that the neighborhood of a proper boolean expression should
always be the two out
From: Jørgen Kvalsvik
---
gcc/gcov.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 35be97cf5ac..95e0a11bc08 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -2580,6 +2580,8 @@ add_branch_counts (coverage_info *coverage, const
arc_info *arc)
}
}
+/*
This phase did not at all behave like advertised, which in turn lead to
ICEs for the new tests.
---
gcc/testsuite/gcc.misc-tests/gcov-19.c | 35 +++---
gcc/tree-profile.cc| 29 +++--
2 files changed, 54 insertions(+), 10 deletions(-)
diff --
---
gcc/testsuite/gcc.misc-tests/gcov-22.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/gcov-22.c
b/gcc/testsuite/gcc.misc-tests/gcov-22.c
index 28b7de66022..3737235d40e 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov-22.c
+++ b/
The search for the initial candidate set for a decision is a delicate
affair in complex CFGs with gotos (mostly from returns). Gotos and
returns in the then-block could create graphs where the goto/return edge
would also be searched for candidates for G, even though they can never
be a part of the
From: Jørgen Kvalsvik
---
gcc/gcov.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 274f2fc5d9f..35be97cf5ac 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -46,6 +46,7 @@ along with Gcov; see the file COPYING3. If not see
#include "color-m
From: Jørgen Kvalsvik
This patch adds support in gcc+gcov for modified condition/decision
coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
test/code coverage and it is particularly important in the avation and
automotive industries for safety-critical applications. MC/DC it
From: Jørgen Kvalsvik
---
gcc/gcov-dump.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/gcov-dump.cc b/gcc/gcov-dump.cc
index 65fa2d7b44b..d85fa98ddd5 100644
--- a/gcc/gcov-dump.cc
+++ b/gcc/gcov-dump.cc
@@ -394,14 +394,14 @@ tag_arcs (const char *filename ATTRIB
From: Jørgen Kvalsvik
---
gcc/gcov.cc | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 21a6da1a7fa..274f2fc5d9f 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -135,6 +135,8 @@ public:
vector lines;
};
+/* Describes a single conditional expression and
On 04/10/2023 11:41, Richard Biener wrote:
On Wed, 4 Oct 2023, Andre Vieira (lists) wrote:
On 30/08/2023 14:04, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
This patch adds a new target hook to enable us to adapt the types of return
and parameters of simd clone
From: Jørgen Kvalsvik
---
gcc/doc/gcov.texi | 3 ++-
gcc/doc/invoke.texi | 14 --
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index 10cfdcf24aa..f6db593a62a 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -175,7 +
From: Jørgen Kvalsvik
---
gcc/common.opt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index 94b1b358585..cd769ad95e0 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -864,7 +864,8 @@ Warn in case a function ends earlier than it begins d
This is an extended set of patches with both review feedback from the v4 set,
as well as a few serious bug fixes and improvements, plus test cases.
There has only been a small-ish adjustment to the algorithm itself, in
expression isolation step. Because of gotos this might need to run multiple
tim
I think the "max poly value" is the LMUL 1 mode coeffs[1]
See int vlenb = BYTES_PER_RISCV_VECTOR.coeffs[1];
So I think bump max_power to exact_log2 (64); is not enough.
since we adjust the LMUL 1 mode size according to TARGET_MIN_VLEN.
I suspect the testcase you append in this patch will fail wi
Hi!
On Wed, 2023-09-13 17:52:14 +0800, Yang Yujie wrote:
> Library build options from --with-multilib-list used to be processed with
> *self_spec, which missed the driver's initial canonicalization. This
> caused limitations on CFLAGS override and the use of driver-only options
> like -m[no]-lsx
I've pushed this to gcc-11 after testing on x86_64-linux.
-- >8 --
Backport the prune.exp change from r12-4425-g1595fe44e11a96 to fix two
testsuite failures when testing with -O0:
FAIL: 20_util/uses_allocator/69293_neg.cc (test for excess errors)
FAIL: 20_util/uses_allocator/cons_neg.cc (test for
On Wed, Oct 04, 2023 at 01:08:15PM +0200, Tobias Burnus wrote:
> I got confused myself when reading
>
> https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Context-Selectors.html
>
> Especially with regards to other platforms like PowerPC.
>
> It turned out that the list is complete, kind of. For 'arc
I got confused myself when reading
https://gcc.gnu.org/onlinedocs/libgomp/OpenMP-Context-Selectors.html
Especially with regards to other platforms like PowerPC.
It turned out that the list is complete, kind of. For 'arch' and 'isa'
those are the only ones - if we want to have more, it has to be
> Hi Honza,
>
> My current patch set for AArch64 VLA omp codegen started failing on
> gcc.dg/gomp/pr87898.c after this. I traced it back to
> 'move_sese_region_to_fn' in tree/cfg.cc not setting count for the bb
> created.
>
> I was able to 'fix' it locally by setting the count of the new bb to th
On Wed, 4 Oct 2023, Andre Vieira (lists) wrote:
>
>
> On 30/08/2023 14:04, Richard Biener wrote:
> > On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
> >
> >> This patch adds a new target hook to enable us to adapt the types of return
> >> and parameters of simd clones. We use this in two ways
On 30/08/2023 14:04, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
This patch adds a new target hook to enable us to adapt the types of return
and parameters of simd clones. We use this in two ways, the first one is to
make sure we can create valid SVE types, includ
Hi,
The attached patch attempts to fix PR111648.
As mentioned in PR, the issue is when a1 is a multiple of vector
length, we end up creating following encoding in result: { base_elem,
arg[0], arg[1], ... } (assuming S = 1),
where arg is chosen input vector, which is incorrect, since the
encoding or
The following clarifies the flatten attribute documentation to mention
the inlining applies also to calls formed as part of inlining earlier
calls but not calls to the function itself.
Will push this tomorrow or so if there are no better suggestions
on the wording.
PR ipa/111643
*
On Wed, 4 Oct 2023 at 02:49, Hans-Peter Nilsson wrote:
> (Just before sending, I noticed you replied off-list; I
> won't add back gcc-patches to cc here myself, but please
> feel free to do it, if you choose to reply.)
>
Sorry, it was a typo of mine, I meant to reply to the list
>
> > From: Ch
Hi Roger,
The patch as it is passed the validation, and it is in general OK.
Although it doesn't address the elephant in the room, namely
output_shift function, it is a welcome cleanup.
I would like you to split the patch in two. One which deals with
improvements on shifts in absence of a barrel s
On 10/4/23 15:49, Xianmiao Qu wrote:
>
> From: quxm
>
I'm sorry for posting the wrong username and email. If someone helps me merge
the code later, please delete this line for me (Just use the username and email
from the email I am currently sending, Xianmiao Qu
).
Thanks,
Xianmiao
On Wed, 4 Oct 2023 at 04:11, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Tue, 3 Oct 2023 15:20:39 +0200
>
> > The patch passed almost all our CI configurations, except arm-eabi when
> > testing with
> > -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> >
This was fixed as 'obvious' with an off-list OK, posted on the PR, from
Harald. Applied to 13-branch and trunk then closed as fixed.
Cheers
Paul
Fortran: Alloc comp of non-finalizable type not finalized [PR111674]
2023-10-04 Paul Thomas
gcc/fortran
PR fortran/37336
PR fortran/111674
* trans
On Mon, Oct 2, 2023 at 2:06 PM Sergei Trofimovich wrote:
>
> From: Sergei Trofimovich
>
> Without the change profiled bootstrap fails for various warnings on
> master branch as:
>
> $ ../gcc/configure
> $ make profiledbootstrap
> ...
> gcc/genmodes.cc: In function ‘int main(int, c
On Wed, 4 Oct 2023 at 03:56, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Tue, 3 Oct 2023 15:20:39 +0200
>
> > Maybe we need a new variant of dg-require-thread-fence ?
>
> Yes: many of the dg-require-thread-fence users need
> something stronger. Tested arm-eabi together with t
1 - 100 of 106 matches
Mail list logo