On Thu, 2024-01-25 at 08:48 +0800, chenglulu wrote:
>
> 在 2024/1/24 上午3:36, Xi Ruoyao 写道:
> > On Mon, 2024-01-22 at 15:27 +0800, chenglulu wrote:
> > > > > The failure of this test case was because the compiler believes that
> > > > > two
> > > > > (UNSPEC_PCREL_64_PART2 [(symbol)]) instances
Pushed to r14-8414.
在 2024/1/24 下午5:19, Jiahao Xu 写道:
It is incorrect to use vld/vori to implement the vec_concatz because when
the LSX
instruction is used to update the value of the vector register, the upper 128
bits of
the vector register will not be zeroed.
gcc/ChangeLog:
*
This patch adds no fusion compile option to disable phase 2 global fusion.
It can help us to analyze the compile-time and debugging.
Committed.
gcc/ChangeLog:
* config/riscv/riscv-opts.h (enum vsetvl_strategy_enum): Add
optim-no-fusion option.
* config/riscv/riscv-vsetvl.cc
--- a/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-7.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-7.c
@@ -41,7 +41,6 @@ foo (int32_t *__restrict a, int32_t *__restrict b, int32_t
*__restrict c,
}
/* { dg-final { scan-assembler {e32,m1} } } */
-/* {
在 2024/1/25 下午3:46, chenglulu 写道:
Jiahao:
Note that the LoongArch 'a' in the title needs to be capitalized.
I modified this patch and incorporated it first.
Thanks, I'll pay attention next time.
在 2024/1/24 下午5:19, Jiahao Xu 写道:
It is incorrect to use vld/vori to implement the
Jiahao:
Note that the LoongArch 'a' in the title needs to be capitalized.
I modified this patch and incorporated it first.
在 2024/1/24 下午5:19, Jiahao Xu 写道:
It is incorrect to use vld/vori to implement the vec_concatz because when
the LSX
instruction is used to update the value of the
Pushed to r14-8412.
在 2024/1/23 上午11:54, Lulu Cheng 写道:
TLS gd ld and ie type symbols will generate corresponding GOT entries,
so non-zero offsets cannot be generated.
The address of TLS le type symbol+addend is not implemented in binutils,
so non-zero offset is not generated here for the time
From: Yanzhang Wang
Ran a full test to adjust some of the tests for scan-assembly. The
behavior is the same as --param=riscv-vector-abi before.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag.
(riscv_fntype_abi): Ditto.
*
On 24 January 2024 20:30:45 CET, Andi Kleen wrote:
>---
> gcc/doc/extend.texi | 16
> 1 file changed, 16 insertions(+)
>
>diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
>index 0bc586d120e7..c68d32bed8de 100644
>--- a/gcc/doc/extend.texi
>+++ b/gcc/doc/extend.texi
>@@
在 2024/1/24 下午5:58, Jiahao Xu 写道:
在 2024/1/24 下午5:48, Xi Ruoyao 写道:
On Wed, 2024-01-24 at 17:19 +0800, Jiahao Xu wrote:
gcc/ChangeLog:
* config/loongarch/larchintrin.h
(__frecipe_s): Update function return type.
(__frecipe_d): Ditto.
(__frsqrte_s): Ditto.
(__frsqrte_d):
On Tue, Jan 23, 2024 at 11:00 PM H.J. Lu wrote:
>
> Changes in v3:
>
> 1. Rebase against commit 02e68389494
> 2. Don't add call_no_callee_saved_registers to machine_function since
> all callee-saved registers are properly clobbered by callee with
> no_callee_saved_registers attribute.
>
The patch
Hi,
Thanks for adjusting this.
on 2024/1/24 19:42, Xi Ruoyao wrote:
> On Wed, 2024-01-24 at 19:08 +0800, chenxiaolong wrote:
>> At 19:00 +0800 on Wednesday, 2024-01-24, Xi Ruoyao wrote：
>>> On Wed, 2024-01-24 at 18:32 +0800, chenxiaolong wrote:
On 20:09 +0800 on Tuesday, 2024-01-23, Xi
On Wed, Jan 24, 2024 at 4:23 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2022-02-10T05:55:15-0800, "H.J. Lu via Gcc-patches"
> wrote:
> > 1. Require linker with GNU_PROPERTY_1_NEEDED support for PR 35513
> > run-time tests.
>
> Moving my x86_64-pc-linux-gnu testing from an old to a newish system
>
on 2024/1/24 23:51, Peter Bergner wrote:
> On 1/24/24 12:04 AM, Kewen.Lin wrote:
>> on 2024/1/24 11:11, Peter Bergner wrote:
>>> But not with this. The -mdejagnu-cpu=power10 option already enables -mvsx.
>>> If the user explcitly forces -mno-vsx via RUNTESTFLAGS, then let them.
>>> The options
On 12/31/23 09:23, Roger Sayle wrote:
Very many thanks (and a Happy New Year) to the pre-commit
patch testing folks at linaro.org. Their testing has revealed that
although my patch is clean on x86_64, it triggers some problems
on aarch64 and arm. The issue (with the previous version of my
On Wed, Jan 24, 2024 at 12:29:51AM +, Qing Zhao wrote:
> This is the 4th version of the patch.
Thanks very much for this!
I tripped over an unexpected behavioral change that the Linux kernel
depends on:
__builtin_types_compatible_p() no longer treats an array marked with
counted_by as
在 2024/1/24 上午3:36, Xi Ruoyao 写道:
On Mon, 2024-01-22 at 15:27 +0800, chenglulu wrote:
The failure of this test case was because the compiler believes that two
(UNSPEC_PCREL_64_PART2 [(symbol)]) instances would always produce the
same result, but this isn't true because the result depends on
This fixes of the vect testcases which uses the gimple FE for LLP64 targets.
The testcases use directly `unsigned long` for the addition to pointers
when they should be using `__SIZETYPE__`. This changes to use that instead.
gcc/testsuite/ChangeLog:
PR testsuite/113548
*
On Wed, Jan 24, 2024 at 4:40 PM H.J. Lu wrote:
>
> On Wed, Jan 24, 2024 at 9:37 AM Andrew Pinski
> wrote:
> >
> > On aarch64, vectorization of `long` multiply can be done if SVE is enabled
> > or if long is 32bit (ILP32). It can also be done for constants too but there
> > is no effective
Adding the missing '[' in
commit e6fbc3cc786a74a098352868348e187877bfbc8b
Author: Andrew Pinski
Date: Wed Jan 24 00:00:34 2024 -0800
Fix vect_long_mult for aarch64 [PR109705]
PR testsuite/109705
* lib/target-supports.exp (check_effective_target_vect_long_mult):
On Wed, Jan 24, 2024 at 9:37 AM Andrew Pinski wrote:
>
> On aarch64, vectorization of `long` multiply can be done if SVE is enabled
> or if long is 32bit (ILP32). It can also be done for constants too but there
> is no effective target test for that just yet.
>
> Build and tested on
My last commit I tested on aarch64 but vect_long_mult was not actually invoked
and I didn't notice that I was missing a `[` in front of
check_effective_target_aarch64_sve.
When I ran the testsuite on x86_64, I got the failure.
Committed as obvious after testing on x86_64.
On 1/24/24 16:20, Palmer Dabbelt wrote:
On Wed, 24 Jan 2024 16:19:06 PST (-0800), jeffreya...@gmail.com wrote:
On 1/24/24 17:07, Patrick O'Neill wrote:
On 12/16/23 10:58, Jeff Law wrote:
On 12/15/23 17:14, Andrew Waterman wrote:
On Fri, Dec 15, 2023 at 1:38 PM Jeff Law
wrote:
On
On Wed, 24 Jan 2024 16:19:06 PST (-0800), jeffreya...@gmail.com wrote:
On 1/24/24 17:07, Patrick O'Neill wrote:
On 12/16/23 10:58, Jeff Law wrote:
On 12/15/23 17:14, Andrew Waterman wrote:
On Fri, Dec 15, 2023 at 1:38 PM Jeff Law wrote:
On 12/12/23 20:54, Palmer Dabbelt wrote:
I
On 1/24/24 17:07, Patrick O'Neill wrote:
On 12/16/23 10:58, Jeff Law wrote:
On 12/15/23 17:14, Andrew Waterman wrote:
On Fri, Dec 15, 2023 at 1:38 PM Jeff Law wrote:
On 12/12/23 20:54, Palmer Dabbelt wrote:
I can't actually find anything in the ISA manual that makes Ztso imply
A.
On 12/16/23 10:58, Jeff Law wrote:
On 12/15/23 17:14, Andrew Waterman wrote:
On Fri, Dec 15, 2023 at 1:38 PM Jeff Law wrote:
On 12/12/23 20:54, Palmer Dabbelt wrote:
I can't actually find anything in the ISA manual that makes Ztso imply
A. In theory the memory ordering is just a
This patch fixes "-g" debug compilation for gfx1100 and gfx1030,
which fail to link when "-g" is specified. The reason is:
When using gfx1100 and compiling with '-g' I was running into an error
because the eflags used for the debugger file has additional eflags
(elf flags) set - contrary to the
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds-checking code. Without the proper
part ref, not only a user may get confused: I was, too...
The testcase is
On Wed, 24 Jan 2024 at 17:27, Jonathan Wakely wrote:
>
> On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> >
> > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > > @@ -1016,10 +1116,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > > >
On 1/24/24 00:57, Jasmine Tang wrote:
Change the style from & to && to reflect boolean result with boolean
operation (instead of bitwise operation)
David Binderman 2017-07-01 13:24:44 UTC
trunk/gcc/cp/lex.c:116]: (style) Boolean result is used in bitwise operation.
Clarify expression with
On 1/19/24 17:36, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Currently, when exporting names from the GMF, or within header modules,
for a set of constrained partial specialisations we only emit the first
one. This is because the
On 1/20/24 05:45, Nathaniel Shead wrote:
On Fri, Jan 19, 2024 at 01:57:18PM -0500, Patrick Palka wrote:
On Wed, 3 Jan 2024, Nathaniel Shead wrote:
+ if (DECL_CONTEXT (decl)
+ && RECORD_OR_UNION_TYPE_P (DECL_CONTEXT (decl))
+ && !DECL_TEMPLATE_INFO (decl))
+
Hi Jeff,
> On 1/24/24 07:40, Robin Dapp wrote:
>> Hi,
>> on Solaris/SPARC several vector tests appeared to be regressing. They
>> were never vectorized but the checks before r14-3612-ge40edf64995769
>> would match regardless if a loop was actually vectorized or not.
>> The refined checks only
On 1/20/24 18:14, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
Currently, importing a namespace declarations marks it as imported, and
so marks it as originating from the module that it was imported from.
This is usually harmless, but
On Wed, 24 Jan 2024, Patrick Palka wrote:
> On Wed, 24 Jan 2024, Jonathan Wakely wrote:
>
> > On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> > >
> > > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> > >
> > > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > > > diff --git
On 1/24/24 07:40, Robin Dapp wrote:
Hi,
on Solaris/SPARC several vector tests appeared to be regressing. They
were never vectorized but the checks before r14-3612-ge40edf64995769
would match regardless if a loop was actually vectorized or not.
The refined checks only match a successful
Tested x86_64-pc-linux-gnu, applying to 12/13.
-- 8< --
Here we were assuming that current_retval_sentinel would be set if we have
seen a throwing cleanup, but that's not the case if the cleanup is after all
returns.
This change isn't needed on trunk, where current_retval_sentinel is set for
Hi Mikael,
Am 24.01.24 um 19:46 schrieb Mikael Morin:
Le 23/01/2024 à 21:36, Harald Anlauf a écrit :
Dear all,
here's the second part of a series for the treatment of missing
optional arguments passed to optional dummies, now fixing the
case that the latter procedures are elemental.
Mostly adopted from the existing C musttail plugin tests.
---
gcc/testsuite/c-c++-common/musttail1.c | 17
gcc/testsuite/c-c++-common/musttail2.c | 36 ++
gcc/testsuite/c-c++-common/musttail3.c | 31 ++
---
gcc/doc/extend.texi | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 0bc586d120e7..c68d32bed8de 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9867,6 +9867,22 @@ foo (int x, int y)
@code{y} is not actually
This patch implements a clang compatible [[musttail]] attribute for
returns.
musttail is useful as an alternative to computed goto for interpreters.
With computed goto the interpreter function usually ends up very big
which causes problems with register allocation and other per function
Implement a C23 clang compatible musttail attribute similar to the earlier
C++ implementation in the C parser.
---
gcc/c/c-parser.cc | 59 +--
gcc/c/c-tree.h| 2 +-
gcc/c/c-typeck.cc | 15 ++--
3 files changed, 61 insertions(+), 15
- Give error messages for all causes of non sibling call generation
- Don't override choices of other non sibling call checks with
must tail. This causes ICEs. The must tail attribute now only
overrides flag_optimize_sibling_calls locally.
- Error out when tree-tailcall failed to mark a must-tail
This version addresses all the feedback so far (Thanks!). The largest
change is support for using [[musttail]] in C23, not just C++.
-Andi
On Wed, Jan 24, 2024 at 11:13:05AM +0200, Janne Blomqvist wrote:
> On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote:
> > > Now, if
> > > the OS adds cospi() to libm and it's in libm's symbol map, then the
> > > cospi() used by gfortran depends on the search order of the loaded
> > > libraries.
>
On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
> >
> > On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> >
> > > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > > >
Le 23/01/2024 à 21:36, Harald Anlauf a écrit :
Dear all,
here's the second part of a series for the treatment of missing
optional arguments passed to optional dummies, now fixing the
case that the latter procedures are elemental. Adjustments
were necessary when the missing dummy has the VALUE
On Tue, 2024-01-16 at 11:12 +, Iain Sandoe wrote:
> Tested on x86_64, i686 Darwin, x86_64 Linux,
> OK for trunk? When?
> thanks
> Iain
Thanks; looks good to me for trunk.
Given that the scope is just the jit testsuite and that you've tested
it on 3 configurations (and presumably made use of
On Tue, 2024-01-16 at 11:10 +, Iain Sandoe wrote:
> Tested on x86_64, i686 Darwin and x86_64 Linux,
> OK for trunk? when ?
> thanks,
> Iain
Hi Iain, thanks for the patch.
I'll have to defer to your Darwin expertise here; given that you've
tested it on the above configurations I'll assume
Andrew Pinski writes:
> On aarch64, vectorization of `long` multiply can be done if SVE is enabled
> or if long is 32bit (ILP32). It can also be done for constants too but there
> is no effective target test for that just yet.
>
> Build and tested on aarch64-linux-gnu with no regressions (also
On Thu, 2024-01-11 at 18:42 -0500, Antoni Boucher wrote:
> Hi.
> This patch fixes the bug 113343.
> I'm wondering if there's a better solution than using mpfr.
> The only other solution I found is real_from_string, but that seems
> overkill to convert the number to a string.
> I could not find a
On 1/23/24 00:13, Alexandre Oliva wrote:
newlib-src/libc/include/sys/fenv.h doesn't define the FE_* macros that
libgcc expects to enable decimal float support. Only after newlib is
configured and built does an overriding header that defines those
macros become available in
On 1/23/24 00:15, Alexandre Oliva wrote:
Targets whose binutils support -shared, but that don't have a shared
libc, and that can't add PDC (non-PIC) to shared libraries, may
succeed at the effective target test for -shared, because it brings
nothing from libc, but tests that rely on -shared
Andrew Pinski writes:
> The problem here is the builtin apply mechanism thinks the FP registers
> are to be used due to get_raw_arg_mode not returning VOIDmode. This
> fixes that oversight and the backend now returns VOIDmode for non-general-regs
> if TARGET_GENERAL_REGS_ONLY is true.
>
> Built
Szabolcs Nagy writes:
> Recent commit introduced a conditional branch in eh_return epilogues
> that is not compatible with speculation tracking:
>
> commit 426fddcbdad6746fe70e031f707fb07f55dfb405
> Author: Szabolcs Nagy
> CommitDate: 2023-11-27 15:52:48 +
>
> aarch64: Use br
On aarch64, vectorization of `long` multiply can be done if SVE is enabled
or if long is 32bit (ILP32). It can also be done for constants too but there
is no effective target test for that just yet.
Build and tested on aarch64-linux-gnu with no regressions (also tested with SVE
enabled).
On Thu, 2023-12-21 at 16:01 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds the support for the convert vector internal function.
Thanks for the patch.
> I'll need to double-check that making the decl a register is
> necessary.
I confess I don't know anything about this aspect of the
The introduction of the optional RCPC3 architectural extension for
Armv8.2-A upwards provides additional support for the release
consistency model, introducing the Load-Acquire RCpc Pair Ordered, and
Store-Release Pair Ordered operations in the form of LDIAPP and STILP.
These operations are
libatomic/ChangeLog:
* libatomic_i.h: Add GEN_SELECTOR implementation for
IFUNC_NCOND(N) == 4.
---
libatomic/libatomic_i.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/libatomic/libatomic_i.h b/libatomic/libatomic_i.h
index 861a22da152..0a854fd908c
The introduction of the optional RCPC3 architectural extension for
Armv8.2-A upwards provides additional support for the release
consistency model, introducing both the Load-Acquire RCpc Pair
Ordered, and Store-Release Pair Ordered operations in the form of
LDIAPP and STILP.
In light of this,
On Wed, 24 Jan 2024 at 15:24, Patrick Palka wrote:
>
> On Wed, 24 Jan 2024, Jonathan Wakely wrote:
>
> > On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > > b/libstdc++-v3/include/bits/stl_pair.h
> > > index b81b479ad43..a9b20fbe7ca
On 1/24/24 04:26, Maciej W. Rozycki wrote:
On Tue, 16 Jan 2024, Maciej W. Rozycki wrote:
I don't have a strong opinion on this. I certainly see Andrew's point, but
it's also the case that if some work earlier in the RTL or gimple pipeline
comes along and compromises the test, then we'd see
Am 24.01.24 um 10:13 schrieb Janne Blomqvist:
On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote:
Now, if
the OS adds cospi() to libm and it's in libm's symbol map, then the
cospi() used by gfortran depends on the search order of the loaded
libraries.
We only include the fallback math
On 1/24/24 05:54, Monk Chiang wrote:
Since the match.pd transforms (zero_one == 0) ? y : z y,
into ((typeof(y))zero_one * z) y. Add splitters to recongize
this expression to generate SFB instructions.
gcc/ChangeLog:
PR target/113095
* config/riscv/sfb.md: New splitters to
The introduction of further architectural-feature dependent ifuncs
for AArch64 makes hard-coding ifunc `_i' suffixes to functions
cumbersome to work with. It is awkward to remember which ifunc maps
onto which arch feature and makes the code harder to maintain when new
ifuncs are added and their
At present, Evaluation of both `has_lse2(hwcap)' and
`has_lse128(hwcap)' may require issuing an `mrs' instruction to query
a system register. This instruction, when issued from user-space
results in a trap by the kernel which then returns the value read in
by the system register. Given the
The armv9.4-a architectural revision adds three new atomic operations
associated with the LSE128 feature:
* LDCLRP - Atomic AND NOT (bitclear) of a location with 128-bit
value held in a pair of registers, with original data loaded into
the same 2 registers.
* LDSETP - Atomic OR (bitset)
With support for new atomic features in Armv9.4-a being indicated by
HWCAP2 bits, Libatomic's ifunc resolver must now query its second
argument, of type __ifunc_arg_t*.
We therefore make this argument known to libatomic, allowing us to
query hwcap2 bits in the following manner:
bool
resolver
v4 updates
1. Make use of HWCAP2_LSE128, as defined in the Linux kernel v6.7
for feature check. This has required adding a new patch to the
series, enabling ifunc resolvers to read a second arg of type
`__ifunc_arg_t *', from which the `_hwcap2' member can be queried
for LSE128
On Thu, 2023-12-21 at 08:33 -0500, Antoni Boucher wrote:
> Hi.
> This patch allows comparing aligned integer types as equal.
> There's a TODO in the code about whether we should check that the
> alignment is equal.
> What are your thoughts on this?
I think we should check for equal alignment.
On Fri, 2024-01-19 at 16:55 -0500, Antoni Boucher wrote:
> Hi.
> This patch allows comparing different instances of array types as
> equal.
> Thanks for the review.
Thanks; the patch looks good to me.
Dave
On 1/24/24 04:16, Maciej W. Rozycki wrote:
Add RTL tests, for RV64 and RV32 where appropriate, corresponding to the
existing cset-sext.c tests. They have been produced from RTL code as at
the entry of the "ce1" pass for the respective cset-sext.c tests built
at -O3.
gcc/testsuite/
On 1/24/24 04:16, Maciej W. Rozycki wrote:
Add a pair of RTL tests, for RV64 and RV32 respectively, corresponding
to the existing pr105314.c test. They have been produced from RTL code
as at the entry of the "ce1" pass for pr105314.c compiled at -O3.
gcc/testsuite/
*
Hi Ajit,
On 21/01/2024 19:57, Ajit Agarwal wrote:
>
> Hello All:
>
> New pass to replace adjacent memory addresses lxv with lxvp.
> Added common infrastructure for load store fusion for
> different targets.
Thanks for this, it would be nice to see the load/store pair pass
generalized to
This patch obviously depends on Andrew's; he wrote in the previous email
of this thread regarding his patch:
Andrew Stubbs wrote:
This is enough to get gfx1100 working for most purposes, on top of the
patch that Tobias committed a week or so ago; there are still some test
failures to
On 1/24/24 12:04 AM, Kewen.Lin wrote:
> on 2024/1/24 11:11, Peter Bergner wrote:
>> But not with this. The -mdejagnu-cpu=power10 option already enables -mvsx.
>> If the user explcitly forces -mno-vsx via RUNTESTFLAGS, then let them.
>> The options set in RUNTESTFLAGS come after the options in the
Hi, is it OK for trunk? I do not have access to the repo, can you
please help me submit the patch? Thanks.
xndcn 于2024年1月17日周三 00:16写道：
>
> Sorry about the mangled content...
> So I add a new add-options for libatomic_16b:
>
> ---
> libstdc++-v3/ChangeLog:
>
> * include/bits/atomic_base.h: add
Am 22.01.24 um 08:45 schrieb Richard Biener:
On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote:
Am 18.01.24 um 20:54 schrieb Roger Sayle:
This patch tweaks RTL expansion of multi-word shifts and rotates to use
PLUS rather than IOR for disjunctive operations. During expansion of
Yes, it is for a use case inside of rustc_codegen_gcc.
The compiler is structured in a way where we don't know if a global
variable might be constant when it is created.
On Wed, 2024-01-24 at 10:09 -0500, David Malcolm wrote:
> On Fri, 2024-01-19 at 16:57 -0500, Antoni Boucher wrote:
> > Hi.
> >
On Wed, 24 Jan 2024, Jonathan Wakely wrote:
> On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > b/libstdc++-v3/include/bits/stl_pair.h
> > index b81b479ad43..a9b20fbe7ca 100644
> > --- a/libstdc++-v3/include/bits/stl_pair.h
> > +++
Hi,
On Mon, Jan 22 2024, Jan Hubicka wrote:
>> Hi,
>>
>> When the check for exceeding param_ipa_cp_value_list_size limit was
>> modified to be ignored for generating values from self-recursive
>> calls, it should have been changed from equal to, to equals toor is
>> greater than. This omission
Ping! That's a one-line fix, and you can find all the details in the
bugzilla entry. Also, I can provide executables built with the affected
toolchains, demonstrating the problem and the fix.
Thanks,
Matteo
Il 17/01/24 12:51, Matteo Italia ha scritto:
SEH _Unwind_Resume_or_Rethrow invokes
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-8391-ge503f9aca91926.
gcc/analyzer/ChangeLog:
PR analyzer/112977
* engine.cc (impl_region_model_context::on_liveness_change):
PR analyzer/112927 reports a false positive from -Wanalyzer-tainted-size
seen on the Linux kernel's drivers/char/ipmi/ipmi_devintf.c with the
analyzer kernel plugin.
The issue is that in:
(A):
if (msg->data_len > 272) {
return -90;
}
(B):
n = msg->data_len;
__check_object_size(to,
On Fri, 2024-01-19 at 16:57 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds a new API gcc_jit_global_set_readonly: it's
> equivalent
> to having a const global variable, but it is useful in the case of
> complex compilers where it is not convenient to use const.
> Thanks for the review.
Hi
On Fri, 2024-01-19 at 16:54 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds a new way to create local variable that won't
> generate
> debug info: it is to be used for compiler-generated variables.
> Thanks for the review.
Thanks for the patch.
> diff --git
We can't support niters with may_be_zero when we end up with a
non-empty latch due to early exit peeling. At least not in
the simplistic way the vectorizer handles this now. Disallow
it again for exits that are not the last one.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Hi,
on Solaris/SPARC several vector tests appeared to be regressing. They
were never vectorized but the checks before r14-3612-ge40edf64995769
would match regardless if a loop was actually vectorized or not.
The refined checks only match a successful vectorization attempt
but are run
On 23/01/2024 15:53, Richard Ball wrote:
> Adds missing bti instruction at the beginning of a virtual
> thunk, when bti is enabled.
>
> gcc/ChangeLog:
>
> * config/arm/arm.cc (arm_output_mi_thunk): Emit
> insn for bti_c when bti is enabled.
>
> gcc/testsuite/ChangeLog:
>
>
Since the match.pd transforms (zero_one == 0) ? y : z y,
into ((typeof(y))zero_one * z) y. Add splitters to recongize
this expression to generate SFB instructions.
gcc/ChangeLog:
PR target/113095
* config/riscv/sfb.md: New splitters to rewrite single bit
sign extension
This is enough to get gfx1100 working for most purposes, on top of the
patch that Tobias committed a week or so ago; there are still some test
failures to investigate, and probably some tuning to do.
It might also get gfx1030 working too. @Richi, could you test it,
please?
I can't test the other
On Wed, Jan 24, 2024 at 11:13:44AM +, Sam James wrote:
>
> Andi Kleen writes:
>
> > This patch implements a clang compatible [[musttail]] attribute for
> > returns.
>
> This is PR83324. See also PR52067 and PR110899.
Thanks for the references. I'll add it there.
>
> > The attribute is
> ...are the three hunks above needed? The reason for asking is that,
> if they were needed, I'd have expected that we'd also need a table
> entry for clang::musttail (which is possible to add). But trying it
> locally, the patch seemed to work without this.
Interesting thanks. I think I copied
Hi!
On 2022-02-10T05:55:15-0800, "H.J. Lu via Gcc-patches"
wrote:
> 1. Require linker with GNU_PROPERTY_1_NEEDED support for PR 35513
> run-time tests.
Moving my x86_64-pc-linux-gnu testing from an old to a newish system
(Ubuntu 20.04), I notice:
[-PASS: g++.target/i386/pr35513-1.C
On Wed, 24 Jan 2024 at 12:01, Jonathan Wakely wrote:
>
> On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> > diff --git a/libstdc++-v3/include/bits/stl_pair.h
> > b/libstdc++-v3/include/bits/stl_pair.h
> > index b81b479ad43..a9b20fbe7ca 100644
> > --- a/libstdc++-v3/include/bits/stl_pair.h
> >
Thank you for your help. I will update the test case.
I test on the Coremark and have 5% improvement on the SiFive CPU.
On Tue, Jan 23, 2024 at 12:24 PM Jeff Law wrote:
>
>
> On 1/21/24 23:12, Monk Chiang wrote:
> > Since the match.pd transforms (zero_one == 0) ? y : z y,
> > into
On Tue, 23 Jan 2024 at 23:54, Patrick Palka wrote:
> diff --git a/libstdc++-v3/include/bits/stl_pair.h
> b/libstdc++-v3/include/bits/stl_pair.h
> index b81b479ad43..a9b20fbe7ca 100644
> --- a/libstdc++-v3/include/bits/stl_pair.h
> +++ b/libstdc++-v3/include/bits/stl_pair.h
> @@ -85,12 +85,70 @@
Thanks for doing this. I'm not qualified to review the patch properly,
but was just curious...
Andi Kleen writes:
> This patch implements a clang compatible [[musttail]] attribute for
> returns.
>
> musttail is useful as an alternative to computed goto for interpreters.
> With computed goto the
Manos Anagnostakis writes:
> The current ldp/stp policy framework implementation was missing cases, where
> the memory operands were reversed. Therefore the call to the framework
> function
> is moved after the lower mem check with the suitable parameters. Also removes
> the mode of
On Wed, 2024-01-24 at 19:08 +0800, chenxiaolong wrote:
> At 19:00 +0800 on Wednesday, 2024-01-24, Xi Ruoyao wrote：
> > On Wed, 2024-01-24 at 18:32 +0800, chenxiaolong wrote:
> > > On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote：
> > > > The vect_int_mod target selector is evaluated with the
1 - 100 of 139 matches
Mail list logo
