Atomic load does not modify the memory. Atomic store does not read the
memory, thus we can use "=" instead.
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_load): Remove "+" for
the memory operand.
(atomic_store): Use "=" instead of "+" for the memory
operand.
-
Formatting a time point with %c was implemented by calling
std::vprint_to with format string constructed from locale's D_T_FMT
string, but in some locales this string does not compliant to
chrono-specs. So just use _M_locale_fmt to avoid this problem.
libstdc++-v3/ChangeLog:
PR libstdc++/
Hello libstdc++ maintainers,
I sent a patch in January, but as it was my first patch, my email client
was not properly configured so the patch format was broken. So I am
re-sending it now.
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674531.html
Since I do not have commit access, if yo
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_compare_and_swapti_scq): New
define_insn.
(atomic_compare_and_swapti): New define_expand.
---
gcc/config/loongarch/sync.md | 89
1 file changed, 89 insertions(+)
diff --git a/gcc/config
Without atomic_fetch_nandsi and atomic_fetch_nanddi, __atomic_fetch_nand
is expanded to a loop containing a CAS in the body, and CAS itself is a
LL-SC loop so we have a nested loop. This is obviously not a good idea
as we just need one LL-SC loop in fact.
As ~(atom & mask) is (~mask) | (~atom), w
On 2/27/25 2:42 PM, Jan Dubiec wrote:
This patch fixes annoying -Wformat warnings when gcc is built
on Windows/MinGW64. Instead of %ld it uses HOST_WIDE_INT_PRINT_DEC
macro, just like many other targets do.
2025-02-27 Jan Dubiec
PR target/109189
gcc/ChangeLog:
* config/h8300/h8
This instruction is used to skip an redundant barrier if -mno-ld-seq-sa
or the memory model requires a barrier on failure. But with -mld-seq-sa
and other memory models the barrier may be nonexisting at all, and we
should remove the "b 3f" instruction as well.
The implementation uses a new operand
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_exchangeti_scq): New
define_insn.
(atomic_exchangeti): New define_expand.
---
gcc/config/loongarch/sync.md | 35 +++
1 file changed, 35 insertions(+)
diff --git a/gcc/config/loongarch/sync.m
With -mlam-bh, we should negate the addend first, and use an amadd
instruction. Disabling the expander makes the compiler do it correctly.
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_fetch_sub):
Disable if ISA_HAS_LAM_BH.
---
gcc/config/loongarch/sync.md | 2 +-
1 file cha
When LSX is not available but sc.q is (for example on LA664 where the
SIMD unit is not enabled), we can use a LL-SC loop for 16-byte atomic
store.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_print_operand_reloc):
Accept "%t" for printing the number of the 64-bit mach
If the vector is naturally aligned, it cannot cross cache lines so the
LSX store is guaranteed to be atomic. Thus we can use LSX to do the
lock-free atomic store, instead of using a lock.
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_storeti_lsx): New
define_insn.
(at
On LoongArch sll.w and srl.w instructions only take the [4:0] bits of
rk (shift amount) into account, and we've already defined
SHIFT_COUNT_TRUNCATED to 1 so the compiler knows this fact, thus we
don't need this instruction.
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_test_and_set):
They are the same.
gcc/ChangeLog:
* config/loongarch/sync.md: Use instead of .
(amo): Remove.
---
gcc/config/loongarch/sync.md | 53 +---
1 file changed, 25 insertions(+), 28 deletions(-)
diff --git a/gcc/config/loongarch/sync.md b/gcc/config/loo
We can use bstrins for masking the address here. As people are already
working on LA32R (which lacks bstrins instructions), for future-proofing
we check whether (const_int -4) is an and_operand and force it into an
register if not.
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_test_a
The entire patch bootstrapped and regtested on loongarch64-linux-gnu
with -march=la664, and I've also tried several simple 16-byte atomic
operation tests locally.
OK for trunk? Or maybe the clean up is OK but the 16-byte atomic
implementation still needs to be confirmed by the hardware team?
Xi
We've implemented the slli + bitwise => bitwise + slli reassociation in
r15-7062. I'd hoped late combine could handle slli.d + bitwise + add.d
=> bitwise + slli.d + add.d => bitwise => alsl.d, but it does not always
work, for example
a |= 0xfff;
b |= 0xfff;
a <<= 2;
b <<= 2;
a += x;
b
On Fri, 28 Feb 2025 at 21:47, Patrick Palka wrote:
>
> On Fri, 28 Feb 2025, Jonathan Wakely wrote:
>
> > On 28/02/25 16:27 -0500, Patrick Palka wrote:
> > > On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> > >
> > > > The specification for std::ranges::iter_move apparently requires us to
> > > > hand
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> The specification for std::ranges::iter_move apparently requires us to
> handle types which do not satisfy std::indirectly_readable, for example
> with overloaded operator* which behaves differently for different value
> categories.
>
> libstdc++-v3/C
Hi Harald,
my "rant" was more about "Why would one spend time with a library meant for
testing only." I totally agree that the one code base approach is one fine
way to go. I didn't not want to insult anyone and apologize, if I did.
Finally this discussion made me think, what it would need to ha
On Fri, 28 Feb 2025, Jonathan Wakely wrote:
> On 28/02/25 16:27 -0500, Patrick Palka wrote:
> > On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> >
> > > The specification for std::ranges::iter_move apparently requires us to
> > > handle types which do not satisfy std::indirectly_readable, for exampl
On Fri, 28 Feb 2025, Patrick Palka wrote:
> On Thu, 27 Feb 2025, Jonathan Wakely wrote:
>
> > The specification for std::ranges::iter_move apparently requires us to
> > handle types which do not satisfy std::indirectly_readable, for example
> > with overloaded operator* which behaves differently
On 28/02/25 16:27 -0500, Patrick Palka wrote:
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
The specification for std::ranges::iter_move apparently requires us to
handle types which do not satisfy std::indirectly_readable, for example
with overloaded operator* which behaves differently for differ
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> The standard requires that we reject attempts to create a ranges::to
> adaptor for cv-qualified types and non-class types. Currently we only
> diagnose it once the adaptor is used in a pipeline.
>
> This adds static assertions to diagnose it immediate
Hi,
This patch fixes a case where the D language implementation was
comparing objects with uninitialized memory.
Explanation:
Floating-point emulation in the D front-end is done via a type named
`struct longdouble`, which in GDC is a small interface around the
real_value type. Because the D code
Am 28.02.25 um 08:24 schrieb Andre Vehreschild:
Hi Thomas,
are you really telling me, that gfortran's coarray test library is compiled for
offloading to GPU (or other SIMD processors)? Because that's what NVPTX is used
for most, right? In my opinion that makes no sense, because coarrays in Fortr
On Fri, Feb 28, 2025 at 5:25 AM Kyrylo Tkachov wrote:
>
> Hi all,
>
> In this PR late-combine was failing to merge:
> dup v31.4s, v31.s[3]
> fmla v30.4s, v31.4s, v29.4s
> into the lane-wise fmla form.
> This is because late-combine checks may_trap_p under the hood on the dup insn.
> This ended up
Transplant a piece of gcc/configure.ac to set gcc_cv_objdump properly so
that GCC_ENABLE_PLUGINS macro from config/gcc-plugin.m4 doesn't set
export_sym_check to " -T". Regenerate libcc1/configure.
---
libcc1/configure| 64 +++--
libcc1/configure.ac | 16
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
-- >8 --
We crash because we generate
{[0 ... 1]={.low=0, .high=1}, [1]={.low=0, .high=1}}
which output_constructor_regular_field doesn't want to see. This
happens since r9-1483: process_init_constructor_array can now creat
Ping.
On 2/20/25 14:24, David Faust wrote:
>
> Gentle ping for this series.
> https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675241.html
>
> On 2/6/25 11:54, David Faust wrote:
>> [v1: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666911.html
>> Changes from v1:
>> - Fix a bu
> Am 28.02.2025 um 17:02 schrieb Filip Kastl :
>
> Hi,
>
> bootstrapped and regtested on x86_64 linux. Ok to be pushed?
Ok
Richard
> Thanks,
> Filip Kastl
>
>
> -- 8< --
>
>
> While writing the sccopy pass I didn't realize that 'replace_uses_by ()' can
> remove portions of the CFG.
On 28/02/2025 16:12, Richard Earnshaw wrote:
On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
A long time ago, this test forced -march=armv6.
With -marm, the generated assembler is:
foo:
sub r0, r0, #48
cmp r0, #9
movhi r0
On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
A long time ago, this test forced -march=armv6.
With -marm, the generated assembler is:
foo:
sub r0, r0, #48
cmp r0, #9
movhi r0, #0
movls r0, #1
bx
Hi,
bootstrapped and regtested on x86_64 linux. Ok to be pushed?
Thanks,
Filip Kastl
-- 8< --
While writing the sccopy pass I didn't realize that 'replace_uses_by ()' can
remove portions of the CFG. This happens when replacing arguments of some
statement results in the removal of an EH edge
Hi all,
on this regression I had to chew a longer time. Assume this Fortran:
type T
integer, allocatable:: a
end type T
result(type T) function bar()
allocate(bar%a)
end function
call foo([bar()])
That Fortran fragment was translated to something like (pseudo code):
T temp;
T arr[];
temp
Hi,
On Fri, 28 Feb 2025, Da Xie wrote:
> This bug comes from a missing check when a function declaration has a
> late-specified return type and a constrained auto type specifier. By
> adding such a check, we can catch such uses and diagnose them as errors.
>
> Successfully bootstrapped and regre
Hi!
I've committed the following patch to wwwdocs to add the Hagenberg core
papers to cxx-status.html.
Unsure about P3542R0, neither cppreference nor clang cxx-status list that.
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 823d8c78..d6e53005 100644
--- a/htdocs/gcc-1
Hello,
On 27/02/2025 15:34, Jonathan Wakely wrote:
On 26/02/25 17:27 +0100, Giuseppe D'Angelo wrote:
On 26/02/2025 16:33, Giuseppe D'Angelo wrote:
Whops, sorry, missed this sub-thread (while replying to the other one).
Change of plans then, I'll amend and remove the ad-hoc constexpr macro.
D
On 08/11/2024 17:44, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68674.c: Use effective-target arm_arch_v7a
and arm_libc_fp_abi.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.target/arm/pr68674.c | 7 +++
This bug comes from a missing check when a function declaration has a
late-specified return type and a constrained auto type specifier. By
adding such a check, we can catch such uses and diagnose them as errors.
Successfully bootstrapped and regretested on x86_64-pc-linux-gnu:
adds 6 new test resu
On 2/19/25 11:25 AM, Marek Polacek wrote:
On Wed, Feb 19, 2025 at 10:14:21AM -0500, Patrick Palka wrote:
On Wed, 19 Feb 2025, Marek Polacek wrote:
I suppose it's safer to leave this for GCC 16, but anyway:
Bootstrapped/regtested on x86_64-pc-linux-gnu.
-- >8 --
Since r10-7718 the attached te
On 2/27/25 11:37 AM, Jakub Jelinek wrote:
On Thu, Feb 27, 2025 at 10:48:14AM -0500, Jason Merrill wrote:
--- libcpp/directives.cc.jj 2025-02-13 19:59:56.202572170 +0100
+++ libcpp/directives.cc2025-02-20 21:40:56.379899457 +0100
@@ -1367,7 +1367,7 @@ do_embed (cpp_reader *pfile)
On 2/27/25 3:15 PM, Jakub Jelinek wrote:
Hi!
I've added the asserts that probe == target because {REAL,IMAG}PART_EXPR
always implies a scalar type and so applying ARRAY_REF/COMPONENT_REF
etc. on it further doesn't make sense and the later code relies on it
to be the last one in refs array. But
On Fri, Feb 28, 2025 at 9:40 AM Jakub Jelinek wrote:
>
> Hi!
>
> The testcase uses -m32 in dg-options, something we try hard not to do,
> if something should be tested only for -m32, it is { target ia32 } test,
> if it can be tested for -m64/-mx32 too, just some extra options are
> needed for ia32
On 2/27/25 3:35 PM, Marek Polacek wrote:
On Thu, Feb 27, 2025 at 10:42:07AM -0500, Jason Merrill wrote:
On 2/26/25 2:16 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Yet another problem that started with r15-6052, compile time evaluation of
prva
On 2/27/25 4:51 PM, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for stage 1?
Yes.
-- >8 --
The PR68942 fix used the tf_conv flag to disable mark_used when
substituting a FUNCTION_DECL callee of an ADL-enabled call. In this
slightly more elaborate testcase, we end u
On 2/27/25 4:51 PM, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
Let's also update the comment before the function that currently says
"the std doesn't anticipate this case" to refer to
[expr.prim.lambda.capture]/7.1
https://eel.is/c++draft/e
Hi all,
In this PR late-combine was failing to merge:
dup v31.4s, v31.s[3]
fmla v30.4s, v31.4s, v29.4s
into the lane-wise fmla form.
This is because late-combine checks may_trap_p under the hood on the dup insn.
This ended up returning true for the insn:
(set (reg:V4SF 152 [ _32 ])
(vec_du
The following fixes a thinko in the handling of interposed weak
definitions which confused the interposition check in
get_availability by setting DECL_EXTERNAL too early.
Bootstrap and regtest running on x86_64-unknown-linux-gnu, will push
if that succeeds.
PR lto/91299
gcc/lto/
*
On Thu, Feb 27, 2025 at 5:11 AM Iain Buclaw wrote:
>
> Excerpts from Lewis Hyatt's message of Februar 26, 2025 2:04 am:
> > On Tue, Feb 25, 2025 at 12:00 PM Iain Buclaw wrote:
> >>
> >> Hi,
> >>
> >> It was noticed that when running the testsuite for gdc and libphobos in
> >> parallel, this was c
What we could do is
prev.set_ratio (calculate_ratio (prev.get_sew (), prev.get_vlmul ()));
prev.set_vlmul (calculate_vlmul (prev.get_sew (), prev.get_ratio ()));
No, that also doesn't work because the ratio can be invalid then.
We fuse two vsetvls. One of them has a larger SEW which w
Okay, let me explain the background of my previous patch.
Prior to applying my patch, for the test case bug-10.c (a reduced example of
a larger program with incorrect runtime results),
the vsetvli sequence compiled with --param=vsetvl-strategy=simple was as
follows:
1. vsetvli zero,a4,e16,m4,ta
On Fri, Feb 28, 2025 at 11:47:44AM +0100, Richard Biener wrote:
> The following disables redundant store elimination to hard register
> variables which isn't valid.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> PR tree-optimization/87984
> *
We currently record a kill for
*x_4(D) = always_throws ();
because we consider the store always executing since the appropriate
check for whether the stmt could throw is guarded by
!cfun->can_throw_non_call_exceptions.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu, will push
after
On Fri, 28 Feb 2025 06:47:24 +0100, "Robin Dapp" wrote:
> > This patch modifies the sequence:
> > vsetvli zero,a4,e32,m4,ta,ma + vsetvli zero,a4,e8,m2,ta,ma
> > to:
> > vsetvli zero,a4,e32,m8,ta,ma + vsetvli zero,zero,e8,m2,ta,ma
> > Functionally, there is no difference. However, this change resol
The following disables redundant store elimination to hard register
variables which isn't valid.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
PR tree-optimization/87984
* tree-ssa-dom.cc (dom_opt_dom_walker::optimize_stmt): Do
not perform redu
It seems the issue is we didn't set "vlmul" ?
Can we do that:
int max_sew = MAX (prev.get_sew (), next.get_sew ());
prev.set_sew (max_sew);
prev.set_vlmul (calculate_vlmul (...));
prev.set_ratio (calculate_ratio (prev.get_sew (), prev.get_vlmul ()));
What we could do is
prev.set_ratio (cal
> Anyway, the 2 FIXes (or inner FIX with outer UNSIGNED_FIX) cause problems
> since the r15-2890 which removed some strict checks in ifcvt.cc on what
> SET_SRC can be actually conditionalized (I must say I'm still worried
> about the change, don't know why one can't get e.g. inline asm or
> somethi
On Fri, Feb 28, 2025 at 11:09:21AM +0100, Richard Biener wrote:
> When the C++ frontend clones a CTOR we do not copy ASM_EXPR constraints
> fully as walk_tree does not recurse to TREE_PURPOSE of TREE_LIST nodes.
> At this point doing that seems too dangerous so the following instead
> avoids gimpli
Many of the constants which are generated using 3 `mov` instruction can be
generated using `mov` plus `sub` instruction. The patch uses following method
to add the mentioned functionality. If a constant `val` can not be generated
using 1 or 2 `mov`, then find `val1` such that `(val + val1)` can be
When the C++ frontend clones a CTOR we do not copy ASM_EXPR constraints
fully as walk_tree does not recurse to TREE_PURPOSE of TREE_LIST nodes.
At this point doing that seems too dangerous so the following instead
avoids gimplification of ASM_EXPRs to clobber the shared constraints
and unshares it
On Fri, 28 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> The testcase uses -m32 in dg-options, something we try hard not to do,
> if something should be tested only for -m32, it is { target ia32 } test,
> if it can be tested for -m64/-mx32 too, just some extra options are
> needed for ia32, it should
Hi!
The testcase uses -m32 in dg-options, something we try hard not to do,
if something should be tested only for -m32, it is { target ia32 } test,
if it can be tested for -m64/-mx32 too, just some extra options are
needed for ia32, it should have dg-additional-options with ia32 target.
Furthermo
Hi Sandra,
thanks for taking on the laborious task. I have browsed over the changes and
found:
Patch 3 in intrinsic.texi:
@@ -2071,6 +2071,9 @@ end program atomic
@cindex Atomic subroutine, ADD with fetch
@table @asis
+@item @emph{Synopsis}:
+@code{CALL ATOMIC_FETCH_ADD (ATOM, VALUE, old [, S
On Thu, 27 Feb 2025 19:43:30 +0800, Kito Cheng wrote:
> Hi Jin Ma:
>
> I realized multilib os dir is not correctly set as you described, but
> I think that info should just come from multilib_select rather than
> creating a new hook to do that, anyway I just wrote a fix...because we
> hit that iss
Hi Harald,
thanks for the review. Committed as gcc-15-7747-gc1606e383a3.
Thanks again,
Andre
On Thu, 27 Feb 2025 21:13:08 +0100
Harald Anlauf wrote:
> Hi Andre,
>
> Am 27.02.25 um 18:36 schrieb Andre Vehreschild:
> > Hi all,
> >
> > attached patch fixes user defined finalizers in deriv
No problem, created PR119054 with a reproducer and some details.
Cheers,
Peter
On Thu, 27 Feb 2025 at 20:45, Jerry D wrote:
>
> On 2/27/25 12:33 PM, Peter Hill wrote:
> > On Thu, 27 Feb 2025 at 18:09, Jerry D wrote:
> >>
> >> On 2/27/25 7:38 AM, Peter Hill wrote:
> >>> Dear all,
> >>>
> >>> The
On Fri, 28 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> I found another test which uses -m32 in gcc.target/i386/ . Similarly
> to the previously posted test, the test ought to be tested during i686-linux
> testing or x86_64-linux test with --target_board=unix\{-m32,-m64\}
> There is nothing ia32 spe
On Fri, 28 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> The testcase in the following patches is miscompiled, because
> ICF only uses operand_equal_p to compare operands and when that
> sees an ADDR_EXPR, it turns on OEP_ADDRESS_OF mode which only cares
> about the exact value instead of checking the
On Fri, Feb 28, 2025 at 9:42 AM Jakub Jelinek wrote:
>
> Hi!
>
> I found another test which uses -m32 in gcc.target/i386/ . Similarly
> to the previously posted test, the test ought to be tested during i686-linux
> testing or x86_64-linux test with --target_board=unix\{-m32,-m64\}
> There is noth
Hi!
I found another test which uses -m32 in gcc.target/i386/ . Similarly
to the previously posted test, the test ought to be tested during i686-linux
testing or x86_64-linux test with --target_board=unix\{-m32,-m64\}
There is nothing ia32 specific on the test, so I've just dropped the -m32.
Test
Hi!
The testcase in the following patches is miscompiled, because
ICF only uses operand_equal_p to compare operands and when that
sees an ADDR_EXPR, it turns on OEP_ADDRESS_OF mode which only cares
about the exact value instead of checking the types etc.
Unfortunately, get_range_strlen/get_range_
71 matches
Mail list logo
