Greg McGary 于2024年1月17日周三 06:20写道：
>
> 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
>
On Thu, Jan 11, 2024 at 7:24 PM 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"
On Wed, 17 Jan 2024 at 02:41, Patrick Palka wrote:
>
> Similar to the previous change for , but since stl_pair.h is an
> internal header we need to use the corresponding internal macro instead.
OK thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_pair.h [__cplusplus > 202002L]:
On Wed, 17 Jan 2024 at 02:40, Patrick Palka wrote:
>
> Guard additions from P2321R2 zip with __cpp_lib_ranges_zip
> instead of __cplusplus > 202020L.
Ah yes, I should have changed all of these in r14-7225-gf8a5298c97c460
OK for trunk, thanks.
>
> libstdc++-v3/ChangeLog:
>
> *
On Wed, 17 Jan 2024 at 00:31, Jason Merrill wrote:
>
> 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
> On Jan 17, 2024, at 10:51, Richard Biener wrote:
>
> On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
>>
>>
>>
>> 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
On Wed, 17 Jan 2024, 02:37 Patrick Palka, wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
OK
> -- >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
on 2024/1/16 06:22, Ajit Agarwal wrote:
> Hello Richard:
>
> On 15/01/24 6:25 pm, Ajit Agarwal wrote:
>>
>>
>> On 15/01/24 6:14 pm, Ajit Agarwal wrote:
>>> Hello Richard:
>>>
>>> On 15/01/24 3:03 pm, Richard Biener wrote:
On Sun, Jan 14, 2024 at 4:29 PM Ajit Agarwal
wrote:
>
>
On Tue, Jan 16, 2024 at 4:00 PM Iain Sandoe wrote:
>
> Tested on x86_64 Darwin, x86_64 Linux.
> OK for trunk? When?
OK now.
> 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
On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
>
>
>
> 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.
On Tue, Jan 16, 2024 at 11:20 PM Greg McGary wrote:
>
> The sign bit of a sign-extending load cannot be known until runtime,
> so don't attempt to simplify it in the combiner.
It feels like this papers over an issue downstream?
> 2024-01-11 Greg McGary
>
> PR rtl-optimization/113010
On Wed, Jan 17, 2024 at 7:42 AM Richard Biener
wrote:
>
> On Tue, Jan 16, 2024 at 9:26 PM Qing Zhao wrote:
> >
> >
> >
> > > 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
> > >>
On Tue, Jan 16, 2024 at 9:26 PM Qing Zhao wrote:
>
>
>
> > 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
>
On Mon, Jan 15, 2024 at 06:10:55PM -0500, Jason Merrill wrote:
> Under what circumstances does it make sense for CLASSTYPE_INTERFACE_ONLY to
> be set in the context of modules, anyway? We probably want to propagate it
> for things in the global module so that various libstdc++ explicit
>
These options were categorized as C++ options, but they apply to all
C-family languages.
gcc/ChangeLog
PR c/111693
* doc/invoke.texi (Option Summary): Move -Wuseless-cast
from C++ Language Options to Warning Options. Add entry for
-Wuse-after-free.
(C++
Huanghui Nie writes:
> Hi.
Please CC the libstdc++ LM for libstdc++ patches, per
https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html#list.patches.
> [...]
Hi.
When I implemented a hash table with reference to the C++ STL, I found that
when the hash table in the C++ STL deletes elements, if the first element
deleted is the begin element, the before begin node is repeatedly assigned.
This creates unnecessary performance overhead.
First, let’s see
So the problem here is that aarch64_ldp_reg_operand will all subreg even subreg
of lo_sum.
When LRA tries to fix that up, all things break. So the fix is to change the
check to only
allow reg and subreg of regs.
Note the tendancy here is to use register_operand but that checks the mode of
the
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
>
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 +-
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.
---
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
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
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
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]
> 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:
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
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
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"
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/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
---
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
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: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
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
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
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
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
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
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.
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:
*
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
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
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.
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
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
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))
+ ?
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
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-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*-*-*.
> 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
>>
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.
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.
*
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*-*-*.
*
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.
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:
> 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
>
>
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
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
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
> -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
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
Hi Richard,
>> + rtx base = strip_offset_and_salt (XEXP (x, 1), );
>
> 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 apply to
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,
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
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
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
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
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
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:
*
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
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
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.
*
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
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
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,
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
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:
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 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
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
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
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
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,
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 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
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/
*
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:
*
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
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
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
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
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
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 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 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.
>
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.
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:
*
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
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
1 - 100 of 118 matches
Mail list logo
