Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The caller of build_nop seems more interesting than that tiny function
itself.
gcc/cp/ChangeLog:
* cp-tree.h (build_nop): Add CXX_MEM_STAT_INFO.
* typeck.cc (build_nop): Add MEM_STAT_DECL.
---
gcc/cp/cp-tree.h | 2 +-
gcc/
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
While looking at another patch I noticed that on a few tests we were doing
nonsensical things like building a reference to a reference. Make sure we
catch that sooner. But let's be friendly in can_convert, since it doesn't
return a convers
On Wed, 2025-01-08 at 07:48 -0800, Andi Kleen wrote:
>
> I wanted to ping this patch series. Thanks.
>
> -Andi
>
Thanks for tha patches, and sorry about not getting back to you earlier
(I've been focusing on analyzing many 100s of build failures with GCC
15 relative to GCC 14)
Overall, the pat
When reading the spec, I somehow missed that we can already (spec wise)
obtain the OpenMP device number from an interop object; hence, implement
this. (For the question what happens if 'interop(omp_interop_none)' was
used, I opened an OpenMP spec issue #4459.)
When reading the spec, I realized th
From: Lingling Kong
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_expand_int_cfmovcc): Expand
to cfcmov pattern.
* config/i386/i386-opts.h (enum apx_features): New.
* config/i386/i386-protos.h (ix86_expand_int_cfmovcc): Define.
* config/i386/i386.cc (
From: Lingling Kong
Hi,
Appreciated to Richard's review, the v5 patch contaings below change:
1. Separate the maskload/maskstore emit out from noce_emit_cmove, add
a new function emit_mask_load_store in optabs.cc.
2. Follow the operand order of maskload and maskstore optab and takes
cond as pre
On Wed, Jan 08, 2025 at 07:47:27PM -0500, David Malcolm wrote:
> On Wed, 2025-01-08 at 07:48 -0800, Andi Kleen wrote:
> >
> > I wanted to ping this patch series. Thanks.
> >
> > -Andi
> >
>
> Thanks for tha patches, and sorry about not getting back to you earlier
> (I've been focusing on analyz
Am 08.01.25 um 19:18 schrieb Steve Kargl:
While working on f_c_string(), it never occurred to me
that the version number should have been bumped. Thanks
for the sleuthing you've done so far.
Same for me!
Best regards
Thomas
On Linux/x86_64,
f79f5b87efc690abc3b8d1b0f927f9348157348b is the first bad commit
commit f79f5b87efc690abc3b8d1b0f927f9348157348b
Author: Tobias Burnus
Date: Wed Jan 8 17:27:39 2025 +0100
OpenMP: Skip declare_variant's append_args it not variant substituted
caused
FAIL: c-c++-common/gomp
PR target/65181
gcc/
* config/nvptx/nvptx.h (STACK_SAVEAREA_MODE): '#define'.
* config/nvptx/nvptx.md [!TARGET_SOFT_STACK]
(save_stack_function): 'define_expand'.
(restore_stack_function): Handle '!TARGET_SOFT_STACK'.
---
gcc/config/nvptx/nvptx.h |
On 12/17/24 11:04 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14/13?
OK.
-- >8 --
Here during partial substitution of the requires-expression (as part of
CTAD constraint rewriting) we segfault from the INDIRECT_REF case of
convert_t
Documenting the status quo.
PR target/65181
gcc/testsuite/
* gcc.target/nvptx/__builtin_stack_save___builtin_stack_restore-1.c:
Add.
---
...tin_stack_save___builtin_stack_restore-1.c | 32 +++
1 file changed, 32 insertions(+)
create mode 100644
gc
Yes, all the RVV intrinsics have passed.
Committed, thanks juzhe.
xu...@eswincomputing.com
发件人： 钟居哲
发送时间： 2025-01-08 20:11
收件人： xuli1; gcc-patches
抄送： kito.cheng; palmer; Li, Pan2; xuli1
主题： Re: [PATCH] RISC-V: Refine registered_functions list for rvv overloaded
intrinsics.
Thanks for optimiz
Hi,
On 20 Dec 2024, at 20:56, Simon Martin wrote:
> Hi,
>
> On 20 Dec 2024, at 20:37, Simon Martin wrote:
>
>> We currently fail due to "infinite recursion" on the following invalid
>> code with -std=c++20 and above
>>
>> === cut here ===
>> template struct S { struct U { const S s; } u; };
>> S
On 1/8/25 10:16 AM, Jan Hubicka wrote:
On Wed, 8 Jan 2025, Jan Hubicka wrote:
On Tue, 10 Dec 2024, Jan Hubicka wrote:
Hi,
int:
struct foo
{
int a;
void bar() const;
~foo()
{
if (a != 42)
__builtin_abort ();
}
};
__attribute__ ((noinline))
void test(const struct foo a
Bootstrapped and regtested on x86_64-redhat-linux. Ok for master?
The FakeStack flag is not zeroed out when can_store_by_pieces()
returns false. Over time, this causes FakeStack::Allocate() to perform
the maximum number of loop iterations, significantly slowing down the
instrumented program.
Le 08/01/2025 à 18:37, Jakub Jelinek a écrit :
On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote:
gcc/fortran/ChangeLog:
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Prevent additional run
over (un-)signed ints and assign kind directly.
---
"Richard Earnshaw (lists)" writes:
> On 27/12/2024 21:47, Thiago Jung Bauermann wrote:
>> In 32-bit Arm assembly, the @ character is the start of a comment so
>> the section type needs to use the % character instead.
>>
>> configure.ac attempts to account for this difference by doing a second
>>
Le 08/01/2025 à 18:23, Andre Vehreschild a écrit :
First of all the recursive attr must not be set on vtypes, neither on module
ones nor anywhere else. Strictly speaking is a vtype recursive, because by its
extends member it references itself through a pointer. But it is guaranteed
that the base
On 12/12/24 2:34 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? The older regression does not seem worth fixing.
-- >8 --
In the first testcase we're overeagerly diagnosing qualified name lookup
failure for f from the current instantiat
On Thu, Jan 9, 2025 at 5:35 AM Jeff Law wrote:
>
>
>
> On 1/8/25 1:53 PM, H.J. Lu wrote:
> > Skip extension on stack pointer since we can't turn
> >
> > (insn 27 26 139 2 (parallel [
> > (set (reg/f:SI 7 sp)
> > (plus:SI (reg/f:SI 7 sp)
> > (const
Hello,
The attached patch adds _GLIBCXX26_CONSTEXPR, in preparation for adding
`constexpr` on some functions starting in C++26.
Thanks,
--
Giuseppe D'Angelo
From 61115549376a29558eb7753f525daf671c6da929 Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Wed, 1 Jan 2025 12:12:29 +0100
Subj
When CD-DCE creates forwarders to reduce false control dependences
it fails to update the irreducible state of edge and the forwarder
block in case the fowarder groups both normal (entry) and edges
from an irreducible region (necessarily backedges). This is because
when we split the first edge, if
Hello,
This patch adds constexpr to the stable_sort algorithms, implementing
P2562R1 for C++26. Tested on x86-64 Linux.
Thanks,
--
Giuseppe D'Angelo
From 951d76ee06abeda932f5c803bfe6d2691403c2e9 Mon Sep 17 00:00:00 2001
From: Giuseppe D'Angelo
Date: Tue, 31 Dec 2024 18:04:45 +0100
Subject: [P
Well, thinking about it, it smells like a side-effect of the 116669 fix. A type
getting the recursive marker enforces the generation of the vtype for it. I
don't see yet, why the iso_c_binding_C_funptr should be marked as recursive. I
will investigate. How much time do I have?
- Andre
On Wed, 8 J
On Wed, Jan 08, 2025 at 11:44:50AM +0100, Giuseppe D'Angelo wrote:
> The attached patch adds _GLIBCXX26_CONSTEXPR, in preparation for adding
> `constexpr` on some functions starting in C++26.
>
> Thanks,
> --
> Giuseppe D'Angelo
> From 61115549376a29558eb7753f525daf671c6da929 Mon Sep 17 00:00:00
On 08/01/2025 11:49, Jakub Jelinek wrote:
+#ifndef _GLIBCXX26_CONSTEXPR
+# if __cplusplus >= 202303L
Shouldn't that be 202400L instead? I mean that is what
-std=c++26/-std=gnu++26 predefines and has been historically what we've been
using for next version.
I think clang++ also predefines 202
Hi!
Based on the comments in the PR, I've tried to write a patch which would
try to keep backwards compatibility with the GCC 11-14 *.mod files.
Testcase was
module a
use, intrinsic :: iso_c_binding
end module a
module b
use, intrinsic :: iso_fortran_env
end module b
and zcat a.mod; zcat b.mo
Hello,
With Stage 3 nearing an end I was wondering what peoples perspective on
this patchset is.
Especially whether there's any chance of getting this in -- and what
should be done about the problematic codegen in target hooks when
compiling C++ (mentioned near the bottom of the original cover
On Wed, Jan 8, 2025 at 10:45 AM Jakub Jelinek wrote:
>
> Hi!
>
> Based on the comments in the PR, I've tried to write a patch which would
> try to keep backwards compatibility with the GCC 11-14 *.mod files.
>
> Testcase was
> module a
> use, intrinsic :: iso_c_binding
> end module a
> module b
On Wed, Jan 08, 2025 at 11:53:53AM +0100, Andre Vehreschild wrote:
> Well, thinking about it, it smells like a side-effect of the 116669 fix. A
> type
> getting the recursive marker enforces the generation of the vtype for it. I
> don't see yet, why the iso_c_binding_C_funptr should be marked as r
This patch skips redirect_to_specific clone for aarch64 and riscv,
because the optimisation has two flaws:
1. It checks the value of the "target" attribute, even on targets that
don't use this attribute for multiversioning.
2. The algorithm used is too aggressive, and will eliminate the
indirecti
On Wed, Jan 08, 2025 at 12:42:39PM +0100, Andre Vehreschild wrote:
> Er, call me stupid, but what is the easiest way to apply your patch? 'git am'
> on
> the part from the date-line to the end stripping your greetings, always leads
> to unrecognized patch format. Using `patch -p1` did not work eit
Le 08/01/2025 à 12:16, Andre Vehreschild a écrit :
That sounds like a feasible solution when finding the erroneous (to my belief)
setting of flag takes longer than expect.
Mikael, do you know your way around the module export stuff and can you point
me directly to the line in question? I haven't
Jeff Law writes:
> On 1/7/25 11:17 AM, Richard Sandiford wrote:
>> Andrew Carlotti writes:
>>> I forgot to include this in the earlier patch; is this ok for master (once
>>> the
>>> pass is merged, of course)?
>>>
>>> gcc/ChangeLog:
>>>
>>> * doc/passes.texi: Document hardreg PRE pass.
>>>
>
On Wed, Jan 08, 2025 at 10:47:39AM +0100, Richard Biener wrote:
> I wonder if we can somehow add some test coverage? Are .mod files
> target independent and thus can we include them in the testsuite?
They are, but they are compressed and having binary data in the testsuite
is a problem. But perh
在 2025/1/8 下午5:04, Richard Biener 写道:
On Wed, 8 Jan 2025, Zhou Zhao wrote:
在 2025/1/7 下午10:45, Richard Biener 写道:
On Thu, 2 Jan 2025, 赵洲 wrote:
Add Reviewer Richard Biener.
-原始邮件-
发件人: "Zhou Zhao"
发送时间:2025-01-02 19:37:07 (星期四)
收件人: gcc-patches@gcc.gnu.org
抄送: xry...@xry111.sit
This patch introduces support for LUTI2/LUTI4 ACLE for SVE2.
LUTI instructions are used for efficient table lookups with 2-bit
or 4-bit indices. LUTI2 reads indexed 8-bit or 16-bit elements from
the low 128 bits of the table vector using packed 2-bit indices,
while LUTI4 can read from the low 128
Tamar Christina writes:
>> >> i.e. we use separate address arithmetic and avoid UMOVs. Counting
>> >> two loads and one store for each element of the scatter store seems
>> >> like overkill for that.
>> >
>> > Hmm agreed..
>> >
>> > How about for stores we increase the load counts by count / 2?
>
Er, call me stupid, but what is the easiest way to apply your patch? 'git am' on
the part from the date-line to the end stripping your greetings, always leads
to unrecognized patch format. Using `patch -p1` did not work either. What am I
not seeing?
- Andre
On Wed, 8 Jan 2025 10:44:50 +0100
Jakub
Hi,
On 08/01/2025 13:06, Jonathan Wakely wrote:
I agree with using 202400L, for consistency with the actual defined
value, and because at a quick glance it's unclear whether 202303 is
the value for C++23 or not. You have to know that 202302 is the real
value to identify that this is "something l
Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
The full list of changes with the posted patches is
(first a.mod, then b.mod, 14 -> 15) below.
I have no idea what adds those __copy_* elts etc. and whether they could be
forced to be in the middle rather than at the end and what is an ABI break
and
Also add "@since C++11" to std::move, std::forward etc.
libstdc++-v3/ChangeLog:
* include/bits/move.h (forward, move, move_if_noexcept, addressof):
Add @since to Doxygen comments.
(forward_like): Add Doxygen comment.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Replace invalid
elements with .
* doc/html/*: Regenerate.
---
Pushed to trunk, backports to follow.
libstdc++-v3/doc/html/index.html | 4 ++--
libstdc++-v3/doc/html/manual/api.html | 4 ++--
libstdc++-
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, January 8, 2025 10:30 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: Fix costing of emulated gathers/scatters
> [PR118188]
>
> Tamar Ch
Documenting the status quo. This specific behavior relates to a 1994 change
(Subversion r7229, Git commit 15fc002672d643fd9d93d220027b5cd2aefc632c).
That one, however, isn't to blame here: we'd otherwise of course run into
nvptx' 'sorry, unimplemented: target cannot support alloca'.
PR ta
On 12/21/24 11:35 AM, Simon Martin wrote:
When erroring out due to an incomplete type, we add a contextual note
about the type. However, when the error is suppressed by
-Wno-template-body, the note remains, making the compiler output quite
puzzling.
This patch makes sure the note is suppressed i
On 1/8/25 2:17 PM, Marek Polacek wrote:
On Wed, Jan 08, 2025 at 07:40:32PM +0100, Jakub Jelinek wrote:
On Wed, Jan 08, 2025 at 01:33:15PM -0500, Marek Polacek wrote:
On Fri, Jan 03, 2025 at 10:46:27PM +0100, Jakub Jelinek wrote:
Hi!
The following testcase ICEs due to re-entering diagnostics.
On 12/12/24 3:28 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and perhpas 14?
OK for both.
-- >8 --
When we encounter an unexpected (likely templated) tree code during
constexpr evaluation we currently ICE even in release mode. But
PR target/65181
gcc/
* config/nvptx/nvptx.md [!TARGET_SOFT_STACK] (save_stack_block):
'define_expand'.
gcc/testsuite/
* gcc.target/nvptx/__builtin_stack_save___builtin_stack_restore-1.c:
Adjust.
---
gcc/config/nvptx/nvptx.md
On 12/12/24 4:08 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk only? The original testcase from the PR seems to compile
successfully on the release branches so I'm avoiding doing anything on
the release branches for now.
OK.
-- >8 --
Hi!
On 2016-05-20T18:09:26+0300, Alexander Monakov wrote:
> On Thu, 21 Apr 2016, Nathan Sidwell wrote:
>> On 04/20/16 12:59, Alexander Monakov wrote:
>> > This patch implements per-warp compiler-defined stacks under -msoft-stack
>> > option, and implements alloca on top of that.
> --- a/gcc/tests
On 12/12/24 3:28 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
This fixes the testcase in the PR but doesn't thoroughly fix the
underlying issue since if we replace fnPtr with e.g. a constexpr variable
so that the callee is truly pote
gcc/
* config/nvptx/nvptx-opts.h (enum ptx_version): Add
'PTX_VERSION_7_3'.
* config/nvptx/nvptx.cc (ptx_version_to_string)
(ptx_version_to_number): Adjust.
* config/nvptx/nvptx.h (TARGET_PTX_7_3): New.
* config/nvptx/nvptx.opt (Enum(ptx_versi
Hi!
On 2024-09-20T18:49:46+0200, I wrote:
> We'd like to raise nvptx code generation from PTX ISA 6.0, sm_30 "Kepler"
> to default PTX ISA 7.3, sm_52 "Maxwell", therefore CUDA 11.3 (2021-04).
> This is, primarily, so that we're able to use 'alloca' and related stack
> manipulation instructions, an
101 - 155 of 155 matches
Mail list logo
