Hello world,
a change in the section heading of the documentation broke a link
in gcc-15/changes.html, fixed with this patch.
Best regards
Thomas
Author: Thomas Koenig
Date: Fri Nov 29 07:19:36 2024 +0100
Correct link to unsigned integers for Fortran.
* htdocs/gcc-
On Fri, Nov 29, 2024 at 3:04 AM Joseph Myers wrote:
>
> As reported in bug 100501 (plus duplicates), the gimplifier ICEs for C
> tests involving a statement expression not returning a value as an asm
> input.
>
> The expected diagnostic for this case (as seen for C++ input) is one
> coming from th
Hi GCC reviewers,
The star-mc1 CPU is an Armv8-m Mainline CPU supporting ARM CDE feature.
The attached is the patch to support adding CDE options for -mcpu=star-mc1.
The patch has been built and tested on the GCC upstream with arm-none-eabi.
Is it OK for trunk?
Thanks.
Best Regards,
Arvin Zhong
On Nov 20, 2024, Richard Biener wrote:
> On Sun, Nov 3, 2024 at 11:27 PM Lewis Hyatt wrote:
>> While testing this with --enable-checking=rtl, I came across one place in
>> final.cc that seems to be a (currently) harmless misuse of RTL:
>>
>> set_cur_block_to_this_block:
>> if (! this_block)
>>
When ifcombining contiguous blocks, we can follow forwarder blocks and
reverse conditions to enable combinations, but when there are
intervening blocks, we have to constrain ourselves to paths to the
exit that share the PHI args with all intervening blocks.
Avoiding considering forwarders when i
Hi!
According to my notes, from the
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669367.html
patch ping the following patches are awaiting middle-end patch review
and nothing else:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669774.html
expr, c, gimplify: Don't clear whol
Did bootstrap with gcc-14 (clean cherrypick, minor offsets).
Built and tested on arm64 & x86_64.
It resolved the reported problem.
Thank you for this patch.
On Tue, 26 Nov 2024, 22:37 Marek Polacek, wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> As the manu
On Thu, Nov 28, 2024 at 11:20:31AM +, Jennifer Schmitz wrote:
> The test gcc.dg/tree-ssa/pow_fold_1.c was failing for 32-bit x86 due to
> incompatibility of '-fexcess-precision=16' with '-mfpmath=387'.
> In order to resolve this, this patch adds -msse -mfpmath=sse+387 for i?86-*-*.
>
> We test
On Thu, Nov 28, 2024 at 11:23:02AM +0100, Richard Biener wrote:
> Sorry for chiming in only late - to me this shows that the desire to inline
> a function more than another function, currently identified as
> DECL_DECLARED_INLINE_P overlaps with frontend semantic differences.
> But don't we reflect
This patch support ssdbltrp[1] and smdbltrp[2] extension.
To enable GCC to recognize and process ssdbltrp and smdbltrp extension
correctly at compile time.
[1] https://github.com/riscv/riscv-isa-manual/blob/main/src/ssdbltrp.adoc
[2] https://github.com/riscv/riscv-isa-manual/blob/main/src/smdbltr
Hi Harald and Jerry,
I cannot see why the segfault is occurring of course:
_gfortran_transfer_character_write (&dt_parm.9, &"line 4:"[1]{lb:
1 sz: 1}, 7);
{
struct array01_integer(kind=4) parm.10;
integer(kind=8) D.4841;
struct array01_intege
On Thu, 28 Nov 2024, Jakub Jelinek wrote:
> On Thu, Nov 28, 2024 at 11:23:02AM +0100, Richard Biener wrote:
> > Sorry for chiming in only late - to me this shows that the desire to inline
> > a function more than another function, currently identified as
> > DECL_DECLARED_INLINE_P overlaps with fr
On Thu, Nov 28, 2024 at 01:03:01PM +0100, Richard Biener wrote:
> > I think auto_inline and inline would be just confusing, even in the negative
> > forms. We actually "auto-inline" even functions not declared inline, just
> > with different heuristics.
>
> But inline __attribute__((feeble_inline
Hi!
In check_builtin_function_arguments in the _BitInt patchset I've changed
INTEGER_TYPE tests to INTEGER_TYPE or BITINT_TYPE, but haven't done the
same in fold_builtin_iseqsig, which now ICEs because of that.
The following patch fixes that.
Bootstrapped/regtested on x86_64-linux and i686-linux
On Thu, Nov 28, 2024 at 3:04 AM Hongtao Liu wrote:
>
> On Wed, Nov 27, 2024 at 9:43 PM Richard Biener
> wrote:
> >
> > On Wed, Nov 27, 2024 at 4:26 AM liuhongt wrote:
> > >
> > > When loop requires any kind of versioning which could increase register
> > > pressure too much, and it's in a deeply
Hi!
When one puts incorrect const or pure attributes on declarations of various
C APIs which have corresponding builtins (vs. what they actually do), we can
get tons of ICEs in gimple-fold.cc.
The following patch fixes it by giving up gimple_fold_builtin_* folding
if the functions don't have gimp
On Thu, 28 Nov 2024, Jakub Jelinek wrote:
> Hi!
>
> When one puts incorrect const or pure attributes on declarations of various
> C APIs which have corresponding builtins (vs. what they actually do), we can
> get tons of ICEs in gimple-fold.cc.
>
> The following patch fixes it by giving up gimpl
Just pinging v2 of this patch series
On 14/11/2024 15:53, Akram Ahmad wrote:
Hi all,
This patch series introduces standard names for scalar, Adv. SIMD, and
SVE saturating arithmetic instructions in the aarch64 backend.
Additional tests are added for scalar saturating arithmetic, as well
as to
The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based
on the input value, but also constrained by a VPT block (if present),
or if used within a DLSTP/LETP loop.
Therefore we need to inform the compiler that this intrinsic reads the
FPCXT register, otherwise it could make incorrect
Ping.
> On 15 Nov 2024, at 17:04, Kyrylo Tkachov wrote:
>
> Hi all,
>
> This is a patch submission following-up from the RFC at:
> https://gcc.gnu.org/pipermail/gcc/2024-November/245076.html
> The patch is rebased and retested against current trunk, some debugging code
> removed, comments impro
On Thu, Nov 14, 2024 at 5:03 PM Jakub Jelinek wrote:
>
> Hi!
>
> The inlining heuristics uses DECL_DECLARED_INLINE_P (whether a function
> has been explicitly marked inline; that can be inline keyword, or for C++
> also constexpr keyword or defining a function inside of a class definition)
> heavi
On 11/21/24 09:38, Stefan Schulze Frielinghaus wrote:
Bootstrap and regtest are still running. If those are successful and
there are no further comments I will push this one in the coming days.
-- >8 --
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_emit_compare): Add mode
p
On Thu, 28 Nov 2024, Jakub Jelinek wrote:
> Hi!
>
> In check_builtin_function_arguments in the _BitInt patchset I've changed
> INTEGER_TYPE tests to INTEGER_TYPE or BITINT_TYPE, but haven't done the
> same in fold_builtin_iseqsig, which now ICEs because of that.
>
> The following patch fixes tha
On Tue, Oct 15, 2024 at 7:59 PM Jakub Jelinek wrote:
>
> Hi!
>
> Here is an updated version of the patch.
>
> My reading of C23 is that if some aggregate field is initialized with
> {} (which is supposed to newly clear padding bits) and then its
> subobjects are overridden with designated initiali
This is needed so that __LONG_LONG_SUPPORTED is defined before we depend
on it.
libstdc++-v3/ChangeLog:
PR libstdc++/117210
* config/os/bsd/dragonfly/os_defines.h: Include .
* config/os/bsd/freebsd/os_defines.h: Likewise.
---
Bootstrapped x86_64-freebsd14, pushed to trunk
After the recent c23, GCC complains because the testcase calls f()
with a parameter whereas the prototype has none.
gcc/testsuite/ChangeLog
* gcc.target/arm/mve/dlstp-loop-form.c: Fix f() prototype.
---
gcc/testsuite/gcc.target/arm/mve/dlstp-loop-form.c | 2 +-
1 file changed, 1 i
On Wed, Nov 13, 2024 at 9:57 AM Jakub Jelinek wrote:
>
> On Tue, Nov 12, 2024 at 06:34:39PM +0100, Jakub Jelinek wrote:
> > What do you think about this? So far lightly tested.
>
> Unfortunately bootstrap/regtest revealed some issues in the patch,
> the tree-ssa-ccp.cc changes break bootstrap bec
On Thu, Nov 7, 2024 at 11:25 AM Jakub Jelinek wrote:
>
> On Thu, Nov 07, 2024 at 09:12:34AM +0100, Uros Bizjak wrote:
> > On Thu, Nov 7, 2024 at 9:00 AM Jakub Jelinek wrote:
> > >
> > > On Thu, Nov 07, 2024 at 08:47:34AM +0100, Uros Bizjak wrote:
> > > > Maybe we should always recognize "redzone"
This patch support ssdbltrp[1] and smdbltrp[2] extension.
To enable GCC to recognize and process ssdbltrp and smdbltrp extension
correctly at compile time.
[1] https://github.com/riscv/riscv-isa-manual/blob/main/src/ssdbltrp.adoc
[2] https://github.com/riscv/riscv-isa-manual/blob/main/src/smdbltr
The test gcc.dg/tree-ssa/pow_fold_1.c was failing for 32-bit x86 due to
incompatibility of '-fexcess-precision=16' with '-mfpmath=387'.
In order to resolve this, this patch adds -msse -mfpmath=sse+387 for i?86-*-*.
We tested this by running the test on an x86_64 machine with
--target_board={unix/-
This patch adds optimization of the following patterns:
(zero_extend:M (subreg:N (not:O==M (X:Q==M ->
(xor:M (zero_extend:M (subreg:N (X:M)), mask))
... where the mask is GET_MODE_MASK (N).
For the cases when X:M doesn't have any non-zero bits outside of mode N,
(zero_extend:M (subreg:N
On Wed, Sep 25, 2024 at 5:32 PM Aleksandar Rakic
wrote:
>
> Hi,
>
> I think I managed to fix indentation from the previous version.
>
> When comparing the tables showing the candidates for the group 1 before
> and after applying this patch, it can be observed that complexities for
> the candidates
On Thu, 28 Nov 2024, Jakub Jelinek wrote:
> On Thu, Nov 28, 2024 at 01:03:01PM +0100, Richard Biener wrote:
> > > I think auto_inline and inline would be just confusing, even in the
> > > negative
> > > forms. We actually "auto-inline" even functions not declared inline, just
> > > with differen
Hi Harald,
>
>> I'll wait until tomorrow to see if Paul intervenes. Otherwise I will
>> proceed and push.
>>
>
I succeeded in breaking things even more! Please proceed and push.
Thanks
Paul
Hi!
The PR14311 commit which added support for __sync_* builtins documented that
there is a warning if a particular operation cannot be implemented.
But that commit nor anything later on implemented such warning, it was
always silent generation of the mentioned calls (which can in most cases
resul
On Thu, Nov 28, 2024 at 1:52 PM Jakub Jelinek wrote:
>
> Hi!
>
> The PR14311 commit which added support for __sync_* builtins documented that
> there is a warning if a particular operation cannot be implemented.
> But that commit nor anything later on implemented such warning, it was
> always sile
>
> I think a 4 state flag { never_inline, default, auto_inline, always_inline }
> would be fine. The question is how to call the macro(s) and values
> and how to merge those from different decls and what we do currently
> e.g. for noinline, always_inline, on the same or on different decls
> of t
On Thu, Nov 28, 2024 at 12:22 PM Jennifer Schmitz wrote:
>
> The test gcc.dg/tree-ssa/pow_fold_1.c was failing for 32-bit x86 due to
> incompatibility of '-fexcess-precision=16' with '-mfpmath=387'.
> In order to resolve this, this patch adds -msse -mfpmath=sse+387 for i?86-*-*.
This is already f
Hi!
On 2024-11-26T16:43:07+0100, Jan Hubicka wrote:
> I also noticed that this patch trigger empty-loop.C failure which I
> originaly attributed to different change. I filled PR117764 on that.
> We are no longer able to eliminate empty loops early, but we still
> optimize them late.
> --- a/gc
When constructing an iterator with a subset of the original, the
original BLOCK_SUBBLOCKS is moved to the first new iterator. Otherwise
this part of the patchset is unchanged.From f40b72c1e750ec948ebf3ffd92da107679d0b702 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Wed, 27 Nov 2024 21:
The target update clause decls and sizes are now Gimplified in
gimplify_scan_omp_clauses. The rest of the patch is mostly unchanged.From 79159cbf815d458114e7c6da8dbb138ce24b7df1 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Wed, 27 Nov 2024 21:51:34 +
Subject: [PATCH 3/5] openmp: Add
A new field has been added to gomp_target to store the gimple_seq for
the iterator loops. This means that gomp_target now needs a separate GSS
code. Accessor functions have been added for this field, and the build
function has been added.
When building the iterator loops for a clause, an artif
This part of the patch is unchanged.From e761481eb3d9b322267b3a22773caa0f0270275f Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Wed, 27 Nov 2024 21:56:08 +
Subject: [PATCH 5/5] openmp, fortran: Add support for iterators in OpenMP
'target update' constructs (Fortran)
This adds Fortr
This is a revised version of the patch series posted at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664541.html
The previous version performed the expansion of the iterators into loops
at the omp-lowering stage, but that meant that the Gimplification of the
clauses with iterators w
This patch version has the omp_ prefixes added to the new functions for
building iterator loops and computing the iterator count.
Also, they now take the iterator vector directly rather than the clause
containing it. This is because depend clauses store the iterator in
TREE_PURPOSE (TREE_DECL
On Thu, Nov 28, 2024 at 4:57 PM Richard Biener
wrote:
>
> On Thu, Nov 28, 2024 at 3:04 AM Hongtao Liu wrote:
> >
> > On Wed, Nov 27, 2024 at 9:43 PM Richard Biener
> > wrote:
> > >
> > > On Wed, Nov 27, 2024 at 4:26 AM liuhongt wrote:
> > > >
> > > > When loop requires any kind of versioning wh
On Thu, 28 Nov 2024, Martin Uecker wrote:
> Bit-fields need additional checks for type compatiblity.
>
>
> Bootstrapped and regression tested on x86_64.
>
>
>
> c: correct type compatibility for bit-fields [PR117828]
>
> Add missing test for consistency of bit-fields when compari
As reported in bug 100501 (plus duplicates), the gimplifier ICEs for C
tests involving a statement expression not returning a value as an asm
input.
The expected diagnostic for this case (as seen for C++ input) is one
coming from the gimplifier and so it seems reasonable to fix the
gimplifier to h
On Wed, Nov 20, 2024 at 08:02:34PM +0800, Cui, Lili wrote:
> PR target/116675
> * gcc.target/i386/pr116675.c: New test.
The test uses dg-do run and scan-assembler* at the same time,
that obviously doesn't work when pr116675.s isn't created at all,
so one gets
PASS: gcc.target/i386/pr11
So these are updated versions of the first two of Mariam's patches for
CRC optimization. They introduce the basic building blocks that are
used by subsequent patches as well as CRC builtin support.
The biggest conceptual change from Mariam's patch is to drop the
assumption that we're going to
We have a number of comments which are duplicated for C++98 and C++11
overloads, where the signatures are slightly different. Instead of
duplicating the comments that are 90% identical, just use a single
comment that can apply to both. In some cases this means saying "an
iterator" instead of "A con
libstdc++-v3/ChangeLog:
PR libstdc++/117822
* include/std/stacktrace (stacktrace(stacktrace&&, const A&)):
Fix typo in qualified-id for is_always_equal trait.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Test
allocator-extended constructors and alloc
On Thu, 7 Nov 2024, Tamar Christina wrote:
> Hi All,
>
> When the patch for PR114074 was applied we saw a good boost in exchange2.
>
> This boost was partially caused by a simplification of the addressing modes.
> With the patch applied IV opts saw the following form for the base addressing;
>
Hi!
On 2024-11-15T23:46:47+, Joseph Myers wrote:
> Change the default language version for C compilation from -std=gnu17
> to -std=gnu23.
Wow, that came quickly.
> A few tests are updated to remove local definitions of
> bool, true and false (where making such an unconditional test change
On Thu, Nov 28, 2024 at 11:27:32AM +, Dimitri John Ledkov wrote:
> Did bootstrap with gcc-14 (clean cherrypick, minor offsets).
> Built and tested on arm64 & x86_64.
> It resolved the reported problem.
> Thank you for this patch.
Thanks a lot for testing it!
> On Tue, 26 Nov 2024, 22:37 Mar
On 11/27/24 9:06 PM, Marek Polacek wrote:
Not a bugfix, but this should only affect C++26.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8--
This patch implements P2865R5 by promoting the warning to error in C++26
only. -Wno-array-compare shouldn't disable the error, so adju
Hi Andre,
On Thu, 28 Nov 2024 at 17:37, Andre Vieira
wrote:
>
> Hi,
>
> This rejects any loops where any predicated instruction comes before the vctp
> that generates the loop predicate. Even though this is not a requirement for
> dlstp transformation we have found potential issues where you can
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Forgot to do this in my original patch.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_pack_indexing=202311L for C++26.
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/feat-cxx26.
On 21/11/2024 15:41, Richard Sandiford wrote:
Claudio Bantaloukas writes:
This patch adds support for the following intrinsics:
- svdot[_f32_mf8]_fpm
- svdot_lane[_f32_mf8]_fpm
- svdot[_f16_mf8]_fpm
- svdot_lane[_f16_mf8]_fpm
The first two are available under a combination of the FP8DOT4 and
This is another place where we can use 'if constexpr' to replace
dispatching to a specialized class template, improving compile times and
avoiding a function call.
libstdc++-v3/ChangeLog:
* include/bits/stl_construct.h (_Destroy(FwdIter, FwdIter)): Use
'if constexpr' instead of di
There are three important parts missing.
I don't see you in MAINTAINERS file, so you need to decide if you assign
copyright to FSF or submit this under DCO.
I wonder if it is ok to add myself to MAINTAINERS file?
Seehttps://gcc.gnu.org/contribute.html#legal for more details (if you
already have
On 11/27/24 9:05 PM, Marek Polacek wrote:
On Wed, Nov 27, 2024 at 04:19:33PM -0500, Jason Merrill wrote:
On 11/6/24 3:33 PM, Marek Polacek wrote:
On Mon, Nov 04, 2024 at 11:10:05PM -0500, Jason Merrill wrote:
On 10/30/24 4:59 PM, Marek Polacek wrote:
On Wed, Oct 30, 2024 at 09:01:36AM -0400,
Hi Christophe,
On 28/11/2024 10:22, Christophe Lyon wrote:
The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based
on the input value, but also constrained by a VPT block (if present),
or if used within a DLSTP/LETP loop.
Therefore we need to inform the compiler that this intrinsi
Hi,
This rejects any loops where any predicated instruction comes before the vctp
that generates the loop predicate. Even though this is not a requirement for
dlstp transformation we have found potential issues where you can end up with a
wrong transformation, so it is safer to reject such loops.
Merge ashl and compound define_insn_and_split
patterns to form macroized pattern.
No functional changes.
gcc/ChangeLog:
* config/i386/i386.md (*3_mask): Macroize
pattern from *ashl3_mask and *3_mask
using any_shift code iterator.
(*3_mask_1): Macroize pattern
from *ashl3_ma
"Robin Dapp" writes:
>> Could you walk me through the failure in more detail? It sounds
>> like can_duplicate_and_interleave_p eventually gets to the point of
>> subdividing the original elements, instead of either combining consecutive
>> elements (the best case), or leaving them as-is (the expe
在 2024/11/28 19:24, Dongyan Chen 写道:
This patch support ssdbltrp[1] and smdbltrp[2] extension.
To enable GCC to recognize and process ssdbltrp and smdbltrp extension
correctly at compile time.
[1] https://github.com/riscv/riscv-isa-manual/blob/main/src/ssdbltrp.adoc
[2] https://github.com/ris
This patch enables ACLE macro __ARM_FEATURE_SVE_VECTOR_OPERATORS to indicate
that C/C++ language operations are available natively on SVE ACLE types.
gcc/ChangeLog:
* config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins): Define
__ARM_FEATURE_SVE_VECTOR_OPERATORS.
---
gcc/con
Hi,
This is v3 of the series
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669255.html
based on review comments. Changes in this version include:
1. Better way of handling poly-sized vector checking in gimple-fold.cc
2. Changelog fix.
Thanks all for the reviews. Based on Richard's c
This patch adds a check for non-GNU vectors to warn that the index is outside
the range of a fixed vector size. For VLA vectors, we don't diagnose.
gcc/ChangeLog:
* c-family/c-common.cc (convert_vector_to_array_for_subscript): Add
range-check for target vector types.
---
gcc/c-f
This patch adds a change to handle VLA's poly indices.
gcc/ChangeLog:
* cp/decl.cc (reshape_init_array_1): Handle poly indices.
gcc/testsuite/ChangeLog:
* g++.dg/ext/sve-sizeless-1.C: Update test to test initialize error.
* g++.dg/ext/sve-sizeless-2.C: Likewise.
---
gcc
This patch adds a test case to cover C/C++ operators on SVE ACLE types. This
does not cover all types, but covers most representative types.
gcc/testsuite:
* gcc.target/aarch64/sve/acle/general/cops.c: New test.
---
.../aarch64/sve/acle/general/cops.c | 579 ++
This patch changes the TYPE_INDIVISBLE flag to 0 to enable SVE ACLE types to be
treated as GNU vectors and have the same semantics with operations that are
defined on GNU vectors.
gcc/ChangeLog:
* config/aarch64/aarch64-sve-builtins.cc (register_builtin_types): Flip
TYPE_INDIVISBL
Handle variable-sized vectors for BIT_FIELD_REF canonicalization.
gcc/ChangeLog:
* gimple-fold.cc (maybe_canonicalize_mem_ref_addr): Handle variable
sized vector types in BIT_FIELD_REF canonicalization.
* tree-cfg.cc (verify_types_in_gimple_reference): Change object-size-
From: Pan Li
Like the strided load/store, the testcases of vector widen are
designed to pick up different sorts of optimization options but actually
these option are ignored according to the Execution log of gcc.log.
This patch would like to make it correct almost the same as what we fixed for
st
From: Pan Li
Like the strided load/store, the testcases of vector widen are
designed to pick up different sorts of optimization options but actually
these option are ignored according to the Execution log of gcc.log.
This patch would like to make it correct almost the same as what we fixed for
st
This patch adds support for checking bounds of SVE ACLE vector initialization
constructors. It also adds support to construct vector constant from init
constructors.
gcc/ChangeLog:
* c-typeck.cc (process_init_element): Add check to restrict
constructor length to the minimum vecto
From: Pan Li
This patch would like to fix the testcases failures of strided
load/store after sorts of optimization option passing to testcase.
* Add no strict align for vector option.
* Adjust dg-final by any-opts and/or no-opts if the rtl dump changes
on different optimization options (like O
On Wed, 27 Nov 2024, Tamar Christina wrote:
> Hi All,
>
> The testcase
>
> #include
> #include
>
> #define N 8
> #define L 8
>
> void f(const uint8_t * restrict seq1,
>const uint8_t *idx, uint8_t *seq_out) {
> for (int i = 0; i < L; ++i) {
> uint8_t h = idx[i];
> memcpy((vo
Hi Tobias!
On 2024-11-14T18:18:57+0100, Tobias Burnus wrote:
> maybe doing parallel work doesn't work well.
>From my own experience: no, doesn't. ;-)
> --- a/htdocs/projects/gomp/index.html
> +++ b/htdocs/projects/gomp/index.html
> omp_target_memset and
> - omp_target_memset_rect_a
This is deprecated in the C++20 standard and will be removed at some
point.
libstdc++-v3/ChangeLog:
* include/bits/stl_relops.h (rel_ops): Add deprecated attribute.
* testsuite/20_util/headers/utility/using_namespace_std_rel_ops.cc:
Add dg-warning for -Wdeprecated warnings
Thanks for using maskload/store_optab and sorry for the very slow review.
Been a bit swamped lately...
The patch seems to be using maskload and maskstore as though they were
variants of movMMcc, with the comparison being part of the load/store.
Instead, the current interface is that:
maskload
Register StdIntegralConstantPrinter with the other C++11 printers, and
register StdTextEncodingPrinter after C++20 printers.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py: Reorder registrations.
---
No behaviour change.
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/py
On Wed, Nov 27, 2024 at 1:39 PM Vladimir Makarov wrote:
>
>
> On 11/27/24 04:05, Uros Bizjak wrote:
> > Hello!
> >
> > I'd like to backport two LRA patches to gcc-14 branch:
> >
> > 1. [PR114942][LRA]: Don't reuse input reload reg of inout early clobber
> > operand
> > https://gcc.gnu.org/git/git
On Thu, 28 Nov 2024 at 15:13, Andre Vieira (lists)
wrote:
>
> Hi Christophe,
>
> On 28/11/2024 10:22, Christophe Lyon wrote:
> > The VCTP instruction creates a Vector Tail Predicate in VPR.P0, based
> > on the input value, but also constrained by a VPT block (if present),
> > or if used within a D
Hi,
On Fri, Nov 15 2024, Martin Jambor wrote:
> Hi,
>
> On Thu, Nov 07 2024, Aldy Hernandez wrote:
>> Jan Hubicka writes:
>>
> 2024-11-01 Martin Jambor
>
> * ipa-prop.cc (ipa_compute_jump_functions_for_edge): When
> creating
> value-range jump function
On Thu, Nov 28, 2024 at 12:19:00PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> Forgot to do this in my original patch.
>
> gcc/c-family/ChangeLog:
>
> * c-cppbuiltin.cc (c_cpp_builtins): Predefine
> __cpp_pack_indexing=202
On Mon, Nov 25, 2024 at 07:55:46PM -0500, Andrew MacLeod wrote:
> From 97bea858ff782dc5c80490bb48cbd3241ad3413c Mon Sep 17 00:00:00 2001
> From: Andrew MacLeod
> Date: Mon, 25 Nov 2024 09:50:33 -0500
> Subject: [PATCH 1/3] Do not calculate an entry range for invariant names.
>
> If an SSA_NAME is
On Mon, Nov 25, 2024 at 07:56:09PM -0500, Andrew MacLeod wrote:
> From 9434efb95a481ea57db8d47919d05cbe17b8bcba Mon Sep 17 00:00:00 2001
> From: Andrew MacLeod
> Date: Sat, 23 Nov 2024 14:05:54 -0500
> Subject: [PATCH 3/3] Only add inferred ranges if they change the value.
>
> Do not add an infer
On Mon, Nov 25, 2024 at 07:56:00PM -0500, Andrew MacLeod wrote:
> From 0aee6d112bf4dd9accd7aaa8b48a520a878dedf9 Mon Sep 17 00:00:00 2001
> From: Andrew MacLeod
> Date: Sat, 16 Nov 2024 08:29:30 -0500
> Subject: [PATCH 2/3] Add a range query to inferred ranges.
>
> Provide a range_query for any in
As suggested by Jason, this makes all __normal_iterator operators into
friends so they can be found by ADL and don't need to be separately
exported in module std.
For the operator<=> comparing two iterators of the same type, I had to
use a deduced return type and add a requires-clause, because it'
Hi,
I need some feedback/discussion on GCC/Binutils command line options
around MTE
tagged stack usage. See "Proposed GCC/Binutils implementation for the user
space ABI for MTE stack" below in the email for the high-level design.
Thanks
Indu
-
MTE Background
--
Memory Ta
The standard says that it's undefined to swap two containers if the
allocators are not equal and do not propagate. This ensures that swap is
always O(1) and non-throwing, but has other undesirable consequences
such as LWG 2152. The 2016 paper P0178 ("Allocators and swap") proposed
making the non-me
On 21/11/2024 14:33, Richard Sandiford wrote:
Claudio Bantaloukas writes:
[...]
@@ -4004,6 +4008,44 @@ SHAPE (ternary_bfloat_lane)
typedef ternary_bfloat_lane_base<2> ternary_bfloat_lanex2_def;
SHAPE (ternary_bfloat_lanex2)
+/* sv_t svfoo[_t0](sv_t, svmfloat8_t, svmfloat8_t, uint64_t)
This benefits from the optimizations in std::_Destroy which avoid doing
any work when using std::allocator.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::_M_impl::_M_resize):
Use std::_Destroy to destroy removed elements.
---
Tested x86_64-linux. Pushed to t
This patch adds support for the following intrinsics:
- svmlalb[_f16_mf8]_fpm
- svmlalb[_n_f16_mf8]_fpm
- svmlalt[_f16_mf8]_fpm
- svmlalt[_n_f16_mf8]_fpm
- svmlalb_lane[_f16_mf8]_fpm
- svmlalt_lane[_f16_mf8]_fpm
- svmlallbb[_f32_mf8]_fpm
- svmlallbb[_n_f32_mf8]_fpm
- svmlallbt[_f32_mf8]_fpm
- svml
This patch adds the following intrinsics:
- svcvt1_bf16[_mf8]_fpm
- svcvt1_f16[_mf8]_fpm
- svcvt2_bf16[_mf8]_fpm
- svcvt2_f16[_mf8]_fpm
- svcvtlt1_bf16[_mf8]_fpm
- svcvtlt1_f16[_mf8]_fpm
- svcvtlt2_bf16[_mf8]_fpm
- svcvtlt2_f16[_mf8]_fpm
- svcvtn_mf8[_f16_x2]_fpm (unpredicated)
- svcvtnb_mf8[_f32_
The ACLE defines a new set of fp8 vector types and intrinsics that operate on
these, some of them operating on the vectors as if they were bags of bits and
some requiring an additional argument of type fpm_t.
The following patches introduce:
- the types
- intrinsics that operate without the fpm_
Hi Paul,
Am 28.11.24 um 13:55 schrieb Paul Richard Thomas:
Hi Harald,
I'll wait until tomorrow to see if Paul intervenes. Otherwise I will
proceed and push.
I succeeded in breaking things even more! Please proceed and push.
I'm sort of glad you failed, too! ;-)
Pushed as r15-5766 .
This patch adds support for the following intrinsics:
- svdot[_f32_mf8]_fpm
- svdot_lane[_f32_mf8]_fpm
- svdot[_f16_mf8]_fpm
- svdot_lane[_f16_mf8]_fpm
The first two are available under a combination of the FP8DOT4 and SVE2
features.
Alternatively under the SSVE_FP8DOT4 feature under streaming m
1 - 100 of 102 matches
Mail list logo
