On Wed, 19 Mar 2025, James K. Lowden wrote:
> On Wed, 19 Mar 2025 15:24:19 +0100 (CET)
> Richard Biener wrote:
>
> > The following removes HOWEVER_GCC_DEFINES_TREE and the alternate
> > definition of tree from symbols.h and instead ensures that both
> > coretypes.h and tree.h are included where
On Fri, 21 Mar 2025, Jakub Jelinek wrote:
> On Wed, Mar 19, 2025 at 06:03:24PM -0400, James K. Lowden wrote:
> > Elsewhere in the parser where there was a conflict like that, I renamed
> > the token. For example, the COBOL word TRUE uses a token named
> > TRUE_kw. I don't mind either way; your s
On Tue, Mar 25, 2025 at 10:59 PM Richard Biener
wrote:
>
>
>
> > Am 26.03.2025 um 04:47 schrieb Andrew Pinski :
> >
> > This adds a simple verification so that the LHS of an assignment is
> > not a function decl. SRA and FRE will produce an ICE for this anyways
> > so let's catch it earlier. Thi
On Tue, Mar 25, 2025 at 07:00:34PM -0500, Peter Bergner wrote:
> On 3/25/25 5:17 PM, Segher Boessenkool wrote:
> > On Tue, Mar 25, 2025 at 03:33:59PM -0500, Peter Bergner wrote:
> >> Segher, any reason you can give on why we shouldn't go the easy route to
> >> "fix" (yes, these are air-quotes) this
Hi everyone,
This is our the third patchset in the series for updating upstream GCC
with the latest changes in our development repository.
Most notably this contains handling for if-let statements by Marc
Poulhiès, changes to our name-resolution pass rewrite, and massive
changes to our AST and HI
> Am 26.03.2025 um 04:47 schrieb Andrew Pinski :
>
> This adds a simple verification so that the LHS of an assignment is
> not a function decl. SRA and FRE will produce an ICE for this anyways
> so let's catch it earlier. This showed up because the fortran front-end
> didn't translate the fun
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, March 25, 2025 19:49
> To: Robert Dubner ; James K. Lowden
> ; Richard Biener
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] cobol: Get rid of __int128 uses in the COBOL FE
> [PR119242]
>
> Hi!
>
> The following patch changes
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, March 25, 2025 19:49
> To: Robert Dubner ; James K. Lowden
> ; Richard Biener
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] cobol: Get rid of __int128 uses in the COBOL FE
> [PR119242]
>
> Hi!
>
> The following patch chan
This adds a simple verification so that the LHS of an assignment is
not a function decl. SRA and FRE will produce an ICE for this anyways
so let's catch it earlier. This showed up because the fortran front-end
didn't translate the function name into the result decl in some cases.
Bootstrapped and
On 3/25/25 1:42 AM, jeevitha wrote:
> gcc/testsuite/
> PR testsuite/119382
> * gcc.target/powerpc/vsx-builtin-7.c: Add '-fno-ipa-icf' to dg-options.
>
> diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
> b/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
> index 5095d5030
From: Arthur Cohen
gcc/rust/ChangeLog:
* hir/tree/rust-hir.h: Add override qualifier to overriden method.
---
gcc/rust/hir/tree/rust-hir.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/rust/hir/tree/rust-hir.h b/gcc/rust/hir/tree/rust-hir.h
index 8ce5cf4d102..8
On Tue, Mar 25, 2025 at 7:55 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch is miscompiled from r15-8478 but latently already
> since my r11-5756 and r11-6631 changes.
> The r11-5756 change was
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561164.html
> which changed the split
From: Raiki Tamura
gcc/rust/ChangeLog:
* hir/tree/rust-hir.cc (Item::item_kind_string): New function.
* hir/tree/rust-hir.h: New function.
* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit):
Modify to check all arms in match expressions even if
Hi, all
This patch aims to ensure each alternative with constraint "jm" should
set addr "gpr16", otherwise maybe raise ICE in reload pass.
Bootstrapped and Regtested for x86_64-pc-linux-gnu{-m32,-m64}, ok for trunk?
BRs,
Lin
gcc/ChangeLog:
PR target/119425
* config/i386/sse.md:
> -Original Message-
> From: Hu, Lin1
> Sent: Tuesday, March 25, 2025 4:23 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: RE: [PATCH v2] i386: Add "s_" as Saturation for AVX10.2 Converting
> Intrinsics.
>
> More details: Alignment with llvm (https://
On 3/25/25 5:17 PM, Segher Boessenkool wrote:
> On Tue, Mar 25, 2025 at 03:33:59PM -0500, Peter Bergner wrote:
>> Segher, any reason you can give on why we shouldn't go the easy route to
>> "fix" (yes, these are air-quotes) this by using -fno-ipa-icf?
>
> One reason is that that option should not
The arm multilib configuration includes two more parameters which
affect multilib selection, marm/mthumb and mfloat-abi. Without those,
the default multilib selection is mis-specified and the only reason it
works is because '.' is the fall-back path.
Add "marm" and "mfloat-abi=soft" to MULTILIB_DE
Override other optimization settings with any -Os or -Oz found in CC
or CFLAGS.
Signed-off-by: Keith Packard
---
libgcc/Makefile.in | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 0719fd0615d..a157e28cbb7 100644
--- a/l
This option adds a per-multilib variant that specifies -Os
instead of the default.
Signed-off-by: Keith Packard
---
config-ml.in | 2 +-
gcc/Makefile.in | 32 +++-
gcc/configure| 13 +
gcc/configure.ac | 7 +++
gcc/doc/instal
Embedded toolchains face conflicting requirements from different
customers. Some need the best possible speed while others are tightly
size constrained. To avoid having every toolchain user need to
re-compile all libraries, it's convenient to add -Os/-Oz as an
additional multilib selector so that p
Hi!
The following patch changes some remaining __int128 uses in the FE
into FIXED_WIDE_INT(128), i.e. emulated 128-bit integral type.
The use of wide_int_to_tree directly from that rather than going through
build_int_cst_type means we don't throw away the upper 64 bits of the
values, so the emitti
On 3/25/25 3:34 AM, Jakub Jelinek wrote:
Hi!
As discussed here and in bugzilla, [[clang::musttail]] attribute in clang
not just strongly asks for tail call or error, but changes behavior.
To quote:
https://clang.llvm.org/docs/AttributeReference.html#musttail
"The lifetimes of all local variables
On 3/25/25 10:59, Tobias Burnus wrote:
Updated patch:
+Available properties for an HIP interop object:
+
+@multitable @columnfractions .20 .35 .20 .20
+@headitem Property @tab C data type @tab API routine @tab
value (if constant)
+@item @code{fr_id} @tab @code{om
On Tue, Mar 25, 2025 at 03:33:59PM -0500, Peter Bergner wrote:
> On 3/25/25 1:42 AM, jeevitha wrote:
> > gcc/testsuite/
> > PR testsuite/119382
> > * gcc.target/powerpc/vsx-builtin-7.c: Add '-fno-ipa-icf' to dg-options.
> >
> > diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
On Tue, Mar 25, 2025 at 12:40 PM Jonathan Wakely wrote:
> Unlike insert_range and assign_range, the append_range function does not
> have a precondition that the range doesn't overlap *this. That means we
> need to avoid relocating the existing elements until after copying from
> the range. This
On 24/03/2025 21:17, Sandra Loosemore wrote:
On 3/24/25 08:20, Paul-Antoine Arras wrote:
On 21/03/2025 20:17, Sandra Loosemore wrote:
Does the attached patch reflect what you have in mind?
diff --git libgomp/libgomp_g.h libgomp/libgomp_g.h
index 8993ec610fb..274f4937680 100644
--- libgomp/libgo
> The imov and imovx classified stores miss reservations in the znver4/5
> pipeline description. The following adds them.
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
>
> OK?
>
> PR target/119010
> * config/i386/zn4zn5.md (znver4_imov_double_store,
> znver5_i
And as an addendum: Special thanks to Richard Biener and Jakub Jelinek
for all their work on this, and to the community in general for the
generous advice and support.
I can honestly say I have never worked in this kind of paradigm, and it's
been a remarkable experince, and really kind of fun.
(
I am putting up this e-mail for the record. I asked myself if it was
"okay for trunk?", and myself answered "If it's not, I quit!"
When merged into the cobolworx test environment, all of our tests pass.
When merged into master, the results compile, and check-cobol, such as
it is, succeeds.
I ju
Hi,
On Tue Mar 25, 2025 at 6:52 PM CET, Jason Merrill wrote:
> On 3/25/25 1:50 PM, Marek Polacek wrote:
>> On Tue, Mar 25, 2025 at 05:18:23PM +, Simon Martin wrote:
>>> We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I
>>> did not go compile something that old, and identi
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
Since r15-8011 cp_build_indirect_ref_1 won't do the *&TARGET_EXPR ->
TARGET_EXPR folding not to change its value category. That fix is
correct but it made us stop extending the lifetime in this testcase,
causing a wrong-code
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Fixed recently by r15-7822.
PR c++/101881
gcc/testsuite/ChangeLog:
* g++.dg/ext/vector44.C: New test.
---
gcc/testsuite/g++.dg/ext/vector44.C | 5 +
1 file changed, 5 insertions(+)
create mode 100644 gcc/testsuite/g++
On Tue, 25 Mar 2025 at 17:31, Tomasz Kaminski wrote:
> I have checked that _M_range_initialize is called only from constructors,
> or _M_initialize_dispatch, that is directly called in the constructor.
> So guards indeed seem to be redundant.
>
> Please add this to the comment message, and otherwi
On 3/25/25 11:43 AM, yxj-github-437 wrote:
This patch would like to avoid the ICE when template lambdas call with
default parameters in unevaluated context. The bug is the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119385. For example as blow:
1 | template
2 | void foo
On Tue, Mar 25, 2025 at 05:48:57PM +, Iain Sandoe wrote:
> Tested on x86_64, aarch64-linux and x86_64-darwin, verified that there
> is no change in the libquadmath build on the platforms that do not need
> it. OK for trunk?
> thanks
> Iain
>
> --- 8< ---
>
> For the configuration of libgcobo
LWG 3291 make std::ranges::iota_view's iterator have input_iterator_tag
as its iterator_category, even though it satisfies the C++20
std::forward_iterator concept. This means that the traditional
std::vector::vector(InputIterator, InputIterator) constructor treats
iota_view iterators as input itera
> This can be rewritten as
>
> void foo(int v)
> {
> {
> int a;
> capture(&a);
> if (condition)
> goto tail_position;
> // do something with a
> }
> tail_position:
> tailcall(v);
> }
>
> or with 'do { ... if (...) break; ...} while (0)' when one prefers that to
> goto
On 3/25/25 09:25, Paul-Antoine Arras wrote:
On 24/03/2025 21:17, Sandra Loosemore wrote:
[snip]
I think you also need to update BUILT_IN_GOMP_INTEROP in omp-
builtins.def; at least, that is the source of the decl used for the
implicit creation/destruction of interop objects in "declare varian
On Tue, Mar 25, 2025 at 05:18:23PM +, Simon Martin wrote:
> We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I
> did not go compile something that old, and identified this change via
> git blame, so might be wrong)
>
> === cut here ===
> struct Foo { int x; };
> Foo& get (
Hello Harald,
OK with the above addressed.
Both addressed and pushed in
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=737a5760bb24a0a945cc2c916ba452e3f0060c58
Thanks for the review (and for catching the miscellaneous
problems on the way)!
Best regards
Thomas
On 3/25/25 1:18 PM, Simon Martin wrote:
We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I
did not go compile something that old, and identified this change via
git blame, so might be wrong)
=== cut here ===
struct Foo { int x; };
Foo& get (Foo &v) { return v; }
void bar ()
On Tue, Mar 25, 2025 at 07:43:28PM +0300, Alexander Monakov wrote:
> Hello,
>
> FWIW I think Clang made a mistake in bending semantics in a way that is
> clearly
> misaligned with the general design of C and C++, where a language-native, so
> to
> speak, solution was available: introduce a scope
On Tue, Mar 25, 2025 at 07:43:28PM +0300, Alexander Monakov wrote:
> FWIW I think Clang made a mistake in bending semantics in a way that is
> clearly
> misaligned with the general design of C and C++, where a language-native, so
> to
> speak, solution was available: introduce a scope for the loc
On Tue, Mar 25, 2025 at 6:20 PM Jonathan Wakely wrote:
> On Tue, 25 Mar 2025 at 16:49, Tomasz Kaminski wrote:
> >
> >
> >
> > On Tue, Mar 25, 2025 at 5:30 PM Jonathan Wakely
> wrote:
> >>
> >> LWG 3291 make std::ranges::iota_view's iterator have input_iterator_tag
> >> as its iterator_category,
On Tue, 25 Mar 2025 at 16:49, Tomasz Kaminski wrote:
>
>
>
> On Tue, Mar 25, 2025 at 5:30 PM Jonathan Wakely wrote:
>>
>> LWG 3291 make std::ranges::iota_view's iterator have input_iterator_tag
>> as its iterator_category, even though it satisfies the C++20
>> std::forward_iterator concept. This
From: Pierre-Emmanuel Patry
gcc/testsuite/ChangeLog:
* rust/compile/macro-delim.rs: Move to...
* rust/compile/macros/mbe/macro-delim.rs: ...here.
* rust/compile/macro-issue1053-2.rs: Move to...
* rust/compile/macros/mbe/macro-issue1053-2.rs: ...here.
* rus
It seems the new expander triggers a latent issue in sched1 causing
extraneous spills in a different sad variant.
Given how close we are to gcc-15 release, disable it for now.
Since we do want to retain and re-enable this capabilty, manully disable
vs. reverting the orig patch which takes away the
Updated patch:
* I noticed that the API functions in omp.h.in (and since OpenMP 6.0)
take omp_interop_rc_t* not int*.
Thus, I updated it to match omp.h.in. Unfortunately, the difference
matters for C++; the enum itself is available already in 5.1 and C does
not care.
* I now use -- as sugg
This is on top of the C++-ify configure and random_r patches.
Tested on x86_64,aarch64-Linux and x86_64-darwin, OK for trunk?
thanks
Iain
--- 8< ---
strfrom{f,d,l,fN) are all C23 and might not be available in general.
This uses snprintf() to provide fall-backs where the libc does not
yet have su
Hello,
FWIW I think Clang made a mistake in bending semantics in a way that is clearly
misaligned with the general design of C and C++, where a language-native, so to
speak, solution was available: introduce a scope for the local variables to
indicate that they cannot escape to the intended tailca
These tests need access to the MRC instruction, but that isn't part of
of the Thumb1 ISA. So skip the tests when this isn't the case.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mtp_1.c: Require arm32.
* gcc.target/arm/mtp_2.c: Likewise.
* gcc.target/arm/mtp_3.c: Likewise.
On Tue, Mar 25, 2025 at 1:43 PM Jonathan Wakely wrote:
> LWG 4229 points out that the std::ranges::to wording refers to class
> types, but I added an assertion using std::is_class_v which only allows
> non-union class types. LWG consensus is that unions should be allowed,
> so this additionally u
> Am 25.03.2025 um 16:22 schrieb Jan Hubicka :
>
>
>>
>>> On Tue, 25 Mar 2025, Richard Biener wrote:
>>>
>>> The following resolves missing reservations for DFmode *movdf_internal
>>> loads and stores, visible as 'nothing' in -fsched-verbose=2 dumps.
>>>
>>> Bootstrap and regtest running o
On Tue, 25 Mar 2025 at 15:53, Tomasz Kamiński wrote:
>
> This is another piece of P1206R7, adding from_range constructor, append_range,
> prepend_range, insert_range, and assign_range members to std::deque.
>
> For append_front of input non-sized range, we are emplacing element at the
> front and
The ftest-*.c tests for Arm check certain ACLE mandated macros to ensure
they are correctly defined based on the selected architecture. ACLE
states that the macro should be defined if the operation exists in
the hardware, but it doesn't have to exist in the current ISA because
and interworking cal
Sandra Loosemore wrote:
On 3/23/25 14:28, Tobias Burnus wrote:
Thus, please useGOMP_DEVICE_DEFAULT_OMP_61 for: […]
Done.
(B) prefer_type & Fortran […]
This turned out to be an accidental redefinition of a variable that
shadowed one of the same name in an outer scope. I added a simplified
v
On 3/23/25 14:28, Tobias Burnus wrote:
[snip]
Thus, please useGOMP_DEVICE_DEFAULT_OMP_61 for:
+ if (dispatch_device_num == NULL_TREE)
+ /* Not remapping device number. */
+ dispatch_device_num = build_int_cst (integer_type_node,
+ GOMP_DEVICE_ICV);
Hi,
On Thu Mar 6, 2025 at 10:15 AM CET, Simon Martin wrote:
> On Wed Mar 5, 2025 at 10:32 PM CET, Jason Merrill wrote:
>> On 3/5/25 6:58 AM, Simon Martin wrote:
>>> Hi Jason,
>>>
>>> On Tue Mar 4, 2025 at 11:47 PM CET, Jason Merrill wrote:
On 2/14/25 12:08 PM, Simon Martin wrote:
> We ha
Sandra Loosemore wrote:
I find the part about the "associated named constant" really
confusing; I am not sure those are for property identifiers or
property values. Can you give an example, or actually list the named
constants individually?
Well, the property is called 'dev_num'; the identif
>> This patch would like to avoid the ICE when template lambdas call with
>> default parameters in unevaluated context. The bug is the same as
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119385. For example as blow:
>>
>> 1 | template
>> 2 | void foo(T x) {
>> 3 | sizeo
On Tue, Mar 25, 2025 at 08:33:41AM -0700, Andi Kleen wrote:
> > 2025-03-25 Jakub Jelinek
> > Andi Kleen
> >
> > PR gcov-profile/118442
> > * profile.cc (branch_prob): Ignore EDGE_FAKE edges from musttail calls
> > to EXIT.
> >
> > * c-c++-common/pr118442.c: New test.
On 25/03/25 13:30 +0100, Tomasz Kamiński wrote:
This is another piece of P1206R7, adding from_range constructor, append_range,
prepend_range, insert_range, and assign_range members to std::deque.
For append_front of input non-sized range, we are emplacing element at the
front and
then reverse i
> 2025-03-25 Jakub Jelinek
> Andi Kleen
>
> PR gcov-profile/118442
> * profile.cc (branch_prob): Ignore EDGE_FAKE edges from musttail calls
> to EXIT.
>
> * c-c++-common/pr118442.c: New test.
>
> --- gcc/profile.cc.jj 2025-01-02 11:23:16.458517673 +0100
> +
On Tue, Mar 25, 2025 at 11:06:05AM -0400, Jason Merrill wrote:
> > The patch introduces 2 new warnings.
> > -Wmusttail-local-addr
> > which is turn on by default and warns for the always dumb cases of passing
> > an address of a local variable or parameter to musttail call's argument.
>
> I don't
> On Tue, 25 Mar 2025, Richard Biener wrote:
>
> > The following resolves missing reservations for DFmode *movdf_internal
> > loads and stores, visible as 'nothing' in -fsched-verbose=2 dumps.
> >
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> The alternative for the larger s
> The imov and imovx classified stores miss reservations in the znver4/5
> pipeline description. The following adds them.
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
>
> OK?
>
> PR target/119010
> * config/i386/zn4zn5.md (znver4_imov_double_store,
> znver5_i
Hi,
On Tue, Mar 25 2025, Sam James wrote:
> r15-7961-gdc47161c1f32c3 fixes a typo in ao_compare::compare_ao_refs
> but there wasn't a testcase available at the time. Now there is.
>
> Thanks to Andrew for the testcase.
>
> gcc/testsuite/ChangeLog:
> PR testsuite/119382
>
> * gcc.dg/ipa
On 3/25/25 8:24 AM, Richard Biener wrote:
The following resolves missing reservations for DFmode *movdf_internal
loads and stores, visible as 'nothing' in -fsched-verbose=2 dumps.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR target/119010
* config/i386/zn4zn5
On 3/25/25 05:12, Tobias Burnus wrote:
On August 24, 2024 Tobias Burnus wrote:
[...] it documents the code added at "[patch][rfc] libgomp: Add OpenMP
interop support to nvptx + gcn plugin",
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661207.html
Quite some time has passed and those
On 3/25/25 00:45, Robin Dapp wrote:
>> - "TARGET_VECTOR"
>> + "TARGET_VECTOR && 0"
> Would you mind adding a comment here before committing, maybe even reference
> the PR? Not that we want to keep this around for long anyway but just to
> make
> sure :)
Of course, I pondered the same but the
On 3/25/25 8:04 AM, Yangyu Chen wrote:
On 25/3/2025 21:23, Kito Cheng wrote:
Will it only cause issues with this patch
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678918.html
Yes. But I think we can merge this first.
But if this patch doesn't fix a regression or possibly a correc
zve32x_zvl64b will have the same requirement as zve32x_zvl32b,
I mean e16,mf4 could be allowed on zve32x_zvl64b, but it also spec
conformance
if implementation decides to raise an illegal instruction on e16,mf4, which
means
e16,mf4 is not safe to use on zve32x/zve32f.
OK I see, thanks. Sometime
I patched this in on top of all the other patches. It passes what Jim has
called the "Bob CI/CD pipeline".
Jim is finalizing his changes.
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, March 25, 2025 05:51
> To: gcc-patches@gcc.gnu.org
> Cc: rdub...@symas.com; Jakub Jeline
On Tue, 25 Mar 2025, Richard Biener wrote:
> The following resolves missing reservations for DFmode *movdf_internal
> loads and stores, visible as 'nothing' in -fsched-verbose=2 dumps.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
The alternative for the larger scale problem of
The imov and imovx classified stores miss reservations in the znver4/5
pipeline description. The following adds them.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
OK?
PR target/119010
* config/i386/zn4zn5.md (znver4_imov_double_store,
znver5_imov_double_sto
On 3/25/25 10:17 AM, yxj-github-437 wrote:
This patch would like to avoid the ICE when template lambdas call with
default parameters in unevaluated context. For example as blow:
1 │ template
2 │ void foo(T x) {
3 │ sizeof [](T=x) { return 0; }();
4 │ }
5
>> This patch would like to avoid the ICE when template lambdas call with
>> default parameters in unevaluated context. For example as blow:
>>
>> 1 │ template
>> 2 │ void foo(T x) {
>> 3 │ sizeof [](T=x) { return 0; }();
>> 4 │ }
>> 5 │
>> 6 │ void test
On 25/3/2025 21:23, Kito Cheng wrote:
Will it only cause issues with this patch
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678918.html
Yes. But I think we can merge this first.
Thanks,
Yangyu Chen
or will it cause problems with the current trunk as well?
If the latter one, coul
As the primary LTO file in this test, it cannot use dg-options. Move
the flags from there to dg-lto-options.
gcc/testsuite/ChangeLog:
* gcc.target/arm/lto/pr96939_0.c (dg-options): Delete. Move the
options from here ...
(dg-lto-options): ... to here.
---
gcc/testsuite/
When expanding to RTL we always use vec_perm_indices with two operands
which can make a difference with respect to supported vs. unsupported.
So the following adjusts a query in match.pd for target support which
got this "wrong" and using 1 for a equal operand permute.
Bootstrapped on x86_64-unkno
Similar to r15-4930-gd56d2f3102ada3, update the branch operations when not
using CBN?Z for inverting the direction of the branch operations.
gcc/testsuite/ChangeLog:
* gcc.target/arm/vect-early-break-cbranch.c: Allow BEQ as well as BNE.
---
.../gcc.target/arm/vect-early-break-cbranch.c
On 3/25/25 9:17 AM, Thomas Schwinge wrote:
Hi!
On 2025-03-24T13:38:56-0400, Jason Merrill wrote:
On 3/24/25 7:02 AM, Thomas Schwinge wrote:
On 2025-03-21T15:46:01+0100, I wrote:
On 2025-03-19T14:25:49+, Jonathan Wakely wrote:
On Wed, 19 Mar 2025 at 14:21, Marek Polacek wrote:
On Wed,
This test has missing prototypes. To avoid disturbing the test, use gnu17.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr65647.c (dg-options): Add -std=gnu17.
---
gcc/testsuite/gcc.target/arm/pr65647.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.t
Will it only cause issues with this patch
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678918.html
or will it cause problems with the current trunk as well?
If the latter one, could you provide a case for that?
Thanks :)
On Tue, Mar 25, 2025 at 7:15 PM Yangyu Chen wrote:
>
> We don't ne
Hi Robin
Sorry Kito, that we're having so much back and forth here, it's not my
> intention to block anything (not that I could anyway). I just want to
> make sure I properly understand the rationale (or the spec, rather).
>
No worries, it's a great chance to clarify the spec together :)
Some t
Hi!
On 2025-03-24T13:38:56-0400, Jason Merrill wrote:
> On 3/24/25 7:02 AM, Thomas Schwinge wrote:
>> On 2025-03-21T15:46:01+0100, I wrote:
>>> On 2025-03-19T14:25:49+, Jonathan Wakely wrote:
On Wed, 19 Mar 2025 at 14:21, Marek Polacek wrote:
> On Wed, Mar 19, 2025 at 12:38:31PM +0
On Mon, 24 Mar 2025 at 16:13, Richard Earnshaw (lists)
wrote:
>
> On 24/03/2025 14:52, Christophe Lyon wrote:
> > On Mon, 24 Mar 2025 at 15:13, Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 21/03/2025 17:30, Christophe Lyon wrote:
> >>> On Fri, 21 Mar 2025 at 16:51, Richard Earnshaw (lists)
>
This is another piece of P1206R7, adding from_range constructor, append_range,
prepend_range, insert_range, and assign_range members to std::deque.
For append_front of input non-sized range, we are emplacing element at the
front and
then reverse inserted elements. This does not existing elements,
On 25/03/2025 12:05, Tobias Burnus wrote:
A GCC 15 regression turned out to be a bug in Newlib related to
undefined behavior that just started to trigger in some cases.
As it is now fixed, it makes IMHO sense to mention that Newlib
commit in GCC's install documentation for AMD GPUs.
Comments, s
LWG 4229 points out that the std::ranges::to wording refers to class
types, but I added an assertion using std::is_class_v which only allows
non-union class types. LWG consensus is that unions should be allowed,
so this additionally uses std::is_union_v.
libstdc++-v3/ChangeLog:
* include/
From: Philip Herron
gcc/rust/ChangeLog:
* hir/rust-hir-dump.cc (Dump::visit): add guards
Signed-off-by: Philip Herron
---
gcc/rust/hir/rust-hir-dump.cc | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/gcc/rust/hir/rust-hir-dump.cc b/gcc/rust/hir/rust-hi
This was fixed last year by r15-2409-g017e3f89b081e4 (and backports), so
just add the testcase.
libstdc++-v3/ChangeLog:
PR libstdc++/118699
* testsuite/27_io/filesystem/operations/copy.cc: Check copying a
file to a directory.
---
Tested x86_64-linux and x86_64-mingw-w64.
A GCC 15 regression turned out to be a bug in Newlib related to
undefined behavior that just started to trigger in some cases.
As it is now fixed, it makes IMHO sense to mention that Newlib
commit in GCC's install documentation for AMD GPUs.
Comments, suggestions to the attached patch?
Tobias
On Tue, Mar 25, 2025 at 12:26 PM Jonathan Wakely wrote:
> The new C++23 member functions assign_range, insert_range and
> append_range were checking whether the begin() iterator changed after
> calling the base class member. That works, but is technically undefined
> when the original iterator ha
Unlike insert_range and assign_range, the append_range function does not
have a precondition that the range doesn't overlap *this. That means we
need to avoid relocating the existing elements until after copying from
the range. This means I need to revert r15-8488-g3e1d760bf49d0e which
made the fro
On 11/03/25 17:39 +, Jonathan Wakely wrote:
Add anchors for the hardbool and uninitialized attributes and then link
directly to them.
gcc/ChangeLog:
* doc/extend.texi (Common Variable Attributes): Add @anchor to
hardbool attribute.
(Common Type Attributes): Add @anch
The new C++23 member functions assign_range, insert_range and
append_range were checking whether the begin() iterator changed after
calling the base class member. That works, but is technically undefined
when the original iterator has been invalidated by a change in capacity.
We can just check the
On August 24, 2024 Tobias Burnus wrote:
[...] it documents the code added at "[patch][rfc] libgomp: Add OpenMP
interop support to nvptx + gcn plugin",
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661207.html
Quite some time has passed and those features are now on mainline.
The attac
We don't need to add priority in ASM name mangling, keeping this might
cause an issue if we call another MV clone directly but only one place
has the priority declared.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_mangle_decl_assembler_name): Remove
priority in fmv asm name mangl
This avoids a runtime error from Clang's annoying -fsanitize=integer
(even though it's not undefined and behaves correctly).
libstdc++-v3/ChangeLog:
PR libstdc++/119429
* include/std/format (__format::_Scanner::_Scanner): Cast
default argument to size_t.
---
Tested x86_64
1 - 100 of 120 matches
Mail list logo
