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 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
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
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
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 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
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
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/
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
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 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
> -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
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_
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
在 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
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
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
> > 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
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)
>> {
>>
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
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 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:
> >>
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
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)
{
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, 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
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
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,
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
From: Pan Li
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.
For example as below code:
21 │
22 │ void compute (
Really nice analysis! Thanks for writing this up.
Sorry for the big quote below, but:
Jan Hubicka writes:
>> > +/* Implement TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE. */
>> > +
>> > +static int
>> > +ix86_ira_callee_saved_register_cost_scale (int)
>> > +{
>> > + return 1;
>> > +}
>> > +
>
> -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]
>
> On Wed, 5 Feb 2025, Tamar Christina wrote:
>
> [...]
On 06/02/2025 22:09, Tobias Burnus wrote:
ROCm 6.3.2 does not like my patch for reasons that I do not understand;
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675200.html
Until that's sorted, I decided to split off two obvious fixes;
I might suggest some further changes, but the full
Hi!
The following testcase ICEs starting with GCC 12 since r12-4526
although the bug has been introduced already in r12-2751.
The problem was in the addition of cond_ define_expand
which uses nonimmediate_operand predicates for both maxmin operands
for all VI1248_AVX512VLBW modes. It works fine w
> On Thu, Feb 6, 2025 at 11:40 PM Vladimir Makarov wrote:
> >
> >
> > On 2/6/25 4:54 PM, Richard Sandiford wrote:
> >
> > Vladimir Makarov writes:
> >
> > This is a complicated problem resulted in many tries to fix it in some
> > general way.
> >
> > In general I am agree with Surya's approach to
Hi Robin,
Thanks for your comment. I think your point is correct, especially the part
about SEWmin.
I will revise this patch again.
On Wed, Feb 5, 2025 at 4:18 PM Robin Dapp wrote:
> > Hi Robin,
> > Sorry, I should have simplified the problem by presenting it in terms of
> > Zve32x, because Zve3
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
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: [
Hello,
Should I continue using this email address to contact you?
Farhan Faruqui
> On 7 Feb 2025, at 01:04, Andrew Pinski wrote:
>
> With release checking we get an uninitialization warning
> inside aarch64_split_move because of jump threading for the case of
> `npieces==0`
> but `npieces` is never 0 (but there is no way the compiler can know that.
> So this fixes the iss
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
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
> 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
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 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
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
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
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
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
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
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
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):
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
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
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]
>
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/
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
> 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 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
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
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
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
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
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
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
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
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 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
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
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
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 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_
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:
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
> 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
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 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: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,
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 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 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/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: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
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
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
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 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
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 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
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 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 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 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
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_
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
1 - 100 of 110 matches
Mail list logo
