On Tue, Sep 3, 2024 at 2:24 PM Haochen Jiang wrote:
>
> Hi all,
>
> The intrin for non-optimized got a typo in mask type, which will cause
> the high bits of __mmask32 being unexpectedly zeroed.
>
> The test does not fail under O0 with current 1b since the testcase is
> wrong. We need to include a
The following avoids performing re-discovery with single lanes in
the attempt to for the use of mask_load_lane as rediscovery will
fail since a single lane of a mask load will appear permuted which
isn't supported.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimiz
On Mon, 2 Sep 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled. The problem is in the last_ovf step.
> The second operand has signed _BitInt(513) type but has the MSB clear,
> so range_to_prec returns 512 for it (i.e. it fits into unsigned
> _BitInt(512)). Because of t
On Mon, 2 Sep 2024, Tobias Burnus wrote:
> Hi Richard,
>
> Am 02.09.24 um 13:58 schrieb Richard Biener:
> > Hmm, I can't really follow how and where it's currently decided whether to
> > output offload tables for the LTRANS units
>
> Before the patch, output_offload_tables is called unconditiona
> -Original Message-
> From: Hu, Lin1
> Sent: Tuesday, September 3, 2024 2:05 PM
> To: Jakub Jelinek ; Andrew Pinski ;
> Liu, Hongtao
> Cc: Jiang, Haochen ; Richard Biener
> ; gcc-patches@gcc.gnu.org; ubiz...@gmail.com
> Subject: RE: [PATCH 2/8] i386: Optimize ordered and nonequal
>
> >
On Linux/x86_64,
8e16f26ca9fad685b9b723da7112ffcc99e81593 is the first bad commit
commit 8e16f26ca9fad685b9b723da7112ffcc99e81593
Author: Levy Hsu
Date: Mon Aug 26 10:46:30 2024 +0930
i386: Support partial vectorized V2BF/V4BF plus/minus/mult/div/sqrt
caused
FAIL: gcc.target/i386/avx10_2
> -Original Message-
> From: Richard Biener
> Sent: Monday, September 2, 2024 12:47 PM
> To: Prathamesh Kulkarni
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [gimplify.cc] Avoid ICE when passing VLA vector to
> accelerator
>
> External email: Use caution opening links or attachments
>
>
From: Bob Duff
Do not pass null for the Collection parameter when
Finalize_Storage_Only is in effect. If the collection
is null in that case, we will blow up later when we
deallocate the object.
gcc/ada/
* exp_ch6.adb (Add_Collection_Actual_To_Build_In_Place_Call):
Remove Finali
From: Steve Baird
Implement the new legality rules of AI22-0106 which (as discussed in the AI)
are needed to disallow constructs whose semantics would otherwise be poorly
defined.
gcc/ada/
* sem_aggr.adb (Resolve_Array_Aggregate): Implement the two new
legality rules of AI11-010
From: Eric Botcazou
The initial implementation of the GNAT aspect/pragma Volatile_Full_Access
made it incompatible with Atomic, because it was not decided whether the
read-modify-write sequences generated by Volatile_Full_Access would need
to be implemented atomically when Atomic was also specifi
From: Steve Baird
The non-strict overflow checking code does a better job of eliminating
overflow checks if given an expression consisting only of predefined
operators (including relationals), literals, identifiers, and conditional
expressions. If it is both feasible and useful, rewrite a
Length
From: Eric Botcazou
The initial implementation of the GNAT aspect/pragma Volatile_Full_Access
made it incompatible with Atomic, because it was not decided whether the
read-modify-write sequences generated by Volatile_Full_Access would need
to be implemented atomically when Atomic was also specifi
From: Eric Botcazou
Some ancient 32-bit ABIs, most notably that of x86/Linux, misalign double
scalars in record types, so comparing DECL_ALIGN with TYPE_ALIGN directly
may give the wrong answer for them.
gcc/ada/
* gcc-interface/trans.cc (addressable_p) : Add kludge
to cope with
The procedure Note_Uplevel_Bound was implemented as a custom expression
tree walk. This change replaces this custom tree traversal by a more
idiomatic use of Traverse_Proc.
gcc/ada/
* exp_unst.adb (Check_Static_Type::Note_Uplevel_Bound): Refactor
to use the generic Traverse_Proc.
From: Eric Botcazou
This has historically been done only on platforms requiring the strict
alignment of memory references, but this can arguably be considered as
being mandated by the language on all of them.
gcc/ada/
* gcc-interface/trans.cc (addressable_p) : Take into
account
From: Eric Botcazou
When updating the size after making a packable type in gnat_to_gnu_field,
we fail to clear it again when it is not constant.
gcc/ada/
* gcc-interface/decl.cc (gnat_to_gnu_field): Clear again gnu_size
after updating it if it is not constant.
Tested on x86_64-
From: Eric Botcazou
The change causes more temporaries to be created at call sites for unaligned
actual parameters, thus revealing that the machinery does not properly deal
with unconstrained nominal subtypes for them.
gcc/ada/
* gcc-interface/trans.cc (create_temporary): Deal with type
On Fri, Aug 30, 2024 at 4:41 AM Jennifer Schmitz wrote:
>
> This patch implements constant folding of binary operations for SVE intrinsics
> by calling the constant-folding mechanism of the middle-end for a given
> tree_code.
> In fold-const.cc, the code for folding vector constants was moved from
On Tue, 3 Sep 2024, Prathamesh Kulkarni wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, September 2, 2024 12:47 PM
> > To: Prathamesh Kulkarni
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [gimplify.cc] Avoid ICE when passing VLA vector to
> > accelerator
> >
On Tue, 3 Sep 2024, Andrew Pinski wrote:
> On Fri, Aug 30, 2024 at 4:41 AM Jennifer Schmitz wrote:
> >
> > This patch implements constant folding of binary operations for SVE
> > intrinsics
> > by calling the constant-folding mechanism of the middle-end for a given
> > tree_code.
> > In fold-con
The following moves the assert on NUM_POLY_INT_COEFFS != 1 after
INTEGER_CST processing.
Bootstrap and regtest running on x86_64-unknown-linux-gnu, pushed
as obvious after getting into stage3.
* fold-const.cc (poly_int_binop): Move assert on
NUM_POLY_INT_COEFFS after INTEGER_CST p
"H.J. Lu" writes:
> On Tue, Aug 27, 2024 at 1:11 PM H.J. Lu wrote:
>>
>> Update analyze_parms not to disable function parameter analysis for
>> -ffat-lto-objects. Tested on x86-64, there are no differences in zstd
>> with "-O2 -flto=auto" -g "vs -O2 -flto=auto -g -ffat-lto-objects".
>>
>>
On Tue, Sep 03, 2024 at 10:42:34AM +0200, Richard Biener wrote:
> The following moves the assert on NUM_POLY_INT_COEFFS != 1 after
> INTEGER_CST processing.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu, pushed
> as obvious after getting into stage3.
>
> * fold-const.cc (pol
On Mon, Sep 2, 2024 at 4:23 AM H.J. Lu wrote:
>
> On Tue, Aug 27, 2024 at 1:11 PM H.J. Lu wrote:
> >
> > Update analyze_parms not to disable function parameter analysis for
> > -ffat-lto-objects. Tested on x86-64, there are no differences in zstd
> > with "-O2 -flto=auto" -g "vs -O2 -flto=auto -
On Linux/x86_64,
62df24e50039ae04aa3b940e680cffd9041ef5bf is the first bad commit
commit 62df24e50039ae04aa3b940e680cffd9041ef5bf
Author: Levy Hsu
Date: Tue Aug 27 14:22:20 2024 +0930
i386: Support partial vectorized V2BF/V4BF smaxmin
caused
FAIL: gcc.target/i386/avx10_2-512-bf-vector-sm
Monday, September 2, 2024 3:15 PM
Kyrylo Tkachov wrote:
>> libstdc++-v3/ChangeLog:
>>
>> * src/c++17/fast_float/fast_float.h (defined): Adjust a condition
>> for AArch64.
>
> libstdc++ is reviewed on its own list (CC’ed here) so I’d suggest splitting
> the libstdc++-v3 hunk into its
> On 3 Sep 2024, at 10:39, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, 3 Sep 2024, Andrew Pinski wrote:
>
>> On Fri, Aug 30, 2024 at 4:41 AM Jennifer Schmitz wrote:
>>>
>>> This patch implements constant folding of binary operations for S
Ok for trunk and releases/gcc-14?
--
Some of the test cases were scanning for "bti", but it would,
incorrectly, match the ".arch_extenssion pacbti".
Also, keep test cases active if a supported Cortex-M core is supplied.
gcc/testsuite/ChangeLog:
* gcc.target/arm/bti-1.c: Enable for Cor
This makes sure to produce interleaving schemes or load-lanes
for single-element interleaving and other permutes that otherwise
would use more than three vectors.
It exposes the latent issue that single-element interleaving with
large gaps can be inefficient - the mitigation in get_group_load_stor
Hello Richard:
This patch addresses all the review comments.
It also fix the arm build failure.
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 added in r
* MAINTAINERS: Update my email address and add myself to DCO.
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 07ea5f5b6e1..cfd96c9f33e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -676,7 +676,7 @@ Christoph Müllner
> > >
> > > PR ipa/116410
> > > * ipa-modref.cc (analyze_parms): Always analyze function parameter
> > > for LTO streaming.
> > >
> > > Signed-off-by: H.J. Lu
> > > ---
> > > gcc/ipa-modref.cc | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff
This makes sure to produce interleaving schemes or load-lanes
for single-element interleaving and other permutes that otherwise
would use more than three vectors.
It exposes the latent issue that single-element interleaving with
large gaps can be inefficient - the mitigation in get_group_load_stor
Hi,
testing matrix multiplication benchmarks shows that FMA on a critical chain
is a perofrmance loss over separate multiply and add. While the latency of 4
is lower than multiply + add (3+2) the problem is that all values needs to
be ready before computation starts.
While on znver4 AVX512 code fa
From: Pan Li
This patch would like to support the form 2 of the scalar signed
integer .SAT_ADD. Aka below example:
Form 2:
#define DEF_SAT_S_ADD_FMT_2(T, UT, MIN, MAX) \
T __attribute__((noinline)) \
sat_s_add_##T##_fmt_2 (T x, T y) \
{
Hi Torbjörn,
On 9/3/24 11:30, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Some of the test cases were scanning for "bti", but it would,
incorrectly, match the ".arch_extenssion pacbti".
Also, keep test cases active if a supported Cortex-M core is supplied.
gcc/testsuite/Ch
Hi,
We disable gathers for zen4. It seems that gather has improved a bit compared
to zen4 and Zen5 optimization manual suggests "Avoid GATHER instructions when
the indices are known ahead of time. Vector loads followed by shuffles result
in a higher load bandwidth." however the situation seems to
On Tue, Sep 3, 2024 at 3:07 PM Jan Hubicka wrote:
>
> Hi,
> We disable gathers for zen4. It seems that gather has improved a bit compared
> to zen4 and Zen5 optimization manual suggests "Avoid GATHER instructions when
> the indices are known ahead of time. Vector loads followed by shuffles result
The following disables peeling for gap avoidance with using smaller
vector accesses when using load-lanes.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
* tree-vect-stmts.cc (get_group_load_store_type): Only disable
peeling for gaps by using smaller vect
This makes it easier to discover whether SLP load or store nodes
participate in load/store-lanes accesses.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
* tree-vect-slp.cc (vect_print_slp_tree): Annotate load
and store-lanes nodes.
---
gcc/tree-vect-slp
On 9/2/24 5:27 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to allow the IMM operand of the unsigned
scalar .SAT_ADD. Like the operand 0, the operand 1 of .SAT_ADD
will be zero extended to Xmode before underlying code generation.
The below test suites are passed for this
On 9/1/24 11:52 PM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to add strict check for imm operand of .SAT_SUB
matching. We have no type checking for imm operand in previous, which
may result in unexpected IL to be catched by .SAT_SUB pattern.
We leverage the int_fits_type
Hi, Richard,
I’d like to ping this patch again.
For the convenience, the original 2nd version of the patch is at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657150.html
The diagnostic part has been reviewed by David. Could you please take a look at
the middle end implementation and le
Hi, Jakub,
I’d like to ping this simple patch again. It’s based on your suggestion in
PR116016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c28
Could you please take a look at the patch and let me know whether its okay for
committing to trunk?
thanks.
Qing
> On Aug 12, 2024, at 09:5
Hi,
this patch adds support for new fussion in znver5 documented in the
optimization manual:
The Zen5 microarchitecture adds support to fuse reg-reg MOV Instructions
with certain ALU instructions. The following conditions need to be met for
fusion to happen:
- The MOV should be reg-r
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We don't need to use std::aligned_storage in std::any. We just need a
POD type of the right size. The void* union member already ensures the
alignment will be correct. Avoiding std::aligned_storage means we don't
need to suppress a -Wdeprecated-decla
On Tue, Sep 03, 2024 at 01:59:45PM +, Qing Zhao wrote:
> Hi, Jakub,
>
> I’d like to ping this simple patch again. It’s based on your suggestion in
> PR116016
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c28
>
> Could you please take a look at the patch and let me know whether it
Hi!
The following patch attempts to implement the current wording of
the C23 #embed expansion rules on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661901.html
patch (haven't yet adjusted the rest of the series, but I expect
only minor tweaks).
After parsing #embed it first che
Monday, September 2, 2024 5:00 PM
Richard Sandiford wrote:
> I think we should instead patch the callers that are using
> aarch64_symbol_binds_local_p for GOT decisions. The function itself
> is checking for a more general property (and one that could be useful
> in other contexts).
The patch h
Tested on x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
This prevents the gcc driver erroneously accepting -nostdlib++ when it
should not when Ada was enabled.
Also, similarly, -nostdinc* (where * is nonempty) is unhandled by either
the Ada or D compiler, so the spec should not subs
Monday, September 2, 2024 5:36 PM
Richard Sandiford wrote:
>> In some cases, the alignment can be bigger than BIGGEST_ALIGNMENT.
>> The patch handles these cases.
>>
>> gcc/ChangeLog:
>>
>>* config/aarch64/aarch64-coff.h (ASM_OUTPUT_ALIGNED_LOCAL):
>>Change alignment.
>
> Can you
Tested x86_64-linux. Pushed to trunk.
-- >8 --
LWG 3736 added a partial specialization of this variable template for
two std::move_iterator types. This is needed for the case where the
types satisfy std::sentinel_for and are subtractable, but do not model
the semantics requirements of std::sized_
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The recent change to use auto_win_file_handle for
std::filesystem::hard_link_count caused a regression. The
std::error_code argument should be cleared if no error occurs, but this
no longer happens. Add a call to ec.clear() in fs::hard_link_count to
From: Saurabh Jha
This series is a revised version of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661860.html.
The first patch of the series is updated to address these comments:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661866.html
All comments are addressed exactly as s
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 AdvSIMD faminmax intrinsics. The intrinsics of
this extensio
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 support for famax and famin in terms of
existing R
On Fri, Aug 23, 2024 at 5:50 AM Richard Biener
wrote:
>
> On Fri, Aug 23, 2024 at 2:36 PM H.J. Lu wrote:
> >
> > obj.found is the number of LTO symbols. We should include the offload
> > section when it is used by linker even if there are no LTO symbols.
>
> OK.
>
> > PR lto/116361
> >
Hi,
Zen5 has 6 instead of 4 ALUs and the integer multiplication can now execute in
3 of them. FP units can do 2 additions and 2 multiplications with latency 2
and 3. This patch updates reassociation width accordingly. This has potential
of increasing register pressure but unlike while benchmarki
Hi All,
The meaning of the testcase was changed by passing it -fwrapv. The reason for
the test failures on some platform was because the test was testing some
implementation defined behavior wrt INT_MIN in generic code.
Instead of using -fwrapv this just removes the border case from the test so
Hi All,
The list of available architecture for Arm is incorrectly listing armv9-a twice.
This removes the duplicate armv9-a enumeration from the part of the list having
M-profile targets.
committed under the obvious rule.
Thanks,
Tamar
gcc/ChangeLog:
* doc/invoke.texi: Remove duplicate
This is an improved version of the previous series that was posted at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652680.html
Compared to the previous version, this version delays the gimplification
of iterators until the very end of gimplify_adjust_omp_clauses (instead
of doing it in
This patch factors out the code to calculate the number of iterations
required and to generate the iteration loop into separate functions from
gimplify_omp_depend for reuse later.
I have also replaced the 'TREE_CODE (*tp) == TREE_LIST && ...' checks
used for detecting an iterator clause with a ma
This patch modifies the C and C++ parsers to accept an iterator as a map
type modifier, encoded in the same way as the depend and affinity
clauses. When finishing the clauses, clauses with iterators are treated
separately from ones without to avoid clashes (e.g. iterating over x[i]
will likely gen
This patch extends the previous patch to cover to/from clauses in
'target update'.From c3dfc4a792610530a4ab729c3f250917b828e469 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Mon, 2 Sep 2024 19:34:09 +0100
Subject: [PATCH 3/5] openmp: Add support for iterators in 'target update'
clauses
This patch adds support for iterators in the map clause of OpenMP target
constructs.
The parsing and translation of iterators in the front-end works the same
as for the affinity and depend clauses.
The iterator gimplification needed to be modified slightly to handle
Fortran. The difference i
This patch adds parsing and translation of the 'to' and 'from' clauses
for the 'target update' construct in Fortran.From cfb6b76da5bba038d854d510a4fd44ddf4fa8f1f Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Mon, 2 Sep 2024 19:34:29 +0100
Subject: [PATCH 5/5] openmp, fortran: Add support
On 9/2/24 7:52 AM, Jovan Vukic wrote:
The patch adds a new instruction pattern to handle conditional branches
with equality checks between shifted arithmetic operands. This pattern
optimizes the use of shifted constants (with trailing zeros), making it
more efficient.
For the C code:
void
Hi All,
When vectorizing a conditional operation we rely on the bool_recog pattern to
hit and convert the bool of the operand to a valid mask.
However we are currently not using the converted operand as this is in a pattern
statement. This change updates it to look at the actual statement to be
Hi All,
Currently the vectorizer cheats when lowering COND_EXPR during bool recog.
In the cases where the conditonal is loop invariant or non-boolean it instead
converts the operation back into GENERIC and hides much of the operation from
the analysis part of the vectorizer.
i.e.
a ? b : c
is
Hi All,
This adds vector constant simplification for EQ and NE. This is useful since
the vectorizer generates a lot more vector compares now, in particular NE and EQ
and so these help us optimize cases where the values were not known at GIMPLE
but instead only at RTL.
Bootstrapped Regtested on a
Hi All,
This defines VECTOR_STORE_FLAG_VALUE to CONST1_RTX for AArch64
so we simplify vector comparisons in AArch64.
With this enabled
res:
moviv0.4s, 0
cmeqv0.4s, v0.4s, v0.4s
ret
is simplified to:
res:
mvniv0.4s, 0
ret
NOTE: I don't really
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Fixed by r13-6693.
PR c++/109095
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class66.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/nontype-class66.C | 19 +++
1 file changed, 19 insertions(+)
create mode
This simplifies the heurstic for split path to see if the join
bb is a ifcvt candidate.
For the predecessors bbs need either to be empty or only have one
statement in them which could be a decent ifcvt candidate.
The previous heurstics would miss that:
```
if (a) goto B else goto C;
B: goto C;
C:
Tested on x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
We rely on .CO_YIELD calls being followed by an assignment (optionally)
and then a switch/if in the same basic block. This implies that a
.CO_YIELD can never end a block. However, since a call to .CO_YIELD is
still a call, if
This moves the check for # of statements to copy in join to
be the first check. This check is the cheapest check so it
should be first. Plus add a print to the dump file since there
was none beforehand.
gcc/ChangeLog:
* gimple-ssa-split-paths.cc (is_feasible_trace): Move
check for
This simplifies the heurstic for split path to see if the join
bb is a ifcvt candidate.
For the predecessors bbs need either to be empty or only have one
statement in them which could be a decent ifcvt candidate.
The previous heurstics would miss that:
```
if (a) goto B else goto C;
B: goto C;
C:
> Am 03.09.2024 um 19:00 schrieb Tamar Christina :
>
> Hi All,
>
> The meaning of the testcase was changed by passing it -fwrapv. The reason for
> the test failures on some platform was because the test was testing some
> implementation defined behavior wrt INT_MIN in generic code.
>
> Inst
Richard Biener writes:
> On Wed, Aug 28, 2024 at 11:10 AM Marc wrote:
>>
>> Hello,
>>
>> Gentle reminder for this simple autoconf patch :)
>
> OK.
>
> Note that completely wiping LIBS might remove requirements detected earlier,
> like some systems require explicit -lc for example. I would inste
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
We ICE in nothrow_spec_p because it got a DEFERRED_NOEXCEPT.
This DEFERRED_NOEXCEPT was created in implicitly_declare_fn
when declaring
Foo& operator=(Foo&&) = default;
in the test. The problem is that in resolve_overloa
This is similar to the recent improvements to the Advanced SIMD popcount
expansion by using SVE. We can utilize SVE to generate more efficient code for
scalar mode popcount too.
PR target/113860
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (popcount2): Update pattern to
This patch is a followup to r15-3311-ge31b6176996567 making some
cleanups to pretty-printing to reflect those changes:
- renaming "chunk_info" to "pp_formatted_chunks"
- renaming "cur_chunk_array" to "m_cur_fomatted_chunks"
- rewording/clarifying comments
and taking the opportunity to add a "m_" pr
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-3430-gd0891f3aa75d31.
gcc/ChangeLog:
* pretty-print-format-impl.h (pp_formatted_chunks::get_prev): New
accessor.
* pretty-print.cc (selftest::push_pp_format): New.
(ASSERT_TEXT_TOK
The body of pretty_printer::format is almost 500 lines long,
mostly comprising two distinct phases.
This patch splits it up so that there are explicit subroutines
for the two different phases, reducing the scope of various
locals, and making it easier to e.g. put a breakpoint on phase 2.
No funct
On Sep 2, 2024, at 4:23 PM, Andi Kleen wrote:
>
> Andi Kleen writes:
>
> PING^3
Ok.
>> Andi Kleen writes:
>>
>> PING^2 for https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html
>>
>> This fixes some musttail related test suite failures that cause noise on
>> various targets.
>>
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I don't see any reason why we can't allow the [[]] attribute syntax in C++98
mode with a pedwarn just like many other C++11 features. In fact, we
already do support it in some places in the grammar, but not in places that
check cp_nth_token
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
We crash when dependent_type_p gets a TEMPLATE_TYPE_PARM outside
a template. That happens here because in
template typename X>
void func() {}
template
struct Y {};
void g() { func(); }
when performing overload
On 9/3/24 12:11 PM, Andrew Pinski wrote:
This moves the check for # of statements to copy in join to
be the first check. This check is the cheapest check so it
should be first. Plus add a print to the dump file since there
was none beforehand.
gcc/ChangeLog:
* gimple-ssa-split-paths.
On 9/3/24 12:11 PM, Andrew Pinski wrote:
This simplifies the heurstic for split path to see if the join
bb is a ifcvt candidate.
For the predecessors bbs need either to be empty or only have one
statement in them which could be a decent ifcvt candidate.
The previous heurstics would miss that:
On 9/3/24 12:11 PM, Andrew Pinski wrote:
This simplifies the heurstic for split path to see if the join
bb is a ifcvt candidate.
For the predecessors bbs need either to be empty or only have one
statement in them which could be a decent ifcvt candidate.
The previous heurstics would miss that:
thanks.
Updated per your suggestion and pushed:
https://gcc.gnu.org/pipermail/gcc-cvs/2024-September/408749.html
Qing
> On Sep 3, 2024, at 10:09, Jakub Jelinek wrote:
>
> On Tue, Sep 03, 2024 at 01:59:45PM +, Qing Zhao wrote:
>> Hi, Jakub,
>>
>> I’d like to ping this simple patch again.
On Tue, 20 Aug 2024 23:18:36 PDT (-0700), jia...@iscas.ac.cn wrote:
在 2024/8/21 3:23, Palmer Dabbelt 写道:
On Mon, 19 Aug 2024 21:53:54 PDT (-0700), jia...@iscas.ac.cn wrote:
Supports RISC-V profiles[1] in -march option.
Default input set the profile before other formal extensions.
V2: Fixes s
On Tue, Sep 3, 2024 at 3:01 PM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> I don't see any reason why we can't allow the [[]] attribute syntax in C++98
> mode with a pedwarn just like many other C++11 features. In fact, we
> already do support it in so
While trying to see if there was a way to improve object-size pass
to use the ranger (for pointer plus), I noticed that it leaves around
the statement containing __builtin_object_size if it was reduced to a constant.
This fixes that by using simple_dce_from_worklist.
Bootstrapped and tested on x86
For this testcase, the trunk produces:
```
f_s16:
fmovs31, w0
fmovs0, w1
```
While the testcase was expecting what was produced in GCC 14:
```
f_s16:
sxthw0, w0
sxthw1, w1
fmovd31, x0
fmovd0, x1
```
After r15-1575-gea8061f46a
I don't see there is conflict if we want to support both gnu2024 and
RVI profiles?
also I am not sure what the usage scenarios for the gnu2024 and how we
defined that?
On Wed, Sep 4, 2024 at 6:49 AM Palmer Dabbelt wrote:
>
> On Tue, 20 Aug 2024 23:18:36 PDT (-0700), jia...@iscas.ac.cn wrote:
> >
As is normally the case when it comes to matters of RISC-V
International, Palmer is taking the least-charitable interpretation
and then adding a generous dollop of falsehoods. The RVA23U64 profile
is set to be ratified soon, and that's our intended target for apps
processors.
On Tue, Sep 3, 2024
On 9/3/24 7:00 PM, Andrew Pinski wrote:
On Tue, Sep 3, 2024 at 3:01 PM Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
I don't see any reason why we can't allow the [[]] attribute syntax in C++98
mode with a pedwarn just like many other C++11 features. In fact,
On Tue, 03 Sep 2024 18:05:42 PDT (-0700), Kito Cheng wrote:
I don't see there is conflict if we want to support both gnu2024 and
RVI profiles?
Ya, they'd just be two different things aimed at solving the same set of
problems. I'm just tired of users coming and complaining that stuff is
broke
Hi
This change adds BFmode support to the ix86_preferred_simd_mode function
enhancing SIMD vectorization for BF16 operations. The update ensures
optimized usage of SIMD capabilities improving performance and aligning
vector sizes with processor capabilities.
Bootstrapped and tested on x86-64-pc-l
While trying to understand PR 115910 I found it was useful to print out
the two costs of doing a signed and unsigned division just like was added in
r15-3272-g3c89c41991d8e8 for popcount==1.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* expr.cc (expand_expr_divmod): Add d
1 - 100 of 108 matches
Mail list logo
