Thomas, Steve,
thanks for the swift feedback!
Am 10.01.25 um 23:57 schrieb Thomas Koenig:
Hello Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I just started to run a bootstrap on cfarm120 (because it is
the only machine I can lay my hands on where I can run
"make -j128" withou
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
30_threads/stop_token/stop_source/109339.cc was failing because we weren't
representing attribute access on the METHOD_TYPE for _Stop_state_ref.
The modules code expected attributes to appear on tt_variant_type and not
on tt_derived_type, b
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
std/time/traits/is_clock.cc was getting a warning about applying the
deprecated attribute to a variant of auto_ptr, which was wrong because it's
on the primary type. This turned out to be because we were ignoring the
attributes on the defin
On Linux/x86_64,
f4e259b4a66c81c234608056117836e13606e4c8 is the first bad commit
commit f4e259b4a66c81c234608056117836e13606e4c8
Author: Alex Coplan
Date: Thu Jul 25 16:34:05 2024 +
vect: Ensure we add vector skip guard even when versioning for aliasing
[PR118211]
caused
FAIL: gcc.
On Linux/x86_64,
68326d5d1a593dc0bf098c03aac25916168bc5a9 is the first bad commit
commit 68326d5d1a593dc0bf098c03aac25916168bc5a9
Author: Alex Coplan
Date: Mon Mar 11 13:09:10 2024 +
vect: Force alignment peeling to vectorize more early break loops [PR118211]
caused
FAIL: gcc.dg/tree
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
PR 70949 appears to have been fi
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
This patch fixes PR71844. As th
On Fri, Jan 10, 2025 at 09:41:13PM +, Harald Anlauf wrote:
>
> There is one question to the reviewer(s), or those knowing better
> than me how to handle IEEE infinity and NaN: with -Ofast, I needed
> to add "-fno-finite-math-only" to the new testcase
> gfortran.dg/ieee/out_of_range.f90, as the
Pushed to r15-6817.
在 2025/1/10 上午10:27, mengqinggang 写道:
Generate 0x1010 instead of 0x101>>12 for lu12i.w. lu32i.d and lu52i.d use
the same processing.
gcc/ChangeLog:
* config/loongarch/lasx.md: Use new loongarch_output_move.
* config/loongarch/loongarch-protos.h (loongarc
On 1/6/25 5:01 PM, Hans-Peter Nilsson wrote:
Regtested native x86_64-linux. Also tested mmix-knuth-mmixware,
where it fixes ONE testcase, but one which is a regression on
master. The PR component is currently ipa, changed from the
original middle-end. IIUC this bug-fix doesn't fit the ipa
c
On 1/10/25 4:59 PM, Palmer Dabbelt wrote:
On Fri, 10 Jan 2025 12:21:15 PST (-0800), jeffreya...@gmail.com wrote:
On 1/10/25 12:11 PM, Robin Dapp wrote:
Integer values and floating-point values need to be converted
by fmv series instructions. So if mode1 is MODE_INT and mode2
is MODE_FLOAT,
On 1/7/25 7:24 PM, YunQiang Su wrote:
Jeff Law 于2025年1月8日周三 07:06写道：
On 1/1/25 6:42 PM, YunQiang Su wrote:
Matthias Klose 于2025年1月1日周三 22:37写道：
in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641619.html
there are two typos in the patch, compared to the local Debian patch,
On Fri, 10 Jan 2025 12:21:15 PST (-0800), jeffreya...@gmail.com wrote:
On 1/10/25 12:11 PM, Robin Dapp wrote:
Integer values and floating-point values need to be converted
by fmv series instructions. So if mode1 is MODE_INT and mode2
is MODE_FLOAT, we should return false in riscv_modes_tieable
On 1/10/25 12:20 AM, Kito Cheng wrote:
Could you rebase and send the patch set again? I can't apply the patch set:
[kitoc@hsinchu18 gcc]$ git am
/tmp/git-pw8sm7zbop/RISC-V-Add-intrinsics-support-and-testcases-for-SiFive-Xsfvcp-extension..patch
Applying: RISC-V: Add intrinsics support for SiFi
On 1/10/25 2:43 PM, Andrew MacLeod wrote:
This should have been done a while ago.
Funny I said kind of the same thing when I did the DOM variant for
integral types a little while back.
The call to simplify MIN and MAX was guarded by a check for INTEGRAL, so
I removed that as the code was
Hello Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I just started to run a bootstrap on cfarm120 (because it is
the only machine I can lay my hands on where I can run
"make -j128" without disturbing anybody :-) and I got
../../trunk/gcc/fortran/trans-intrinsic.cc: In function ‘
Dear all,
the attached patch is supposed to be a complete implementation of
the F2018 intrinsic OUT_OF_RANGE. This is mostly straightforward,
with runtime code fully expanded inline. It is also extended to
support the new UNSIGNED type of gfortran as of current 15-mainline.
The testcases are cr
> On Jan 10, 2025, at 15:34, Jeff Law wrote:
>
>
>
> On 1/9/25 1:39 PM, Qing Zhao wrote:
>>> On Jan 9, 2025, at 14:10, Jeff Law wrote:
>>>
>>>
>>>
>>> On 1/9/25 10:48 AM, Qing Zhao wrote:
>>>
>
> I think Jeff's patch is not reasonable since it boils down to not diagnose
> -W
This should have been done a while ago.
The call to simplify MIN and MAX was guarded by a check for INTEGRAL, so
I removed that as the code was already generalized to work with any type.
And no attempt was being made to pass in a relation... so I query for a
relation between op0 and op1, and
This is an equality comparison rather than a three-way comparison like
memcmp and <=>, so name it more precisely.
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h
(__atomic_wait_address_until_v): Replace __atomic_compare with
__atomic_eq.
(__atomic_wait_a
> Strided load store should demand RATIO instead of SEW and LMUL.
> Is it VSETVL PASS bug ? I don't understand why configure it depand SEW + LMUL
Yeah, you're right, I was looking at indexed loads in the spec...
It's a problem in the vsetvl pass, yes. Half of it I already fixed but the
other hal
Also add missing precondition check to constructor and fix existing
check in count_down which was duplicated by mistake.
libstdc++-v3/ChangeLog:
PR libstdc++/98749
* include/std/latch (latch::max()): Use std::cmp_less to handle
the case where __platform_wait_t is wider tha
When using a proxy object for atomic waiting and notifying operations,
we need to ensure that the _M_ver value is always incremented by a
notifying operation, even if we return early without doing the futex
wake syscall. Otherwise we get missed wake-ups because the notifying
thread doesn't modify t
We don't need to wait if we know the counter has reached zero.
libstdc++-v3/ChangeLog:
* include/std/latch (latch::arrive_and_wait): Optimise.
---
This one's commented out for now, but sending for review anyway.
libstdc++-v3/include/std/latch | 12
1 file changed, 12 inser
Making these non-templates will allow them to be moved into the library
at some point.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__platform_wait): Change function
template to a normal function. The parameter is always
__platform_wait_t* which is just int* for t
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h: Whitespace fixes.
* include/bits/atomic_wait.h: Likewise.
---
libstdc++-v3/include/bits/atomic_timed_wait.h | 198 +-
libstdc++-v3/include/bits/atomic_wait.h | 8 +-
2 files changed, 100 insertions
We can pass around void* instead of casting incompatible pointers to
__platform_wait_t*, and then only static_cast to __platform_wait_t* when
we know that's valid.
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h (__atomic_wait_address_until):
Remove reinterpret_cast and
From: Thomas Rodgers
This change splits the __wait_args data members to a new struct
__wait_args_base and then passes that type by const pointer to the low
level implementation functions.
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h (__spin_until_impl): Accept
__wa
From: Jonathan Wakely
This series complete Tom's work to refactor the C++20 atomic wait/notify
code. The goal is to make the implementation ready for some pieces to be
moved into libstdc++.so instead of defining everything inline in the
headers.
Also available for review at
https://forge.sourcew
From: Thomas Rodgers
This represents a major refactoring of the previous atomic::wait
and atomic::notify implementation detail. The aim of this change
is to simplify the implementation details and position the resulting
implementation so that much of the current header-only detail
can be moved in
Remove the unnecessary __wait_args_base base class, which seems to serve
no purpose. Everywhere it's used we actually want __wait_args instead.
The code using the __wait_flags bitmask type is broken, because the
__spin_only constant includes the __do_spin element. This means that
testing (__args &
On 1/10/25 4:41 AM, Richard Biener wrote:
The following puts in a hard limit on ext-dce because it might end
up requiring memory on the order of the number of basic blocks
times the number of pseudo registers. The limiting follows what
GCSE based passes do and thus I re-use --param max-gcse-m
This fixes warnings like the following during bootstrap:
sparc-sun-solaris2.11/libstdc++-v3/include/bits/atomic_futex.h:324:53: warning:
unused parameter ‘__mo’ [-Wunused-parameter]
324 | _M_load_when_equal(unsigned __val, memory_order __mo)
|~~
This moves all non-dependent state and logic for std::barrier into a
new non-template base class, to avoid template bloat.
This would permit moving the _M_arrive function into the library instead
of the header.
libstdc++-v3/ChangeLog:
* include/std/barrier (__tree_barrier_base): New clas
On 2025-01-10 07:50, Siddhesh Poyarekar wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* lib/target-supports.exp
On 1/10/25 1:00 AM, Richard Biener wrote:
It's a problem we're never going to fully solve. Some of the
testcases show missed optimizations which we can work on. Some show
we diagnose IL we later are able to optimize away, some simply show
that users are not always happy with how we decide
Hi Folks,
> On 10 Jan 2025, at 18:30, Wilco Dijkstra wrote:
>
> Hi Andrew,
>
>> Personally I would like this deprecated even for bare-metal. Yes the
>> iwatch ABI is an ILP32 ABI but I don't see GCC implementing that any
>> time soon and I suspect it would not be hard to resurrect the code at
>
On 1/9/25 1:39 PM, Qing Zhao wrote:
On Jan 9, 2025, at 14:10, Jeff Law wrote:
On 1/9/25 10:48 AM, Qing Zhao wrote:
I think Jeff's patch is not reasonable since it boils down to not diagnose
-Warray-bounds but instead remove those stmts.
If these stmts are dead-code that are generate
On 1/10/25 12:11 PM, Robin Dapp wrote:
Integer values and floating-point values need to be converted
by fmv series instructions. So if mode1 is MODE_INT and mode2
is MODE_FLOAT, we should return false in riscv_modes_tieable_p,
and vice versa.
I think that's on purpose because we can read and
Ping for:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656541.html
Thanks & Best Regards
Abdul Basit
-Original Message-
From: Ijaz, Abdul B
Sent: Friday, November 22, 2024 2:14 PM
To: gcc-patches@gcc.gnu.org
Cc: Ijaz, Abdul B
Subject: [PING*2][PATCH 1/1] config: Handle dash in l
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Fixed by r15-6740.
PR c++/118391
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval20.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/lambda-uneval20.C | 15 +++
1 file changed, 15 insertions(+)
create mode 100
Ping.
On Fri, Dec 20, 2024 at 08:58:05AM -0500, Marek Polacek wrote:
> Ping.
>
> On Tue, Nov 26, 2024 at 05:35:50PM -0500, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > As the manual states, using "-fhardened -fstack-protector" will pr
This doesn't enable anything within the compiler, but this allows the
flag to be passed the assembler. There also doesn't appear to be a
kernel cpuinfo name yet.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V9_5A): Add CPA.
* config/aarch64/aarch64-option-
I missed that the documentation doesn't include armv8.7-a
within armv9.2-a.
I'll commit this as obvious.
gcc/ChangeLog:
* doc/invoke.texi: Add +wfxt and +xs to armv9.2-a
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index
0be372079e9947e22cb43f723b51e1a5a8dd4ef7..07c1b982d32
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (V9_5A): New.
* doc/invoke.texi: Document armv9.5-a option.
diff --git a/gcc/config/aarch64/aarch64-arches.def
b/gcc/config/aarch64/aarch64-arches.def
index
fd4881a8ebfbd3446e2995b9dcf1133918665be6..dacb7b6f37a3
Hi Richard,
> It looks like you committed the original version instead, with no extra
> explanation. I suppose I should have asked for another review round
> instead.
Did you check the commit log?
Change the AARCH64_EXPAND_ALIGNMENT macro into proper function calls to make
future change
Hi Richard,
> Yeah, somewhat. But won't we go on to test has_lse2 anyway, due to:
>
> # elif defined (LSE2_LRCPC3_ATOP)
> # define IFUNC_NCOND(N) 2
> # define IFUNC_COND_1 (has_rcpc3 (hwcap, features))
> # define IFUNC_COND_2 (has_lse2 (hwcap, features))
>
> If we want to reduce the
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
The documentation for LAMBDA_EXPR_THIS_CAPTURE seems outdated because
it says the field is only used at parse time, but apparently it's also
used at instantiation time.
Non-'this' captures don't seem to be affected, b
> Integer values and floating-point values need to be converted
> by fmv series instructions. So if mode1 is MODE_INT and mode2
> is MODE_FLOAT, we should return false in riscv_modes_tieable_p,
> and vice versa.
I think that's on purpose because we can read and write float values
from/to integer r
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
When I was much more active in a
On Thu, 2025-01-09 at 22:28 -0500, David Malcolm wrote:
> On Thu, 2025-01-09 at 21:15 -0500, Jason Merrill wrote:
> > On 1/9/25 7:00 PM, David Malcolm wrote:
> > > On Thu, 2025-01-09 at 14:21 -0500, Jason Merrill wrote:
> > >
> > > Thanks for taking a look...
> > >
> > > > > On 1/9/25 2:11 PM, Da
On Tue, 1 Oct 2024, Patrick Palka wrote:
> On Thu, 12 Sep 2024, Patrick Palka wrote:
>
> > (Sorry to resurrect this thread so late, I lost track of this patch...)
> >
> > On Fri, 2 Dec 2022, Jason Merrill wrote:
> >
> > > On 12/2/22 09:30, Patrick Palka wrote:
> > > > On Thu, 1 Dec 2022, Jason
On 2025-01-10 16:46, Richard Earnshaw (lists) wrote:
On 07/01/2025 20:16, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
a pattern is needed that uses PUSH/BL/POP sequence instead of a single
B instruction
On Tue, 1 Oct 2024, Patrick Palka wrote:
> On Mon, 16 Sep 2024, Patrick Palka wrote:
>
> > On Thu, 30 Nov 2023, Patrick Palka wrote:
> >
> > > On Fri, 3 Nov 2023, Patrick Palka wrote:
> > >
> > > > On Tue, 3 May 2022, Jason Merrill wrote:
> > > >
> > > > > On 5/2/22 14:50, Patrick Palka wrot
Wilco Dijkstra writes:
> Hi Richard,
>
>>> + /* LSE2 is a prerequisite for atomic LDIAPP/STILP. */
>>> + if (!(hwcap & HWCAP_USCAT))
>>> return false;
>>
>> Is there a reason for not using has_lse2 here? It'd be good to have
>> a comment if so.
>
> Yes, the MRS instructions cause expensiv
Hi Andrew,
> Personally I would like this deprecated even for bare-metal. Yes the
> iwatch ABI is an ILP32 ABI but I don't see GCC implementing that any
> time soon and I suspect it would not be hard to resurrect the code at
> that point.
My patch deprecates it in all cases currently. It will be
Hi Richard,
>> + /* LSE2 is a prerequisite for atomic LDIAPP/STILP. */
>> + if (!(hwcap & HWCAP_USCAT))
>> return false;
>
> Is there a reason for not using has_lse2 here? It'd be good to have
> a comment if so.
Yes, the MRS instructions cause expensive traps, so we try to avoid them whe
On Fri, Jan 10, 2025 at 3:18 AM Simon Martin wrote:
>
> We currently accept the following invalid code (EDG and MSVC do as well)
clang does too: https://github.com/llvm/llvm-project/issues/121706 .
Note it might be useful if a testcase with multiply `*` is included too:
```
struct A {
A ()
> On Jan 10, 2025, at 10:05, Richard Biener wrote:
>
> On Fri, Jan 10, 2025 at 3:27 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jan 10, 2025, at 03:00, Richard Biener
>>> wrote:
>>>
>>> On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wrote:
> On Jan 9, 2025, at 14:10, Jeff Law w
On 1/10/25 9:19 AM, Paul Richard Thomas wrote:
Hi Harald, hi all,
As of today, Gerhard Steinmetz has no fewer than 33 regressions to his
name out of a total of 54 for fortran and libgfortran. It's time that
some of these bugs are swatted, I think :-)
As well as this PR, 106946 seems to have
It seems odd that we add "native" to the list for -march but not for
-mcpu. This is probably a bug, but for now we'll preserve the existing
behaviour.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_print_hint_for_core_or_arch): Inline into...
(aarch64_print_hint_for_
This feature flag bit only exists to support the +crypto alias. Outside
of option processing this bit needs to be set or unset consistently.
This patch goes with the latter option.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc: Assert that CRYPTO
bit is not set.
The list of cores in aarch64-common.cc included an explicit "generic"
entry, despite this entry also being present in aarch64-cores.def.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(all_cores): Remove explicit generic entry.
diff --git a/gcc/common/config/aarch64/aa
Add infrastructure to allow rewriting the architecture strings passed to
the assembler (either as -march options or .arch directives). There was
already canonicalisation everywhere except for an -march driver option
passed directly to the compiler; this patch applies the same
canonicalisation ther
Use aarch64_validate_cpu instead of the existing duplicate (and worse)
version of the -mcpu parsing code.
The original code used fatal_error; I'm guessing that using error
instead should be ok.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_rewrite_selected_cpu
Aside from moving the functions, the only changes are to make them
non-static, and to use the existing info arrays within aarch64-common.cc
instead of the info arrays remaining in aarch64.cc.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_get_all_extension_candi
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_get_all_extension_candidates): Inline into...
(aarch64_print_hint_for_extensions): ...this.
diff --git a/gcc/common/config/aarch64/aarch64-common.cc
b/gcc/common/config/aarch64/aarch64-common.cc
index
5cc
Features from a cpu or base architecture that were explicitly disabled
by a +nofeat option were being incorrectly added back in before checking
for conflicts between -mcpu and -march options. This patch instead
compares the returned feature masks directly.
gcc/ChangeLog:
* config/aarch64
Replace `const struct processor *` in output parameters with
`aarch64_arch` or `aarch64_cpu`.
Replace `std:string` parameter in aarch64_print_hint_for_extensions with
`char *`.
Also name the return parameters more clearly and consistently.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
Also add a (currently unused) processor field to processor_info, and
change name from "" to NULL for the terminating array entries.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(struct aarch64_option_extension): Rename to..
(struct extension_info): ...this.
Replace `enum aarch64_processor` and `enum target_cpus` with
`enum aarch64_cpu`, and prefix the entries with `AARCH64_CPU_`.
Also rename aarch64_none to aarch64_no_cpu.
gcc/ChangeLog:
* config/aarch64/aarch64-opts.h
(enum aarch64_processor): Rename to...
(enum aarch64_cpu)
Hi PA,
Paul-Antoine Arras wrote:
This amended patch checks the context and adds the suggested testcase.
LGTM - thanks!
Do not call cp_parser_omp_dispatch directly in cp_parser_pragma
This is a followup to
ed49709acda OpenMP: C++ front-end support for dispatch + adjust_a
This series also fixes a couple of minor bugs (see 01/11 and 11/11).
The aim of the refactor is to get all of the target parsing logic (whether via
command line options, or attributes) into a single location with as much code
regularity and reuse as is reasonably possible. This includes reorderin
FYI, I discovered this latent bug while testing a patch I'm working on.
The loop checking for built-in constant operand restrictions was missing
some operands due to the loop limit being too small. Fixing that exposed
a testsuite failure which is caused by a typo in the pmxvi4ger8pp definition
wh
Hi Harald, hi all,
As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
out of a total of 54 for fortran and libgfortran. It's time that some of
these bugs are swatted, I think :-)
As well as this PR, 106946 seems to have fixed itself and I have fixes for
102333 and 96087 w
Hi Thomas,
Thomas Koenig wrote:
Comments, remarks, suggestions?
I assume you regression-tested (you didn't say).
Yes, it was build with a bootstrapping configuration (with a
non-offloading compiler, but it shouldn't matter here) on
x86_64-gnu-linux and I did run "make check-fortran" in the
m
Wilco Dijkstra writes:
> Hi Kyrill,
>
>>> Add AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS and
>>> AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT
>>> to the baseline tuning since all modern cores use it. Fix the
>>> neoverse512tvb tuning to be
>>> like Neoverse V1/V2.
>>
>> For neoversev512tvb this me
On 1/10/25 5:02 AM, Jakub Jelinek wrote:
Hi!
In the following testcase there are 2 issues, one is that B doesn't
have operator<=> and the other is that A's operator<=> has int return
type, i.e. not the standard comparison category.
Because of the int return type, retcat is cc_last; when we first
Wilco Dijkstra writes:
> ping
>
>
> Simplify and cleanup ifunc selection logic. Since LRCPC3 does
> not imply LSE2, has_rcpc3() should also check LSE2 is enabled.
>
> Passes regress and bootstrap, OK for commit?
>
> libatomic:
> * config/linux/aarch64/host-config.h (has_lse2): Cleanup.
On Fri, Jan 10, 2025 at 6:06 AM Wilco Dijkstra wrote:
>
>
> ILP32 was originally intended to make porting to AArch64 easier. Support was
> never merged in the Linux kernel or GLIBC, so it has been unsupported for many
> years. There isn't a benefit in keeping unsupported features forever, so
> d
Akram Ahmad writes:
> Ah whoops- I didn't see this before sending off V4 just now, my apologies.
> I'll try my best to get this implemented before the end of the day so that
> it doesn't miss the deadline.
No rush! The delay here is entirely my fault, so no problem if the
patch lands early stage
Integer values and floating-point values need to be converted
by fmv series instructions. So if mode1 is MODE_INT and mode2
is MODE_FLOAT, we should return false in riscv_modes_tieable_p,
and vice versa.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_modes_tieable_p):
gcc/testsuite/Change
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We need to remember that the ::operator new is replaceable to avoid a bogus
error about __builtin_operator_new finding a non-replaceable function.
This affected __get_temporary_buffer in stl_tempbuf.h.
gcc/cp/ChangeLog:
* module.c
On Thu, Jan 09, 2025 at 09:39:49PM -0500, Jason Merrill wrote:
> > @@ -6685,7 +6692,14 @@ gimplify_modify_expr (tree *expr_p, gimp
> > /* Don't do this for calls that return addressable types,
> > expand_call
> > relies on those having a lhs. */
> > && !(TREE_ADDRESSABLE (TRE
Hi Tobias,
Comments, remarks, suggestions?
I assume you regression-tested (you didn't say).
Otherwise, I regard the common Fortran code as obvious - and
the OpenMP part covered by my (co)maintainership.
Regarding the Fortran part:
- fndecl = build_decl (input_location,
+ fndecl = build_
Hi Kyrill,
>> Add AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS and
>> AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT
>> to the baseline tuning since all modern cores use it. Fix the
>> neoverse512tvb tuning to be
>> like Neoverse V1/V2.
>
> For neoversev512tvb this means adding AARCH64_EXTRA_TUNE_AVOI
On 07/01/2025 20:16, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
> a pattern is needed that uses PUSH/BL/POP sequence instead of a single
> B instruction to reuse an already existing function in the
The commit message contains an explanation.
commit 94d8de53388793f4d5fc0d0aa00fef32ca4aa870
Author: Vladimir N. Makarov
Date: Fri Jan 10 10:36:24 2025 -0500
[PR118017][LRA]: Fix test for i686
My previous patch for PR118017 contains a test which fails on i686. The patch fixes this
Hi Tobias,
On 07/01/2025 12:13, Tobias Burnus wrote:
Paul-Antoine Arras wrote:
This is a followup to
ed49709acda OpenMP: C++ front-end support for dispatch + adjust_args.
The call to cp_parser_omp_dispatch only belongs in
cp_parser_omp_construct. In
cp_parser_pragma, handle PRAGMA_OMP_DISPATC
The following were found compiling SPEC CPU 2017 with valgrind.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
* tree-vect-slp.cc (vect_analyze_slp): Release saved_stmts
vector.
(vect_build_slp_tree_2): Release new_oprnds_info when not
used.
---
gcc/tr
The following fixes memory leaks found compiling SPEC CPU 2017 with
valgrind.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
* df-core.cc (rest_of_handle_df_finish): Release dflow for
problems without free function (like LR).
* gimple-crc-optimization.cc (c
On 09/01/2025 23:04, Richard Sandiford wrote:
+ gcc_assert (imm != 0);
The constraints do allow 0, so I'm not sure this assert is safe.
Certainly we shouldn't usually get unfolded instructions, but strange
things can happen with fuzzed options.
Does the code mishandle that case? It looke
On Fri, Jan 10, 2025 at 3:27 PM Qing Zhao wrote:
>
>
>
> > On Jan 10, 2025, at 03:00, Richard Biener
> > wrote:
> >
> > On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wrote:
> >>
> >>
> >>
> >>> On Jan 9, 2025, at 14:10, Jeff Law wrote:
> >>>
> >>>
> >>>
> >>> On 1/9/25 10:48 AM, Qing Zhao wrote:
>
Ah whoops- I didn't see this before sending off V4 just now, my apologies.
I'll try my best to get this implemented before the end of the day so that
it doesn't miss the deadline.
On 09/01/2025 23:04, Richard Sandiford wrote:
Akram Ahmad writes:
In the above example, subtraction replaces the a
> On 10 Jan 2025, at 15:54, Wilco Dijkstra wrote:
>
> ping
>
>
> Add AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS and
> AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT
> to the baseline tuning since all modern cores use it. Fix the neoverse512tvb
> tuning to be
> like Neoverse V1/V2.
For neovers
On Fri, 10 Jan 2025 at 14:51, Jonathan Wakely wrote:
>
> On Sun, 8 Dec 2024 at 15:36, Jan Hubicka wrote:
> >
> > Hi,
> > std::vector has independent implementation for bool which has its won
> > size/capacity functions. I updated them to add __builtin_unreachable to
> > announce that size is nev
> On 10 Jan 2025, at 15:30, Richard Sandiford wrote:
>
> Wilco Dijkstra writes:
>> As a minor cleanup remove Cortex-A57 FMA steering pass. Since Cortex-A57 is
>> pretty old, there isn't any benefit of keeping this.
>>
>> Passes regress & bootstrap, OK for commit?
>>
>> gcc:
>> * config.gcc
ping
Add AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS and
AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT
to the baseline tuning since all modern cores use it. Fix the neoverse512tvb
tuning to be
like Neoverse V1/V2.
gcc/ChangeLog:
* config/aarch64/aarch64-tuning-flags.def (AARCH64_EXTRA_TU
ping
Add FULLY_PIPELINED_FMA to tune baseline - this is a generic feature that is
already enabled for some cores, but benchmarking it shows it is faster on all
modern cores (SPECFP improves ~0.17% on Neoverse V1 and 0.04% on Neoverse N1).
Passes regress & bootstrap, OK for commit?
gcc/ChangeLo
On Sun, 8 Dec 2024 at 15:36, Jan Hubicka wrote:
>
> Hi,
> std::vector has independent implementation for bool which has its won
> size/capacity functions. I updated them to add __builtin_unreachable to
> announce that size is never more than max_size. However while testing the
> code
> I notice
1 - 100 of 154 matches
Mail list logo
