gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-43.c: Add vect128.
---
gcc/testsuite/gcc.dg/vect/bb-slp-43.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
index dad2d24262d..8aedb06bf72 100
I think it's vectorized by 128bit vector too.
vector(4) int vect__9.9;
vector(4) int vect__2.6;
vector(4) int vect__1.5;
int _1;
int _5;
int _11;
int _13;
vector(4) int _27;
[local count: 1073741824]:
vect__1.5_24 = MEM [(int *)&b];
vect__2.6_25 = vect__1.5_24 + { 1, 2, 3,
Hi!
The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_confli
On Mon, Jan 15, 2024 at 01:28:04PM +0100, Richard Biener wrote:
> On Mon, Jan 15, 2024 at 12:27 PM Andrew Carlotti
> wrote:
> >
> > This allows code to determine why a particular function is
> > multiversioned. For now, this will primarily be used to preserve
> > existing name mangling quirks whe
Hi!
These symbols were exported at an incorrect symbol version,
the following patch fixes that.
I believe we should also rename the symbols (__nested_func_ptr_*
or __gcc_nested_func_ptr_* or similar), __builtin_ in the name
doesn't look right, but that will need more changes to make it
work.
Boo
On Tue, Jan 16, 2024 at 2:13 AM Roger Sayle wrote:
>
>
> This patch resolves PR rtl-optimization/111267 by improving RTL-level
> forward propagation. This x86_64 code quality regression was caused
> (exposed) by my changes to improve how x86's (TImode) argument passing
> is represented at the RTL
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> gcc/testsuite/ChangeLog:
OK
> * gcc.dg/vect/bb-slp-43.c: Add vect128.
>
> ---
> gcc/testsuite/gcc.dg/vect/bb-slp-43.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
> b/gcc/testsui
On Tue, 16 Jan 2024, juzhe.zh...@rivai.ai wrote:
> I think it's vectorized by 128bit vector too.
>
> vector(4) int vect__9.9;
> vector(4) int vect__2.6;
> vector(4) int vect__1.5;
> int _1;
> int _5;
> int _11;
> int _13;
> vector(4) int _27;
>
>[local count: 1073741824]:
>
On Tue, 16 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> These symbols were exported at an incorrect symbol version,
> the following patch fixes that.
>
> I believe we should also rename the symbols (__nested_func_ptr_*
> or __gcc_nested_func_ptr_* or similar), __builtin_ in the name
> doesn't look r
On Tue, 16 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following patch adds a quick workaround to bugs in VAR_DECL
> partitioning.
> The problem is that there is no dependency between ADDR_EXPRs of local
> decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
> (including ivopts int
On Tue, 2024-01-16 at 12:58 +0800, Xi Ruoyao wrote:
> On Tue, 2024-01-16 at 10:57 +0800, chenxiaolong wrote:
> > 在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道：
> > > On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote:
> > > > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote：
> > > > > On
Thanks, so I add a test: atomic_float/compare_exchange_padding.cc, which
will fail due to timeout without the patch.
---
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h: add __builtin_clear_padding in
__atomic_float constructor.
* testsuite/lib/dg-options.exp: enable libatomic for IA32 and
On Tue, 2024-01-16 at 17:53 +0800, xndcn wrote:
> Thanks, so I add a test: atomic_float/compare_exchange_padding.cc,
> which will fail due to timeout without the patch.
Please resend in plain text instead of HTML. Sending in HTML causes the
patch mangled.
And libstdc++ patches should CC libstd..
On Tue, Jan 16, 2024 at 5:58 AM Xi Ruoyao wrote:
>
> On Tue, 2024-01-16 at 10:57 +0800, chenxiaolong wrote:
> > 在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道：
> > > On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote:
> > > > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote：
> > > > > On
On Tue, Jan 16, 2024 at 10:00:09AM +0100, Richard Biener wrote:
> I'm not sure how fancy we need to get with this workaround, so
> changing to INTEGRAL_TYPE_P works for me.
I'll go for it.
BTW, I've also built linux kernel allyesconfig, and in there
per the statistics gathering patch there are so
This adds some more entries to avr-mcus.def
Johann
--
AVR: Add AVR16EB, AVR16EA and AVR32EA devices.
gcc/
* config/avr/avr-mcus.def (avr16eb14, avr16eb20, avr16eb28, avr16eb32)
(avr16ea28, avr16ea32, avr16ea48, avr32ea28, avr32ea32, avr32ea48): Add.
* doc/avr-mmcu.texi:
It would be neater if the middle end for target_clones used a target
hook for version name mangling, so we only do version name mangling
once. However, that would require more intrusive refactoring that will
have to wait till Stage 1.
This patch builds upon the testsuite additions in patch 1/5 o
The target hook aarch64_class_max_nregs returns the incorrect result for 64-bit
structure modes like V31DImode or V41DFmode etc. The calculation of the nregs
is based on the size of AdvSIMD vector register for 64-bit modes which ought to
be UNITS_PER_VREG / 2. This patch fixes the register size.
Tested on x86_64, i686 Darwin and x86_64 Linux,
OK for trunk? when ?
thanks,
Iain
--- 8< ---
Currently, we have no exports list for libgccjit, which means that
all symbols are exported, including those from libstdc++ which is
linked statically into the lib. This causes failures when the
shared l
Tested on x86_64, i686 Darwin, x86_64 Linux,
OK for trunk? When?
thanks
Iain
--- 8< ---
Currently when a test fails, we print out a lot of information,
this includes items that are not stable between invocations (e.g.
the PID for the executable). That makes automated comparisons
between test run
tested on x86_64, i686 Darwin, x86_64 Linux,
OK for trunk ? When ?
thanks
Iain
--- 8< ---
test-ggc-bugfix.c fails early on Darwin versions using a linker that
complains if libSystem is not present on user-land link lines.
Add this to fix that specific issue.
gcc/testsuite/ChangeLog:
*
It is a regression on the mainline for -fdump-ada-spec in a pathological case.
Tested on x86-64/Linux, applied on the mainline.
2024-01-16 Eric Botcazou
PR ada/113397
* c-ada-spec.cc (check_type_name_conflict): Add guard for the
presence of DECL_NAME on a TYPE_DECL.
On Mon, Jan 15, 2024 at 04:04:49PM -0500, Jason Merrill wrote:
> On 1/15/24 04:41, Nathaniel Shead wrote:
> > While working on another bug, I noticed the ENABLE_SCOPE_CHECKING macro
> > and thought to try it out. It caused selftest to ICE. This patch is a
> > minimal fix to get it working again.
>
On Mon, Jan 15, 2024 at 05:38:25PM -0500, Jason Merrill wrote:
> On 1/11/24 01:12, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu. OK for trunk?
> >
> > -- >8 --
> >
> > Currently, thread_locals in header modules cause ICEs. This patch makes
> > the required changes
On 1/16/24 06:59, Nathaniel Shead wrote:
On Mon, Jan 15, 2024 at 04:04:49PM -0500, Jason Merrill wrote:
On 1/15/24 04:41, Nathaniel Shead wrote:
While working on another bug, I noticed the ENABLE_SCOPE_CHECKING macro
and thought to try it out. It caused selftest to ICE. This patch is a
minimal
On Mon, Jan 15, 2024 at 06:10:55PM -0500, Jason Merrill wrote:
> On 1/8/24 10:27, Patrick Palka wrote:
> > On Mon, 8 Jan 2024, Nathaniel Shead wrote:
> > > On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
> > > > On Sun, 3 Dec 2023, Nathaniel Shead wrote:
> > > > >
> > > > > The TYPE
Hi,
PR 108007 is another manifestation where we rely on DCE to clean-up
after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
can leave behind statements which are fed uninitialized values and
trap, even though their results are themselves never used.
I have already fixed this for u
The following avoids prologue peeling when doing early exit
vectorization with the IV exit before the early exit. That's because
we it invalidates the invariant that the effective latch of the loop
is empty causing wrong continuation to the main loop. In particular
this is prone to break virtual
On 15/01/24 19:09 -0500, Patrick Palka wrote:
On Mon, 15 Jan 2024, Jonathan Wakely wrote:
I think I'm happy with this now. It has tests for all the new functions,
and the performance of the charset alias match algorithm is improved by
reusing part of .
Tested x86_64-linux.
-- >8 --
This is a
On 1/2/24 14:07, Hans-Peter Nilsson wrote:
On Tue, 2 Jan 2024, Jeff Law wrote:
On 1/1/24 20:22, Hans-Peter Nilsson wrote:
Tested mmix-knuth-mmixware (where all torture-variants of
gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
x86_64-pc-linux-gnu. Also stepped through the test for
When GCC is configured with --enable-target-optspace the compiler generates
a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
when compiling for SPARC V8. Add HAVE_AS_SYM_ASSIGN to replace it with a
call to __sanitizer_internal_memcpy.
libsanitizer/ChangeLog:
* sanit
On 1/12/24 06:59, Maciej W. Rozycki wrote:
On Fri, 12 Jan 2024, Andrew Pinski wrote:
Verify that if-conversion succeeded through noce_try_store_flag_mask, as
per PR rtl-optimization/105314, tightening the test case and making it
explicit.
gcc/testsuite/
* gcc.target/riscv/
On 1/9/24 17:58, Kito Cheng wrote:
Oops, I should leave more context here:
Actually we discussed that years ago, and most people agree with that,
but I guess we are just missing that, and also the ISA string isn't so
terribly long yet at that moment, however...the number of extensions are
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
-- >8 --
This paper changes the identity element of views::cartesian_product to
be a single empty tuple instead of an empty range.
libstdc++-v3/ChangeLog:
* include/std/ranges (views::_CartesianProduct::operator()):
On Tue, 16 Jan 2024 at 14:39, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
Oh! I thought this went in as part of the original cartesian_product
commit. I would have asked you to do it at the same time otherwise,
sorry.
Yes, OK for trunk and gcc-13, thank
On Tue, Jan 16, 2024 at 03:11:39PM +0100, Daniel Cederman wrote:
> When GCC is configured with --enable-target-optspace the compiler generates
> a memcpy call in the Symbolizer constructor in sanitizer_symbolizer.cpp
> when compiling for SPARC V8. Add HAVE_AS_SYM_ASSIGN to replace it with a
> call
The following makes reduction epilogue code generation handle missing
LC PHIs for the reductions, in particular also avoid replacing results
on one exit with epilogue result from another one (but not avoiding
generation of dead epilogues yet). The proper fix should be eventually
to create the miss
On Tue, 16 Jan 2024, Jonathan Wakely wrote:
> On Tue, 16 Jan 2024 at 14:39, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
>
> Oh! I thought this went in as part of the original cartesian_product
> commit. I would have asked you to do it at the same ti
On 1/15/24 05:56, Maxim Kuvyrkov wrote:
Hi Vladimir,
Hi Jeff,
Richard and Alexander have reviewed this patch and [I assume] have no
further comments. OK to merge?
I think the question is whether or not we're too late. I know that
Richard S has held off on his late-combine pass and I'm hol
Tested on x86_64 Darwin, x86_64 Linux.
OK for trunk? When?
thanks
Iain
--- 8< ---
Currently, these section names have wrong syntax for Mach-O.
Although they were added some time ago; recently added tests are
now emitting them leading to new fails on Darwin.
This adds a Mach-O variant for each.
On 12/15/23 04:53, Thomas Schwinge wrote:
Hi Jason!
I think you usually deal with these kind of GCC Git things? If not,
please let me know.
I just took care of this; I didn't notice it until now because the
subject line didn't seem relevant to me.
On 2023-10-26T10:21:18+0200, I wrote:
Fi
On 1/3/24 05:07, Richard Sandiford wrote:
Jeff Law writes:
I know we're deep into stage3 and about to transition to stage4. So if
the consensus is for this to wait, I'll understand
This it the V3 of the ext-dce patch based on Joern's work from last year.
Changes since V2:
Handle M
Remove from documentation spec strings that no longer exist in the code:
- predefines: removed in 2003 (From-SVN: r66917)
- signed_char: removed in 2002 (From-SVN: r49444)
gcc/
* doc/invoke.texi (Spec Files): Remove obsolete spec strings
---
gcc/doc/invoke.texi | 3 ---
1 file changed, 3
On Tue, 16 Jan 2024, Jeff Law wrote:
> > It's not clear to me what you mean by an "RTL testcase", i.e. how you'd
> > see the testcase changed (or an additional one produced instead) and why,
> > please elaborate. Right now we verify that branches are absent from
> > output, but not how that hap
On Tue, 16 Jan 2024 at 14:07, Jonathan Wakely wrote:
>
> On 15/01/24 19:09 -0500, Patrick Palka wrote:
> >> +friend _Iterator
> >> +operator+(_Iterator __i, difference_type __n)
> >
> >constexpr?
>
> Fixed. I've added tests that all iterator ops are usable in constant
> expressions, which f
Sorry about the mangled content...
So I add a new add-options for libatomic_16b:
---
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h: add __builtin_clear_padding in
__atomic_float constructor.
* testsuite/lib/dg-options.exp: add new add-options for libatomic_16b.
* testsuite/29_atomics/atomi
On Tue, 16 Jan 2024 at 15:39, Jonathan Wakely wrote:
>
> On Tue, 16 Jan 2024 at 14:07, Jonathan Wakely wrote:
> >
> > On 15/01/24 19:09 -0500, Patrick Palka wrote:
> > >> +friend _Iterator
> > >> +operator+(_Iterator __i, difference_type __n)
> > >
> > >constexpr?
> >
> > Fixed. I've added
v1 -> v2:
* Updated rtl for bclr, bset, insert and extract[u].
This patch series presents the comprehensive implementation of the BITMANIP
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing c
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
* common/config/
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cv-alu-fail-compile.c: Change warning to error.
---
.../gcc.target/riscv/cv-alu-fail-compile.c| 40 +--
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile.c
b/gc
This patch series presents the comprehensive implementation of the SIMD
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
However, your input, reviews, and suggestions are invaluable
On Thu, 4 Jan 2024 14:39:23 -0700, Jeff Law wrote:
> On 1/4/24 02:23, Mikael Pettersson wrote:
> > emit_library_call_value_1 calls emit_push_insn with NULL_TREE
> > for TYPE. Sometimes emit_push_insn needs to assign a temp with
> > that TYPE, which causes a segfault.
> >
> > Fixed by computing th
On Thu, 4 Jan 2024 14:39:23 -0700, Jeff Law wrote:
> On 1/4/24 02:23, Mikael Pettersson wrote:
> > emit_library_call_value_1 calls emit_push_insn with NULL_TREE
> > for TYPE. Sometimes emit_push_insn needs to assign a temp with
> > that TYPE, which causes a segfault.
> >
> > Fixed by computing th
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cv-alu-fail-compile.c: Change warning to error.
---
.../gcc.target/riscv/cv-alu-fail-compile.c| 40 +--
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/gcc/testsuite/gcc.target/riscv/cv-alu-fail-compile.c
b/gc
v2 -> v3:
* Removed duplicate ftype.
This patch series presents the comprehensive implementation of the SIMD
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
However, your input,
Hi Richard,
>> + rtx base = strip_offset_and_salt (XEXP (x, 1), &offset);
>
> This should be just strip_offset, so that we don't lose the salt
> during optimisation.
Fixed.
> +
> + if (offset.is_constant ())
> I'm not sure this is really required. Logically the same thing
> would app
Add support for -mcpu=cobalt-100 (Neoverse N2 with a different implementer ID).
Passes regress, OK for commit?
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def (AARCH64_CORE): Add 'cobalt-100' CPU.
* config/aarch64/aarch64-tune.md: Regenerated.
* doc/invoke.texi (-mcpu):
> -Original Message-
> From: Wilco Dijkstra
> Sent: Tuesday, January 16, 2024 5:23 PM
> To: GCC Patches
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; Richard Sandiford
>
> Subject: [PATCH] AArch64: Add -mcpu=cobalt-100
>
>
> Add support for -mcpu=cobalt-100 (Neoverse N2 with a differe
On Tue, 2024-01-16 at 11:13 +, Iain Sandoe wrote:
> tested on x86_64, i686 Darwin, x86_64 Linux,
> OK for trunk ? When ?
Thanks. LGTM for trunk; given that the impact is limited to just a jit
testcase I think this can go in now.
Dave
> thanks
> Iain
>
> --- 8< ---
>
> test-ggc-bugfix.c f
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
xfail all scan-tree-dump-times checks on hppa*64*-*-* in sra-17.c and sra-18.c
2024-01-16 John David Anglin
gcc/testsuite/ChangeLog:
PR tree-optimization/91624
* gcc.dg/tree-ssa/sra-17.c: xfail all scan-tree-dump-t
On Sat, 2024-01-13 at 13:57 +, Iain Sandoe wrote:
> Add a dg-require-alias to cover this.
Sorry about the breakage; LGTM for trunk.
Thanks
Dave
>
> gcc/testsuite/ChangeLog:
>
> * jit.dg/test-alias-attribute.c: Require target alias
> support.
>
> Signed-off-by: Iain Sandoe
On Sat, 2024-01-13 at 13:57 +, Iain Sandoe wrote:
> Darwin has a different .section directive that has more fields and
> uses different whitespace. Amend the whitespace in the scan-asm to
> be more flexible.
LGTM for trunk, assuming your testing was successful.
Thanks
Dave
>
> gcc/testsuit
On Sat, 2024-01-13 at 13:57 +, Iain Sandoe wrote:
> If we want to support multiple object formats and to allow for
> scan-assembler tests, we need to make it possible to adjust the
> tests on a per-target basis.
>
> This adds similar mechamisms to jit-verify-assembler-output{,-not}
> to those
On Sat, 2024-01-13 at 13:57 +, Iain Sandoe wrote:
> Several of the jit tests check for assembler-specific output
> which differs on Mach-O from ELF.
>
> This patch uses the facility to make the scans targer-dependent
> and adds handling for darwin.
Sorry about the issues with the tests.
Than
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Skip various cmp-mem-const tests on lp64 hppa*-*-*
Prior optimization already reduced the constant.
2024-01-16 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/cmp-mem-const-3.c: Skip on lp64 hppa*-*-*.
* gcc.d
Tested on hppa64-hp-hpux11.11 with lto disabled. Committed to trunk.
Dave
---
Require target lto in several tests
2024-01-16 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/c23-tag-alias-2.c: Require target lto.
* gcc.dg/c23-tag-alias-3.c: Likewise.
* gcc.dg/gnu
On 1/15/24 06:28, Andrew Carlotti wrote:
There's no functional change here, but it makes it clearer that all
three locations should be doing the same thing (aside from changes to
flag_abi_version).
OK.
gcc/cp/ChangeLog:
* mangle.cc (mangle_decl): Consistently use get_mangled_id.
di
> On Jan 15, 2024, at 4:31 AM, Richard Biener
> wrote:
>
>> All my questions for unshare_expr relate to a LTO bug that I currently
>> stuck with
>> when using .ACCESS_WITH_SIZE in bound sanitizer (only with -flto, without
>> -flto, no issue):
>>
>> [opc@qinzhao-aarch64-ol8 gcc]$ sh t
>> du
Tested on hppa64-hpux11.11. Committed to trunk.
Dave
---
xfail scan-tree-dump-not throw in g++.dg/pr99966.C on hppa*64*-*-*
2024-01-16 John David Anglin
gcc/testsuite/ChangeLog:
PR tree-optimization/110794
* g++.dg/pr99966.C: xfail scan-tree-dump-not throw on hppa*64*-*-*.
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Remove xfail for hppa*-*-hpux* from stdatomic-flag.c and stdatomic-flag-2.c
Tests now pass on hppa64-hp-hpux11.11.
2024-01-16 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/atomic/stdatomic-flag.c: Remove xfail.
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Add .data.rel.ro.local to read only sections in gcc.dg/array-quals-1.c
2024-01-16 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/array-quals-1.c: Add .data.rel.ro.local to read only
sections.
diff --git a/gcc
On 1/11/24 15:34, Dmitry Drozodv wrote:
You are absolutely right, we can't throw all side-effects away.
+ /* C++ [conv.lval]p3:
+If T is cv std::nullptr_t, the result is a null pointer constant. */
+ return ((TREE_SIDE_EFFECTS (expr) && !CONVERT_EXPR_P (expr))
+ ?
On 1/12/24 03:48, Jakub Jelinek wrote:
On Fri, Jan 12, 2024 at 07:40:19AM +, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
I'm still getting used to things so let me know if the change log
entries are excessive, thanks.
From 9dc168e7bcbbd7d515fa28cb9cae28ec
Tested aarch64-linux. I plan to push this to fix an error when using
trunk with Clang.
-- >8 --
We were relying on P1814R0 (CTAD for alias templates) which isn't
supported by Clang. We can just not use CTAD and provide an explicit
template argument list for _Utf32_view.
Ideally we'd define a ded
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we crash in maybe_retrofit_in_chrg on an invalid dtor
with explicit this. Such member functions do not get converted
to METHOD_TYPE. If a dtor gets parameters, we reset arg_types
to void_list_node in grokdeclarator. This
Tested x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Diagnostics should start with a lower-case letter.
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator) : Tweak diagnostic
messages.
---
gcc/cp/decl.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/cp/dec
RVV requires VSET?VL? instructions to dynamically configure VLEN at
runtime. There's a custom pass to do that which has a simple mode
which generates a VSETVL for each V insn and a lazy/optimal mode which
uses LCM dataflow to move VSETVL around, identify/delete the redundant
ones.
Currently simple
When staring at VSETVL pass for PR/113429, spotted some minor
improvements.
1. For readablity, remove some redundant condition check in Phase 2
function earliest_fuse_vsetvl_info ().
2. Add iteration count in debug prints in same function.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc
I thought I'd just missed the bug fixing season of stage3, but there
appears to a little latitude in early stage4 (for vector patches), so
I'll post this now.
This patch resolves PR target/106060 by providing efficient methods for
materializing/synthesizing special "vector" constants on x86. Cur
On 1/16/24 16:28, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Here we crash in maybe_retrofit_in_chrg on an invalid dtor
with explicit this. Such member functions do not get converted
to METHOD_TYPE. If a dtor gets parameters, we reset arg_
On 1/16/24 16:28, Marek Polacek wrote:
Tested x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Diagnostics should start with a lower-case letter.
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator) : Tweak diagnostic
messages.
---
gcc/cp/decl.cc | 6 +++---
1 file changed, 3 inse
The sign bit of a sign-extending load cannot be known until runtime,
so don't attempt to simplify it in the combiner.
2024-01-11 Greg McGary
PR rtl-optimization/113010
* combine.cc (expand_compound_operation): Don't simplify
SIGN_EXTEND of a MEM on WORD_REGISTER_OPERATI
LGTM.
juzhe.zh...@rivai.ai
From: Vineet Gupta
Date: 2024-01-17 05:41
To: gcc-patches; Robin Dapp; juzhe . zhong @ rivai . ai
CC: Jeff Law; kito.cheng; gnu-toolchain; Vineet Gupta
Subject: [PATCH v2] RISC-V: RVV: add toggle to control vsetvl pass behavior
RVV requires VSET?VL? instructions to d
LGTM.
juzhe.zh...@rivai.ai
From: Vineet Gupta
Date: 2024-01-17 05:41
To: gcc-patches; Robin Dapp; juzhe . zhong @ rivai . ai
CC: Jeff Law; kito.cheng; gnu-toolchain; Vineet Gupta
Subject: [PATCH] RISC-V: fix some vsetvl debug info in pass's Phase 2 code [NFC]
When staring at VSETVL pass for PR
On 1/10/24 04:22, Ken Matsui wrote:
+/* Return true if T is an integral type. With __STRICT_ANSI__, __int128 and
+ unsigned __int128 are not integral types. */
This really needs a rationale, since they are actually integer types. I
know __int128 is considered an extension rather than an e
On 1/10/24 04:22, Ken Matsui wrote:
+/* Return true if T is a floating point type. With __STRICT_ANSI__, __float128
+ is not a floating point type. However, _Float128 is a floating point type.
My comment about __is_integral again, but more so; if we support
_Float128, why not __float128?
On 1/10/24 04:23, Ken Matsui wrote:
This patch implements built-in trait for std::is_unsigned.
+case CPTK_IS_UNSIGNED:
+ return TYPE_UNSIGNED (type1);
This seems to lack the checks for arithmetic type that the __is_signed
patch has.
Jason
gcc/ChangeLog:
* doc/sourcebuild.texi: Add attributes for keywords.
---
gcc/doc/sourcebuild.texi | 20
1 file changed, 20 insertions(+)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 8082100a3c9..6c33237ac78 100644
--- a/gcc/doc/sourcebuild.te
Hi Juzhe,
I'm seeing that this patch introduces failures with rv32gcv-ilp32d as
seen here https://github.com/ewlu/gcc-precommit-ci/issues/1194. Digging
a little deeper, it appears that there's an illegal instruction in a
shared library which (at least for FAIL:
gcc.c-torture/execute/920501-8.
On Thu, Jan 11, 2024 at 10:24 AM Fangrui Song wrote:
>
> Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
> mangled name). Similar constraints are available in other targets (e.g.
> "S" for aarch64/riscv, "Cs" for m68k).
>
> There isn't a good way for x86 yet, e.g. "i" does
Are you saying using glibc lib ? I do the testing with newlib, I didn't
anything wrong.
It seems that this patch triggers latent bug of VSETVL PASS (Even though this
patch doesn't change anything related to VSETVL PASS).
I will investigate it.
Thanks.
juzhe.zh...@rivai.ai
From: Edwin Lu
D
On 1/16/2024 5:41 PM, juzhe.zh...@rivai.ai wrote:
Are you saying using glibc lib ? I do the testing with newlib, I didn't
anything wrong.
Yes, I'm seeing the problem using glibc. Looking at our postcommit ci
reports, it appears to only affect linux rv32gcv.
It seems that this patch triggers la
> Yes, I'm seeing the problem using glibc. Looking at our postcommit ci
> reports, it appears to only affect linux rv32gcv.
Just FYI. Double confirmed rv64gcv with glibc works well with this patch.
Pan
-Original Message-
From: Edwin Lu
Sent: Wednesday, January 17, 2024 9:45 AM
To: juz
On 1/15/24 02:22, Ilya Leoshkevich wrote:
Compile tested for the ia64-elf target; bootstrap and regtest running
on x86_64-redhat-linux. Ok for trunk when successful?
ia64-elf build fails with the following warning:
[all 2024-01-12 16:32:34] ../../gcc/gcc/config/ia64/ia64.cc:3889:59
On 1/15/24 19:04, HAO CHEN GUI wrote:
Hi,
This patch adds const0 move checking for CLEAR_BY_PIECES. The original
vec_duplicate handles duplicates of non-constant inputs. But 0 is a
constant. So even a platform doesn't support vec_duplicate, it could
still do clear by pieces if it supports c
gcc/Changelog
PR target/112973
* doc/extend.texi (BPF Built-in Functions): Wrap long lines and
give the section a light copy-editing pass.
---
gcc/doc/extend.texi | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/gc
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This compile-time and diagnostic improvement[1] is less important in
C++23 mode where deducing this is available and used in _Pipe, but for
benefit of C++20 mode and for consistency let's set the flag on the most
recently added
Similar to the previous change for , but since stl_pair.h is an
internal header we need to use the corresponding internal macro instead.
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h [__cplusplus > 202002L]:
Guard P2321R2 changes with __glibcxx_ranges_zip instead.
---
libstdc
Guard additions from P2321R2 zip with __cpp_lib_ranges_zip
instead of __cplusplus > 202020L.
libstdc++-v3/ChangeLog:
* include/std/tuple [__cplusplus > 202002L]: Guard P2321R2
changes with __cpp_lib_ranges_zip instead.
---
libstdc++-v3/include/std/tuple | 18 +-
On Wed, Jan 17, 2024 at 5:59 AM Roger Sayle wrote:
>
>
> I thought I'd just missed the bug fixing season of stage3, but there
> appears to a little latitude in early stage4 (for vector patches), so
> I'll post this now.
>
> This patch resolves PR target/106060 by providing efficient methods for
>
1 - 100 of 118 matches
Mail list logo
