Based on the feedback we got, we would like to re-alias avx10.x to 512
bit in the future. This leaves the current avx10.1 alias to 256 bit
inconsistent. Since it has been there for GCC 14.1 and GCC 14.2,
we decide to deprecate avx10.1 alias. The current proposal is not
adding it back in the future,
Hi all,
According to the previous feedback on our RFC for AVX10 option adjustment
and discussion with LLVM, we finalized how we are going to handle that.
The overall direction is to re-alias avx10.x alias to 512 bit and only
using -mno-avx10.x to disable everything instead of the current confusin
On Wed, 12 Feb 2025, Andrew Pinski wrote:
> On Wed, Feb 12, 2025 at 4:04 AM Richard Biener wrote:
> >
> > The PR indicates a very specific issue with regard to SSA coalescing
> > failures because there's a pre IV increment loop exit test. While
> > IVOPTs created the desired IL we later simplify
>>> Other thoughts?
>>
>> The docs seem to hint TARGET_SCHED_CAN_SPECULATE_INSN is meant for stuff
>> we can't/don't model in the pipeline, but I have no idea how to model
>> the VL=0 case there.
> Maybe so, but what Edwin is doing looks sensible enough. It wouldn't be
> the first time a hook
On 2/13/25 20:46, Jeff Law wrote:
>> BTW what exactly is speculative scheduling ? As in what is it actually
>> trying to
>> schedule ahead ?
> In simplest terms assume we have this kind of graph
>
> 0
> / \
>1-->2
>
>
> The scheduler knows how to build scheduling regions, essentially
On Thu, 13 Feb 2025, Jonathan Wakely wrote:
> On Tue, 11 Feb 2025 at 05:59, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/version.def (ranges_cache_latest): Define.
> >
Hi,
If only apply the first and second patches, the code will not compile.
Otherwise LGTM.
Thanks!
在 2025/2/13 下午5:41, Xi Ruoyao 写道:
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
The SCMPU instruction doesn't change the C and Z flags when the
incoming length is zero, which means the insn will produce a
value based upon the existing flag values.
As a quick kludge, adjust these flags to ensure a zero result in this
case.
Signed-off-by: Keith Packard
---
gcc/config/rx/rx.m
As mentioned in avx10.1 option deprecate patch, based on the feedback
we got, we would like to re-alias avx10.x to 512 bit.
For -mno- options, also mentioned in the previous patch, it is confusing
what it is disabling when it comes to avx10. So we will only provide
-mno-avx10.x options from AVX10.
Ping.
I have incorporated review comments from Peter in this revised patch. The
comment was to remove -mvsx option from dg-options as this is implied by
-mcpu=power8.
Ok for trunk?
Regards,
Surya
On 09/01/25 8:53 pm, Surya Kumari Jangala wrote:
> Ping
>
> On 02/12/24 2:20 pm, Surya Kumari Jang
Don't assume that stack slots can only be accessed by stack or frame
registers. We first find all registers defined by stack or frame
registers. Then check memory accesses by such registers, including
stack and frame registers.
gcc/
PR target/109780
PR target/109093
* config/i386/i386.cc (ix86_
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.
Add option '-maddr-reg-reg-cost='.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Add
option '-maddr-reg-reg-cost='.
* config/loongarch
On Thu, Feb 13, 2025 at 12:48:44PM +0100, Richard Biener wrote:
> So what this basically does is ensure we mark DECL_VALUE_EXPR when
> VAR is marked which isn't done when marking a tree node.
>
> That you special-case the hashtable walker is a workaround for
> us not being able to say
>
> struct
On 2/13/25 14:17, Robin Dapp wrote:
Other thoughts?
>>> The docs seem to hint TARGET_SCHED_CAN_SPECULATE_INSN is meant for stuff
>>> we can't/don't model in the pipeline, but I have no idea how to model
>>> the VL=0 case there.
>> Maybe so, but what Edwin is doing looks sensible enough. It
Split the implementation of the function loongarch_cpu_cpp_builtins into two
parts:
1. Macro definitions that do not change (only considering 64-bit architecture)
2. Macro definitions that change with different compilation options.
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (bu
v1 -> v2:
1. Move __loongarch_{arch,tune} _LOONGARCH_{ARCH,TUNE}
__loongarch_{div32,am_bh,amcas,ld_seq_sa} and
__loongarch_version_major/__loongarch_version_minor to update function.
2. Fixed PR118843.
3. Add testsuites.
v2 -> v3:
1. Modify test cases (pr118828-3.c pr118828-4.c).
Lulu Cheng
PR target/118828
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (loongarch_pragma_target_parse):
Update the predefined macros.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr118828.c: New test.
* gcc.target/loongarch/pr118828-2.c: New test.
*
PR target/118843
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc
(loongarch_update_cpp_builtins): Fix macro definition issues.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr118843.c: New test.
---
gcc/config/loongarch/loongarch-c.cc | 27
gcc/ChangeLog:
* config/loongarch/loongarch-target-attr.cc
(loongarch_pragma_target_parse): Move to ...
(loongarch_register_pragmas): Move to ...
* config/loongarch/loongarch-c.cc
(loongarch_pragma_target_parse): ... here.
(loongarch_register_pragmas
Gerald Pfeifer writes:
> On Mon, 11 Nov 2024, Sam James wrote:
>> Request that reporters try `-fsanitize=address,undefined` rather than
>> just `-fsanitize=undefined` when reporting bugs. We get invalid bug
>> reports which ASAN would've caught sometimes, even if it's less often
>> than where UBS
On Thu, Feb 13, 2025 at 1:58 AM H.J. Lu wrote:
>
> x86 conditional branch (jcc) target can be either a label or a symbol.
> Add a pass to fold tail call with jcc by turning:
>
> jcc .L6
> ...
> .L6:
> jmp tailcall
>
> into:
>
> jcc tailcall
>
> After basic block
Applied the following avr news to gcc-15:
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 7638d3d5..41425257 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -500,6 +500,10 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
>-msplit-lds
On Thu, Feb 13, 2025 at 5:31 PM Uros Bizjak wrote:
>
> On Thu, Feb 13, 2025 at 1:58 AM H.J. Lu wrote:
> >
> > x86 conditional branch (jcc) target can be either a label or a symbol.
> > Add a pass to fold tail call with jcc by turning:
> >
> > jcc .L6
> > ...
> > .L6:
> > jmp
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
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
On Tue, 11 Feb 2025 at 05:59, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (ranges_cache_latest): Define.
> * include/bits/version.h: Regenerate.
> * include/std/
On 12/02/2025 11:01, Christophe Lyon wrote:
> Almost a copy/paste from the recent aarch64 version of this patch,
> this one is a bit more intrusive because it also introduces
> arm_general_gimple_fold_builtin.
>
> With this patch,
> gcc.target/arm/aes_xor_combine.c scan-assembler-not veor
> passes
On Wed, Feb 05, 2025 at 10:53:24AM -0800, Kees Cook wrote:
> On Wed, Feb 05, 2025 at 12:59:58PM +0100, Jakub Jelinek wrote:
> > Kees, any progress on this?
>
> I need to take another run at it. I got stalled out when I discovered
> that I array-of-char-arrays attributes got applied at the "wrong"
On Thu, 13 Feb 2025, Jakub Jelinek wrote:
> On Thu, Feb 13, 2025 at 12:48:44PM +0100, Richard Biener wrote:
> > So what this basically does is ensure we mark DECL_VALUE_EXPR when
> > VAR is marked which isn't done when marking a tree node.
> >
> > That you special-case the hashtable walker is a w
On 2/13/25 1:47 AM, Robin Dapp wrote:
Other thoughts?
The docs seem to hint TARGET_SCHED_CAN_SPECULATE_INSN is meant for stuff
we can't/don't model in the pipeline, but I have no idea how to model
the VL=0 case there.
Maybe so, but what Edwin is doing looks sensible enough. It wouldn't be
On Wed, 12 Feb 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Tamar Christina
> > Sent: Wednesday, February 12, 2025 3:20 PM
> > To: Richard Biener
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: RE: [PATCH v2]middle-end: delay checking for alignment to load
> > [PR11846
On 2/13/25 5:12 AM, Vineet Gupta wrote:
On 2/13/25 14:17, Robin Dapp wrote:
Other thoughts?
The docs seem to hint TARGET_SCHED_CAN_SPECULATE_INSN is meant for stuff
we can't/don't model in the pipeline, but I have no idea how to model
the VL=0 case there.
Maybe so, but what Edwin is doing l
> The vsevl pass is LCM based. So it's not allowed to add a vsetvl on a
> path that didn't have a vsetvl before. Consider this simple graph.
>
> 0
> / \
>2-->3
>
> If we have need for a vsetvl in bb2, but not bb0 or bb3, then the vsetvl
> will land in bb4. bb0 is not a valid inserti
A compare with zero may be taken as a sign bit test by
fold_truth_andor_for_ifcombine, but the operand may be extended from a
narrower field. If the operand was narrower, the bitsize will reflect
the narrowing conversion, but if it was wider, we'll only know whether
the field is sign- or zero-ex
> Yeah, I remember the same issue with the rounding-mode setter placement.
>
> Wouldn't that be fixable by requiring a dummy/wildcard/dontcare vsetvl in bb3
> (or any other block that doesn't require one)? Such a dummy vsetvl would be
> fusible with every other vsetvl. If there are dummy vsetvls
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
Some vect-simd-clone tests fail when targeting ancient x86 variants,
because the expected transformations only take place with -msse4 or
higher.
So arrange for these tests to take an -msse4 option on x86, so that
the expected vectorization takes place, but decay to a compile test if
vect.exp wou
Hi!
The following testcase ICEs, because we have multiple levels of
DECL_VALUE_EXPR VAR_DECLs:
character(kind=1) id_string[1:.id_string] [value-expr: *id_string.55];
character(kind=1)[1:.id_string] * id_string.55 [value-expr:
FRAME.107.id_string.55];
integer(kind=8) .id_string [value-expr:
I got tired of repeating the conditional that recognizes ia32 or
x86_64, and introduced 'x86' as a shorthand for that, adjusting all
occurrences in target-supports.exp, to set an example. I found some
patterns that recognized i?86* and x86_64*, but I took those as likely
cut&pastos instead of tr
Hi!
On Tue, Feb 11, 2025 at 11:47:09PM +0100, Jason Merrill wrote:
> The implementation in r15-3840 used a novel technique of wrapping the entire
> range-for loop in a CLEANUP_POINT_EXPR, which confused the coroutines
> transformation. Instead let's use the existing extend_ref_init_temps
> mechan
LGTM!
Thanks!
在 2025/2/11 下午2:34, Xi Ruoyao 写道:
Since r15-1120, multi-word shifts/rotates produces PLUS instead of IOR.
It's generally a good thing (allowing to use our alsl instruction or
similar instrunction on other architectures), but it's preventing us
from using bytepick. For example, if
On Wed, Feb 12, 2025 at 12:07:53AM +0100, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> Since -frange-for-ext-temps has been causing trouble, let's not enable it
> by default in pre-C++23 GNU modes for GCC 15, and also allow disabling it in
> C++23 and up.
Hi, Ruoyao:
When will it be convenient for you to submit the v2 version of the patch?
I am planning to merge the current patches and then test the optimal values
for -malign-{functions,labels,jumps,loops} on that basis.
在 2025/2/12 上午3:30, Xi Ruoyao 写道:
On Tue, 2025-02-11 at 16:52 +0800, Lul
Apart from minor updates, this patch is primarily an important caveat
about binutils PR ld/32580, which has broken the binutils 2.44 ld on
Solaris/x86.
Tested on i386-pc-solaris2.11, committed to trunk.
Rainer
--
--
On Thu, Feb 13, 2025 at 9:31 AM H.J. Lu wrote:
>
> Don't assume that stack slots can only be accessed by stack or frame
> registers. We first find all registers defined by stack or frame
> registers. Then check memory accesses by such registers, including
> stack and frame registers.
>
> gcc/
>
Old versions of Solaris ld and GNU ld didn't support CIEv3 in .eh_frame.
To avoid this breaking the build
[build] Default to DWARF 4 on Solaris if linker supports CIEv3
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00669.html
checked for the necessary linker support, defaulting to
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
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.
v1 =
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
Alexandre Oliva writes:
> 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
The existing usage comment for check-function-bodies is presumably a
typo, as it doesn't match existing uses. Fix it.
Tested on x86_64-linux-gnu. I'm going to install it as obvious if there
are no objections in the next 24 hours.
for gcc/testsuite/ChangeLog
* lib/scanasm.exp (check
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.
This is not suitable for LASX where lasx_xvpick has a different
semantic.
gcc/ChangeLog:
* config/loongarch/simd.md (LVEC): New define_mode_attr.
(simdfmt_as_
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 Thu, 2025-02-13 at 17:01 +0800, Lulu Cheng wrote:
> Hi, Ruoyao:
>
> When will it be convenient for you to submit the v2 version of the
> patch?
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675672.html
>
> I am planning to merge the current patches and then test the optimal
> value
On 2/12/25 23:30, Jason Merrill wrote:
External email: Use caution opening links or attachments
In the new `check_known_compiler_messages_nocache` procedure I use some
Why is it not enough to look for the message with "[regexp" like
check_alias_available does?
Jason
The goal was that I
On Thu, 13 Feb 2025, Richard Biener wrote:
> On Wed, 12 Feb 2025, Andrew Pinski wrote:
>
> > On Wed, Feb 12, 2025 at 4:04 AM Richard Biener wrote:
> > >
> > > The PR indicates a very specific issue with regard to SSA coalescing
> > > failures because there's a pre IV increment loop exit test. W
The PR indicates a very specific issue with regard to SSA coalescing
failures because there's a pre IV increment loop exit test. While
IVOPTs created the desired IL we later simplify the exit test into
the undesirable form again. The following fixes this up during RTL
expansion where we try to im
On Thu, 13 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because we have multiple levels of
> DECL_VALUE_EXPR VAR_DECLs:
> character(kind=1) id_string[1:.id_string] [value-expr: *id_string.55];
> character(kind=1)[1:.id_string] * id_string.55 [value-expr:
> FRAME.107.
On 2/13/2025 4:12 AM, Vineet Gupta wrote:
On 2/13/25 14:17, Robin Dapp wrote:
Other thoughts?
The docs seem to hint TARGET_SCHED_CAN_SPECULATE_INSN is meant for stuff
we can't/don't model in the pipeline, but I have no idea how to model
the VL=0 case there.
Maybe so, but what Edwin is doing
On 2/13/25 11:57 AM, Robin Dapp wrote:
I did try adding some additional logic to adjust the way vsetvl fusion
occurs across basic blocks in these scenarios i.e. performing the
fusion in the opposite manner (breaking lcm guarantees); however, from
my testing, fusing two vsetvls didn't actually
On Tue, Nov 26, 2024 at 05:35:50PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> As the manual states, using "-fhardened -fstack-protector" will produce
> a warning because -fhardened wants to enable -fstack-protector-strong,
> but it can
Hi!
The ggc_set_mark call in gt_value_expr_mark_2 is actually wrong, that
just marks the VAR_DECL itself, but doesn't mark the subtrees of it (type
etc.). So, I think we need to test gcc_marked_p for whether it is marked
or not, if not marked walk the DECL_VALUE_EXPR and then gt_ggc_mx mark
the V
Am 12.02.25 um 21:49 schrieb Jerry D:
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
This is not a review, just some random comments on the testsuite changes
by your patch
Increment LABEL_NUSES when using minipool_vector_label to avoid the zero
use count on minipool_vector_label.
PR target/118866
* config/arm/arm.cc (arm_reorg): Increment LABEL_NUSES when
using minipool_vector_label.
--
H.J.
From 91907dc6d948bf256dfa95a161af783df44b1b65 Mon Sep 17 00:00:00 2001
Fr
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r15-6707 I changed this function to use build_stub_object to more simply
produce the right type, but it occurs to me that forward_parm would be even
better, specifically for the diagnostic.
This changes nothing with respect to PR118791.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
gcc/cp/ChangeLog:
* tree.cc (handle_init_priority_attribute): Use OPT_prio_ctor_dtor.
gcc/testsuite/ChangeLog:
* g++.dg/special/initp1.C: Test disabling -Wprio-ctor-dtor.
---
gcc/cp/tree.cc| 3 ++-
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This test added by r15-7507 doesn't get some expected diagnostics if we
implicitly make I(E) constexpr.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class72.C: Disable -fimplicit-constexpr.
---
gcc/testsuite/g++.dg/cpp2a/nontyp
From: Ed Catmur
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Per https://wiki.dwarfstd.org/C++0x_Variadic_templates.md
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:
17$: DW_TAG_formal_parameter_pack
DW_AT_name("args")
18$: DW_TAG_formal_param
On Thu, 13 Feb 2025 06:46:10 PST (-0800), jeffreya...@gmail.com wrote:
On 2/13/25 1:47 AM, Robin Dapp wrote:
Other thoughts?
The docs seem to hint TARGET_SCHED_CAN_SPECULATE_INSN is meant for stuff
we can't/don't model in the pipeline, but I have no idea how to model
the VL=0 case there.
Ma
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, February 13, 2025 4:55 PM
> To: Tamar Christina
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org; nd
>
> Subject: Re: [PATCH v2]middle-end: delay checking for alignment to load
> [PR118464]
>
> Tamar Christina writes:
>
I added class jit_diagnostic_listener in r15-4760-g0b73e9382ab51c
but forgot to annotate one of the vfuncs with "override".
Fixed thusly.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7515-g6ac313525a1fae.
gcc/jit/ChangeLog:
PR other/116613
On Thu, Feb 06, 2025 at 04:30:47PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 21, 2025 at 04:59:16PM +0100, Jakub Jelinek wrote:
> > On Tue, Jan 07, 2025 at 01:49:04PM +0100, Jakub Jelinek wrote:
> > > On Wed, Dec 18, 2024 at 12:15:15PM +0100, Jakub Jelinek wrote:
> > > > On Fri, Dec 06, 2024 at 05:
On 2/13/25 11:13 AM, Palmer Dabbelt wrote:
FWIW, that's what tripped up my "maybe there's a functional bug here"
thought. It looks like the scheduling is seeing
bne t0, x0, end
vsetvli t1, t2, ...
vsetvli x0, t2, ...
...
end:
vsetvli x0, t2, ...
and thinking it's s
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we have:
template
struct X{
T val;
decltype(auto) value(){
return (val);
}
};
where the return type of value should be 'int &' since '(val)' is an
expression, not a name, and decltype(aut
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,0(a0)
sub a1,a1,a5 <-- a1 poten
Hi Jerry,
This is OK.
Pushed as r15-7509. Thanks for the review!
It would be good to get confirmation that the lapack builds
now. I use to be set up here to do that, but dont have it at the moment.
It checked the original test case, that passed. But yes, a Lapack
tester would be nice.
From: Zixing Liu
gcc/ChangeLog:
* config/rs6000/rs6000-d.cc: define ELFv1 and ELFv2
version identifiers according to the target options.
gcc/testsuite/ChangeLog:
* gdc.dg/ppcabi.d: Add a test to test for code generation
correctness when using IEEE 128 and new
From: Zixing Liu
This patch was formerly known as
"gdc: define ELFv1, ELFv2 and D_PPCUseIEEE128 versions for powerpc",
due to new developments in https://github.com/dlang/dmd/pull/20826,
compiler is now not required to mark D_PPCUseIEEE128 version identifier.
Instead, correctly setting real.mant_
On 2/10/25 2:25 AM, Andre Vehreschild wrote:
[PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635]
I have applied all patches. Regression tested OK here.
From patch 5 there was one reject:
patching file gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90
Hunk #1 FAILED at 39
Hello world,
this was an interesting regression. It came from my recent
patch, where an assert was triggered because a procedure artificial
dummy argument generated for a global symbol did not have the
information if if was a function or a subroutine. Fixed by
adding the information in gfc_get_
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Some things in the front-end use a TARGET_EXPR to create a temporary, then
refer to its TARGET_EXPR_SLOT separately later; in this testcase,
maybe_init_list_as_range does. So we need to handle that pattern in
extend_all_temps.
PR c
On 2/13/25 8:19 AM, Robin Dapp wrote:
The vsevl pass is LCM based. So it's not allowed to add a vsetvl on a
path that didn't have a vsetvl before. Consider this simple graph.
0
/ \
2-->3
If we have need for a vsetvl in bb2, but not bb0 or bb3, then the vsetvl
will land in bb
Vladimir Makarov writes:
> On 2/7/25 12:18 PM, Richard Sandiford wrote:
>> 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.
>>
>> I've included an aarch64 vers
On 2/13/25 11:59 AM, Thomas Koenig wrote:
Hello world,
this was an interesting regression. It came from my recent
patch, where an assert was triggered because a procedure artificial
dummy argument generated for a global symbol did not have the
information if if was a function or a subroutine.
Tamar Christina writes:
>> -Original Message-
>> That said, I'm quite sure we don't want to have a dr->target_alignment
>> that isn't power-of-two, so if the comput doesn't end up with a
>> power-of-two value we should leave it as the target prefers and
>> fixup (or fail) during vectorizab
> I did try adding some additional logic to adjust the way vsetvl fusion
> occurs across basic blocks in these scenarios i.e. performing the
> fusion in the opposite manner (breaking lcm guarantees); however, from
> my testing, fusing two vsetvls didn't actually remove the fused
> expression f
On Thu, 13 Feb 2025 07:38:13 PST (-0800), jeffreya...@gmail.com wrote:
On 2/13/25 8:19 AM, Robin Dapp wrote:
The vsevl pass is LCM based. So it's not allowed to add a vsetvl on a
path that didn't have a vsetvl before. Consider this simple graph.
0
/ \
2-->3
If we have need f
Ping.
On Thu, Feb 06, 2025 at 11:26:48AM -0500, Marek Polacek wrote:
> Ping.
>
> On Tue, Jan 21, 2025 at 11:05:46AM -0500, Marek Polacek wrote:
> > Ping.
> >
> > On Fri, Jan 10, 2025 at 03:07:52PM -0500, Marek Polacek wrote:
> > > Ping.
> > >
> > > On Fri, Dec 20, 2024 at 08:58:05AM -0500, Mare
On 2/12/25 7:03 AM, Robin Dapp wrote:
Hi,
in PR118832 we have another instance of the problem already noticed in
PR117878. We sometimes use e.g. expand_simple_binop for vector
operations like shift or and. While this is usually OK, it causes
problems when doing it late, e.g. during LRA.
In
On 2/12/25 2:22 PM, Jakub Jelinek wrote:
I agree that the most common cases should be all the arguments the same
type. I was working under the assumption that the args would be compatible
types already, forgetting that IFNs are different in that regard than other
gimple ops. I wouldn't wan
On 2/13/25 11:37 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Here we have:
template
struct X{
T val;
decltype(auto) value(){
return (val);
}
};
where the return type of value should be 'int &' sinc
On Thu, Feb 13, 2025 at 5:17 PM Uros Bizjak wrote:
>
> On Thu, Feb 13, 2025 at 9:31 AM H.J. Lu wrote:
> >
> > Don't assume that stack slots can only be accessed by stack or frame
> > registers. We first find all registers defined by stack or frame
> > registers. Then check memory accesses by su
The code example here does:
```
if (begin == end) __builtin_unreachable();
std::list nl(begin, end);
for (auto it = nl.begin(); it != nl.end(); it++)
{
...
}
/* Remove the first element of the list. */
nl.erase(nl.begin());
```
And we get a warning because because we jump threaded the case were w
On 2/13/25 1:42 PM, Harald Anlauf wrote:
Am 12.02.25 um 21:49 schrieb Jerry D:
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
This is not a review, just some random comme
On 2/14/25 04:58, Jeff Law wrote:
> I'd guess it more work than it'd be worth. We're just not seeing
> vsetvls being all that problematical on our design. I do see a lot of
> seemingly gratutious changes in the vector config, but when we make
> changes to fix that we generally end up with wors
On 2/12/25 7:58 AM, Richard Biener wrote:
For the testcase in question which uses a fold-left vectorized
reduction of a reverse iterating loop we'd need two forwprop
invocations to first bypass the permute emitted for the reverse
iterating loop and then to decompose the vector load that only
f
Hi all,
When AVX512 is not explicitly set, we should not take EVEX512 bit into
consideration when checking vector size. It will solve the intrin header
file reporting warnings when compiling with -Wsystem-headers.
However, there is side effect on the usage for '-march=xxx -mavx10.1-256',
where xx
Pushed to r15-7521..r15-7524
在 2025/2/13 下午8:59, Lulu Cheng 写道:
v1 -> v2:
1. Move __loongarch_{arch,tune} _LOONGARCH_{ARCH,TUNE}
__loongarch_{div32,am_bh,amcas,ld_seq_sa} and
__loongarch_version_major/__loongarch_version_minor to update function.
2. Fixed PR118843.
3. Add testsuites.
v2 -
Pushed to r15-7525.
在 2025/2/13 下午4:40, Lulu Cheng 写道:
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.
Add option '-maddr-reg-reg-cost='.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Add
1 - 100 of 103 matches
Mail list logo
