Hi Segher,
Thanks for the comments!
on 2022/11/17 02:58, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 16, 2022 at 02:51:04PM +0800, Kewen.Lin wrote:
>> The current handlings in rs6000_emit_vector_compare is a bit
>> complicated to me, especially after we emit vector float
>> comparison insn
Hi Segher,
Thanks for the comments!
on 2022/11/17 02:44, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 16, 2022 at 02:48:25PM +0800, Kewen.Lin wrote:
>> * config/rs6000/rs6000.cc (rs6000_emit_vector_compare_inner): Remove
>> float only comparison operators.
>
> Why? Is that
We used to expand atomic_exchange_n(ptr, new, mem_order) for subword types
into something like:
{
__typeof__(*ptr) t = atomic_load_n(ptr, mem_order);
atomic_compare_exchange_n(ptr, , new, true, mem_order, mem_order);
return t;
}
It's incorrect because another thread may
Hi,
The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to
indicate if branch by CC bits is invalid or not. The new expand pattern
"cbranchcc4" is created which intend to match the pattern defined in
"*cbranch", "*cbranch_2insn" and "*creturn". The operand sequence in
"cbranchcc4" is
> Am 17.11.2022 um 05:10 schrieb Tamar Christina via Gcc-patches
> :
>
> Hi All,
>
> At the moment when the VEC_PERMs generated by this match.pd rule is generated
> it creates two different SSA_NAMEs for the folded operand. Because of this it
> the permute switches from a single operand
Am Mi., 16. Nov. 2022 um 22:00 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> We can use an array instead of a std::vector, and we can avoid the
> binary search for the common case of a time point after the most recent
> leap second. On one
LGTM. A minor issue is "enabling -fprefetch-loop-arrays at -O3" is not
documented, but AArch64 and i386 are already doing this anyway. We can
add the fact into the doc later.
On Wed, 2022-11-16 at 10:10 +0800, Lulu Cheng wrote:
> v2 -> v3:
> 1. Remove preldx support.
>
>
Hi,
As mentioned in the previous version patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604646.html
The suboptimal code is generated for "assigning from parameter" or
"assigning to return value".
This patch enhances the assignment from parameters like the below
cases:
/case1.c
> I assume the "full permutation" condition is to avoid performing some
> extra operations that would raise exception flags. If so, are there
> conditions (-fno-trapping-math?) where the transformation would be safe
> with arbitrary shuffles?
Yes, that could be an alternative choice with
On Thu, 2022-11-17 at 11:46 +0800, Jinyang He wrote:
> > So we do need an additional dbar for compare-and-exchange, but do
> > not
> > need it for a bare atomic exchange?
> Yes.
Ok, I just noticed we also don't use dbar in atomic_add etc.
I've adjusted the patch a little (in attachment):
On 16/11/22 12:54, Jonathan Wakely wrote:
On Wed, 16 Nov 2022 at 11:35, Jonathan Wakely wrote:
On Wed, 16 Nov 2022 at 06:04, François Dumont wrote:
On 15/11/22 17:17, Jonathan Wakely wrote:
On 06/10/22 19:38 +0200, François Dumont wrote:
Hi
Looks like the previous patch was not enough.
On 11/7/22 11:58, Palmer Dabbelt wrote:
The docs say we take ISA strings, but that's never really been the case:
at a bare minimum we've required lower case strings, but there's
generally been some subtle differences as well in things like version
handling and such. We talked about removing
Hi All,
At the moment when the VEC_PERMs generated by this match.pd rule is generated
it creates two different SSA_NAMEs for the folded operand. Because of this it
the permute switches from a single operand permute to a two operand permute and
the target may no longer support a permute for this.
On 11/15/22 01:33, jiawei wrote:
This testcase mix exist spill-1.c and adding new fun to check if
there have redundant addi intructions. Idea provided by Jeff Law.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/spill-sp-adjust.c: New test.
I made several
On 2022/11/17 上午11:38, Xi Ruoyao wrote:
On Thu, 2022-11-17 at 10:55 +0800, Jinyang He wrote:
On 2022/11/17 上午9:39, Jinyang He wrote:
On 2022/11/16 下午7:46, Xi Ruoyao wrote:
On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
+ return "%G6\\n\\t"
+ "1:\\n\\t"
+
On Thu, 2022-11-17 at 10:55 +0800, Jinyang He wrote:
> On 2022/11/17 上午9:39, Jinyang He wrote:
>
> > On 2022/11/16 下午7:46, Xi Ruoyao wrote:
> >
> > > On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
> > >
> > > > > > + return "%G6\\n\\t"
> > > > > > + "1:\\n\\t"
> > > > > > +
On 11/12/22 16:55, Andrew Pinski via Gcc-patches wrote:
On Sat, Nov 12, 2022 at 3:47 PM Bernhard Reutner-Fischer via
Gcc-patches wrote:
gcc/ChangeLog:
* value-range.cc (get_bound_with_infinite_markers): New static helper.
(irange::as_string): New definition.
*
PR analyzer/107711 reports an ICE since r13-4073-gd8aba860b34203 with
the combination of -fanalyzer and -Wunused-macros.
The issue is that in c_translation_unit::consider_macro's call to
cpp_create_reader I was passing "ident_hash" for use by the the new
reader, but that takes ownership of that
On 2022/11/17 上午9:39, Jinyang He wrote:
On 2022/11/16 下午7:46, Xi Ruoyao wrote:
On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
+ return "%G6\\n\\t"
+ "1:\\n\\t"
+ "ll.\\t%0,%1\\n\\t"
+ "and\\t%7,%0,%z3\\n\\t"
+ "or%i5\\t%7,%7,%5\\n\\t"
+
On Fri, Nov 11, 2022 at 5:09 PM Cui,Lili via Gcc-patches
wrote:
>
> From: Lili Cui
>
> Hi Hontao,
>
> This patch is to enable 256 move by pieces for ALDERLAKE and AVX2.
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
>
> OK for master?
Ok.
>
>
> gcc/Changelog:
>
> *
On 11/15/22 09:31, Aldy Hernandez via Gcc-patches wrote:
I know it's past the end of stage1, but I'm afraid we'll drag this
around forever in the GCC12 branch, and it's an easy readbility fix.
p.s. Or if you prefer:
if (!lb_nan && !ub_nan && !maybe_nan && )
r.clear_nan ();
OK for
On 11/16/22 03:26, Manolis Tsamis wrote:
On Sun, Nov 13, 2022 at 3:33 AM Jeff Law via Gcc-patches
wrote:
On 11/7/22 15:07, Palmer Dabbelt wrote:
On Thu, 03 Nov 2022 15:23:28 PDT (-0700), j...@ventanamicro.com wrote:
On 11/2/22 18:26, Palmer Dabbelt wrote:
I also tried to remove that
So my tester started showing even more regressions on the sh3/sh4 runs
recently (beyond the one recently reported in BZ triggered by some DCE
related changes). Bisection kept showing inconsistent results. I was
starting to think memory management error, but valgrind didn't flag
anything.
On 2022/11/16 下午7:46, Xi Ruoyao wrote:
On Wed, 2022-11-16 at 10:11 +0800, Jinyang He wrote:
+ return "%G6\\n\\t"
+ "1:\\n\\t"
+ "ll.\\t%0,%1\\n\\t"
+ "and\\t%7,%0,%z3\\n\\t"
+ "or%i5\\t%7,%7,%5\\n\\t"
+ "sc.\\t%7,%1\\n\\t"
+ "beqz\\t%7,1b\\n\\t";
Do
On Wed, Nov 16, 2022 at 08:22:39AM -0500, Jason Merrill wrote:
> On 11/15/22 19:35, Marek Polacek wrote:
> > On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote:
> > > On 11/12/22 06:53, Marek Polacek wrote:
> > > > In this PR, we are crashing because we've encountered a UDL where a
> >
LGTM, thanks :)
On Thu, Nov 17, 2022 at 5:17 AM Kevin Lee wrote:
>
> l insn condition has been modified based on the thread in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605481.html. The
> lfloor-lecil-inexact checks call instead of scan-assembler-not
> "fcvt.l.s/d" due to
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
For powerpc64le we need to be able to format both of __ieee128 and
__ibm128, so we need the std::to_chars overloads for both types to be
visible at once. The __ieee128 overloads are always visible in C++23
mode, because they're used to
Hi,
r13-3950-g071e428c24ee8c enables O2 small loop unrolling, but it breaks
-fno-unroll-loops for rs6000 with loop_unroll_adjust hook. Adjust the
option handling and target hook accordingly.
Bootstrapped & regtested on powerpc64le-linux-gnu, OK for trunk?
gcc/ChangeLog:
PR
Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4115-gff199a859b2a95.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/named-constants-via-command-line.c: New test.
* gcc.dg/analyzer/named-constants-via-macros-3.c: New test.
*
PR analyzer/107711 seems to be a bug in how named constants are looked up
by the analyzer in the C frontend.
To help debug this, this patch extends -fdump-analyzer and
-fdump-analyzer-stderr so that they dump this part of the analyzer's
startup.
Successfully bootstrapped & regrtested on
Backports applied to releases/gcc-11 and releases/gcc-12. Thanks!
Philipp.
On Tue, 15 Nov 2022 at 11:43, Richard Sandiford
wrote:
> Philipp Tomsich writes:
> > Richard,
> >
> > is this OK for backport to GCC-12 and GCC-11?
>
> The fusion part seems potentially risky for a stable branch, but
On Wed, Nov 16, 2022 at 10:58:18PM +0100, Harald Anlauf via Fortran wrote:
>
> @Steve: please close PR if you think everything is ok.
>
Thanks. I'll close the pr.
--
Steve
Dear all,
I've committed the attached patch for Steve after regtesting.
It obviously checks the types of character length to be integer
before passing them to mpz_*.
Pushed as r13-4113-gbdd784fc48a283d54f5f1e3cc2a0668c14dd3bee
Thanks,
Harald
@Steve: please close PR if you think everything is
l insn condition has been modified based on the thread in
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605481.html. The
lfloor-lecil-inexact checks call instead of scan-assembler-not
"fcvt.l.s/d" due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107723.
Is this patch good for commit?
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is only a partial fix for the PR.
libstdc++-v3/ChangeLog:
PR libstdc++/107720
* include/std/format (__format::_Arg_t): Fix typo in enumerator
name.
(_Arg_value::_S_get): Fix missing semi-colons.
---
Tested x86_64-linux. Pushed to trunk.
-- >8 --
We can use an array instead of a std::vector, and we can avoid the
binary search for the common case of a time point after the most recent
leap second. On one system where I tested this, utc_clock::now() now
takes about 16ns instead of 31ns.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Clang doesn't define __builtin_toupper, so use std::toupper.
Also add some (not actually required since C++20) typename keywords to
help Clang versions up to and including 15.
libstdc++-v3/ChangeLog:
PR libstdc++/107712
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This restricts std::format support for _Float128 (and __float128) to
targets where glibc provides __strfromf128 and so can give correct
output.
libstdc++-v3/ChangeLog:
* include/std/format [__FLT128_DIG__] (_GLIBCXX_FORMAT_F128):
Dear all,
the attached obvious patch fixes a NULL pointer dereference
when referencing a CLASS variable with a bad decl.
Pushed as r13-4107-g96e4244ef3ccf4867ca4e37fbc6800e64ef30af6
after regtesting on x86_64-pc-linux-gnu.
Thanks,
Harald
From 96e4244ef3ccf4867ca4e37fbc6800e64ef30af6 Mon Sep 17
On Mon, Nov 14, 2022 at 09:55:29PM +, Joseph Myers wrote:
> On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
>
> > So, I wonder if we don't need to add a target hook where targets will be
> > able to provide upper bound on error for floating point functions for
> > different floating
On 11/16/22 11:06, Marek Polacek wrote:
On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote:
On 11/15/22 19:30, Marek Polacek wrote:
@@ -996,19 +1040,26 @@ register_constexpr_fundef (const constexpr_fundef )
**slot = value;
}
-/* FUN is a non-constexpr function called in a
On 11/16/22 09:46, Jakub Jelinek wrote:
On Wed, Nov 16, 2022 at 09:33:27AM -0500, Jason Merrill wrote:
and at that point I fear decl_maybe_constant_var_p will not work
properly. Shall this hunk be moved somewhere else (cp_finish_decl?)
where we can already call it, or do the above in
Am 16.11.22 um 12:39 schrieb Mikael Morin:
Le 15/11/2022 à 21:45, Harald Anlauf via Fortran a écrit :
Dear all,
when constant expressions involve parentheses, array constructors,
typespecs, and the power operator (**), we could fail with an ICE
during simplification in arith_power.
Debugging
Applied to master. Thanks!
Philipp.
On Tue, 15 Nov 2022 at 18:36, Jeff Law wrote:
>
> On 11/13/22 13:48, Philipp Tomsich wrote:
> > We avoid reassociating "(~(a >> BIT_NO)) & 1" into "((~a) >> BIT_NO) & 1"
> > by splitting it into a zero-extraction (bext) and an xori. This both
> > avoids
Applied to master. Thanks!
Philipp.
On Tue, 15 Nov 2022 at 18:25, Jeff Law wrote:
>
> On 11/13/22 13:48, Philipp Tomsich wrote:
> > For a straightforward application of bext for the following function
> >long bext64(long a, char bitno)
> >{
> > return (a & (1UL << bitno)) ? 0 : -1;
On Fri, 4 Nov 2022, Hongyu Wang via Gcc-patches wrote:
This is a follow-up patch for PR98167
The sequence
c1 = VEC_PERM_EXPR (a, a, mask)
c2 = VEC_PERM_EXPR (b, b, mask)
c3 = c1 op c2
can be optimized to
c = a op b
c3 = VEC_PERM_EXPR (c, c, mask)
for all integer vector
Hi!
On Wed, Nov 16, 2022 at 02:51:04PM +0800, Kewen.Lin wrote:
> The current handlings in rs6000_emit_vector_compare is a bit
> complicated to me, especially after we emit vector float
> comparison insn with the given code directly. This patch is
> to refine the handlings for vector integer
On 11/16/22 05:17, Richard Biener via Gcc-patches wrote:
On Tue, 15 Nov 2022, Tamar Christina wrote:
Ping, anyone alive in here? ?
You have to queue behind all the others waiting, sorry. But it's on
my list of things to look at - but it's also a complex thing and thus
requires a larger
On 11/16/22 09:01, Tom Tromey wrote:
"Jeff" == Jeff Law via Gcc-patches writes:
This patch uses the toplevel configure parts for GMP/MPFR for
gdb.
Jeff> If the GDB folks confirm they want this behavior, then the toplevel
Jeff> bits are fine.
I think we do, but my inclination is to wait
Hi!
On Wed, Nov 16, 2022 at 02:48:25PM +0800, Kewen.Lin wrote:
> * config/rs6000/rs6000.cc (rs6000_emit_vector_compare_inner): Remove
> float only comparison operators.
Why? Is that correct? Your mail says nothing about this :-(
Is there any testcase that covers this, and that
On 11/16/22 17:04, Richard Biener wrote:
On Tue, Nov 15, 2022 at 11:46 AM Aldy Hernandez wrote:
On 11/15/22 08:15, Richard Biener wrote:
On Mon, Nov 14, 2022 at 8:05 PM Aldy Hernandez wrote:
On 11/14/22 10:12, Richard Biener wrote:
On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez
On Wed, 2022-11-16 at 11:19 +0800, Lulu Cheng wrote:
> The "m" constraint is defined as follows:
> (define_memory_constraint "m"
> (and (match_code "mem")
> (match_test "loongarch_12bit_offset_address_p (XEXP (op, 0),
> mode)")))
> This setting must be a memory operand.
> ''ZD"
On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote:
> On 11/15/22 19:30, Marek Polacek wrote:
> > @@ -996,19 +1040,26 @@ register_constexpr_fundef (const constexpr_fundef
> > )
> > **slot = value;
> > }
> > -/* FUN is a non-constexpr function called in a context that requires a
>
On Tue, Nov 15, 2022 at 11:46 AM Aldy Hernandez wrote:
>
>
>
> On 11/15/22 08:15, Richard Biener wrote:
> > On Mon, Nov 14, 2022 at 8:05 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/14/22 10:12, Richard Biener wrote:
> >>> On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez wrote:
>
>
Hello,
I would like to submit the patch below addressing bug jit/101491.
Please note that another patch has also been submitted in the bug
report by another FreeBSD user. We worked indipendently. The two
patches look functionally equivalent but use different styles. In
particular, I followed
> "Jeff" == Jeff Law via Gcc-patches writes:
>> This patch uses the toplevel configure parts for GMP/MPFR for
>> gdb.
Jeff> If the GDB folks confirm they want this behavior, then the toplevel
Jeff> bits are fine.
I think we do, but my inclination is to wait until after GDB 13 branches.
On Tue, Nov 15, 2022 at 2:52 PM Aldy Hernandez wrote:
>
> On Mon, Nov 14, 2022 at 10:12 AM Richard Biener
> wrote:
> >
> > On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez wrote:
> > >
> > > It irks me that a PR named "we should track ranges for floating-point
> > > hasn't been closed in this
On Wed, Nov 16, 2022 at 03:40:02PM +, Tamar Christina wrote:
> > Even:
> >
> > --- gcc/match.pd.jj 2022-11-15 07:56:05.240348804 +0100
> > +++ gcc/match.pd2022-11-16 16:35:34.854080956 +0100
> > @@ -8259,7 +8259,7 @@ and,
> > (simplify
> >(op (vec_perm @0 @0 @2) (vec_perm @1 @1 @2))
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, November 16, 2022 3:38 PM
> To: Richard Biener
> Cc: Tamar Christina ; Hongyu Wang
> ; Prathamesh Kulkarni
> ; Richard Sandiford
> ; Hongyu Wang ;
> hongtao@intel.com; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH]
On Wed, Nov 16, 2022 at 9:00 AM Torbjorn SVENSSON via Gcc-patches
wrote:
>
> Hi,
>
> On 2022-11-16 03:11, Hans-Peter Nilsson wrote:
> > How was r13-2619-g34b9a03353d3fd "gcov: Respect triplet when looking
> > for gcov" tested? I'm having a hard time believing it was tested with
> > a
On Wed, Nov 16, 2022 at 04:30:06PM +0100, Richard Biener via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 4:29 PM Richard Biener
> wrote:
> >
> > On Wed, Nov 16, 2022 at 4:25 PM Tamar Christina
> > wrote:
> > >
> > > Hi,
> > >
> > > This patch is causing several ICEs because it changes the
On Wed, Nov 16, 2022 at 8:29 AM Kewen.Lin wrote:
>
> Hi,
>
> As Robin spotted, my recent commit r13-3716 caused an ICE
> on s390 if vector access with length is enabled there (his
> patch for the enablement hasn't been committed yet). The
> failure is caused by one stupid typo, the bias on s390
On Wed, Nov 16, 2022 at 3:33 AM Kewen.Lin wrote:
>
> on 2022/11/10 11:30, Kewen.Lin wrote:
> > on 2022/11/9 15:56, Eric Botcazou wrote:
> >>> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but
> >>> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, November 16, 2022 3:30 PM
> To: Tamar Christina
> Cc: Hongyu Wang ; Prathamesh Kulkarni
> ; Richard Sandiford
> ; Hongyu Wang ;
> hongtao@intel.com; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Optimize VEC_PERM_EXPR
The following propely restricts the bitfield access to integral types
when we look through VEC_UNPACK with the intent to emit a widening
conversion.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/107686
* tree-ssa-forwprop.cc
When the frontend clobbers a parameter and that parameter gets
rewritten into SSA then we ICE because we didn't expect this. Avoid
using the parameter decl to create a SSA default def in this case.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/107679
On Wed, Nov 16, 2022 at 4:29 PM Richard Biener
wrote:
>
> On Wed, Nov 16, 2022 at 4:25 PM Tamar Christina
> wrote:
> >
> > Hi,
> >
> > This patch is causing several ICEs because it changes the permutes from a
> > single register
> > permute to a multi register due to the lowering of the
On Wed, Nov 16, 2022 at 4:25 PM Tamar Christina wrote:
>
> Hi,
>
> This patch is causing several ICEs because it changes the permutes from a
> single register
> permute to a multi register due to the lowering of the expressions to
> different SSA names.
>
> See
Hi,
This patch is causing several ICEs because it changes the permutes from a
single register
permute to a multi register due to the lowering of the expressions to different
SSA names.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717
I have a prototype fix which adds a new rule to CSE
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This test of leap second handling is taken from the C++20 standard.
libstdc++-v3/ChangeLog:
* testsuite/std/time/clock/utc/1.cc: Check handling across leap
second insertion.
---
.../testsuite/std/time/clock/utc/1.cc | 24
On Wed, Nov 16, 2022 at 09:33:27AM -0500, Jason Merrill wrote:
> > and at that point I fear decl_maybe_constant_var_p will not work
> > properly. Shall this hunk be moved somewhere else (cp_finish_decl?)
> > where we can already call it, or do the above in start_decl for
> > cxx_dialect < cxx20
On 11/16/22 09:08, Jakub Jelinek wrote:
On Wed, Nov 16, 2022 at 08:20:34AM -0500, Jason Merrill wrote:
Ok. But there is another issue, the
https://eel.is/c++draft/expr.const#5.2
spot that P2647R1 is changing didn't exist in C++20, it was only added with
P2242R3. So, if one would treat P2647R1
libatomic/ChangeLog:
* Makefile.in: Re-generate.
---
libatomic/Makefile.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in
index 89e29fc60a7..a0fa3dfc8cc 100644
--- a/libatomic/Makefile.in
+++ b/libatomic/Makefile.in
@@ -383,7 +383,6 @@
On Wed, Nov 16, 2022 at 08:20:34AM -0500, Jason Merrill wrote:
> > Ok. But there is another issue, the
> > https://eel.is/c++draft/expr.const#5.2
> > spot that P2647R1 is changing didn't exist in C++20, it was only added with
> > P2242R3. So, if one would treat P2647R1 as a DR for C++20, one has
On Wed, 16 Nov 2022 at 13:47, Jakub Jelinek wrote:
> On Wed, Nov 16, 2022 at 01:45:19PM +, Jonathan Wakely wrote:
> > > On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek wrote:
> > >
> > >> Hi!
> > >>
> > >> As filed by Jonathan in the PR, I've screwed up the requires syntax
> > >> in the
> Hi,
>
> this should have been part of r12-578-g717d278af93a4a. Call edge
> summaries provide information required for IPA-SRA transformations in
> the callees but are generated when analyzing callers and thus also
> callers which are not IPA-SRA candidates themselves. Therefore we
> analyze
On Wed, Nov 16, 2022 at 01:45:19PM +, Jonathan Wakely wrote:
> > On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek wrote:
> >
> >> Hi!
> >>
> >> As filed by Jonathan in the PR, I've screwed up the requires syntax
> >> in the extended floating point specialization:
> >> -
On Wed, 16 Nov 2022 at 13:42, Jonathan Wakely wrote:
>
>
> On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek wrote:
>
>> Hi!
>>
>> As filed by Jonathan in the PR, I've screwed up the requires syntax
>> in the extended floating point specialization:
>> -requires(__complex_type<_Tp>::type)
>> +
On Mon, 14 Nov 2022 at 13:57, Jakub Jelinek wrote:
> Hi!
>
> As filed by Jonathan in the PR, I've screwed up the requires syntax
> in the extended floating point specialization:
> -requires(__complex_type<_Tp>::type)
> +requires requires { typename __complex_type<_Tp>::type; }
> and
On 11/15/22 19:30, Marek Polacek wrote:
On Mon, Nov 14, 2022 at 06:00:58PM -0500, Jason Merrill wrote:
On 11/9/22 10:53, Marek Polacek wrote:
This patch implements C++23 P2448, which lifts more restrictions on the
constexpr keyword. It's effectively going the way of being just a hint
(hello,
Tested x86_64-linux, with GDB 12.1. Pushed to trunk.
-- >8 --
The recent changes to FilteringTypePrinter affect the result of
gdb.lookup_type('std::string') in StdExpAnyPrinter, causing it to always
return the std::__cxx11::basic_string specialization. This then causes a
gdb.error exception when
Tested x86_64-linux with GDB 12.1. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (is_specialization_of): Fix
incorrect terminology in docstring and describe arguments.
(FilteringTypePrinter): Add default argument for new parameter,
> Hi,
>
> IPA-CP transformation summary streaming code currently won't stream
> out transformations necessary for clones which are only necessary for
> materialization of other clones (such as an IPA-CP clone which is then
> cloned again by IPA-SRA). However, a follow-up patch for bettor
>
Replace lots of repeated checks against strings with a hash_map lookup.
Add some missing type-checking for handling known functions (e.g. checks
for pointer types).
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4088-g21501ec751c102.
gcc/analyzer/ChangeLog:
I'm taking the liberty of pushing this minor reorganization to the
analyzer in stage 3.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4087-g3685aed8ef34b7.
gcc/ChangeLog:
* Makefile.in (ANALYZER_OBJS): Add analyzer/checker-event.o.
On Wed, Nov 16, 2022 at 2:13 PM Alexander Monakov
wrote:
>
> On Wed, 16 Nov 2022, Jan Hubička wrote:
>
> > This looks really promising. I will experiment with the patch for
> separate
> > znver3 model, but I think we should be able to keep
> > them unified and hopefully get both less code
On 11/15/22 19:35, Marek Polacek wrote:
On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote:
On 11/12/22 06:53, Marek Polacek wrote:
In this PR, we are crashing because we've encountered a UDL where a
string-literal is expected. This patch makes the parser reject string
and
On 11/16/22 01:19, Jakub Jelinek wrote:
On Wed, Nov 16, 2022 at 12:27:02AM +, Jonathan Wakely wrote:
On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
Here is an updated patch that passed bootstrap/regtest, the only
change
On 11/16/22 03:25, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 04:49:27PM -0500, Jason Merrill wrote:
Or do you want to outline the
if (result != error_mark_node
&& TREE_CODE (TREE_TYPE (cand->fn)) != METHOD_TYPE
&& TREE_SIDE_EFFECTS (obj))
{
On Wed, 16 Nov 2022, Jan Hubička wrote:
> This looks really promising. I will experiment with the patch for separate
> znver3 model, but I think we should be able to keep
> them unified and hopefully get both less code duplicatoin and table sizes.
Do you mean separate znver4 (not '3') model
On 11/16/22 05:17, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 06:22:36PM -0500, Jason Merrill wrote:
Here is another version of the patch that passed bootstrap/regtest, the only
change are tweaks to 2 further testcases.
2022-11-13 Jakub Jelinek
* decl.cc (grokdeclarator):
On 11/16/22 05:35, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 05:57:26PM -0500, Jason Merrill wrote:
So, my understanding of this is we shouldn't check TYPE_ALIGN in
layout_compatible_type_p, but instead DECL_ALIGN in
next_common_initial_seqence.
Agreed.
+#if
Hao
cbranchcc4 is a named pattern and requires a specific operand ordering. If
you change *cbranch to cbranchcc4, you must change the order of the
operands, not a quick and dirty hack to *cbranch. Also, you should change
*cbranch_2insn and *creturn as well so that all of the patterns are
On 16/11/2022 11:42, Tobias Burnus wrote:
This is a part of a patch by Andrew (hi!) - namely that part that only
adds the
__builtin_gcn_kernarg_ptr. More is planned, see below.
The short term benefit of this patch is to permit replacing hardcoded
numbers
by a builtin – like in libgomp (see
On Wed, 16 Nov 2022 at 10:55, Jonathan Wakely wrote:
>
> On Wed, 16 Nov 2022 at 02:46, Patrick Palka via Libstdc++
> wrote:
> >
> > When linking with a static library, the linker seems to exclude a
> > constituent .o object (including its global initializers) if nothing
> > from it is referenced
On Tue, Nov 15, 2022 at 7:33 PM Jeff Law wrote:
> Thanks for clarifying. ISTM that operand predicate is quite poorly named.
>
> OK for the trunk.
Thanks. Applied to master.
-- Max
On Wed, 16 Nov 2022 at 11:54, Jonathan Wakely wrote:
>
> On Wed, 16 Nov 2022 at 11:35, Jonathan Wakely wrote:
> >
> > On Wed, 16 Nov 2022 at 06:04, François Dumont wrote:
> > >
> > > On 15/11/22 17:17, Jonathan Wakely wrote:
> > > > On 06/10/22 19:38 +0200, François Dumont wrote:
> > > >> Hi
>
On Tue, 15 Nov 2022, Richard Sandiford wrote:
> "Andre Vieira (lists)" writes:
> > On 07/11/2022 11:05, Richard Biener wrote:
> >> On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
> >>
> >>> Sorry for the delay, just been reminded I still had this patch outstanding
> >>> from last stage 1.
Hello,
On Wed, Nov 16, 2022 at 12:53 PM Kumar, Venkataramanan <
venkataramanan.ku...@amd.com> wrote:
> [AMD Official Use Only - General]
>
> Hi,
>
>
> > Top znver table sizes in insn-automata.o:
> >
> > Before:
> >
> > 30056 r znver1_fp_min_issue_delay
> > 120224 r znver1_fp_transitions
>
>
> >
On Tue, 15 Nov 2022, Richard Sandiford wrote:
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Tuesday, November 15, 2022 11:59 AM
> >> To: Tamar Christina via Gcc-patches
> >> Cc: Tamar Christina ; nd ;
> >> rguent...@suse.de;
1 - 100 of 124 matches
Mail list logo
