On Wed, 21 Aug 2024, Jiufu Guo wrote:
Hi,
There are a few PRs (meta-bug PR101926) about accessing aggregate
parameters/returns which are passed through registers.
A major reason of those issues is when access the aggregate, the
temporary stack slots are used without leverage the information ab
Hi, any more comments about this patch to fix zfa's ICE?
BR,
Jin
The heuristics for factoring out with a constant checks that the assignment
statement
is the last statement of the basic block but sometimes there is a predicate or
a nop statement
after the assignment. Rejecting this case does not make sense since both
predicates and nop
statements are removed
H=$BUNSEN/INST/bin:$PATH sh -x
+ echo master
+ echo basepoints/gcc-15-3524-ga523c2ba5862
+ echo a523c2ba58621c3630a1cd890d6db82879f92c90
+ echo git://gcc.gnu.org/git/gcc.git
+ find . -name '*.log' -o -name '*.sum' -o -name '.bunsen.*'
+ t-upload-git-push ssh://sou
пт, 13 сент. 2024 г. в 20:41, Georg-Johann Lay :
>
> The transparent call insns like "*parityhi2.libgcc" output a single
> [R]CALL instruction that can be skipped by the skip instructions.
> Such insns have attribute "type" of "xcall" and can therefore
> be easily recognized.
>
> Ok for trunk?
Ple
On Fri, 13 Sep 2024, Patrick Palka wrote:
> On Fri, 13 Sep 2024, Patrick Palka wrote:
>
> > On Fri, 13 Sep 2024, Jonathan Wakely wrote:
> >
> > > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> > > >
> > > > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > > > wrote:
> > > > >
> > > >
We currently ICE upon the following testcase when using -ftime-report
=== cut here ===
template < int> using __conditional_t = int;
template < typename _Iter >
concept random_access_iterator = requires { new _Iter; };
template < typename _Iterator >
struct reverse_iterator {
using iterator_conce
On Fri, 13 Sep 2024, Patrick Palka wrote:
> On Fri, 13 Sep 2024, Jonathan Wakely wrote:
>
> > On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> > >
> > > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > as usual thank you for the review. V2
On Fri, 13 Sep 2024, Jonathan Wakely wrote:
> On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> >
> > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > wrote:
> > >
> > > Hello,
> > >
> > > as usual thank you for the review. V2 is attached.
> > >
> > > On 02/08/2024 14:38, Jonathan Wakely w
On Sep 12, 2024, at 6:08 PM, Alexandre Oliva wrote:
>
> On Sep 12, 2024, Mike Stump wrote:
>
>> On Sep 3, 2024, at 11:44 PM, Alexandre Oliva wrote:
>>>
>>> Here's an updated and refreshed version that gets trunk built with
>>> --disable-hosted-libstdcxx on x86_64-linux-gnu to not get any spur
OK. Sorry about dropping the balli on a review.
I thought it had already been approved and committed.
--
steve
On Fri, Sep 13, 2024 at 12:19:48PM +0200, Mikael Morin wrote:
> Ping:
>
> https://gcc.gnu.org/pipermail/fortran/2024-July/060640.html
>
> Maybe I could argue that I can self approve,
On 9/12/24 3:12 PM, Marek Polacek wrote:
On Wed, Sep 11, 2024 at 10:25:34PM -0400, Jason Merrill wrote:
On 9/11/24 4:08 PM, Marek Polacek wrote:
@@ -6503,10 +6504,17 @@ check_bases_and_members (tree t)
bool fn_const_p = (copy == 2);
if (fn_const_p && !imp_const_p)
-
The transparent call insns like "*parityhi2.libgcc" output a single
[R]CALL instruction that can be skipped by the skip instructions.
Such insns have attribute "type" of "xcall" and can therefore
be easily recognized.
Ok for trunk?
Johann
--
AVR: Detect more skip opportunities.
The tra
On Fri, 13 Sept 2024 at 11:26, Jonathan Wakely wrote:
>
> On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
> >
> > On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> > wrote:
> > >
> > > Hello,
> > >
> > > as usual thank you for the review. V2 is attached.
> > >
> > > On 02/08/2024 14:38, Jonat
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
PR116696 expressed surprise that explicit 'constexpr' was needed on one
function; this was because the function isn't 'inline', and
-fimplicit-constexpr doesn't try to promote non-inline functions. Let's be
more helpful in that situation, a
Hi Jason,
On 12 Sep 2024, at 16:48, Jason Merrill wrote:
> On 9/12/24 7:23 AM, Simon Martin wrote:
>> Hi,
>>
>> While looking at more open PRs, I have discovered that the problem
>> reported in PR109790 is very similar to that in PR100632, so I’m
>> combining both in a single patch attached here.
пт, 13 сент. 2024 г. в 15:08, Georg-Johann Lay :
>
> This is a no-op change that uses the recently added avr_byte()
> function instead of simplify_gen_subreg (QImode, ...
>
> Ok for trunk?
Ok.
Please, apply.
Denis
>
> Johann
>
> --
>
> AVR: Use avr_byte instead of simplify_gen_subreg (QImod
On Fri, Sep 13, 2024 at 04:24:47PM +0200, Tobias Burnus wrote:
> As #embed is now supported by GCC (thanks!), I could commit this patch :-)
Thanks to Joseph for the reviews.
> Committed as r15-3629-g508ef585243d46 →
> https://gcc.gnu.org/r15-3629-g508ef585243d46
>
> Unless I missed something, we
On July 19, 2024 Tobias Burnus wrote:
Updated patch attached.
As #embed is now supported by GCC (thanks!), I could commit this patch :-)
Committed as r15-3629-g508ef585243d46 →
https://gcc.gnu.org/r15-3629-g508ef585243d46
Unless I missed something, we need to wait for a few pending patches
On 9/13/24 6:17 AM, Jakub Jelinek wrote:
Hi!
Another spot where we mark_used a function (in this case ctor or dtor)
even when it is just artificially used inside of thunks (emitted on mingw
with -Os for the testcase).
Bootstrapped/regtested on x86_64-linux and i686-linux and tested with
a cross
On Fri, Sep 13, 2024 at 12:33:00PM +0200, Jakub Jelinek wrote:
> Hi!
>
> Jonathan reported on IRC that certain unnamed proprietary static analyzer
> is unhappy about the new finish_embed function and it is actually right.
> On a testcase like:
> #embed __FILE__ limit (0) if_empty (0)
> params->if_
On Fri, 13 Sept 2024 at 11:00, Giuseppe D'Angelo wrote:
>
> Hello,
>
> Thank you for the review!
>
> Il 13/09/24 10:49, Jonathan Wakely ha scritto:
> >
> > But I can make these minor changes locally and push it if you want -
> > there's no need for a v2 patch.
> I'd gladly take this offer, please f
On Fri, Sep 13, 2024 at 01:19:02PM +0200, Richard Biener wrote:
> The genmatch.cc parts are OK - I wonder how much the new dependences
> push gimple-match* and generic-match* compilation to the end?
Only time will tell.
Looking at my past 3 x86_64-linux bootstraps (-j32) but I'm doing i686-linux
b
On Thu, Sep 12, 2024 at 7:20 PM Andrew Pinski wrote:
>
> While working on a different patch, I noticed the heuristics were not
> doing the right thing if there was statements before the NOP/PREDICTs.
> (LABELS don't have other statements before them).
>
> This fixes that oversight which was added
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 Wed, Sep 11, 2024 at 4:04 PM Richard Biener
> > wrote:
> > >
> > > On Wed, Sep 11, 2024 at 4:17 AM liuhongt wrote:
> > > >
> > > > GCC12 enables vectorization for O2 with very ch
After the loop exit an internal function call (CRC, CRC_REV) is added,
and its result is assigned to the output CRC variable (the variable where
the calculated CRC is stored
after the loop execution).
The removal of the loop is left to CFG cleanup and DCE.
gcc/
* gimple-crc-optimization.cc
Gives an opportunity to execute the code on bit level,
assigning symbolic values to the variables which don't have initial values.
Supports only CRC specific operations.
Example:
uint8_t crc;
uint8_t pol = 1;
crc = crc ^ pol;
during symbolic execution crc's value will be:
crc(8), crc(7), ... crc
This is a no-op change that uses the recently added avr_byte()
function instead of simplify_gen_subreg (QImode, ...
Ok for trunk?
Johann
--
AVR: Use avr_byte instead of simplify_gen_subreg (QImode, ...
There are many places where asm output functions have to look at
the constituen
Symbolically execute potential CRC loops and check whether the loop
actually calculates CRC (uses LFSR matching).
Calculated CRC and created LFSR are compared on each iteration of the
potential CRC loop.
gcc/
* Makefile.in (OBJS): Add crc-verification.o.
* crc-verification.cc: New file.
This patch introduces two new expanders for the aarch64 backend,
dedicated to generate optimized code for CRC computations.
The new expanders are designed to leverage specific hardware capabilities
to achieve faster CRC calculations,
particularly using the crc32, crc32c and pmull instructions when
On Thu, Aug 22, 2024 at 1:19 PM Richard Biener
wrote:
> On Fri, Aug 2, 2024 at 6:15 PM Mariam Arutunian
> wrote:
> >
> > After the loop exit an internal function call (CRC, CRC_REV) is added,
> > and its result is assigned to the output CRC variable (the variable
> where the calculated CRC is st
gcc/testsuite/gcc.target/aarch64/
* crc-builtin-pmul64.c: New test.
Signed-off-by: Mariam Arutunian
---
.../gcc.target/aarch64/crc-builtin-pmul64.c | 61 +++
1 file changed, 61 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/aarch64/crc-builtin-pmul64.c
diff
This patch introduces two new expanders for the i386 backend,
dedicated to generating optimized code for CRC computations.
The new expanders are designed to leverage specific hardware capabilities
to achieve faster CRC calculations,
particularly using the pclmulqdq or crc32 instructions when suppor
This patch adds a new compiler pass aimed at identifying naive CRC
implementations,
characterized by the presence of a loop calculating a CRC (polynomial long
division).
Upon detection of a potential CRC, the pass prints an informational message.
Performs CRC optimization if optimization level is
This patch introduces new built-in functions to GCC for computing
bit-forward and bit-reversed CRCs.
These builtins aim to provide efficient CRC calculation capabilities.
When the target architecture supports CRC operations (as indicated by the
presence of a CRC optab),
the builtins will utilize th
If the target is ZBC or ZBKC, it uses clmul instruction for the CRC
calculation. Otherwise, if the target is ZBKB, generates
table-based
CRC, but for reversing inputs and the output uses bswap and brev8
instructions. Add new tests to check CRC generation for ZBC, ZBKC
and
ZBKB
gcc/testsuite/gcc.target/riscv/
* crc-builtin-zbc32.c: New file.
* crc-builtin-zbc64.c: Likewise.
Signed-off-by: Mariam Arutunian
Mentored-by: Jeff Law
---
.../gcc.target/riscv/crc-builtin-zbc32.c | 21 ++
.../gcc.target/riscv/crc-builtin-zbc64.c | 66 ++
Add two new internal functions (IFN_CRC, IFN_CRC_REV), to provide faster
CRC generation.
One performs bit-forward and the other bit-reversed CRC computation.
If CRC optabs are supported, they are used for the CRC computation.
Otherwise, table-based CRC is generated.
The supported data and CRC sizes
Hi!
Jonathan reported on IRC that certain unnamed proprietary static analyzer
is unhappy about the new finish_embed function and it is actually right.
On a testcase like:
#embed __FILE__ limit (0) if_empty (0)
params->if_empty.count is 1, limit is 0, so count is 0 (we need just
a single token and
*PING*
Joseph, could you take a quick look at the handling of the new option?
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661267.html
Le 23/08/2024 à 10:31, Mikael Morin a écrit :
From: Mikael Morin
The documentation in this patch was partly reworded, compared
to the previous versi
On Sat, 3 Aug 2024 at 00:10, Jonathan Wakely wrote:
>
> On Fri, 2 Aug 2024 at 23:49, Giuseppe D'Angelo
> wrote:
> >
> > Hello,
> >
> > as usual thank you for the review. V2 is attached.
> >
> > On 02/08/2024 14:38, Jonathan Wakely wrote:
> > > On Fri, 2 Aug 2024 at 13:17, Jonathan Wakely wrote:
Ping:
https://gcc.gnu.org/pipermail/fortran/2024-July/060640.html
Maybe I could argue that I can self approve, as the patch is a partial
revert an old patch of mine:
https://gcc.gnu.org/r180889
Le 07/07/2024 à 11:00, Mikael Morin a écrit :
Hello,
this is another small cleanup I had lying a
Hi!
Another spot where we mark_used a function (in this case ctor or dtor)
even when it is just artificially used inside of thunks (emitted on mingw
with -Os for the testcase).
Bootstrapped/regtested on x86_64-linux and i686-linux and tested with
a cross compiler to x86_64-mingw on the testcase,
Hello,
Thank you for the review!
Il 13/09/24 10:49, Jonathan Wakely ha scritto:
But I can make these minor changes locally and push it if you want -
there's no need for a v2 patch.
I'd gladly take this offer, please feel free to amend as needed and push :)
Cheers,
--
Giuseppe D'Angelo
smi
The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
mandatory from Armv9.5-a. It introduces instructions for computing the
floating point absolute maximum and minimum of the two vectors
element-wise.
This patch adds code generation for famax and famin in terms of existing
unspecs.
The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
mandatory from Armv9.5-a. It introduces instructions for computing the
floating point absolute maximum and minimum of the two vectors
element-wise.
This patch introduces SVE2 faminmax intrinsics. The intrinsics of this
extension a
From: Saurabh Jha
This patch series adds support for SVE2 faminmax. It should be merged
only after AdvSIMD faminmax patch series is merged:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662131.html
The first patch adds intrinsics and the second patch adds support for
combining FMAX/FM
On Fri, 30 Aug 2024 at 11:52, Giuseppe D'Angelo wrote:
>
> Hello,
>
> This patch completes the fix for PR108846, extending it to range-based
> copy/move algorithms, and also fixes a faulty static_assert in them
> (PR116471).
> It's a minor improvement over the patch I've attached to PR116471 (I've
On 8/6/24 4:59 PM, Jakub Jelinek wrote:
On Mon, May 27, 2024 at 10:36:19AM +0530, Tejas Belagod wrote:
This patch tests various OpenMP lastprivate clause with SVE object types in
various construct contexts.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/omp/lastprivate.c: New test.
On Fri, Sep 13, 2024 at 8:32 AM Thor Preimesberger
wrote:
>
> > There are three oddities I immediately notice:
> >
> > The PLUS_EXPR operands are in a array "operands" while the RETURN_EXPR
> > "operand" or "child pointer" is refered to from "return_expr". I think
> > both are
> > tcc_expression
On Fri, Sep 13, 2024 at 8:00 AM wrote:
>
> From: Pan Li
>
> Given all commutative binary operators requires types matching
> for both operands. Remove the types_match check for case 1 of
> the signed SAT_ADD, because we have (bit_xor @0 @1), which ensure
> the operands have the correct TREE type
чт, 12 сент. 2024 г. в 17:32, Georg-Johann Lay :
>
> This patch reworks avr_out_compare:
>
> Use new convenient helper functions that may be useful in
> other output functions, too.
>
> Generalized some special cases that only work for EQ and NE
> comparisons. For example, with the patch
>
> ;; R2
I'll wait for Linaro CI to confirm this works, and then push.
I didn't see the regression because I only tested on x86_64.
-- >8 --
This aarch64-*-* test needs an update for the diagnostic I changed in
r15-3614-g9fe57e4879de93.
gcc/testsuite/ChangeLog:
* g++.dg/ext/sve-sizeless-1.C: Ad
53 matches
Mail list logo
