Because the _M_format(__rg, __fc) were placed outside of if constexpr,
these method and it's childs where instantiated, even if _M_format
could be used.
To simplify the if constexpr chain, we introduce a __simply_formattable_range
(name based on simple-view) exposition only concept, that checks if
> Am 16.04.2025 um 23:37 schrieb Tamar Christina :
>
> Hi All,
>
> The following testcase shows an incorrect masked codegen:
>
> #define N 512
> #define START 1
> #define END 505
>
> int x[N] __attribute__((aligned(32)));
>
> int __attribute__((noipa))
> foo (void)
> {
> int z = 0;
> for
On Wed, Mar 12, 2025 at 1:00 PM Jonathan Wakely wrote:
> On Tue, 11 Mar 2025 at 12:22, Tomasz Kamiński wrote:
> >
> > Floating points types _Float16, _Float32, _Float64, and bfloat16,
> > can be formatted only if std::to_chars overloads for such types
> > where provided. Currently this is only th
On Fri, Mar 28, 2025 at 9:33 PM Jonathan Wakely wrote:
> On 28/03/25 16:31 +0100, Tomasz Kamiński wrote:
> >The formatters for chrono types defined the parse/format methods
> >as accepting unconstrained types, this in combination with lack
> >of constrain on _CharT lead to them falsy statisfying
From: Jeremy Bettis
This patch addresses an issue in the C preprocessor where incorrect
line number information is generated when processing files with a
large number of lines. The problem arises from improper handling
of location intervals in the line map, particularly when locations
exceed LINE
> From: Richard Sandiford
> Date: Tue, 15 Apr 2025 09:23:21 +0100
> > Ok to commit?
>
> OK, thanks.
Thanks!
Though, I noticed another "cheaper" in the function header.
Fixing that one was a more obvious correction (thus
committed as such), as per the commit message: what the
function determine
gcc/ChangeLog
PR c/88382
* doc/extend.texi (Syntax Extensions): Adjust menu.
(Raw String Literals): New section.
---
gcc/doc/extend.texi | 20
1 file changed, 20 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 5bc2785f802..09
On Wed, Apr 16, 2025 at 08:52:17PM +0200, Jakub Jelinek wrote:
> The following testcase ICEs since r15-1579 (addition of late combiner),
> because *clrmem_short can't be split.
> The problem is that the define_insn uses
>(use (match_operand 1 "nonmemory_operand" "n,a,a,a"))
>(use (match_ope
On 4/11/25 1:08 PM, Alexandre Oliva wrote:
>
> gcc.target/powerpc/power11-3.c uses target_clones, that depends on
> ifunc. Require ifunc support.
This looks "obvious" to me.
The only systems we (IBM) have access to build and test on all have ifunc
support, so we clearly didn't hit this ourselve
On 4/16/25 12:27 AM, Alexandre Oliva wrote:
> Since that sort of broad change will presumably not make gcc-15 (it
> wouldn't fix a regression, not even the problem addressed by the
> upthread patch),
Yes, the patch to change powerpc64 -> powerpc64_hw is definitely a
gcc-16 patch.
> ...may I un
On 4/16/25 16:55, Andrew MacLeod wrote:
I started at a 0.2% overall compilation increase (1.8% in VRP). In the
end, this patch is down to 0.6% in VRP, and only 0.08% overall, so
manageable for all the extra work.
Final version performance run...
VRP slowed down by 0.28%
Threading sped u
Include the term used in the standard to ease further research for users,
and while at it, rephrase the description of the rule entirely using
Alexander Monakov's suggestion: it was previously wrong (and imprecise) as
"the same address" may well be re-used later on, and the issue is the
access via
Jakub Jelinek writes:
> On Wed, Mar 26, 2025 at 10:41:52AM +, Sam James wrote:
>> Include the term used in the standard to ease further research for users.
>>
>> gcc/ChangeLog:
>>
>> * doc/invoke.texi: Use "compatible types" term.
>> ---
>> gcc/doc/invoke.texi | 8
>> 1 file
On 4/16/25 17:28, Sam James wrote:
Andrew MacLeod writes:
* gcc.dg/tree-ssa/phi-opt-value-5.c : WIth the expanded ranges, CCP2
pass use to export:
Global Exported: d_3 = [irange] int [-INF, +INF] MASK 0xfffe
VALUE 0x1
and now
Global Exported: d_3 = [irange] int [-INF, -1][1, +
On 4/15/25 11:44 PM, Alexandre Oliva wrote:
> On Apr 15, 2025, Peter Bergner wrote:
>> I have verified the modified test case ICEs with the exact same
>> error as the original test case using the commit immediately
>> before the commit the fixed the ICE.
>
> Awesome, thanks! I hereby withdraw th
After the conversion for phiopt's conditional operand
to use maybe_push_res_to_seq, it was found that gimple_extract
will extract out from REALPART_EXPR/IMAGPART_EXPR/VCE and BIT_FIELD_REF,
a memory load. But that extraction was not needed as memory loads are not
simplified in match and simplify. S
ABSU_EXPR lowering incorrectly used the resulting type
for the new expression but in the case of ABSU the resulting
type is an unsigned type and with ABSU is folded away. The fix
is to use a signed type for the expression instead.
Bootstrapped and tested on x86_64-linux-gnu.
PR middle-end
Andrew MacLeod writes:
> This was a fun one! An actual bug, and it took a while to sort out.
> After chasing down some red herrings, this turns out to be an issue of
> interaction between the range and value masks and intervening
> calculations.
(Just want to say thanks for the detailed commi
This includes all of the regression fixes that were backported yesterday to GCC
14
and 13 that are also regressions in GCC 12.
Andrew Pinski (6):
phiopt: Reset the number of iterations information of a loop when
changing an exit from the loop [PR117243]
backprop: Fix deleting of a phi nod
This testcase was fixed by r15-3052-gc7b76a076cb2c6ded but is
a testcase that failed in a different fashion and a much older
failure than the one added with r15-3052.
Pushed as obvious after a quick test.
PR tree-optimization/118476
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr11
After r12-5300-gf98f373dd822b3, value_replacement would be able to look at the
following cfg structure:
```
[local count: 1014686024]:
if (h_6 != 0)
goto ; [94.50%]
else
goto ; [5.50%]
[local count: 114863530]:
# h_6 = PHI <0(4), 1(5)>
[local count: 1073741824]:
# f_8 = P
The problem here is remove_unused_var is called on a name that is
defined by a phi node but it deletes it like removing a normal statement.
remove_phi_node should be called rather than gsi_remove for phinodes.
Note there is a possibility of using simple_dce_from_worklist instead
but that is for an
After r12-5300-gf98f373dd822b3, phiopt could get the following bb structure:
|
middle-bb -|
||
| || |
phi<1, 2> | |
cond | |
|| |
|+---|
Which was considered 2 loops. The inner loop had esimtate of upper
This was a fun one! An actual bug, and it took a while to sort out.
After chasing down some red herrings, this turns out to be an issue of
interaction between the range and value masks and intervening calculations.
The original patch from 11/2023 adjusts intersection so that it can
enhance
Here is the proposal on the Clang Discourse:
https://discourse.llvm.org/t/rfc-bounds-safety-in-c-syntax-compatibility-with-gcc/85885
-bw
On Wed, 16 Apr 2025 at 20:57, François Dumont wrote:
>
> libstdc++: Add _GLIBCXX_DEBUG checks on unordered container
> local_iterator
>
> Some _GLIBCXX_DEBUG checks in include/debug/safe_local_iterator.h
> were not properly
> tested.
>
> Fix several tests not testing the contai
On 4/13/25 10:50 PM, Keith Packard wrote:
pattern using rx_cmpstrn is cmpstrsi for which len is a constant -1,
so we'll be moving the setpsw instructions from rx_cmpstrn to
cmpstrnsi as follows:
1. Adjust the predicate on the length operand from "register_operand"
to "nonmemory_operand
libstdc++: Add _GLIBCXX_DEBUG checks on unordered container
local_iterator
Some _GLIBCXX_DEBUG checks in include/debug/safe_local_iterator.h
were not properly
tested.
Fix several tests not testing the container corresponding to their
location in the
testsuite location.
On Wed, Apr 16, 2025 at 01:49:50PM -0500, Robert Dubner wrote:
> I am not well-versed in license and legal issues. But I see that except
> for the GO language, gcc/cobol is almost unique in that there is a LICENSE
> file.
>
> This patch gets rid of it.
>
> Okay for trunk?
>
>
> Subject: [PATCH
These tests were backported from gcc-14 where the testsuite
automatically adds -std=gnu++20 as needed. That doesn't happen on the
older release branches, so an explicit dg-options directive is needed to
ensure the tests are run by default. Otherwise they'll only be run when
somebody uses a custom -
Hi!
Aaron mentioned in the PR that late in C23 N3124 was adopted and
$@` are now part of basic character set. The paper has been implemented
in GCC from what I can see, but we should allow for GNU23/2Y $@` in
raw string delimiters as well, like they are allowed for C++26, because
the delimiters c
On Tue, Apr 15, 2025 at 12:19 PM Uros Bizjak wrote:
>
> On Tue, Apr 15, 2025 at 2:23 PM H.J. Lu wrote:
> >
> > On Tue, Apr 15, 2025 at 12:45 AM Uros Bizjak wrote:
> > >
> > > On Tue, Apr 15, 2025 at 1:06 AM H.J. Lu wrote:
> > > >
> > > > ix86_add_cfa_restore_note omits the REG_CFA_RESTORE REG n
Hi!
The following testcase ICEs since r15-1579 (addition of late combiner),
because *clrmem_short can't be split.
The problem is that the define_insn uses
(use (match_operand 1 "nonmemory_operand" "n,a,a,a"))
(use (match_operand 2 "immediate_operand" "X,R,X,X"))
(clobber (match_scratch:P
On Tue, Apr 15, 2025 at 2:19 PM Ard Biesheuvel wrote:
>
> On Tue, 15 Apr 2025 at 09:48, Uros Bizjak wrote:
> >
> > On Thu, Apr 10, 2025 at 2:27 PM Ard Biesheuvel wrote:
> > >
> > > From: Ard Biesheuvel
> > >
> > > Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
> > > __fen
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here when merging the two decls, remove_contract_attributes loses
ATTR_IS_DEPENDENT on the format attribute, so apply_late_template_attributes
just returns, so the attribute doesn't get propagated to the type where the
warning looks for it.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Since r12-5426 apply_late_template_attributes suppresses various global
state to avoid applying active pragmas to earlier declarations; we also
need to override target_option_current_node.
PR c++/114772
PR c++/101180
gcc/cp
On 4/14/25 10:24 PM, Alexandre Oliva wrote:
And here's another that came up more recently:
The gcc-14 backport that split the pr114194 testcase for rv32 and rv64
would only generate the expected rv32 sequence if commit
6b315907c0353f71169a7555e653d29a981fef67 had also been backported, but
it
I am not well-versed in license and legal issues. But I see that except
for the GO language, gcc/cobol is almost unique in that there is a LICENSE
file.
This patch gets rid of it.
Okay for trunk?
Subject: [PATCH] cobol: Eliminate gcc/cobol/LICENSE. [PR119759]
gcc/cobol
PR cobol/11975
On 4/14/25 10:22 PM, Alexandre Oliva wrote:
On Apr 14, 2025, Jeff Law wrote:
No strong opinion. I'd lean towards xfail or twiddling the test since
that's obviously super-save WRT codegen on the gcc-14 release branch.
Twiddling it is, then (pending approval ;-)
The pr118182-2.c testcase
-Q does something completely different in conjunction with --help than it
does otherwise; its main entry in the manual didn't mention that, nor did
-Q have an entry in the index for the --help usage.
gcc/ChangeLog
PR driver/90465
* doc/invoke.texi (Overall Options): Add a @cindex f
> Am 16.04.2025 um 15:24 schrieb Eric Botcazou :
>
> Hi,
>
> this is a regression introduced on the mainline and 14 branch by:
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-October/391658.html
>
> The change bypasses int_fits_type_p (essentially) to work around the
> signedness constraints,
On Wed, Apr 16, 2025 at 6:25 AM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression introduced on the mainline and 14 branch by:
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-October/391658.html
>
> The change bypasses int_fits_type_p (essentially) to work around the
> signedness constraints, b
On Wed, 16 Apr 2025 at 16:14, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Wed, 16 Apr 2025 14:41:17 +0200
>
> > ping?
>
> Since you directed it at me and CC:ed the list; in case that
> was deliberate: I can only repeat "still ok", but I don't
> have approval rights to the test
Hi!
On 2025-04-15T00:22:26+0200, I wrote:
> --- a/libgomp/testsuite/libgomp.c++/target-exceptions-pr118794-1.C
> +++ b/libgomp/testsuite/libgomp.c++/target-exceptions-pr118794-1.C
> +/* Help nvptx offloading overcome a code generation issue;
> + PR106445, PR118518. */
> +#define ALWAYS_INLINE
>>
>> Thanks, will file bugs and fix them first.
>
> I filed two bugs against GCC15:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717
>
> And assigned to myself.
Both the above were resolved.
Qing
From: Pan Li
After we add the frm register to the global_regs, we may not need to
define_insn that volatile to emit the frm restore insns. The
cooperatively-managed global register will help to handle this, instead
of emit the volatile define_insn explicitly.
gcc/ChangeLog:
* config/ri
Hi, Sid:
> On Apr 10, 2025, at 06:56, Siddhesh Poyarekar wrote:
>
>
>> Maybe you could add it when a pointer to an annotated
>> struct is passed as parameter, but also there it is not
>> clear to me that we might want to materialize new
>> accesses to the struct at this point.
>> An alternative
Hi Jeff, Robin,
Thanks for your comments.
On 30/03/2025 01:30, Jeff Law wrote:
On 3/27/25 1:39 PM, Robin Dapp wrote:
Hi Paul-Antoine,
This pattern enables the combine pass to merge a vec_duplicate into a
plus-mult
or minus-mult RTL instruction.
Before this patch, we have two instructions,
PR target/106445
libgomp/
* testsuite/libgomp.c++/pr106445-1.C: New.
* testsuite/libgomp.c++/pr106445-1-O0.C: Likewise.
---
libgomp/testsuite/libgomp.c++/pr106445-1-O0.C | 3 +++
libgomp/testsuite/libgomp.c++/pr106445-1.C| 18 ++
2 files changed
On Wed, 16 Apr 2025 at 15:17, Tomasz Kaminski wrote:
>
>
>
> On Wed, Apr 16, 2025 at 3:47 PM Tomasz Kamiński wrote:
>>
>> Because the _M_format(__rg, __fc) were placed outside of if constexpr,
>> these method and it's childs where instantiated, even if _M_format> _Range>
>> could be used. Now we
Hi!
On 2025-03-25T11:51:26+0100, Tom de Vries wrote:
> On 3/25/25 11:18, Thomas Schwinge wrote:
>> On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
>> wrote:
>>> Starting with ptx isa version 6.3, a ptx directive .alias is available.
>>
>> Regarding the following item specifically:
>>
On Wed, 16 Apr 2025 at 15:22, Jonathan Wakely wrote:
>
> On Wed, 16 Apr 2025 at 12:59, Tomasz Kaminski wrote:
> >
> >
> >
> > On Wed, Apr 16, 2025 at 1:32 PM Jonathan Wakely wrote:
> >>
> >> On Wed, 16 Apr 2025 at 12:18, Jonathan Wakely wrote:
> >> >
> >> > This fixes:
> >> > FAIL: 17_intro/hea
On Wed, 16 Apr 2025 at 12:59, Tomasz Kaminski wrote:
>
>
>
> On Wed, Apr 16, 2025 at 1:32 PM Jonathan Wakely wrote:
>>
>> On Wed, 16 Apr 2025 at 12:18, Jonathan Wakely wrote:
>> >
>> > This fixes:
>> > FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++23 (test for
>> > excess errors)
On Wed, Apr 16, 2025 at 3:47 PM Tomasz Kamiński wrote:
> Because the _M_format(__rg, __fc) were placed outside of if constexpr,
> these method and it's childs where instantiated, even if _M_format _Range>
> could be used. Now we put the calls in else branch of if constexpr.
>
> libstdc++-v3/Chang
> From: Christophe Lyon
> Date: Wed, 16 Apr 2025 14:41:17 +0200
> ping?
Since you directed it at me and CC:ed the list; in case that
was deliberate: I can only repeat "still ok", but I don't
have approval rights to the testsuite parts.
>
> On Thu, 10 Apr 2025 at 15:48, Hans-Peter Nilsson wrot
Alex wrote:
Here is a follow up patch for documentation of the omp.h allocators,
I'm not super happy with it but I wanted to get eyes on it before I go
to sleep tonight.
I want the table in there somewhere but I'm not confident that where I
put it was the right place.
I think having the C++ te
Because the _M_format(__rg, __fc) were placed outside of if constexpr,
these method and it's childs where instantiated, even if _M_format
could be used. Now we put the calls in else branch of if constexpr.
libstdc++-v3/ChangeLog:
* include/std/format (range_formatter::format): Do not inst
I forgot to do this yesterday, it is now done.
Thank you to everyone who helped me get this far,
Alex
From 0e8b6f0dad11ece6c693e4765f3c58309ff8ef12 Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Wed, 16 Apr 2025 07:26:50 -0600
Subject: [PATCH] MAINTAINERS: Add myself to Write After Approval
ChangeL
Hi,
Znver5 has latency of addss 2 in typical case while all earlier versions has
latency 3.
Unforunately addss cost is used to cost many other SSE instructions than just
addss and
setting the cost to 2 makes us to vectorize 4 64bit stores into one 256bit
store which
in turn regesses imagemagick
Hi,
this patch adds streaming of return summaries from compile time to ltrans
which are now needed for vrp to not ouput false errors on musttail.
Bootstrapped/regtested x86_64-linux, comitted.
Co-authored-by: Jakub Jelinek
gcc/ChangeLog:
PR tree-optimization/119614
* ip
Hi,
this is a regression introduced on the mainline and 14 branch by:
https://gcc.gnu.org/pipermail/gcc-cvs/2023-October/391658.html
The change bypasses int_fits_type_p (essentially) to work around the
signedness constraints, but in doing so disregards the peculiarities of
boolean types whose
ping?
On Thu, 10 Apr 2025 at 15:48, Hans-Peter Nilsson wrote:
>
> > From: Christophe Lyon
> > Date: Thu, 10 Apr 2025 15:38:48 +0200
>
> > On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote:
> > >
> > > > From: Christophe Lyon
> > > > Date: Thu, 10 Apr 2025 15:21:23 +0200
> > >
> > > Not su
Hi Richard,
> For the record it now builds fine on s390x-linux (big endian) as well, but
> test results are not that good. At least _some_ tests pass ...
>
> Native configuration is s390x-ibm-linux-gnu
>
> === cobol tests ===
>
>
> Running target unix
> FAIL: cobol.dg/literal1.cob
On Wed, Apr 16, 2025 at 02:17:37PM +0200, Richard Biener wrote:
> On Tue, Apr 15, 2025 at 4:33 PM Jeff Law wrote:
> >
> >
> >
> > On 4/15/25 7:57 AM, Andreas Schwab wrote:
> > > * configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
> > > 64-bit multilib.
> > Can't say I'm
On Mon, 14 Apr 2025, Jakub Jelinek wrote:
> Hi!
>
> Here is just a port of the previously posted patch to mingw which
> clearly has the same problems.
>
> Untested though, I don't have Windows anywhere around.
OK.
Richard.
> 2025-04-14 Jakub Jelinek
>
> PR libstdc++/119796
> *
On Mon, 14 Apr 2025, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR (and I think in PR101075 too), we can run into
> deadlock with libat_lock_n calls with larger n.
> As mentioned in PR66842, we use multiple locks (normally 64 mutexes
> for each 64 byte cache line in 4KiB page) and current
On Tue, Apr 15, 2025 at 4:33 PM Jeff Law wrote:
>
>
>
> On 4/15/25 7:57 AM, Andreas Schwab wrote:
> > * configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
> > 64-bit multilib.
> Can't say I'm happy with the amount of Cobol related churn at this phase
> in our cycle. But
On Wed, Apr 16, 2025 at 1:32 PM Jonathan Wakely wrote:
> On Wed, 16 Apr 2025 at 12:18, Jonathan Wakely wrote:
> >
> > This fixes:
> > FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++23 (test for
> excess errors)
> > FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++26 (test
On Wed, 16 Apr 2025 at 12:54, Tomasz Kamiński wrote:
>
> The _Rg is deduced to lvalue reference for the lvalue arguments,
> and in such case __format::__maybe_const_range<_Rg, _CharT> is always _Rg
> (adding const to reference does not change behavior).
>
> Now we correctly check if _Range = const
The _Rg is deduced to lvalue reference for the lvalue arguments,
and in such case __format::__maybe_const_range<_Rg, _CharT> is always _Rg
(adding const to reference does not change behavior).
Now we correctly check if _Range = const remove_reference_t<_Rg> is
formattable range, furthermore as ran
We don't need to mention ranges::out_value_result in this comment,
because doesn't care about that name.
libstdc++-v3/ChangeLog:
* include/std/numeric: Only mention ranges::iota in comment.
---
Pushed to gcc-14 as obvious.
libstdc++-v3/include/std/numeric | 2 +-
1 file changed, 1 ins
On Wed, 16 Apr 2025 at 12:18, Jonathan Wakely wrote:
>
> This fixes:
> FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++23 (test for
> excess errors)
> FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++26 (test for
> excess errors)
>
> The purpose of 'not defined>' is to be
This fixes:
FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++23 (test for excess
errors)
FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++26 (test for excess
errors)
The purpose of 'not defined>' is to be ill-formed (as
required by [format.range.fmtkind]) and to give an err
On Wed, Apr 16, 2025 at 11:13 AM Jonathan Wakely wrote:
> On Wed, 16 Apr 2025 at 09:55, Tomasz Kaminski wrote:
> >
> >
> >
> > On Wed, Apr 16, 2025 at 10:47 AM Jonathan Wakely
> wrote:
> >>
> >> On 16/04/25 10:37 +0200, Tomasz Kaminski wrote:
> >> >Just to clarify, we still will be missing the
On Tue, 15 Apr 2025 at 17:38, Jonathan Wakely wrote:
>
> In r14-7153-gadbc46942aee75 we removed a duplicate definition of
> __glibcxx_want_range_iota from , but __cpp_lib_ranges_iota
> should be defined in at all.
Oops, that was meant to say "should not be defined"
>
> libstdc++-v3/ChangeLog:
>
On Wed, 16 Apr 2025 at 11:10, Jonathan Wakely wrote:
>
> On 16/04/25 11:45 +0200, Tomasz Kamiński wrote:
> >This patch implements formatter specializations for pair and tuple form
> >P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
> >ranges are now supported.
> >
> >The for
On 16/04/25 11:45 +0200, Tomasz Kamiński wrote:
This patch implements formatter specializations for pair and tuple form
P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
ranges are now supported.
The formatters for pairs and tuples whose corresponding elements are the same
On Wed, Apr 16, 2025 at 11:49 AM Tomasz Kamiński
wrote:
> This patch implements formatter specializations for pair and tuple form
> P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
> ranges are now supported.
>
> The formatters for pairs and tuples whose corresponding eleme
On Wed, 16 Apr 2025 at 10:38, Tomasz Kaminski wrote:
>
>
>
> On Wed, Apr 16, 2025 at 11:17 AM Jonathan Wakely wrote:
>>
>> On 16/04/25 09:13 +0200, Tomasz Kamiński wrote:
>> >This patch implements formatter specializations for pair and tuple form
>> >P2286R8. In addition using 'm` and range_forma
This patch implements formatter specializations for pair and tuple form
P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
ranges are now supported.
The formatters for pairs and tuples whose corresponding elements are the same
(after applying remove_cvref_t) derive from the sa
On Wed, Apr 16, 2025 at 11:17 AM Jonathan Wakely wrote:
> On 16/04/25 09:13 +0200, Tomasz Kamiński wrote:
> >This patch implements formatter specializations for pair and tuple form
> >P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
> >ranges are now supported.
> >
> >The f
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, April 16, 2025 9:57 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH]middle-end: fix masking for partial vectors and early
> break
> [PR119351]
>
> On Wed, 16 Apr 2025, Tamar Christina wrote:
The following tries to address us BB vectorizing a loop body that
swaps consecutive elements of an array like for bubble-sort. This
causes the vector store in the previous iteration to fail to forward
to the vector load in the current iteration since there's a partial
overlap.
We try to detect th
On Wed, Apr 16, 2025 at 11:08 AM xionghuluo wrote:
>
> Hi, the bootstrap-lto-locality is much longer compared to boostrap-lto
> and bootstrap, and
>
> It seems that stage2 and stage3 only produced 5 partitions in LTO, is
> this reasonable...
Likely due to the high default of
-param=lto-max-local
On 16/04/25 09:13 +0200, Tomasz Kamiński wrote:
This patch implements formatter specializations for pair and tuple form
P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
ranges are now supported.
The formatters for pairs and tuples whose corresponding elements are the same
On Wed, 16 Apr 2025 at 09:55, Tomasz Kaminski wrote:
>
>
>
> On Wed, Apr 16, 2025 at 10:47 AM Jonathan Wakely wrote:
>>
>> On 16/04/25 10:37 +0200, Tomasz Kaminski wrote:
>> >Just to clarify, we still will be missing the formatter for adaptors
>> >(stack, queue, piority_queue).
>>
>> Yes, but I d
Hi, the bootstrap-lto-locality is much longer compared to boostrap-lto
and bootstrap, and
It seems that stage2 and stage3 only produced 5 partitions in LTO, is
this reasonable...
Also could you please inform how much is the exact performance gain, please?
make bootstrap:
On 16/04/2025 08:57, Tamar Christina wrote:
Hi All,
The given test is intended to test vectorization of a strided access done by
having a step of > 1.
GCN target doesn't support load lanes, so the testcase is expected to fail,
other targets create a permuted load here which we then then reject.
On Wed, 16 Apr 2025, Tamar Christina wrote:
> Hi All,
>
> The following testcase shows an incorrect masked codegen:
>
> #define N 512
> #define START 1
> #define END 505
>
> int x[N] __attribute__((aligned(32)));
>
> int __attribute__((noipa))
> foo (void)
> {
> int z = 0;
> for (unsigned
On Wed, 16 Apr 2025, Tamar Christina wrote:
> Hi All,
>
> The given test is intended to test vectorization of a strided access done by
> having a step of > 1.
>
> GCN target doesn't support load lanes, so the testcase is expected to fail,
> other targets create a permuted load here which we then
On Wed, Apr 16, 2025 at 10:47 AM Jonathan Wakely wrote:
> On 16/04/25 10:37 +0200, Tomasz Kaminski wrote:
> >Just to clarify, we still will be missing the formatter for adaptors
> >(stack, queue, piority_queue).
>
> Yes, but I doubt most people want to use those :-)
>
We are good as long as vecto
On 16/04/25 10:37 +0200, Tomasz Kaminski wrote:
Just to clarify, we still will be missing the formatter for adaptors
(stack, queue, piority_queue).
Yes, but I doubt most people want to use those :-)
Just to clarify, we still will be missing the formatter for adaptors
(stack, queue, piority_queue).
On Wed, Apr 16, 2025 at 10:04 AM Jonathan Wakely wrote:
> On Wed, 16 Apr 2025 at 08:15, Tomasz Kamiński wrote:
> >
> > This patch implements formatter specializations for pair and tuple form
> >
On Wed, 16 Apr 2025 at 08:15, Tomasz Kamiński wrote:
>
> This patch implements formatter specializations for pair and tuple form
> P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
> ranges are now supported.
>
> The formatters for pairs and tuples whose corresponding element
There are few whitespace changes that are caused by me mass removing spaces
that are followed by tabs.
They seem to affect only the code that was recently added by me in debug
string and range support, so I think it is ok to keep them.
On Wed, Apr 16, 2025 at 9:16 AM Tomasz Kamiński wrote:
> Thi
Hi All,
The given test is intended to test vectorization of a strided access done by
having a step of > 1.
GCN target doesn't support load lanes, so the testcase is expected to fail,
other targets create a permuted load here which we then then reject.
However some GCN arch don't seem to support
Hi All,
The following testcase shows an incorrect masked codegen:
#define N 512
#define START 1
#define END 505
int x[N] __attribute__((aligned(32)));
int __attribute__((noipa))
foo (void)
{
int z = 0;
for (unsigned int i = START; i < END; ++i)
{
z++;
if (x[i] > 0)
On Tue, 15 Apr 2025, Tamar Christina wrote:
> Hi All,
>
> The following example:
>
> #define N 512
> #define START 2
> #define END 505
>
> int x[N] __attribute__((aligned(32)));
>
> int __attribute__((noipa))
> foo (void)
> {
> for (signed int i = START; i < END; ++i)
> {
> if (x[i
This patch implements formatter specializations for pair and tuple form
P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
ranges are now supported.
The formatters for pairs and tuples whose corresponding elements are the same
(after applying remove_cvref_t) derive from the sa
On Tue, 15 Apr 2025, H.J. Lu wrote:
> Hi,
>
> I'd like to backport this testsuite enhancement to GCC 14 so that
>
> https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680896.html
>
> can be backported to GCC 14 with testcases unchanged.
OK.
>
> H.J.
> ---
> As PR target/116174 shown, we ma
1 - 100 of 102 matches
Mail list logo
