On Fri, 21 Jun 2024 at 15:51, Richard Sandiford
wrote:
>
> Evgeny Karpov writes:
> > Monday, June 10, 2024 7:03 PM
> > Richard Sandiford wrote:
> >
> >> Thanks for the update. Parts 1-5 look good to me. Some minor comments
> >> below about part 6:
> >>
> >> If the TARGET_DLLIMPORT_DECL_ATTRIBU
on 2024/6/21 18:36, Kewen.Lin wrote:
> Hi Arthur,
>
> on 2024/6/21 18:17, Arthur Cohen wrote:
>> Hi,
>>
>> Sorry about the delay in my answer! The patch looks good to me :) Will you
>> push it as part of your patchset?
>>
>
> Thanks for the review! Since this one doesn't necessarily depend on
>
Add the --include and --exclude flags to gcov to control what functions
to report on. This is meant to make gcov more practical as an when
writing test suites or performing other coverage experiments, which
tends to focus on a few functions at the time. This really shines in
combination with the -t
Hi All,
It looks like I forgot to check in the C++ frontend if a condition exist for the
loop being adorned with novector. This causes a segfault because cond isn't
expected to be null.
This fixes it by issuing the same kind of diagnostics we issue for the other
pragmas.
Bootstrapped Regtested
The value vec objects are destroyed on exit, but release still needs to
be called explicitly.
gcc/ChangeLog:
* tree-profile.cc (find_conditions): Release vectors before
return.
---
gcc/tree-profile.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/tree-profile.cc b/
gcc/ChangeLog:
* doc/gcov.texi: Add MC/DC section.
---
gcc/doc/gcov.texi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index dc79bccb8cf..a9221738cce 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/g
Without key terms like "masking" and "MC/DC" it is not at all obvious
what --conditions actually reports on, and there is no easy path for the
user to figure out. By at least including the two key terms MC/DC and
masking users have something to search for.
gcc/ChangeLog:
* gcov.cc (print_
Make gcov aware which edges are the true/false to more accurately
reconstruct the CFG. There are plenty of bits left in arc_info and it
opens up for richer reporting.
gcc/ChangeLog:
* gcov-io.h (GCOV_ARC_TRUE): New.
(GCOV_ARC_FALSE): New.
* gcov.cc (struct arc_info): Add
These are the main highlights since v1:
1. The instrumentation phase has been reworked and tries to eliminate
redundant instructions. This has a massive impact on performance,
taking the compile time of tree.c from 13m30s-14m to ~2m30s on my
machine, and the resulting tree.o from ~50M to
Hi Kewen,
Sorry for not answering earlier - yes, this sounds good to me :) thanks
for taking care of that.
Best,
Arthur
On 6/21/24 12:36, Kewen.Lin wrote:
Hi Arthur,
on 2024/6/21 18:17, Arthur Cohen wrote:
Hi,
Sorry about the delay in my answer! The patch looks good to me :) Will you pus
GCC maintainers:
version 3, rebased on current mainline tree. Version 2 of the patch was out of
sync. Retested the patch on
Power 10 with no regressions.
version 2, update the dg options per the feedback. Retested the patch on Power
10 with no regressions.
This patch updates the dg options.
on 2024/6/12 20:32, Ian Lance Taylor wrote:
> "Kewen.Lin" writes:
>
>> Hi,
>>
>> Gentle ping:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653387.html
>>
>> BR,
>> Kewen
>>
>> on 2024/6/3 11:00, Kewen Lin wrote:
>>> Joseph pointed out "floating types should have their mode,
>>> not a
Kewen:
On 6/23/24 19:41, Kewen.Lin wrote:
> Hi,
>
> on 2024/6/22 00:15, Carl Love wrote:
>> GCC maintainers:
>>
>> version 2, update the dg options per the feedback. Retested the patch on
>> Power 10 with no regressions.
>>
>> This patch updates the dg options.
>>
>> The patch has been tested o
Hi all,
I just pushed this 09/52 v2 with its following target changes
as r15-1594, thanks a lot for your comments/reviews/approvals!
BR,
Kewen
> Subject: [PATCH 09/52] Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook
> mode_for_floating_type
>
> Currently how we determine which mode will
Jeff Law writes:
> On 6/17/24 3:53 AM, Richard Sandiford wrote:
>> This patch makes target-independent code use force_subreg instead
>> of simplify_gen_subreg in some places. The criteria were:
>>
>> (1) The code is obviously specific to expand (where new pseudos
>> can be created), or at l
Hi!
On 2024-06-20T14:34:18+0100, Richard Sandiford
wrote:
> This patch adds a combine pass that runs late in the pipeline.
> [...]
Nice!
> The patch [...] disables the pass by default on i386, rs6000
> and xtensa.
Like here:
> --- a/gcc/config/i386/i386-options.cc
> +++ b/gcc/config/i386/i38
Thomas Schwinge writes:
> Hi!
>
> On 2024-06-20T14:34:18+0100, Richard Sandiford
> wrote:
>> This patch adds a combine pass that runs late in the pipeline.
>> [...]
>
> Nice!
>
>> The patch [...] disables the pass by default on i386, rs6000
>> and xtensa.
>
> Like here:
>
>> --- a/gcc/config/i38
Hi!
On 2024-06-25T10:07:47+0100, Richard Sandiford
wrote:
> Thomas Schwinge writes:
>> On 2024-06-20T14:34:18+0100, Richard Sandiford
>> wrote:
>>> This patch adds a combine pass that runs late in the pipeline.
>>> [...]
>>
>> Nice!
>>
>>> The patch [...] disables the pass by default on i386,
Thomas Schwinge writes:
> Hi!
>
> On 2024-06-25T10:07:47+0100, Richard Sandiford
> wrote:
>> Thomas Schwinge writes:
>>> On 2024-06-20T14:34:18+0100, Richard Sandiford
>>> wrote:
This patch adds a combine pass that runs late in the pipeline.
[...]
>>>
>>> Nice!
>>>
The patch [.
>>
>> >> - if (slp_node)
>> >> + if (slp_node && SLP_TREE_LANES (slp_node) > 1)
>> >
>> > Hmm, that looks wrong. It looks like SLP_TREE_NUMBER_OF_VEC_STMTS is off
>> > instead, which is bad.
>> >
>> >> nvectors = SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node);
>> >>else
>> >>
Ping.[Message-ID: <1a420e3e-3285-4e0b-87bd-6714fedc0...@linux.ibm.com>]
Peter
On 6/19/24 4:14 PM, Peter Bergner wrote:
> We currently only emit the ROP-protect hash* insns for Power10, where the
> insns were added to the architecture. We want to emit them for earlier
> cpus (where they oper
This passes -m32 when -mv8plus is specified on Linux (like on Solaris).
Applied to mainline and 14 branch.
2024-06-25 Eric Botcazou
PR target/115608
* config/sparc/linux64.h (CC1_SPEC): Pass -m32 for -mv8plus.
--
Eric Botcazoudiff --git a/gcc/config/sparc/linux64.h b/gcc/c
Hi,
on 2024/6/25 03:00, Carl Love wrote:
> GCC maintainers:
>
> version 3, rebased on current mainline tree. Version 2 of the patch was out
> of sync. Retested the patch on
> Power 10 with no regressions.
>
> version 2, update the dg options per the feedback. Retested the patch on
> Power 1
Hi Evgeny,
I am not sure whether I have chosen the right email in the thread but:
a x86-64 GNU Linux build currently fails as follows.
At a glance, it seems to be sufficient to remove the prototype
declaration in i386.cc.
Namely:
gcc/config/i386/i386.cc:107:12: error: 'rtx_def*
legitimize_d
> The value vec objects are destroyed on exit, but release still needs to
> be called explicitly.
>
> gcc/ChangeLog:
>
> * tree-profile.cc (find_conditions): Release vectors before
> return.
I wonder if you turn
hash_map, vec> exprs;
to
hash_map, auto_vec> exprs;
Won't hash_
> gcc/ChangeLog:
>
> * doc/gcov.texi: Add MC/DC section.
OK,
thanks!
Honza
> ---
> gcc/doc/gcov.texi | 72 +++
> 1 file changed, 72 insertions(+)
>
> diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
> index dc79bccb8cf..a9221738cce 100644
> ---
> Without key terms like "masking" and "MC/DC" it is not at all obvious
> what --conditions actually reports on, and there is no easy path for the
> user to figure out. By at least including the two key terms MC/DC and
> masking users have something to search for.
>
> gcc/ChangeLog:
>
> *
On Tue, Jun 25, 2024 at 11:32 AM Feng Xue OS
wrote:
>
> >>
> >> >> - if (slp_node)
> >> >> + if (slp_node && SLP_TREE_LANES (slp_node) > 1)
> >> >
> >> > Hmm, that looks wrong. It looks like SLP_TREE_NUMBER_OF_VEC_STMTS is off
> >> > instead, which is bad.
> >> >
> >> >> nvector
On Mon, Jun 24, 2024 at 9:38 PM Segher Boessenkool
wrote:
>
> I didn't see this before. Sigh.
>
> On Tue, Jan 02, 2024 at 09:47:11AM +, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> > >> This patch adds a c
On 6/25/24 12:23, Jan Hubicka wrote:
The value vec objects are destroyed on exit, but release still needs to
be called explicitly.
gcc/ChangeLog:
* tree-profile.cc (find_conditions): Release vectors before
return.
I wonder if you turn
hash_map, vec> exprs;
to
hash_m
On 6/25/24 12:25, Jan Hubicka wrote:
Without key terms like "masking" and "MC/DC" it is not at all obvious
what --conditions actually reports on, and there is no easy path for the
user to figure out. By at least including the two key terms MC/DC and
masking users have something to search for.
gc
Tuesday, June 25, 2024 12:03 PM
Tobias Burnus wrote:
>
> Hi Evgeny,
>
> I am not sure whether I have chosen the right email in the thread but:
> a x86-64 GNU Linux build currently fails as follows.
>
> At a glance, it seems to be sufficient to remove the prototype
> declaration in i386.cc.
>
>
Hi!
On 2024-06-14T11:08:15+0200, Richard Biener wrote:
> We can at least mimic single def-use cycle optimization when doing
> single-lane SLP reductions and that's required to avoid regressing
> compared to non-SLP.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
>
> * tree
On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
>
> On 6/18/24 10:31, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
>
> Makes sense to me, though probably the [meta.unary.prop] table should be
> adjusted in the same way. Jonathan, what do you think
Hi,
With the introduction of low overhead loops in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3dfc28dbbd21b1d708aa40064380ef4c42c994d7
we defined arm_predict_doloop_p, this is meant to be a low-weight check
to rule out loops we are not considering for doloop optimization and it
is used by
This should help to diagnose problems like PR115631.
Bootstrapped & regression-tested on aarch64-linux-gnu, pushed as obvious.
Richard
gcc/
* dbgcnt.def (late_combine): New debug counter.
* late-combine.cc (insn_combination::run): Use it.
---
gcc/dbgcnt.def | 1 +
gcc/late
Hi All,
This adds a conditional store optimization for the vectorizer as a pattern.
The vectorizer already supports modifying memory accesses because of the pattern
based gather/scatter recognition.
Doing it in the vectorizer allows us to still keep the ability to vectorize such
loops for archite
Ping^4 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html
On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote:
> In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if
> the build is configured --enable-default-pie. Let's fix them.
>
> Tested on x86_64-linux-gnu. Ok for
Gerald noticed these stale viewcvs links. I'll push this to trunk later
this week, and backport too.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/faq.xml: Replace viewcvs links with cgit links.
* doc/xml/manual/allocator.xml: Likewise.
* doc/xml/manual/mt_allocator.xml: Lik
From: Pan Li
This patch would like to add the test cases of the vector truncate after
.SAT_SUB. Aka:
#define DEF_VEC_SAT_U_SUB_TRUNC_FMT_1(OUT_T, IN_T) \
void __attribute__((noinline)) \
vec_sat_u_sub_trunc_##OUT_T##_fmt_1 (OUT_T *ou
Please read https://gcc.gnu.org/contribute.html#patches and ensure
you've included everything, for example ...
On 22/06/24 17:11 -0400, Shengdun Wang wrote:
__glibcxx_assert_fail is not defined when we disable
the libstdcxx-verbose. This causes ABI break when a
binary is compiled with verbose en
On Tue, 25 Jun 2024, Thomas Schwinge wrote:
> Hi!
>
> On 2024-06-14T11:08:15+0200, Richard Biener wrote:
> > We can at least mimic single def-use cycle optimization when doing
> > single-lane SLP reductions and that's required to avoid regressing
> > compared to non-SLP.
> >
> > Bootstrapped and
On Mon, Jun 24, 2024 at 1:28 AM liuhongt wrote:
>
> > I think the check for TYPE_UNSIGNED should be of TREE_TYPE (@0) rather
> > than type here.
>
> Changed
>
> > Or maybe you need `types_match (type, TREE_TYPE (@0))` too.
> And use tree_nop_conversion_p (type, TREE_TYPE (@0)) and add view_convert
On Mon, 24 Jun 2024, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, June 20, 2024 8:49 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; bin.ch...@linux.alibaba.com
> > Subject: RE: [PATCH][ivopts]: use affine_tree when com
On 6/24/24 22:35, Andrew Pinski wrote:
On Mon, Jun 24, 2024 at 7:20 PM Andrew MacLeod wrote:
// Fill ssa-cache R with any outgoing ranges on edge E, using QUERY.
bool gori_on_edge (class ssa_cache &r, edge e, range_query *query =
NULL);
This is what the fast_vrp routines uses. We ca
On Tue, 25 Jun 2024, Hu, Lin1 wrote:
> Hi,
>
> This is the current version.
>
> I haven't made any major changes to the original code, I think it will have
> less impact on your code. And I think the current API is sufficient to
> support the mode selection you mentioned, if you have any conc
The following fixes a missed tail-merging observed for the testcase
in PR115629. The issue is that when deps_ok_for_redirect doesn't
compute both would be valid prevailing blocks it rejects the merge.
The following instead makes sure to record the working block as
prevailing. Also stmt comparison
The following replaces conditional is_export_p calls as is_export_p
handles a NULL bb itself.
Bootstrap running on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
* gimple-range-gori.cc (gori_compute::may_recompute_p):
Call is_export_p with NULL bb.
---
gcc/gimple-range-gori.cc |
gcc/ChangeLog:
* doc/rtl.texi (jump_table_data): Fix typos.
---
Pushed as obvious.
gcc/doc/rtl.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index c1717ab5f6b..a1ede418c21 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.
On 6/25/24 09:44, Richard Biener wrote:
The following replaces conditional is_export_p calls as is_export_p
handles a NULL bb itself.
Bootstrap running on x86_64-unknown-linux-gnu, OK?
Absolutely.
Thanks
Andrew
Thanks,
Richard.
* gimple-range-gori.cc (gori_compute::may_recompute
> On Jun 24, 2024, at 1:50 AM, Stefan Schulze Frielinghaus
> wrote:
>
> Ping.
>
> On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote:
>> Ping.
>>
>> On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote:
>>> This implements hard register constr
late-combine was failing to take targetm.cannot_copy_insn_p into
account, which led to multiple definitions of PIC symbols on
arm*-*-* targets.
Currently bootstrapping & regression testing on arm-linux-gnueabihf
and aarch64-linus-gnu. It should fix the bootstrap-lto problem
reported by Linaro's C
The following makes analysis and transform agree on constraints.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
PR tree-optimization/115646
* tree-call-cdce.cc (check_pow): Check for bit_sz values
as allowed by transform.
* gcc.dg/pr115646.c: New testc
On 6/25/24 8:07 AM, Richard Sandiford wrote:
late-combine was failing to take targetm.cannot_copy_insn_p into
account, which led to multiple definitions of PIC symbols on
arm*-*-* targets.
Currently bootstrapping & regression testing on arm-linux-gnueabihf
and aarch64-linus-gnu. It should fi
This function had a reference to an uninitialized variable on the
error path. The problem was diagnosed by clang but not gcc. It seems
the cleanest solution is to initialize all the loop-clause variables
at the point of declaration rather than at different places in the
code.
The C++ front end d
On Tue, 25 Jun 2024, Paul Koning wrote:
> >>> could be rewritten into
> >>>
> >>> int test (int x, int y)
> >>> {
> >>> asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y));
> >>> return x;
> >>> }
>
> I like this idea but I'm wondering: regular constraints specify what
> sort of value is
On Mon, 24 Jun 2024, Jason Merrill wrote:
> On 6/24/24 21:00, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk/14?
> >
> > -- >8 --
> >
> > The capture proxy handling in finish_decltype_type added in r14-5330
> > was stripping the refere
On Thu, 13 Jun 2024, Patrick Palka wrote:
> On Thu, 13 Jun 2024, Jason Merrill wrote:
>
> > On 6/13/24 11:05, Patrick Palka wrote:
> > > On Thu, 23 May 2024, Jason Merrill wrote:
> > >
> > > > On 5/23/24 17:42, Patrick Palka wrote:
> > > > > On Thu, 23 May 2024, Jason Merrill wrote:
> > > > >
>
On 25/06/2024 12:53, Andre Vieira (lists) wrote:
> Hi,
>
> With the introduction of low overhead loops in
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3dfc28dbbd21b1d708aa40064380ef4c42c994d7
> we defined arm_predict_doloop_p, this is meant to be a low-weight check to
> rule out loops we are
On 6/25/24 07:15, Jonathan Wakely wrote:
On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
On 6/18/24 10:31, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
Makes sense to me, though probably the [meta.unary.prop] table should be
adjusted in the same
On 6/25/24 11:03, Patrick Palka wrote:
On Mon, 24 Jun 2024, Jason Merrill wrote:
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
The capture proxy handling in finish_decltype_type added in r14-5330
was strippi
On 6/13/24 13:00, Patrick Palka wrote:
On Thu, 13 Jun 2024, Jason Merrill wrote:
On 6/13/24 11:05, Patrick Palka wrote:
On Thu, 23 May 2024, Jason Merrill wrote:
On 5/23/24 17:42, Patrick Palka wrote:
On Thu, 23 May 2024, Jason Merrill wrote:
On 5/23/24 14:06, Patrick Palka wrote:
Bootst
On Tue, 25 Jun 2024, Jason Merrill wrote:
> On 6/25/24 11:03, Patrick Palka wrote:
> > On Mon, 24 Jun 2024, Jason Merrill wrote:
> >
> > > On 6/24/24 21:00, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > for trunk/14?
> > > >
> > > > --
On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote:
>
>
> > On Jun 24, 2024, at 1:50 AM, Stefan Schulze Frielinghaus
> > wrote:
> >
> > Ping.
> >
> > On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote:
> >> Ping.
> >>
> >> On Fri, May 24, 2024 at 11:13:12AM
On 6/25/24 04:01, Tamar Christina wrote:
Hi All,
It looks like I forgot to check in the C++ frontend if a condition exist for the
loop being adorned with novector. This causes a segfault because cond isn't
expected to be null.
This fixes it by issuing the same kind of diagnostics we issue for
On Mon, Jun 24, 2024 at 10:00:40PM -0700, Andrew Pinski wrote:
> The problem here is even though we pass std namespace to lookup_template_class
> as the context, it will look at the current scope for the name too.
> The fix is to lookup the qualified name first and then use that
> for lookup_templa
The 06/25/2024 17:10, Jason Merrill wrote:
> On 6/25/24 04:01, Tamar Christina wrote:
> > Hi All,
> >
> > It looks like I forgot to check in the C++ frontend if a condition exist
> > for the
> > loop being adorned with novector. This causes a segfault because cond isn't
> > expected to be null.
Hello All:
This patch addressed cleanup of the code and fix linaro failures.
All comments are addressed.
Common infrastructure using generic code for pair mem fusion of different
targets.
rs6000 target specific code implement virtual functions defined by generic code.
Target specific code are
> On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus
> wrote:
>
> On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote:
>>
> ...
> could be rewritten into
>
> int test (int x, int y)
> {
> asm ("foo %0,%1,%2" : "+{r4}" (x) : "{r5}" (y), "d" (y));
>
Just FYI. This patch does something to gcc.target/mips/madd-8.c, and
gcc.target/mips/msub-8.c.
-PASS: gcc.target/mips/madd-8.c -O2 scan-assembler \tmul\t
-PASS: gcc.target/mips/madd-8.c -O2 scan-assembler-not \tmadd\t
-PASS: gcc.target/mips/madd-8.c -O2 scan-assembler-not \tmflo\t
-PAS
On Tue, 25 Jun 2024 at 16:17, Jason Merrill wrote:
>
> On 6/25/24 07:15, Jonathan Wakely wrote:
> > On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
> >>
> >> On 6/18/24 10:31, Marek Polacek wrote:
> >>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
> >>
> >> Makes sense to
So the late combine work has exposed a latent bug in the fr30 port.
The fr30 "call" instruction is pc-relative with a *very* limited range,
12 bits to be precise.
With such a limited range its hard to see how we could ever consistently
use it in the compiler, with the possible exception of s
Alexandre Oliva writes:
> On Jun 24, 2024, "Richard Earnshaw (lists)" wrote:
>
>> A signed shift right on a 16-bit vector element by 15 would still
>> yield -1
>
> Yeah. Indeed, ISTM that we *could* have retained the clamping
> transformation for *signed* shifts, since the clamping would only ma
Thanks for the review and the inputs, Richard Biener. The `-finline-as=` option
is an interesting.
However, this PR specifically aims to make these `-O3` inline params to be
available under some `-f` option, similar to some of the existing inline
options.
On 6/24/24, 6:28 AM, "Richard Biener"
On Tue, Jun 25, 2024 at 06:22:56PM +0100, Jonathan Wakely wrote:
> On Tue, 25 Jun 2024 at 16:17, Jason Merrill wrote:
> >
> > On 6/25/24 07:15, Jonathan Wakely wrote:
> > > On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
> > >>
> > >> On 6/18/24 10:31, Marek Polacek wrote:
> > >>> Bootstrapped
On 6/25/24 00:27, Andrew Pinski wrote:
On Mon, Jun 24, 2024 at 7:35 PM Andrew Pinski wrote:
This should be:
warning (OPT_Wdisabled_optimization, "Using fast VRP algorithm. %d basic blocks"
" exceeds %<%--param=vrp-block-limit=d%> limit",
n_basic_blocks_for_fn (fun), param_vrp_block_limi
This is another round of AMO testcase cleanup. Consolidates a lot of testcases
and unifies the testcase names.
Patrick O'Neill (3):
RISC-V: Rename amo testcases
RISC-V: Consolidate amo testcase variants
RISC-V: Update testcase comments to point to PSABI rather than Table
A.6
.../gcc.ta
Rename riscv/amo/ testcases to follow a '{ext}-{model}-{name}-{memory order}.c'
naming convention.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo/amo-table-a-6-load-2.c: Move to...
* gcc.target/riscv/amo/a-rvwmo-load-acquire.c: ...here.
* gcc.target/riscv/amo/amo-table-a-
Many riscv/amo/ testcases use check-function-bodies. These testcases can be
consolidated with related testcases (memory ordering variants) without affecting
the assertions.
Give functions descriptive names so testsuite failures are obvious from the
'FAIL:' line.
gcc/testsuite/ChangeLog:
Table A.6 was originally the source of truth for the recommended mappings.
Point to the PSABI doc since the memory model mappings have been moved there.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo/a-rvwmo-fence.c: Replace A.6 reference with
PSABI.
* gcc.target/riscv/amo/a-rvw
On 6/25/24 15:07, Marek Polacek wrote:
On Tue, Jun 25, 2024 at 06:22:56PM +0100, Jonathan Wakely wrote:
On Tue, 25 Jun 2024 at 16:17, Jason Merrill wrote:
On 6/25/24 07:15, Jonathan Wakely wrote:
On Tue, 25 Jun 2024 at 03:12, Jason Merrill wrote:
On 6/18/24 10:31, Marek Polacek wrote:
Bo
On 6/25/24 12:52, Tamar Christina wrote:
The 06/25/2024 17:10, Jason Merrill wrote:
On 6/25/24 04:01, Tamar Christina wrote:
Hi All,
It looks like I forgot to check in the C++ frontend if a condition exist for the
loop being adorned with novector. This causes a segfault because cond isn't
exp
On 6/25/24 11:45, Patrick Palka wrote:
On Tue, 25 Jun 2024, Jason Merrill wrote:
On 6/25/24 11:03, Patrick Palka wrote:
On Mon, 24 Jun 2024, Jason Merrill wrote:
On 6/24/24 21:00, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8
On 12/19/23 2:53 AM, Sergei Lewis wrote:
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_vector::expand_vec_cmpmem): New
function
declaration.
* config/riscv/riscv-string.cc (riscv_vector::expand_vec_cmpmem): New
function; this generates an inline vectorised memory c
On Mon, 2024-06-24 at 21:27 -0700, Andrew Pinski wrote:
> On Mon, Jun 24, 2024 at 7:35 PM Andrew Pinski
> wrote:
> >
> > On Mon, Jun 24, 2024 at 7:20 PM Andrew MacLeod
> > wrote:
> > >
> > >
> > > On 6/22/24 09:15, Richard Biener wrote:
> > > > On Fri, Jun 21, 2024 at 3:02 PM Andrew MacLeod
>
On 6/25/24 3:14 PM, Patrick O'Neill wrote:
This is another round of AMO testcase cleanup. Consolidates a lot of testcases
and unifies the testcase names.
Patrick O'Neill (3):
RISC-V: Rename amo testcases
RISC-V: Consolidate amo testcase variants
RISC-V: Update testcase comments to po
On 6/25/24 2:04 AM, Jørgen Kvalsvik wrote:
Make gcov aware which edges are the true/false to more accurately
reconstruct the CFG. There are plenty of bits left in arc_info and it
opens up for richer reporting.
gcc/ChangeLog:
* gcov-io.h (GCOV_ARC_TRUE): New.
(GCOV_ARC_FALSE)
The patch fixes the issue introduced in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=63512c72df09b43d56ac7680cdfd57a66d40c636
and reported at
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655599.html .
Regards,
Evgeny
The patch fixes the issue with compilation on x86_64-gnu-linux
when war
From: Gianluca Guida
The Zabha extension adds support for subword Zaamo ops.
Extension: https://github.com/riscv/riscv-zabha.git
Ratification: https://jira.riscv.org/browse/RVS-1685
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::to_string): Skip zabha
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2023.xml: Change reference from
mainline GCC to the release branch.
* doc/html/manual/status.html: Regenerate.
---
libstdc++-v3/doc/html/manual/status.html | 3 +--
libstdc++-v3/doc/xml/manual/status_cxx2023.xml | 3
Pushed to gcc-12.
-- >8 --
When I tried to make the release branch versions of these docs refer to
the release branch instead of "mainline GCC", for some reason I left the
text "not any particular release" there. That's just confusing, because
the docs are for a particular release, the latest on
Pushed to gcc-13.
-- >8 --
When I tried to make the release branch versions of these docs refer to
the release branch instead of "mainline GCC", for some reason I left the
text "not any particular release" there. That's just confusing, because
the docs are for a particular release, the latest on
On Tue, 25 Jun 2024 at 23:34, Jonathan Wakely wrote:
>
> Pushed to gcc-13.
And the equivalent for gcc-14 too.
>
> -- >8 --
>
> When I tried to make the release branch versions of these docs refer to
> the release branch instead of "mainline GCC", for some reason I left the
> text "not any parti
This script automates some updates that should be made when branching
from trunk. Putting them in a script makes it much easier and means I
won't forget what should be done.
Any suggestions for doing this differently?
Anything I've forgotten that should be added here?
We could add an entry to th
Pushed to trunk.
On Thu, 20 Jun 2024 at 16:34, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> Dispatching to partial specializations doesn't really seem to offer much
> benefit here. The __is_trivial(T) condition is a compile-time constant
> so the untaken branches are dead code
> On 25 Jun 2024, at 22:59, Evgeny Karpov wrote:
>
> The patch fixes the issue introduced in
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=63512c72df09b43d56ac7680cdfd57a66d40c636
> and reported at
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655599.html .
Trivial patches like this
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translates DW_TAG_union_type DIEs into LF_UNION symbols.
gcc/
* dwarf2codeview.cc (write_lf_union): New function.
(write_custom_types): Call write_lf_union.
(add_struct_forward_def): Handle DW_TAG_union_type
On 6/17/24 6:17 PM, Mark Harmstone wrote:
Translates DW_TAG_array_type DIEs into LF_ARRAY symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_array to union.
(write_lf_array): New function.
(write_custom_types): Call
As reported here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655434.html
the schema validation I added for generated .sarif files in
r15-1541-ga84fe222029ff2 used the "jsonschema" command line tool, which
has been deprecated by more recent versions of the Python 3 "jsonschema"
module.
T
This patch eliminates all implicit uses of "global_dc" from
the path-printing logic and from
gcc_rich_location::add_location_if_nearby.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu
1 - 100 of 110 matches
Mail list logo
