I intent to commit this a bit later today as obvious,
unless there are comments.
This is about two functions unconditionally return 'true'.
Both appear (also) in an 'if' condition that is pointless.
(The second one also appears in two other calls without an
'if', so far for consistency.)
Beside
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
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
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
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
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, 25 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcases FAIL because musttail failures are diagnosed
> not just in the tailc or musttail passes, but also during the tailr1
> and tailr2.
> tailr1 pass is before IPA and in the testcases eh cleanup has not
> cleaned up the IL suf
Modify ChangeLog.
This patch aims to add "s_" after 'cvt' represent saturation.
gcc/ChangeLog:
* config/i386/avx10_2-512convertintrin.h (_mm512_mask_cvtx2ps_ph):
Formatting fixes
(_mm512_mask_cvtx_round2ps_ph): Ditto
(_mm512_maskz_cvtx_round2ps_ph): Ditto
(_mm512
The following removes uses of strtof128 which are all in some way
verifying something parses as _Float128 but which lexing should
have guarnateed.
Tested on x86_64-unknown-linux-gnu.
Richard.
gcc/cobol/
* parse.y (intrinsic): Remove checking that $r1->field->data.initial
parses a
On Mon, Mar 24, 2025 at 9:54 AM Iain Sandoe wrote:
>
> Currently, we misconfigure GCC on POSIX platforms that require the
> inclusion of to declare 'basename()'.
>
> The series here does the following:
> - ensures that the libiberty configure caters for platforms that need
> (it does not alt
On Tue, Mar 25, 2025 at 11:02:39AM +0100, Richard Biener wrote:
> On Mon, Mar 24, 2025 at 9:54 AM Iain Sandoe wrote:
> >
> > Currently, we misconfigure GCC on POSIX platforms that require the
> > inclusion of to declare 'basename()'.
> >
> > The series here does the following:
> > - ensures that
Hi, all
This patch aims to add "s_" after 'cvt' represent saturation.
Bootstrapped and regtested on x86_64-linux-gnu-{-m32,-m64}, OK for trunk?
BRs,
Lin
gcc/ChangeLog:
* config/i386/avx10_2-512convertintrin.h: Modify intrin name.
* config/i386/avx10_2convertintrin.h: Ditto.
gc
On Mon, 24 Mar 2025, Jakub Jelinek wrote:
> On Mon, Mar 24, 2025 at 10:55:44PM +0100, Jakub Jelinek wrote:
> > If it was HOST_WIDE_INT_MAX + (size_t) 1 to ~(size_t) 0, previously it would
> > be false and now is false.
>
> Sorry, this case used to be false and now is true.
Just to add, when writ
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/ipa-icf-40.c: New test.
Co-authored-by: Andrew Pinsk
Hi!
The following testcases FAIL because musttail failures are diagnosed
not just in the tailc or musttail passes, but also during the tailr1
and tailr2.
tailr1 pass is before IPA and in the testcases eh cleanup has not
cleaned up the IL sufficiently yet to make the musttail calls pass,
even tailr
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
> 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, 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
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.
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
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
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
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
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, 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
> 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 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
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 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
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 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 ()
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 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 (
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
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
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
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
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
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
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);
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,
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
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
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,
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
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/
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
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
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
> 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
> 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
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
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 and function parameters end immediately
be
More details: Alignment with llvm
(https://github.com/llvm/llvm-project/pull/131592)
BRs,
Lin
> -Original Message-
> From: Hu, Lin1
> Sent: Tuesday, March 25, 2025 4:10 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH v2] i386: Add "s_" as Satura
On Tue, Mar 25, 2025 at 08:47:49AM +0100, Richard Biener wrote:
> On Mon, 24 Mar 2025, Jakub Jelinek wrote:
>
> > On Mon, Mar 24, 2025 at 10:55:44PM +0100, Jakub Jelinek wrote:
> > > If it was HOST_WIDE_INT_MAX + (size_t) 1 to ~(size_t) 0, previously it
> > > would
> > > be false and now is false
On 3/21/25 9:00 AM, Jakub Jelinek wrote:
Hi!
Here is an updated version of Surya's PR116028 fix from August, which got
reverted because it caused bootstrap failures on aarch64, later on bootstrap
comparison errors there as well and problems on other targets as well.
The changes compared to the
On 3/25/25 11:18, Thomas Schwinge wrote:
Hi Tom!
On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
wrote:
Starting with ptx isa version 6.3, a ptx directive .alias is available.
Regarding the following item specifically:
Unreferenced aliases are not emitted (these can occur f.i. w
Hi Tom!
On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
wrote:
> Starting with ptx isa version 6.3, a ptx directive .alias is available.
Regarding the following item specifically:
> Unreferenced aliases are not emitted (these can occur f.i. when inlining a
> call to an alias). This
On Mon, Mar 24, 2025 at 09:50:26AM -0700, Andi Kleen wrote:
> gcc/ChangeLog:
>
> PR gcov-profile/118442
> * cfg-flags.def (MUSTTAIL):
> * profile.cc (branch_prob):
> * tree-cfg.cc (gimple_flow_call_edges_add):
Descriptions missing.
> --- a/gcc/cfg-flags.def
> +++ b/gcc/cf
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).
Oh, ok, I got the point why you confused on this, the new condition is
little bit `i
- "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 :)
--
Regards
Robin
On Mon, Mar 24, 2025 at 5:11 PM Iain Sandoe wrote:
>
> This adds support for target-configured specs for library-specific
> specs. Initially, we will use this for the libm (but it's then
> required by other pending patches).
>
> The first patch adds to the driver and the library, the second makes
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.
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
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/
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
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
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
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
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
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
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
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
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
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, 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:
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
> -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 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
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 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
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++
> 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
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
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.
(
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
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
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
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
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)
>
1 - 100 of 120 matches
Mail list logo
