On Thu, 9 Jan 2025, Zhou Zhao wrote:
>
> 在 2025/1/8 下午6:30, Richard Biener 写道:
> > On Wed, 8 Jan 2025, Zhou Zhao wrote:
> >
> >> 在 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, 赵洲 wrot
>From 929fb2091ffe50a35a1b2dae1f1ce20357bc435b Mon Sep 17 00:00:00 2001
From: shynur
Date: Thu, 9 Jan 2025 14:11:38 +0800
Subject: [PATCH] Avoid unused-variable-error when configured with
'CFLAGS=-DNDEBUG'
---
libgomp/target.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --g
Thank you all.
Jim
Jeff Law 於 2025年1月8日 週三 上午5:51寫道：
>
>
>
> On 1/2/25 12:13 AM, Tsung Chun Lin wrote:
> > Don't use the QI vector if its size is equal to UNITS_PER_WORD for
> > better code generation.
> >
> > Before patch:
> >
> > vsetivlizero,4,e8,mf4,ta,ma
> > vmv.v.i v1,0
> > addi
On 11/27/24 12:29 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14/13?
OK.
-- >8 --
Here we end up ICEing at instantiation time for the call to
f ultimately because we wrongly consider the call to be
non-dependent, and so we specializ
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
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
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
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
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.
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
> -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
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
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
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
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 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 --
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 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
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
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
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/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 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/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
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
"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
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.
---
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
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/
Documenting the status quo.
PR target/65181
gcc/testsuite/
* gcc.target/nvptx/alloca-2-O1.c: New.
---
gcc/testsuite/gcc.target/nvptx/alloca-2-O1.c | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/nvptx/alloca-2-O1.c
d
Hi!
On 2015-08-21T15:31:06-0400, Nathan Sidwell wrote:
> 1) alloca. PTX defines but doesn't implement support. and if one passes
> types
> suitable for a 64-bit ABI ptxas emits errors. This patch gives a clear error
> at
> compilation time, rather than an obscure failure later.
> --- confi
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_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "x.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Some issues caught by a check from another patch:
In the convert_like_internal bad_p handling, we are iterating from outside
to inside, so once we recurse into convert_like we need to stop looping.
In build_ramp_function, we're assigning R
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
If the result of build_stub_object gets printed by %E it looks something
like '(A&&)1', which seems confusing. Let's instead print it as
'std::declval()' since that's how the library writes the same idea.
gcc/cp/ChangeLog:
* metho
On Wed, Jan 8, 2025 at 3:08 AM Jakub Jelinek wrote:
>
> On Wed, Jan 08, 2025 at 10:17:59AM +0100, Richard Biener wrote:
> > > As mentioned in the PR, the a r<< (bitsize-b) to a r>> b and similar
> > > match.pd optimization which has been introduced in GCC 15 can introduce
> > > UB which wasn't the
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
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_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) "x.ii":14:17 discrim 1 283 {*addsi_1}
(exp
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
Hi,
On 21 Dec 2024, at 17:35, 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 n
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 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.
> > > When diagnosing
The previous fix only worked for C, for C++ we need to add more
information to the underlying type so that
finish_class_member_access_expr accepts it.
This patch makes gcc.target/arm/mve/intrinsics/pr118332.c pass in C++
mode.
gcc/ChangeLog:
PR target/118332
* config/arm/arm-mve-
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.
> > When diagnosing -Wformat-security warning, we try to print instantiation
> > context, whic
On Fri, Jan 03, 2025 at 10:46:27PM +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs due to re-entering diagnostics.
> When diagnosing -Wformat-security warning, we try to print instantiation
> context, which calls tsubst with tf_none, but that in the end calls
> cp_build_function_
Wilco Dijkstra writes:
> Hi Richard,
>
>> ...I still think we should avoid testing can_create_pseudo_p.
>> Does it work with the last part replaced by:
>>
>> if (!DECIMAL_FLOAT_MODE_P (mode))
>> {
>> if (aarch64_can_const_movi_rtx_p (src, mode)
>> || aarch64_float_const_represent
On Wed, Jan 08, 2025 at 10:33:53AM +0100, Jakub Jelinek wrote:
>
> As mentioned in the PR, there is a *.mod incompatibility between GCC 14 and
> GCC 15, at least when using iso_c_binding or iso_fortran_env intrinsic
> modules, because new entries have been added to those modules in the middle,
> c
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.
> ---
> gcc/fortran/module.cc | 13 ++---
Hi all,
I like to take Jakub's patch a little bit further and add two things, that
annoy me:
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 po
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
> try when checking the assembler for section
On Wed, Dec 11, 2024 at 10:19 AM Patrick Palka wrote:
>
> On Wed, 27 Nov 2024, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk/14/13?
>
> Ping.
Ping.
>
> It occurred to me that another way to fix this PR might be to tweak the
> overlo
On Wed, 8 Jan 2025, Patrick Palka wrote:
> On Thu, Dec 12, 2024 at 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.
Oops, does not seem worth fixing _on release branches_ rat
On Tue, Dec 17, 2024 at 11:04 AM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk/14/13?
Ping.
>
> -- >8 --
>
> Here during partial substitution of the requires-expression (as part of
> CTAD constraint rewriting) we segfault from the INDIR
On Thu, Dec 12, 2024 at 3:29 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk and perhpas 14?
Ping.
>
> -- >8 --
>
> When we encounter an unexpected (likely templated) tree code during
> constexpr evaluation we currently ICE even in rel
On Thu, Dec 12, 2024 at 3:29 PM Patrick Palka wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk/14?
Ping.
>
> 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
> s
On Thu, Dec 12, 2024 at 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.
Ping.
>
> -- >8 --
>
> In the first testcase we're overeagerly diagnosing qualified name lookup
> failure f
On Thu, Dec 12, 2024 at 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 no
> On Jan 7, 2025, at 07:29, Richard Biener wrote:
>
> On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jan 6, 2025, at 11:01, Richard Biener wrote:
>>>
>>> On Mon, Jan 6, 2025 at 3:43 PM Qing Zhao wrote:
> On Jan 6, 2025, at 09:21, Jeff Law wrote:
>>
On Wed, Jan 08, 2025 at 04:34:18PM +0100, Jakub Jelinek wrote:
> I'm testing for that instead:
> --- gcc/module.cc.jj 2025-01-08 15:23:54.511732946 +0100
> +++ gcc/module.cc 2025-01-08 16:32:14.963984426 +0100
> @@ -7122,9 +7122,11 @@ use_iso_fortran_env_module (void)
>
>i = 0;
> #defin
I wanted to ping this patch series. Thanks.
-Andi
On Wed, Jan 08, 2025 at 04:09:36PM +0100, Andre Vehreschild wrote:
> One of the issues are lines:
>
> module.cc 7125-7130: Here it is assumed that the signed and unsigned types are
> adjacent maybe?!
>
> I have changed this:
>
> diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
> index
Hi Kyrill,
Thanks for the feedback on V2. I found a pattern which works for
the open-coded signed arithmetic, and I've implemented the other
feedback you provided as well.
I've send the modified patch in this thread as the SVE patch [2/2]
hasn't been changed, but I'm happy to send the entire V3 p
On Tue, 2025-01-07 at 10:44 +0800, Lulu Cheng wrote:
> After changing this cost from 1 to 3, the performance of spec2006
> 401 473 416 465 482 can be improved by about 2% on LA664.
Would this fix https://gcc.gnu.org/PR114978 (or at least make it
latent)?
>
> Add option '-maddr-reg-reg-cost='.
>
> 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 ();
> > > > }
> >
One of the issues are lines:
module.cc 7125-7130: Here it is assumed that the signed and unsigned types are
adjacent maybe?!
I have changed this:
diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
index c4312b641c1..05bc802957e 100644
--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.
On Wed, Jan 08, 2025 at 03:48:46PM +0100, Andre Vehreschild wrote:
> Hi,
>
> I have added this small patch (attached). Unfortunately I got regressions
>
> some in iso_fortran_env_8.f90
> and several in unsigned_NN.f90 tests.
>
> Just retesting w/o my patch and already seeing the iso_fortran_env
On Tue, Jan 07, 2025 at 06:52:29PM -0500, David Malcolm wrote:
> On Tue, 2025-01-07 at 15:08 -0500, Marek Polacek wrote:
> > > @@ -4548,22 +4553,28 @@ error_args_num (location_t loc, tree
> > > fndecl, bool too_many_p)
> > > == DECL_NAME (TYPE_NAME (DECL_CONTEXT
> > > (fndecl)
> > >
Hi,
I have added this small patch (attached). Unfortunately I got regressions
some in iso_fortran_env_8.f90
and several in unsigned_NN.f90 tests.
Just retesting w/o my patch and already seeing the iso_fortran_env one again.
I am also not totally sure, that I applied both your patches correctly.
On 1/8/25 19:48, Andrew Carlotti wrote:
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
On 08/01/2025 13:37, Christophe Lyon wrote:
> On Wed, 8 Jan 2025 at 14:17, Richard Earnshaw (lists)
> wrote:
>>
>> On 19/12/2024 12:17, Christophe Lyon wrote:
>>> Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
>>> to compile on arm-linux-gnueabihf with
>>> fatal error: gnu/st
On 08/01/2025 13:56, Tamar Christina wrote:
>> -Original Message-
>> From: Richard Earnshaw (lists)
>> Sent: Wednesday, January 8, 2025 1:18 PM
>> To: Christophe Lyon ; gcc-patches@gcc.gnu.org;
>> Richard Sandiford ; Tamar Christina
>> ; Andre Simoes Dias Vieira
>> ; ktkac...@nvidia.com;
>
On Wed, Dec 18, 2024 at 2:55 PM Aleksandar Rakic
wrote:
>
> Hi,
>
> > >
> > > Hi,
> > >
> > > I think I managed to fix indentation from the previous version.
> > >
> > > When comparing the tables showing the candidates for the group 1
> > > before and after applying this patch, it can be observed
Hi!
On 2022-12-02T13:03:14+0100, I wrote:
> Generally PASS with:
>
> $ ptxas --version
> ptxas: NVIDIA (R) Ptx optimizing assembler
> Copyright (c) 2005-2018 NVIDIA Corporation
> Built on Sun_Sep__9_21:06:46_CDT_2018
> Cuda compilation tools, release 10.0, V10.0.145
>
> ..., an
On Wed, Jan 08, 2025 at 03:16:46PM +0100, Mikael Morin wrote:
> I think your patch is enough, we don't need to target same-bytes formats
> between module versions.
I can confirm the ICE on the small reproducer I've posted is gone with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/6729
Andrew Carlotti writes:
> 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 aggress
Hi!
On 2024-12-06T12:29:12+0100, I wrote:
> --- a/gcc/config/nvptx/nvptx.opt
> +++ b/gcc/config/nvptx/nvptx.opt
> march-map=sm_50
> -Target RejectNegative Alias(misa=,sm_35)
> +Target RejectNegative Alias(misa=,sm_37)
Pushed to trunk branch commit 59a4089ccab5a8ae3ddfa7b1b762caf2125a49a7
"nvptx
On 1/8/25 2:34 AM, Richard Sandiford wrote:
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
On Tue, Jan 07, 2025 at 03:20:35PM -0800, Andi Kleen wrote:
> > There is one case I didn't handle and I'd like to discuss.
> > The initial commit to enable this new extension also changed
> > cp_parser_asm_specification_opt to use cp_parser_asm_string_expression.
> > That function doesn't have anyt
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__ ((no
Le 08/01/2025 à 14:13, Jakub Jelinek a écrit :
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
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_* elt
> 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)
> > {
> > int b = a
On Mon, Dec 9, 2024 at 11:15 PM Lewis Hyatt wrote:
>
> On Mon, Dec 09, 2024 at 02:07:07PM +0100, Richard Biener wrote:
> > On Tue, Dec 3, 2024 at 2:42 PM Richard Biener
> > wrote:
> > >
> > > On Tue, Dec 3, 2024 at 2:07 PM Lewis Hyatt wrote:
> > > >
> > > > On Tue, Dec 03, 2024 at 01:28:28PM +01
On 19/12/2024 12:17, Christophe Lyon wrote:
> The vect testsuite adds -mfpu=neon before the arm_v8_3a_complex_neon
> flags via check_vect_support_and_set_flags, so before this change
> testcases are compiled with -mfpu=neon (and no -march/-mfloat-abi
> flag) with an arm-linux-gnueabihf toolchain co
> -Original Message-
> From: Richard Earnshaw (lists)
> Sent: Wednesday, January 8, 2025 1:18 PM
> To: Christophe Lyon ; gcc-patches@gcc.gnu.org;
> Richard Sandiford ; Tamar Christina
> ; Andre Simoes Dias Vieira
> ; ktkac...@nvidia.com;
> raman...@nvidia.com
> Subject: Re: [PATCH 3/4] arm
On Wed, Jan 08, 2025 at 02:35:56PM +0100, Mark Wielaard wrote:
> > --- gcc/dwarf2out.cc.jj 2025-01-02 11:23:35.541251268 +0100
> > +++ gcc/dwarf2out.cc2025-01-07 10:09:16.866866563 +0100
> > @@ -8755,6 +8755,14 @@ break_out_comdat_types (dw_die_ref die)
> > unit = new_die (DW_T
On Wed, 8 Jan 2025 at 14:17, Richard Earnshaw (lists)
wrote:
>
> On 19/12/2024 12:17, Christophe Lyon wrote:
> > Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
> > to compile on arm-linux-gnueabihf with
> > fatal error: gnu/stubs-soft.h: No such file or directory
> > because
Hi Jakub,
On Tue, 2025-01-07 at 20:22 +0100, Jakub Jelinek wrote:
> DWARF has voted in yesterday https://dwarfstd.org/issues/241209.1.html ,
> which is basically just a guarantee that the DWARF 6 draft
> DW_AT_language_{name,version} attribute codes and content of
> https://dwarfstd.org/languages-
On 19/12/2024 12:17, Christophe Lyon wrote:
> Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
> to compile on arm-linux-gnueabihf with
> fatal error: gnu/stubs-soft.h: No such file or directory
> because they are actually compiled with
> -mfloat-abi=softfp -mfpu=auto -mcpu=unse
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
> 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
On 19/12/2024 12:17, Christophe Lyon wrote:
> These two testcases have twice the same dg-add-options
> arm_v8_3a_complex_neon, the patch removes one of them.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/complex/complex-operations-run.c: Remove duplicate
> dg-add-options arm_v8_3a_co
libstdc++-v3/ChangeLog:
* include/bits/move.h (__addressof, forward, forward_like, move)
(move_if_noexcept, addressof): Add always_inline attribute.
Replace _GLIBCXX_NODISCARD with [[__nodiscard__]].
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/bits/mov
On 19/12/2024 12:17, Christophe Lyon wrote:
> The test uses floats, not fp16 so it should use arm_v8_3a_complex_neon
> instead of arm_v8_3a_fp16_complex_neon.
>
> This makes it PASS on arm-linux-gnueabihf instead of being UNRESOLVED.
>
> gcc/testsuite/ChangeLog:
> * gcc.dg/vect/comple
On Thu, 12 Dec 2024 at 00:05, Jonathan Wakely wrote:
>
> Any std::span constructor with a runtime length has a precondition
> that the length is equal to N (except when N == std::dynamic_extent).
>
> Currently every constructor with a runtime length does:
>
> if constexpr (extent != dynamic_extent
libstdc++-v3/ChangeLog:
* include/std/span: Fix indentation.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/std/span | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libstdc++-v3/include/std/span b/libstdc++-v3/include/std/span
index 4b40
libstdc++-v3/ChangeLog:
PR libstdc++/118260
* python/hook.in: Run 'skip' commands for some simple accessor
functions.
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/python/hook.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/libstdc++-v3/python/hook.i
The std-clib.cc module definition file assumes that all names are
available unconditionally, but that's not true for all targets. Use the
same preprocessor conditions as are present in the headers.
A similar change is needed in std.cc.in for the features that
depend on the SSO std::string, guard
On Wed, 18 Dec 2024 at 21:19, Jonathan Wakely wrote:
>
> std::regex builds a cache of equivalence classes by calling
> std::regex_traits::transform_primary(c) for every char, which then
> calls std::collate::transform which calls strxfrm. On several
> targets strxfrm fails for non-ASCII characters
1 - 100 of 155 matches
Mail list logo
