On Fri, Feb 07, 2025 at 05:51:19PM -0600, Peter Bergner wrote:
> On 2/7/25 4:02 PM, Michael Meissner wrote:
> > (define_predicate "invert_fpmask_comparison_operator"
> > - (match_code "ne,unlt,unle"))
> > + (ior (match_code "ne")
> > + (and (match_code "unlt,unle")
> > + (match_test
On Fri, Feb 07, 2025 at 05:51:19PM -0600, Peter Bergner wrote:
> On 2/7/25 4:02 PM, Michael Meissner wrote:
> > (define_predicate "invert_fpmask_comparison_operator"
> > - (match_code "ne,unlt,unle"))
> > + (ior (match_code "ne")
> > + (and (match_code "unlt,unle")
> > + (match_test
>> But I don't think offering the -mvec-elide-x0 option is beneficial.
>> I'd just enable this change unconditionally. Or, in the unlikely
>> event there's a uarch that benefits from the old code generation, this
>> would be better handled as a consequence of -mtune than as a new
>> top-level opti
A couple of Vector pseudoinstructions use x0 scalar which being regfile
crosser could be inefficient on certain wider uarches.
Use the imm 0 form, which should be functionally equivalent.
pseudoinsnorig insn with x0 this patch
On Fri, Feb 7, 2025 at 1:57 PM H.J. Lu wrote:
>
> For
>
> ---
> int f(int);
>
> int advance(int dz)
> {
> if (dz > 0)
> return (dz + dz) * dz;
> else
> return dz * f(dz);
> }
> ---
>
> Before r15-1619-g3b9b8d6cfdf593
>
> advance(int):
> pushrbx
> mov
> -Original Message-
> From: Jakub Jelinek
> Sent: Friday, February 7, 2025 4:08 PM
> To: Liu, Hongtao
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] i386: Fix ICE with conditional QI/HI vector maxmin
> [PR118776]
>
> Hi!
>
> The following testcase ICEs starting with GCC 12 since r
在 2025/2/7 下午7:51, Xi Ruoyao 写道:
Now that C default is C23, so we can no longer use LSX/LASX instructions
for these operations as the standard disallows raising INEXACT
exceptions. So LoongArch is no longer suitable for these effective
targets.
Fix the test failures on gcc.dg/vect/vect-roundi
Replacing x0 with 0 when possible is fine; it should never hurt and
might help on some uarches. (Of course, future versions of those
uarches will eventually be forced to improve handling of x0, anyway,
since as Vineet notes, some of the interesting cases don't have
immediate forms.)
But I don't t
On Fri, 2025-02-07 at 07:04 -0700, Jeff Law wrote:
>
> On 2/7/25 5:51 AM, Oleg Endo wrote:
> > > Hi,
> > >
> > > Can the issue be resolved in a target independent manner as suggested
> > > below?
> > > Or is it better to deal with this in the target code?
> That seems like a pretty heavy hamm
On 2/7/25 4:02 PM, Michael Meissner wrote:
> (define_predicate "invert_fpmask_comparison_operator"
> - (match_code "ne,unlt,unle"))
> + (ior (match_code "ne")
> + (and (match_code "unlt,unle")
> + (match_test "!HONOR_NANS (DFmode) || !TARGET_P9_VECTOR"
Is it always safe to use
On 2/7/25 4:04 PM, Simon Martin wrote:
Hi Jason,
On 7 Feb 2025, at 14:21, Jason Merrill wrote:
On 2/6/25 3:05 PM, Simon Martin wrote:
Hi Jason,
On 6 Feb 2025, at 16:48, Jason Merrill wrote:
On 2/5/25 2:21 PM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 21:23, Jason Merrill wrote:
O
This is version 2 of the patch.
Changes from the V1 patch:
1: I added a test in invert_fpmask_comparison_operator to not allow UNLE and
UNLT unless fast math is in force. Both invert_fpmask_comparison_operator and
fpmask_comparison_operator are used to form floating point conditional moves on
Po
On 2/7/25 11:01 AM, Georg-Johann Lay wrote:
Am 07.02.25 um 17:12 schrieb Jeff Law:
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
if ((a = ira_curr_regno_allocno_
Hi Jason,
On 7 Feb 2025, at 14:21, Jason Merrill wrote:
> On 2/6/25 3:05 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 6 Feb 2025, at 16:48, Jason Merrill wrote:
>>
>>> On 2/5/25 2:21 PM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 21:23, Jason Merrill wrote:
> On 2/4/
Hi Steve,
Am 07.02.25 um 21:39 schrieb Steve Kargl:
On Fri, Feb 07, 2025 at 09:31:12PM +0100, Harald Anlauf wrote:
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks reasonable.
While it is a really old bug but wrong code, I'd like to backport
this also at least to 14-branch. Any
On Fri, Feb 07, 2025 at 09:31:12PM +0100, Harald Anlauf wrote:
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
Looks reasonable.
> While it is a really old bug but wrong code, I'd like to backport
> this also at least to 14-branch. Any reservations?
If it passes regression testing,
Dear all,
the initialization of allocatable non-deferred character with NULL
when being a component of a derived type used a wrong path instead
of properly initializing with a null pointer and produced really
weird code.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
While it is a really o
I pushed the following fix as obvious after testing the build and verifying
the warning was silenced.
Peter
rs6000: Add cast to avoid pointer to integer comparison warning [PR117674]
libgcc/
PR target/117674
* config/rs6000/linux-unwind.h (ppc_backchain_fallback): Add cast to
Applied this one.
Johann
--
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 362f345c..6a41ac97 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -376,6 +376,12 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
Code generation for the 32-bi
On Mon, Feb 03, 2025 at 01:04:08PM +, Alfie Richards wrote:
>
> The `record` argument in maybe_version_function was intended to allow
> controlling recording the relationship of versions. However, it only
> exercised this if both input funcitons were already marked as versioned,
> and this sam
Am 07.02.25 um 17:12 schrieb Jeff Law:
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
if ((a = ira_curr_regno_allocno_map[regno]) == NULL)
{
Richard Sandiford writes:
> FWIW, here's a very rough initial version of the kind of thing
> I was thinking about. Hopefully the hook documentation describes
> the approach. It's deliberately (overly?) flexible.
Argh! I forgot:
diff --git a/gcc/ira-color.cc b/gcc/ira-color.cc
index de34be31f4
On Fri, Feb 7, 2025 at 9:20 AM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > Really nice analysis! Thanks for writing this up.
> >
> > Sorry for the big quote below, but:
> >
> > Jan Hubicka writes:
> >> [...]
> >> PR117081 is about regression in povray. The reducted testcase:
> >>
On 2/6/25 5:35 PM, Jan Hubicka wrote:
Register 3 (first caller saved) has cost 11000. This comes from:
add_cost = ((ira_memory_move_cost[mode][rclass][0]
+ ira_memory_move_cost[mode][rclass][1])
* saved_nregs / hard_regno_nregs (
On Sun, 2025-02-02 at 21:47 -0800, Andi Kleen wrote:
> >
> > If I reading this right, calls to get_next_line lead to insertions
> > into
> > the ring buffer whilst the buffer is empty or the last line in the
> > ring
> > buffer cache is m_line_num - 1.
> >
> > There are a few places where we upda
For thumb2, popping a single low register off the stack should prefer
POP over LDR to mirror the behaviour of the PUSH on entry. This saves
a couple of bytes in the resulting image. This is a relatively niche
case as it's rare to push a single low register onto the stack, but
still worth getting
My earlier change for making the compiler prefer
POP {PC}
over
LDR PC, [SP], #4
had a slightly unexpected consequence in that we now also call
arm_emit_multi_reg_pop to handle single register pops when the
register is not PC. This exposed a latent bug in this function w
Richard Sandiford writes:
> Really nice analysis! Thanks for writing this up.
>
> Sorry for the big quote below, but:
>
> Jan Hubicka writes:
>> [...]
>> PR117081 is about regression in povray. The reducted testcase:
>>
>> void foo (void);
>> void bar (void);
>>
>> int
>> test (int a)
>> {
>>
> > gcc/ChangeLog:
> >
> > 2025-01-20 Martin Jambor
> >
> > PR ipa/118097
> > * ipa-cp.cc (ipa_get_jf_arith_result): Adjust comment.
> > (ipa_get_jf_pass_through_result): Removed.
> > (ipa_value_from_jfunc): Use directly ipa_get_jf_arith_result, do
> > not specify operation t
> >
> >0: 89 f8 mov%edi,%eax<--- move1
> >2: 48 83 ec 18 sub$0x18,%rsp <--- stack
> > frame creation
> >6: f7 d8 neg%eax
> >8: 89 44 24 0c mov%eax,0xc(%rsp) <--- spil
A couple of Vector pseudoinstructions use x0 scalar which being regfile
crosser could be inefficient on certain wider uarches.
Use the imm 0 form, which should be functionally equivalent.
pseudoinsn orig insn with x0 this patch
---
On 2/7/25 6:15 AM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
This testcase wasn't running, because adl-5_a had the wrong extension.
adl-5_d should have been reporting an error because 'frob' is only
visible from within the 'hidden' module but this was m
On 2/3/25 2:09 AM, Richard Sandiford wrote:
Jeff Law writes:
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
if ((a = ira_curr_regno_allocno_map[regno]) == NULL)
{
a = ira_create_allocno (regno, fals
Hello,
and a gentle ping, please.
Martin
On Fri, Jan 24 2025, Martin Jambor wrote:
> Hi,
>
> the following version of the patch has one of the testcase adjusted to
> use long long and so pass also on 32bit i386 (and hopefully 32bit Arm
> too), otherwise it has not changed from what I posted on W
On 2/7/25 9:28 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
On 1/31/25 8:46 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Happy to remove the custom inform for lambdas, but I felt that the
original messa
On 2/7/25 9:19 AM, Nathaniel Shead wrote:
On Fri, Feb 07, 2025 at 08:05:54AM -0500, Jason Merrill wrote:
On 1/31/25 8:44 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
My fix for this issue in r15-7147 turns out to not be quite sufficient;
On 2/6/25 1:37 PM, Jakub Jelinek wrote:
Hi!
cp_parser_range_for temporarily reverts IDENTIFIER_BINDING changes
to hide the decls from the structured bindings from lookup during
parsing of the expression after :
If there are 2 or more name independent decls, we undo IDENTIFIER_BINDING
for the sam
On 2/6/25 1:21 PM, Jakub Jelinek wrote:
On Thu, Feb 06, 2025 at 10:40:52AM -0500, Jason Merrill wrote:
Thanks.
@@ -7202,6 +7210,28 @@ cxx_eval_loop_expr (const constexpr_ctx
cxx_eval_constant_expression (ctx, expr, vc_prvalue,
non_constant_p
On 05/02/25 13:43 +, Jonathan Wakely wrote:
On 28/10/24 17:15 +, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
I noticed that the libstdc++ patch is essentially separate and figured I
could send it upstream earlier to give reviewers more time to look at
it.
I am still working on
Because basic_ostream::sentry::~sentry is implicitly noexcept, we can't
let any exceptions escape from it, or the program would terminate. If
the streambuf's sync() function throws, or if it returns an error and
setting badbit in the stream state throws, then the program would
terminate.
LWG 835 i
From: Giuseppe D'Angelo
The code was caching the result of `invoke(proj, *it)` in a local
`auto &&` variable. The problem is that this may create dangling
references, for instance in case `proj` is `std::identity` (the common
case) and `*it` produces a prvalue: lifetime extension does not
apply h
Add a comment referencing PR 111050, to ensure the fix made by
r12-9903-g1be57348229666 doesn't get reverted.
libstdc++-v3/ChangeLog:
PR libstdc++/111050
* include/bits/hashtable_policy.h (_Hash_node_value_base): Add
comment about always_inline attributes.
---
Tested x86_
Thanks Jeff and Andrew, committed as the CI passed.
Pan
-Original Message-
From: Andrew Waterman
Sent: Friday, February 7, 2025 9:54 PM
To: Jeff Law
Cc: Li, Pan2 ; gcc-patches@gcc.gnu.org;
juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v1] RISC-V:
On Fri, Feb 07, 2025 at 08:14:23AM -0500, Jason Merrill wrote:
> On 1/31/25 8:46 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > Happy to remove the custom inform for lambdas, but I felt that the
> > original message (which suggests that defi
On 2/3/25 2:09 AM, Richard Sandiford wrote:
So yeah, I think the first question is why ira_build_conflicts isn't
kicking in for this register or (if it is) why we still get register 0.
So pulling on this thread leads me into the code that sets up
ALLOCNO_WMODE in create_insn_allocnos:
On Fri, Feb 07, 2025 at 08:05:54AM -0500, Jason Merrill wrote:
> On 1/31/25 8:44 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > My fix for this issue in r15-7147 turns out to not be quite sufficient;
> > static member templ
On 2/6/25 3:50 AM, Alexandre Oliva wrote:
On leon3-elf and presumably on other targets, the test fails due to
differences in calling conventions and other reasons, that add extra
gimple stmts that prevent the expected optimization at the expected
point. The optimization takes place anyway, j
On 2/7/25 5:51 AM, Oleg Endo wrote:
Hi,
Can the issue be resolved in a target independent manner as suggested below?
Or is it better to deal with this in the target code?
That seems like a pretty heavy hammer though. For that reason alone I
think this is going to need some discussion and I
On 7 Feb 2025, at 14:17, Jason Merrill wrote:
> On 2/7/25 4:41 AM, Simon Martin wrote:
>> We've been rejecting the following valid code since GCC 4
>>
>> === cut here ===
>> struct A {
>>explicit A (int);
>>operator void* () const;
>> };
>> void foo (const A& x) {
>>auto res = 0 ? x :
On Fri, Feb 7, 2025 at 5:51 AM Jeff Law wrote:
>
>
>
> On 2/7/25 5:59 AM, Andrew Waterman wrote:
> > This patch runs counter to the ABI spec, which states that vxrm is not
> > preserved across calls and is volatile upon function entry [1]. vxrm
> > does not play the same role as frm plays in the
On Fri, Feb 07, 2025 at 02:48:22PM +0100, Richard Biener wrote:
> The following makes the dlfcn.h explicitly requested which avoids
> build failure when JIT is enabled but plugin support disabled as
> currently the include is conditional on plugin support.
>
> I've built GCC with JIT enabled and p
On 2/7/25 5:59 AM, Andrew Waterman wrote:
This patch runs counter to the ABI spec, which states that vxrm is not
preserved across calls and is volatile upon function entry [1]. vxrm
does not play the same role as frm plays in the calling convention.
(I won't get into the rationale in this ema
The following makes the dlfcn.h explicitly requested which avoids
build failure when JIT is enabled but plugin support disabled as
currently the include is conditional on plugin support.
I've built GCC with JIT enabled and plugin support disabled as well
as the other way around successfully with t
On 2/6/25 1:52 PM, Jakub Jelinek wrote:
On Thu, Feb 06, 2025 at 01:45:59PM -0500, Marek Polacek wrote:
--- gcc/cp/constexpr.cc.jj 2025-02-05 13:14:34.771198185 +0100
+++ gcc/cp/constexpr.cc 2025-02-06 09:53:03.236587121 +0100
@@ -9717,7 +9717,8 @@ potential_constant_expression_1 (tree t,
On 2/6/25 1:44 PM, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled since r12-6325 stopped
preevaluating the initializers for new expression.
If evaluating the initializers throws, there is a correct cleanup
for that, but it is marked CLEANUP_EH_ONLY. While in standard
C++ that is
On 2/6/25 1:48 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In a member-specification of a class, a noexcept-specifier is
a complete-class context. Thus we delay parsing until the end of
the class via our DEFERRED_PARSE mechanism; see cp_
On 2/6/25 1:49 PM, Jakub Jelinek wrote:
Hi!
My r15-3046 change regressed the first half of the following testcase.
When it calls decl_attributes, it doesn't handle attributes with
dependent arguments correctly and so is now rejected that N is not
a constant integer during template parsing.
I've
On 2/6/25 3:05 PM, Simon Martin wrote:
Hi Jason,
On 6 Feb 2025, at 16:48, Jason Merrill wrote:
On 2/5/25 2:21 PM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 21:23, Jason Merrill wrote:
On 2/4/25 3:03 PM, Jason Merrill wrote:
On 2/4/25 11:45 AM, Simon Martin wrote:
On 4 Feb 2025, at
Hi Andrew,
Andrew Stubbs wrote:
I just realized that I'm assuming that -march=gfx1100 object files
will link with -march=gfx11-generic libraries, and produce gfx1100
binaries. Is this not the case?
Currently not: lld checks that the ELF ISA and flags (xnack, sramecc, …)
are identical and, if
On 2/7/25 4:41 AM, Simon Martin wrote:
We've been rejecting the following valid code since GCC 4
=== cut here ===
struct A {
explicit A (int);
operator void* () const;
};
void foo (const A& x) {
auto res = 0 ? x : 0;
}
int main () {
A a{5};
foo(a);
}
=== cut here ===
The problem
On 1/31/25 8:46 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Happy to remove the custom inform for lambdas, but I felt that the
original message (which suggests that defining it within a class should
make it OK) was unhelpful here.
Similarly the 'i
On 07/02/2025 12:53, Tobias Burnus wrote:
Hi Andrew,
Andrew Stubbs wrote:
I think the correct place for this whole concept might be in the
MULTILIB_MATCHES configuration option, not in mkoffload.
In any case, mkoffload needs to know about this; if only the driver
('gcc') knows about it, it c
On 1/31/25 8:45 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
In r15-7202 we made lambdas between a template parameter scope and a
class/function/initializer be considered TU-local, in lieu of working
out how to mangle them to the su
On 1/31/25 8:44 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
My fix for this issue in r15-7147 turns out to not be quite sufficient;
static member templates apparently go down a different code path and
need their own handling.
PR
This patch runs counter to the ABI spec, which states that vxrm is not
preserved across calls and is volatile upon function entry [1]. vxrm
does not play the same role as frm plays in the calling convention.
(I won't get into the rationale in this email, but the rationale isn't
especially importan
Hi Andrew,
Andrew Stubbs wrote:
I think the correct place for this whole concept might be in the
MULTILIB_MATCHES configuration option, not in mkoffload.
In any case, mkoffload needs to know about this; if only the driver
('gcc') knows about it, it comes too late for the early debug file
wri
> Hi,
>
> Can the issue be resolved in a target independent manner as suggested below?
> Or is it better to deal with this in the target code?
>
> Best regards,
> Oleg Endo
>
> On Fri, 2024-09-27 at 00:26 -0400, Pietro Monteiro wrote:
> > The prefetch instruction that is emitted by __builtin_pre
Since PR116142 has been fixed, now we can add the standard names so the
compiler will generate better code if the result of a widening
production is reduced.
gcc/ChangeLog:
* config/loongarch/simd.md (even_odd): New define_int_attr.
(vec_widen_mult__): New define_expand.
gcc/test
Like what we've done for {lsx_,lasx_x}v{add,sub,mul}l{ev,od}, use
special predicates and TImode RTL instead of hard-coded const vectors
and UNSPECs.
Also reorder two operands of the outer plus in the template, so combine
will recognize {x,}vadd + {x,}vmulw{ev,od} => {x,}vmaddw{ev,od}.
gcc/ChangeL
On 07/02/2025 11:44, Tobias Burnus wrote:
Andrew Stubbs wrote:
On 07/02/2025 09:40, Tobias Burnus wrote:
This patch permits loading generic ISA code objects - by just
trying whether the runtime accepts it. If not, it fails with
an error. - The error messages should be a bit more helpful in
som
On 07/02/2025 10:17, Tobias Burnus wrote:
This patch is part of the following series (not yet in mainline);
this patch depends on the first one, but only makes sense if both are in:
* "[gcn] Add gfx9-generic and generic-associated gfx*"
(email subject: "Re: [Patch] [GCN] Handle generic ISA na
On 07/02/2025 11:16, Tobias Burnus wrote:
Andrew Stubbs wrote:
Otherwise, this patch seems fine (I have not reviewed the new magic
numbers and settings.)
As Andrew mentioned via chat, we also have to update the 'amdhsa.version'.
Well, that's what the attached patch does. (I have no idea which
These pattern definitions are tediously long, invoking 32 UNSPECs and
many hard-coded long const vectors. To simplify them, at first we use
the TImode vector operations instead of the UNSPECs, then we adopt an
approach in AArch64: using a special predicate to match the const
vectors for odd/even i
Despite it's just a special case of "a widening product of which the
result used for reduction," having these standard names allows to
recognize the dot product pattern earlier and it may be beneficial to
optimization. Also fix some test failures with the test cases:
- gcc.dg/vect/vect-reduc-chai
Like what we've done for {lsx_,lasx_x}v{add,sub,mul}l{ev,od}, use
special predicates instead of hard-coded const vectors.
gcc/ChangeLog:
* config/loongarch/lasx.md (lasx_xvpickev_b): Remove.
(lasx_xvpickev_h): Remove.
(lasx_xvpickev_w): Remove.
(lasx_xvpickev_w_f):
Like what we've done for {lsx_,lasx_x}v{add,sub,mul}l{ev,od}, use
special predicates and TImode RTL instead of hard-coded const vectors
and UNSPECs.
gcc/ChangeLog:
* config/loongarch/lasx.md (UNSPEC_LASX_XVHADDW_Q_D): Remove.
(UNSPEC_LASX_XVHSUBW_Q_D): Remove.
(UNSPEC_LASX
For
a = (v4si){0x, 0x, 0x, 0x}
we just want
vrepli.b $vr0, 0xdd
but the compiler actually produces a load:
la.local $r14,.LC0
vld $vr0,$r14,0
It's because we only tried vrepli.d which wouldn't work. Try all vrepli
instructions for const int vector
We have some vector instructions for operations on 128-bit integer, i.e.
TImode, vectors. Previously they had been modeled with unspecs, but
it's more natural to just model them with TImode vector RTL expressions.
For the preparation, allow moving V1TImode and V2TImode vectors in LSX
and LASX reg
This series is intended to fix some test failures on
vect-reduc-chain-*.c by adding the [su]dot_prod* expand for LSX and LASX
vector modes. But the code base of the related instructions was not
readable, so clean it up first (using the approach learnt from AArch64)
before adding the expands.
Boot
We agreed with LLVM developer to not enforce the architectural
dependencies between fp8 multiplication features, and they have already
been removed from LLVM and Binutils. Remove them from GCC as well.
I have bootstrapped and regression tested this. There are no test
result changes between GCC
Now that C default is C23, so we can no longer use LSX/LASX instructions
for these operations as the standard disallows raising INEXACT
exceptions. So LoongArch is no longer suitable for these effective
targets.
Fix the test failures on gcc.dg/vect/vect-rounding-*.c. For the old
standards or -ff
Andrew Stubbs wrote:
On 07/02/2025 09:40, Tobias Burnus wrote:
This patch permits loading generic ISA code objects - by just
trying whether the runtime accepts it. If not, it fails with
an error. - The error messages should be a bit more helpful in
some cases as before.
...
Also I think all
Tested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This testcase wasn't running, because adl-5_a had the wrong extension.
adl-5_d should have been reporting an error because 'frob' is only
visible from within the 'hidden' module but this was missed.
gcc/testsuite/ChangeLog:
* g++.dg/
On Fri, 7 Feb 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, February 5, 2025 1:15 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: RE: [PATCH]middle-end: delay checking for alignment to load
> > [PR118464]
>
Andrew Stubbs wrote:
Otherwise, this patch seems fine (I have not reviewed the new magic
numbers and settings.)
As Andrew mentioned via chat, we also have to update the 'amdhsa.version'.
Well, that's what the attached patch does. (I have no idea which tool /
library relies on it, but it makes
On 07/02/2025 09:40, Tobias Burnus wrote:
This patch is part of the following series (all unreviewed so far)
but can be independently applied:
* [Patch] [gcn] Fix gfx906's sramecc setting,
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675251.html
* "[gcn] Add gfx9-generic and gener
On Fri, Feb 7, 2025 at 11:00 AM Alexandre Oliva wrote:
>
> On Feb 6, 2025, Sam James wrote:
>
> > Richard Biener writes:
> >> On Thu, Feb 6, 2025 at 2:41 PM Alexandre Oliva wrote:
> >>>
> >>> On Jan 27, 2025, Richard Biener wrote:
> >>> > (I see the assert is no longer in the patch).
> >>>
>
On 07/02/2025 10:37, Tobias Burnus wrote:
Andrew Stubbs wrote:
The attached patch now adds gfx9-generic - alongside the existing
gfx{10-3,1}-generic and all gfx* that are enabled by those.
What happened to the documentation patch with the "Experimental"
markers? I'm still uncomfortable with a
Andrew Stubbs wrote:
The attached patch now adds gfx9-generic - alongside the existing
gfx{10-3,1}-generic and all gfx* that are enabled by those.
What happened to the documentation patch with the "Experimental"
markers? I'm still uncomfortable with adding so many untested devices,
so the doc
This patch is part of the following series (not yet in mainline);
this patch depends on the first one, but only makes sense if both are in:
* "[gcn] Add gfx9-generic and generic-associated gfx*"
(email subject: "Re: [Patch] [GCN] Handle generic ISA names in libgomp's
plugin-gcn.c";
this thr
> You mean the "rivoscibot/toolchain-ci-rivos-test" from the patchwork ? That
> looks great!
>
> https://patchwork.sourceware.org/project/gcc/patch/20250207082032.1450527-1-pan2...@intel.com/
Yes that one.
--
Regards
Robin
On Feb 6, 2025, Sam James wrote:
> Richard Biener writes:
>> On Thu, Feb 6, 2025 at 2:41 PM Alexandre Oliva wrote:
>>>
>>> On Jan 27, 2025, Richard Biener wrote:
>>> > (I see the assert is no longer in the patch).
>>>
>>> That's because the assert went in as part of an earlier patch. I tak
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-02-07 00:36
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Fix ratio in vsetvl fuse rule [PR115703].
Hi,
in PR115
On 07/02/2025 00:25, Tobias Burnus wrote:
After spending some time with the debugger, I am now convinced that
ROCm 6.3.2 does not yet support generic. The amd-staging branch at
https://github.com/ROCm/ROCR-Runtime/ support does, albeit only after
the tag rocm-6.3.2. However, the released ROCm 6.3
Thanks Robin.
> OK (unless the CI complains of course).
You mean the "rivoscibot/toolchain-ci-rivos-test" from the patchwork ? That
looks great!
https://patchwork.sourceware.org/project/gcc/patch/20250207082032.1450527-1-pan2...@intel.com/
Pan
-Original Message-
From: Robin Dapp
Sen
> Inspired by PR118103, the VXRM register should be treated almost the
> same as the FRM register, aka cooperatively-managed global register.
> Thus, add the VXRM to global_regs to avoid the elimination by the
> late-combine pass.
OK (unless the CI complains of course).
--
Regards
Robin
The following fixes a latent issue where we use ranges to verify
correctness of a vector conversion optimization. We rely on ranges
from 'op0' which for SLP is extracted from the representative stmt
which does not necessarily correspond to any actual scalar operation.
We also do not verify the ran
We've been rejecting the following valid code since GCC 4
=== cut here ===
struct A {
explicit A (int);
operator void* () const;
};
void foo (const A& x) {
auto res = 0 ? x : 0;
}
int main () {
A a{5};
foo(a);
}
=== cut here ===
The problem is that for COND_EXPR, add_builtin_candidate h
This patch is part of the following series (all unreviewed so far)
but can be independently applied:
* [Patch] [gcn] Fix gfx906's sramecc setting,
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675251.html
* "[gcn] Add gfx9-generic and generic-associated gfx*"
(email subject: "Re: [
Richard Sandiford writes:
> In particular, one thing that the examples above have in common is that
> they don't need to allocate a frame for local variables. That seems
> like it ought to be part of the mix. If we need to allocate a frame
> using addition anyway, then presumably one of the adva
1 - 100 of 110 matches
Mail list logo
