1.Added dg-do compile on LoongArch.
When binutils does not support vector instruction sets, an error occurs
because the assembler does not recognize vector instructions.
2.Added "-mlsx" option for vectorization on LoongArch.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/gen-vect-2.c:
gcc/testsuite/ChangeLog:
* gcc.dg/pr104992.c: Added additional "-mlsx" compilation options.
* gcc.dg/signbit-2.c: Dito.
* gcc.dg/tree-ssa/scev-16.c: Dito.
* gfortran.dg/graphite/vect-pr40979.f90: Dito.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
---
在 2024/1/12 下午7:42, Xi Ruoyao 写道:
在 2024-01-12星期五的 09:46 +0800，chenglulu写道：
I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS:
we need a target hook to tell the generic code
UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll
see millions lines of
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_split_symbol):
Assign the '/u' attribute to the mem.
gcc/testsuite/ChangeLog:
* g++.target/loongarch/got-load.C: New test.
---
gcc/config/loongarch/loongarch.cc | 5 +
Adds a few new testcases for some missed optimization regressions.
The analysis on how each should be optimized is in the testcases
themselves (and in the bug report).
Committed as obvious after running the testsuite to make sure they pass.
PR tree-optimization/107823
PR
This patch fixes the regression between GCC 13.2.0 and trunk GCC (GCC-14)
GCC 13.2.0:
lui a5,%hi(a)
li a4,19
sb a4,%lo(a)(a5)
li a0,0
ret
Trunk GCC:
vsetvli a5,zero,e8,mf2,ta,ma
li a4,-32768
vid.v v1
Since commits 2c3db94d9fd ("c: Turn int-conversion warnings into
permerrors") and 55e94561e97e ("c: Turn -Wimplicit-function-declaration
into a permerror") these tests fail with errors such as:
FAIL: gcc.target/arm/pr59858.c (test for excess errors)
FAIL: gcc.target/arm/pr65647.c (test for
On Linux/x86_64,
d14ef0987de2f6f2dac64f4f0f068b929078a01d is the first bad commit
commit d14ef0987de2f6f2dac64f4f0f068b929078a01d
Author: Tamar Christina
Date: Fri Jan 12 15:27:45 2024 +
testsuite: Make bitint early vect test more accurate
caused
FAIL:
On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
> >
> > On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
> > > >
> > > > On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> > > >
> > > > > I'd
On Fri, 12 Jan 2024 at 18:11, Patrick Palka wrote:
>
> On Thu, 11 Jan 2024, Jonathan Wakely wrote:
>
> > Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only.
> >
> > Reviews requested.
> >
> > -- >8 --
> >
> > This is a step towards implementing the C++23 change P2408R5, "Ranges
> >
On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
>
> On Fri, 12 Jan 2024, Jonathan Wakely wrote:
>
> > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
> > >
> > > On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> > >
> > > > I'd like to commit this to trunk for GCC 14. Please take a look.
> > >
It would be good to update the bundled tzdata for GCC 14.1 and 13.3
Tested x86_64-linux.
Any objections?
-- >8 --
Import the new 2023d tzdata.zi file.
libstdc++-v3/ChangeLog:
* src/c++20/tzdata.zi: Import new file from 2023d release.
---
libstdc++-v3/src/c++20/tzdata.zi | 23
Here's a partial patch for PR libstdc++/113318 to implement another
C++26 feature: https://wg21.link/p1885r12
I'm writing the rest of the tests, but thought I would post it now for
comments on the general approach.
The text_encoding class is basically just a pointer to an {ID,name} pair
in the
On Tue, 2024-01-02 20:41:37 +0100, Ilya Leoshkevich wrote:
> diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc
> index ac566efcf19..92d00bf922f 100644
> --- a/gcc/config/ia64/ia64.cc
> +++ b/gcc/config/ia64/ia64.cc
> @@ -3886,8 +3886,7 @@ ia64_expand_prologue (void)
> /* Output the
On Fri, 12 Jan 2024 at 18:33, Patrick Palka wrote:
>
> On Fri, 12 Jan 2024, Jonathan Wakely wrote:
>
> > On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
> > >
> > > On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> > >
> > > > I'd like to commit this to trunk for GCC 14. Please take a look.
> > >
On Fri, 12 Jan 2024 at 20:10, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK
>
> PR libstdc++/108827
> PR libstdc++/111327
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (bind_back): Define.
> *
On Fri, 12 Jan 2024 at 20:09, Patrick Palka wrote:
>
> This simplifies the operator() of _Bind_front using C++23 deducing
> this, allowing us to condense multiple nearly identical operator()
> overloads into one.
>
> In passing I think we can remove _Bind_front's defaulted special member
>
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, January 12, 2024 4:26 AM
> To: Andrew Pinski (QUIC)
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCHv3] aarch64/expr: Use ccmp when the outer expression is
> used twice [PR100942]
>
> Andrew Pinski writes:
> > Ccmp is not
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc++/108827
PR libstdc++/111327
libstdc++-v3/ChangeLog:
* include/bits/version.def (bind_back): Define.
* include/bits/version.h: Regenerate.
* include/std/functional (_Bind_back): Define
This simplifies the operator() of _Bind_front using C++23 deducing
this, allowing us to condense multiple nearly identical operator()
overloads into one.
In passing I think we can remove _Bind_front's defaulted special member
declarations and just let the compiler implicitly generate them for us.
Hi Bernhard,
On 1/12/24 10:44, Bernhard Reutner-Fischer wrote:
On Wed, 10 Jan 2024 23:24:22 +0100
Harald Anlauf wrote:
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 82f388c05f8..88502c1e3f0 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2926,6
On Fri, 12 Jan 2024, Jonathan Wakely wrote:
> On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
> >
> > On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> >
> > > I'd like to commit this to trunk for GCC 14. Please take a look.
> > >
> > > -- >8 --
> > >
> > > This is the last part of PR
On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only.
>
> Reviews requested.
>
> -- >8 --
>
> This is a step towards implementing the C++23 change P2408R5, "Ranges
> iterators as inputs to non-Ranges algorithms". C++20 random access
>
Use default cost model scheduling on these test cases. All these tests
introduce scan dump failures with -mtune generic-ooo. Since the vector
cost models are the same across all three tunes, some of the tests
in PR113249 will be fixed with this patch series.
39 additional unique testsuite
Enables assert that every typed instruction is associated with a
dfa reservation
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sched_variable_issue): enable assert
Signed-off-by: Edwin Lu
---
V2:
- No changes
V3:
- No changes
---
gcc/config/riscv/riscv.cc | 6 --
1 file changed, 4
Creates new generic vector pipeline file common to all cpu tunes.
Moves all vector related pipelines from generic-ooo to generic-vector-ooo.
Creates new vector crypto related insn reservations. Add temporary attribute
for making changes to the vector cost model
gcc/ChangeLog:
*
This patch adds non-vector related insn reservations and updates/creates
new insn reservations so all non-vector typed instructions have a reservation.
gcc/ChangeLog:
* config/riscv/generic-ooo.md (generic_ooo_sfb_alu): Add reservation
(generic_ooo_branch): ditto
*
Updates all tune insn reservation pipelines to cover all types defined by
define_attr "type" in riscv.md.
Creates new vector insn reservation pipelines in new file generic-vector-ooo.md
which has separate automaton vector_ooo where all reservations are mapped to.
This allows all tunes to share a
This links an example from the avr-gcc wiki that shows how to set up
a linker script for the __flashN avr address spaces in
section AVR Named Address Spaces of the GCC user manual.
Johann
--
AVR: Documentation: Web-Link an example ld-Script for Address-Space
__flashN.
gcc/
*
On Fri, 12 Jan 2024 at 17:55, Patrick Palka wrote:
>
> On Thu, 11 Jan 2024, Jonathan Wakely wrote:
>
> > I'd like to commit this to trunk for GCC 14. Please take a look.
> >
> > -- >8 --
> >
> > This is the last part of PR libstdc++/108822 implementing P2255R2, which
> > makes it ill-formed to
On Jan 12, 2024, at 2:52 AM, Hans-Peter Nilsson wrote:
>
> Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.)
>
> On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote:
>
>> Tested mmix-knuth-mmixware (where all torture-variants of
>> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> I'd like to commit this to trunk for GCC 14. Please take a look.
>
> -- >8 --
>
> This is the last part of PR libstdc++/108822 implementing P2255R2, which
> makes it ill-formed to create a std::tuple that would bind a reference
> to a temporary.
>
avr attribute "address" only supports exactly one argument,
fixed thusly.
Johann
--
AVR: Documentation: Attribute address has exactly one argument.
gcc/
* doc/extend.texi (AVR Variable Attributes) [address]: Remove
documentation for a version without argument, which is not
Thanks a lot for the reply.
> On Jan 12, 2024, at 11:28 AM, Richard Biener
> wrote:
>
>
>
>> Am 12.01.2024 um 16:55 schrieb Qing Zhao :
>>
>> Hi,
>>
>> I have some questions on using the utility routine “unshare_expr”:
>>
>> From my understanding, there should be NO shared nodes in a
On 1/12/24 09:09, Jason Merrill wrote:
On 12/23/23 14:46, Nathan Sidwell wrote:
On 12/18/23 17:10, Jason Merrill wrote:
On 12/18/23 16:57, Nathan Sidwell wrote:
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have
another theory
about how
On 02/01/2024 09:23, ezra.sito...@arm.com wrote:
> From: Ezra Sitorus
>
> Add vld1q, vst1, vst1q and vst1 intrinsics to arm port.
>
> Ezra Sitorus (12):
> [GCC] arm: vld1q_types_x2 ACLE intrinsics
> [GCC] arm: vld1q_types_x3 ACLE intrinsics
> [GCC] arm: vld1q_types_x4 ACLE intrinsics
>
> Am 12.01.2024 um 16:55 schrieb Qing Zhao :
>
> Hi,
>
> I have some questions on using the utility routine “unshare_expr”:
>
> From my understanding, there should be NO shared nodes in a GENERIC function.
> Otherwise, gimplication might fail.
There is sharing and this is why we unshare
Hi,
I have some questions on using the utility routine “unshare_expr”:
From my understanding, there should be NO shared nodes in a GENERIC function.
Otherwise, gimplication might fail.
Therefore, when we insert new tree nodes manually into the GENERIC function, we
should
Make sure there is
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> When build_array_ref doesn't use ARRAY_REF, it casts the index to sizetype
> already, performs POINTER_PLUS_EXPR and then dereferences.
> While when emitting ARRAY_REF, we try to keep index expression as is in
> whatever type it had, which is
Vladimir Makarov 于2024年1月11日周四 22:35写道：
>
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
>
> The patch was successfully bootstrapped and tested on x86_64, aarch64,
> ppc64le
This patch causes some ICE on MIPS:
Currently we scale the number of stmts allowed for forward
jump threading to limit those for backwards jump threading
by applying a factor of two to the counted stmts. That doesn't
allow fine-grained adjustments, like by a single stmt as needed
for PR109893. The following changes the factor to
Tested on i686 and powerpc darwin, and a cross from x86-64 darwin to
powerpc, pushed to trunk, thanks,
Iain
--- 8< ---
This is seen on 32b targets with a 64b multilib, and is an ICE when
the build has checking enabled. The fix is to exit the routine
early if the sender or receiver are already
On 1/11/24 17:01, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As discussed, our handling of corresponding object parameters needed to
handle the using-declaration case better. And I took the opportunity to
share code between the add_method and cand_parms_match
On 12/23/23 14:46, Nathan Sidwell wrote:
On 12/18/23 17:10, Jason Merrill wrote:
On 12/18/23 16:57, Nathan Sidwell wrote:
On 12/18/23 16:31, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu. Does this make sense? Did you have
another theory
about how to merge these?
Why isn't
Tested on powerpc-darwin9, pushed to trunk, thanks,
Iain
--- 8< ---
Recent changes to the member names of the diagnostics class missed one case in
the Darwin PowerPC host code. Fixed thus.
gcc/ChangeLog:
* config/rs6000/host-darwin.cc (segv_handler): Use the revised
Hi!
OK to push the attached
"GCN: Enable effective-target 'vect_early_break', 'vect_early_break_hw'"?
("The relevant test cases are all-PASS with just [two] exceptions, to be
looked into individually, later on." I'm not currently planning to look
into that.)
Grüße
Thomas
-
On Fri, 12 Jan 2024, Andrew Pinski wrote:
> > Verify that if-conversion succeeded through noce_try_store_flag_mask, as
> > per PR rtl-optimization/105314, tightening the test case and making it
> > explicit.
> >
> > gcc/testsuite/
> > * gcc.target/riscv/pr105314.c: Scan the RTL
On 1/12/24 07:45, Jakub Jelinek wrote:
Hi!
The following patch attempts to implement what apparently clang++
implemented for explicit object member function mangling, but nobody
actually proposed in patch form in
https://github.com/itanium-cxx-abi/cxx-abi/issues/148
Ok for trunk if it passes
Just realized that you were asking for the patch I forgot to join...
Here it is.
Le ven. 12 janv. 2024 à 11:09, Guillaume Gomez
a écrit :
>
> > It sounds like the patch you have locally is ready, but it has some
> > nontrivial changes compared to the last version you posted to the list.
> >
Status
==
The GCC development branch which will become GCC 14 is now
in regression and documentation fixes only mode (Stage 4).
Please concentrate now on fixing regressions from GCC 13
and earlier.
GCC 14.1 will be released when we reach the milestone of
zero P1 regressions (note not all
Since the advent of devices AVR*, the spec pattern mmcu=avr* does no
more work to discriminate between devices and cores like avr51.
This means -nodevicelib no more works for AVR* devices because that
option is removed for mmcu=avr* (which were only cores in the old days).
Instead of that
Hi!
The following patch attempts to implement what apparently clang++
implemented for explicit object member function mangling, but nobody
actually proposed in patch form in
https://github.com/itanium-cxx-abi/cxx-abi/issues/148
Ok for trunk if it passes full bootstrap/regtest? So far just
g:f26f92b534f9 implemented unsigned extensions using ZIPs rather than
UXTL{,2}, since the former has a higher throughput than the latter on
amny cores. The optimisation worked by lowering directly to ZIP during
expand, so that the zero input could be hoisted and shared.
However, changing to ZIP
Am 12.01.24 um 04:37 schrieb Jan-Benedict Glaw:
On Thu, 2024-01-04 17:28:02 +0100, Georg-Johann Lay wrote:
This fixes the avr-specific attributes io, io_low and address,
that are all basically the same except that io and io_low imply
assertions on allowed addressing modes.
---
As explained in the covering note to the previous patch,
the fact that aarch64-sve-* is now used for multiple header
files means that function_builder::add_overloaded_function
now needs to use a global map to detect duplicated overload
functions, instead of the member variable that it used
The PR shows that we were registering the same overloaded SVE
builtins twice. This was supposed to be prevented by
function_builder::add_overloaded_function, which uses a map
to detect whether a function of the same name has already been
registered. add_overloaded_function then had some asserts
Andrew Pinski writes:
> Ccmp is not used if the result of the and/ior is used by both
> a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation
> here by using ccmp in this case.
> Two changes is required, first we need to allow the outer statement's
> result be used more than once.
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> John reported that on HP-UX we no longer emit needed external libcalls.
>
> The problem is that we didn't strip name encoding when looking up
> the identifiers in assemble_external_libcall and
> process_pending_assemble_externals, while
>
在 2024-01-12星期五的 09:46 +0800，chenglulu写道：
> > I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS:
> > we need a target hook to tell the generic code
> > UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll
> > see millions lines of messages like
> >
> >
On Jan 12, 2024, "Kewen.Lin" wrote:
>>> By checking PR112917, IMHO we should keep this unbiasing
>>> guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 &&
>>> TARGET_STACK_BIAS), similar to some existing code special
>>> treating SPARC stack bias.
>>
>> I'm afraid this change will most
Hi Ajit,
I have taken a quick look at the patch and my comments are inlined:
On 09/01/24 4:44 pm, Ajit Agarwal wrote:
> Hello All:
>
> This pass is registered before ira rtl pass.
> Bootstrapped and regtested for powerpc64-linux-gnu.
>
> No regressions for spec 2017 benchmarks and improvements
Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.)
On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote:
> Tested mmix-knuth-mmixware (where all torture-variants of
> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
> x86_64-pc-linux-gnu. Also stepped through the test for native,
>
On Thu, 11 Jan 2024 at 22:17, Jonathan Wakely wrote:
>
> I'd like to commit this to trunk for GCC 14. Please take a look.
>
> -- >8 --
>
> This is the last part of PR libstdc++/108822 implementing P2255R2, which
> makes it ill-formed to create a std::tuple that would bind a reference
> to a
VLA is a known issue for a long time.GCC doesn't have too much cse optimization forVLA vectors. It should be a big work to investigate what's going on.I think most cse optimization for precomputed result are vls loop. So I think as long as we can do a good job on cost model which pick appropriate
> It sounds like the patch you have locally is ready, but it has some
> nontrivial changes compared to the last version you posted to the list.
> Please post your latest version to the list.
Sure!
This patch adds the support for attributes on functions and variables. It does
so by adding the
> Tested on both RV32/RV64 no regression, Ok for trunk ?
Yes, thanks!
Btw out of curiosity, did you see why we actually fail to
optimize away the VLA loop? We should open a bug for that
I suppose.
Regards
Robin
On Thu, Jan 11, 2024 at 3:37 PM Maciej W. Rozycki wrote:
>
> Verify that if-conversion succeeded through noce_try_store_flag_mask, as
> per PR rtl-optimization/105314, tightening the test case and making it
> explicit.
>
> gcc/testsuite/
> * gcc.target/riscv/pr105314.c: Scan the
Hi!
John reported that on HP-UX we no longer emit needed external libcalls.
The problem is that we didn't strip name encoding when looking up
the identifiers in assemble_external_libcall and
process_pending_assemble_externals, while
assemble_name_resolve does that:
const char *real_name =
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> For INTEGER_CST operands, the code decides if it should emit the whole
> INTEGER_CST into memory, or if there are enough upper bits either all 0s
> or all 1s to warrant an optimization, where we use memory for lower limbs
> or even just an
Hi!
For INTEGER_CST operands, the code decides if it should emit the whole
INTEGER_CST into memory, or if there are enough upper bits either all 0s
or all 1s to warrant an optimization, where we use memory for lower limbs
or even just an INTEGER_CST for least significant limb and fill in the
rest
On Wed, 10 Jan 2024 23:24:22 +0100
Harald Anlauf wrote:
> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> index 82f388c05f8..88502c1e3f0 100644
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -2926,6 +2926,10 @@ gfc_dt;
> typedef struct gfc_forall_iterator
> {
LGTM
On Fri, Jan 12, 2024 at 7:36 AM Maciej W. Rozycki wrote:
>
> The optimization levels pr105314.c is iterated over are needlessly
> overridden with "-O2", limiting the coverage of the test case to that
> level, perhaps with additional options the original optimization level
> has been
LGTM
On Fri, Jan 12, 2024 at 7:37 AM Maciej W. Rozycki wrote:
>
> Verify that if-conversion succeeded through noce_try_store_flag_mask, as
> per PR rtl-optimization/105314, tightening the test case and making it
> explicit.
>
> gcc/testsuite/
> * gcc.target/riscv/pr105314.c: Scan
Hi!
Andre reported on IRC that this test has weird preprocessor conditions,
obviously the intent was to test whether corresponding __*_MANT_DIG__
is equal to the expected value like earlier in the function definitions,
but somehow I've ended up with a comma expression instead, which was
always
On Fri, 12 Jan 2024 at 06:53, Daniel Krügler wrote:
>
> Am Do., 11. Jan. 2024 um 21:23 Uhr schrieb Jonathan Wakely
> :
> >
> > Tested x86_64-linux. Does this look better now?
>
> Yes, thank you.
Thanks, pushed.
Tested aarch64-linux, pushed to trunk.
-- >8 --
This was approved for C++23 at he June 2021 virtual meeting.
This allows more efficient construction of std::pair members when {} is
used as a constructor argument. The perfect forwarding constructor can
be used, so that the member variables are
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> This is the case I was talking about in
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642423.html
> and Zdenek kindly found a testcase for it.
> We can only create BITINT_TYPE with precision at most 65535, not 65536,
> so need to
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The code to assign large/huge _BitInt SSA_NAMEs to partitions intentionally
> ignores uninitialized SSA_NAMEs:
> /* Also ignore uninitialized uses. */
> if (SSA_NAME_IS_DEFAULT_DEF (s)
> && (!SSA_NAME_VAR (s)
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase revealed a typo in condition, as the comment
> says the intent is
>/* If lhs of stmt is large/huge _BitInt SSA_NAME not in m_names
>it means it will be handled in a loop or straight line code
>
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 11, 2024 at 12:12:59PM +0100, Jakub Jelinek wrote:
> > So, the problem was that in 2 spots I was comparing TYPE_SIZE of large/huge
> > BITINT_TYPEs to determine if it can be handled cheaply.
> > On x86_64 with limb_mode == abi_limb_mode
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/format (__format::_Arg_store): Fix PR number in
comment. Simplify preprocessor code.
---
libstdc++-v3/include/std/format | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
Hi!
This is the case I was talking about in
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642423.html
and Zdenek kindly found a testcase for it.
We can only create BITINT_TYPE with precision at most 65535, not 65536,
so need to punt if we'd want to create it.
Bootstrapped/regtested on
Hi!
The following testcase revealed a typo in condition, as the comment
says the intent is
/* If lhs of stmt is large/huge _BitInt SSA_NAME not in m_names
it means it will be handled in a loop or straight line code
at the location of its (ultimate) immediate use, so
Hi!
The code to assign large/huge _BitInt SSA_NAMEs to partitions intentionally
ignores uninitialized SSA_NAMEs:
/* Also ignore uninitialized uses. */
if (SSA_NAME_IS_DEFAULT_DEF (s)
&& (!SSA_NAME_VAR (s) || VAR_P (SSA_NAME_VAR (s
continue;
Hi!
When build_array_ref doesn't use ARRAY_REF, it casts the index to sizetype
already, performs POINTER_PLUS_EXPR and then dereferences.
While when emitting ARRAY_REF, we try to keep index expression as is in
whatever type it had, which is reasonable e.g. for signed or unsigned types
narrower
On Thu, Jan 11, 2024 at 12:12:59PM +0100, Jakub Jelinek wrote:
> So, the problem was that in 2 spots I was comparing TYPE_SIZE of large/huge
> BITINT_TYPEs to determine if it can be handled cheaply.
> On x86_64 with limb_mode == abi_limb_mode (both DImode) that works fine,
> if TYPE_SIZE is equal,
On Fri, Jan 12, 2024 at 07:40:19AM +, waffl3x wrote:
> Bootstrapped and tested on x86_64-linux with no regressions.
>
> I'm still getting used to things so let me know if the change log
> entries are excessive, thanks.
> From 9dc168e7bcbbd7d515fa28cb9cae28ec113fae0f Mon Sep 17 00:00:00 2001
1. Introduce vector regmove new tune info.
2. Adjust scalar_to_vec cost in add_stmt_cost.
We will get optimal codegen after this patch with -march=rv64gcv_zvl256b:
lui a5,%hi(a)
li a4,19
sb a4,%lo(a)(a5)
li a0,0
ret
Tested on both
On Fri, 12 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> This replaces two more usages of single_exit that I had missed before.
> They both seem to happen when we re-use the ifcvt scalar loop for versioning.
>
> The condition in versioning is the same as the one for when we don't re-use
> the
On GENERIC tcc_comparison can have int type so restrict the PR113126
fix to vector types.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/113344
* match.pd ((double)float CMP (double)float -> float CMP float):
Perform result type check only for
Hi, Richard.
I tried hard in RISC-V backend. I found to fix the case with
-march=rv64gcv_zvl4096b can not be without vec_to_scalar count.
Is there an approach that we can count vec_to_scalar cost without this piece
code in middle-end ?
/* ??? Enable for loop costing as well. */
Hi All,
This replaces two more usages of single_exit that I had missed before.
They both seem to happen when we re-use the ifcvt scalar loop for versioning.
The condition in versioning is the same as the one for when we don't re-use the
scalar loop.
I hit these during an LTO enabled bootstrap
On Fri, Jan 12, 2024 at 7:15 AM Feng Xue OS wrote:
>
> Add a depth parameter to limit recursion of vec_slp_has_scalar_use.
OK.
> Feng
> ---
>
> .../gcc.target/aarch64/bb-slp-pr113091.c | 22 ++
> gcc/tree-vect-slp.cc | 207 ++
> 2 files
On Fri, Jan 12, 2024 at 3:15 AM HAO CHEN GUI wrote:
>
> Hi Richard,
>Thanks so much for your comments.
>
>
> >> patch.diff
> >> diff --git a/gcc/config/rs6000/rs6000-string.cc
> >> b/gcc/config/rs6000/rs6000-string.cc
> >> index 7f777666ba9..4c9b2cbeefc 100644
> >> ---
94 matches
Mail list logo
