On Tue, Feb 20, 2024 at 06:35:34PM +0800, Kewen.Lin wrote:
> Hi Mike,
>
> Sorry for late reply (just back from vacation).
>
> on 2024/2/8 03:58, Michael Meissner wrote:
> > On Wed, Feb 07, 2024 at 05:21:10PM +0800, Kewen.Lin wrote:
> >> on 2024/2/6 14:01, Michael Meissner wrote:
> >> Sorry for th
on 2024/2/21 09:37, Peter Bergner wrote:
> On 2/20/24 3:27 AM, Kewen.Lin wrote:
>> on 2024/2/20 02:45, Segher Boessenkool wrote:
>>> On Tue, Jan 16, 2024 at 10:50:01AM +0800, Kewen.Lin wrote:
it consists of some aspects:
- effective target powerpc_p{8,9}vector_ok are removed
an
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
on 2024/2/20 19:19, Segher Boessenkool wrote:
> On Tue, Feb 20, 2024 at 05:27:07PM +0800, Kewen.Lin wrote:
>> Good question, it mainly follows the practice of option direct-move here.
>> IMHO at least for power8-vector we want WarnRemoved for now as it's
>> documented before, and we can probably ma
Hi kito and juzhe.
There may be 2 items for double-confirm. Thanks a lot.
1. Not very sure if we need to upgrade the version for __riscv_th_v_intrinsic.
2. Do we need to upgrade the even a newer version (like 1.0) for the GCC 14
release, or we can do it later.
Pan
-Original Message-
Fr
From: Pan Li
Upgrade the version of RVV intrinsic from 0.11 to 0.12.
PR target/114017
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Upgrade
the version to 0.12.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-__riscv_v_intrinsic.c: Upda
v1 -> v2:
- Rebased to master.
- Specifies "(void)" for the empty parameter list of loongarch_global_init.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Mark -m[no-]recip as
aliases to -mrecip={all,none}.
* config/loongarch/loongarch.opt: Same.
* config/loongarch/loongarch-def.h: Modify ABI condition macros for
convenience.
* config/loongarc
In binutils 2.40 and earlier versions, only a warning will be reported
when a relocation immediate value is out of bounds. As a result,
the value of the macro HAVE_AS_COND_BRANCH_RELAXATION will also be
defined as 1 when the assembler does not support conditional branch
relaxation. Therefore, add t
Sorry, this title is incomplete and has been resent.
在 2024/2/21 上午11:08, Lulu Cheng 写道:
Because binutils2.42 corrects the implementation of
".align [abs-expr,[abs-expr[,abs-expr]]]".
The macro ASM_OUTPUT_ALIGN_WITH_NOP in GCC uses this assembler directive,
and an error occurs. See link below fo
From: Xi Ruoyao
Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure
building a cross compiler if the cross assembler is not installed yet.
gcc/ChangeLog:
PR target/112299
* config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0
if not defined yet.
(
From: Xi Ruoyao
As the commit message of r14-4674 has indicated, if the assembler does
not support conditional branch relaxation, a relocation overflow may
happen on conditional branches when relaxation is enabled because the
number of NOP instructions inserted by the assembler will be more than
gcc/ChangeLog:
* config.in: Regenerate.
* config/loongarch/genopts/loongarch.opt.in: Add compilation option
mrelax. And set the initial value of explicit-relocs according to the
detection status.
* config/loongarch/gnu-user.h: When compiling with -mno-relax,
There are two reasons for removing this macro definition:
1. The default in the assembler is to use the nop instruction for filling.
2. For assembly directives: .align [abs-expr[, abs-expr[, abs-expr]]]
The third expression it is the maximum number of bytes that should be
skipped by this alig
Because binutils2.42 corrects the implementation of
".align [abs-expr,[abs-expr[,abs-expr]]]".
The macro ASM_OUTPUT_ALIGN_WITH_NOP in GCC uses this assembler directive,
and an error occurs. See link below for detailed description.
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645067.html
From: Xi Ruoyao
As the commit message of r14-4674 has indicated, if the assembler does
not support conditional branch relaxation, a relocation overflow may
happen on conditional branches when relaxation is enabled because the
number of NOP instructions inserted by the assembler will be more than
gcc/ChangeLog:
* config.in: Regenerate.
* config/loongarch/genopts/loongarch.opt.in: Add compilation option
mrelax. And set the initial value of explicit-relocs according to the
detection status.
* config/loongarch/gnu-user.h: When compiling with -mno-relax,
From: Xi Ruoyao
Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure
building a cross compiler if the cross assembler is not installed yet.
gcc/ChangeLog:
PR target/112299
* config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0
if not defined yet.
(
There are two reasons for removing this macro definition:
1. The default in the assembler is to use the nop instruction for filling.
2. For assembly directives: .align [abs-expr[, abs-expr[, abs-expr]]]
The third expression it is the maximum number of bytes that should be
skipped by this alig
Because binutils2.42 corrects the implementation of
".align [abs-expr,[abs-expr[,abs-expr]]]".
The macro ASM_OUTPUT_ALIGN_WITH_NOP in GCC uses this assembler directive,
and an error occurs. See link below for detailed description.
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645067.html
After r7-987-gf17a223de829cb, the access for the elements of a vector type
would lose the qualifiers.
So if we had `constvector[0]`, the type of the element of the array would not
have const on it.
This was due to a missing build_qualified_type for the inner type of the vector
when building the
gcc/ChangeLog:
* config.in: Regenerate.
* config/loongarch/genopts/loongarch.opt.in: Add compilation option
mrelax. And set the initial value of explicit-relocs according to the
detection status.
* config/loongarch/gnu-user.h: When compiling with -mno-relax,
From: Xi Ruoyao
As the commit message of r14-4674 has indicated, if the assembler does
not support conditional branch relaxation, a relocation overflow may
happen on conditional branches when relaxation is enabled because the
number of NOP instructions inserted by the assembler will be more than
Because binutils2.42 corrects the implementation of
".align [abs-expr,[abs-expr[,abs-expr]]]".
The macro ASM_OUTPUT_ALIGN_WITH_NOP in GCC uses this assembler directive,
and an error occurs. See link below for detailed description.
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645067.html
There are two reasons for removing this macro definition:
1. The default in the assembler is to use the nop instruction for filling.
2. For assembly directives: .align [abs-expr[, abs-expr[, abs-expr]]]
The third expression it is the maximum number of bytes that should be
skipped by this alig
From: Xi Ruoyao
Now loongarch.md uses HAVE_AS_TLS, we need this to fix the failure
building a cross compiler if the cross assembler is not installed yet.
gcc/ChangeLog:
PR target/112299
* config/loongarch/loongarch-opts.h (HAVE_AS_TLS): Define to 0
if not defined yet.
(
On 2/20/24 3:27 AM, Kewen.Lin wrote:
> on 2024/2/20 02:45, Segher Boessenkool wrote:
>> On Tue, Jan 16, 2024 at 10:50:01AM +0800, Kewen.Lin wrote:
>>> it consists of some aspects:
>>> - effective target powerpc_p{8,9}vector_ok are removed
>>> and replaced with powerpc_vsx_ok.
>>
>> So all suc
LGTM, thanks for fixing that issue :)
On Wed, Feb 21, 2024 at 6:03 AM Edwin Lu wrote:
>
> The testcase pr113742.c is failing for 32 bit targets due to the following cc1
> error:
> cc1: error: ABI requries '-march=rv64'
>
> Specify '-march=rv64gc' with '-mtune=sifive-p600-series'
>
> V1: https://g
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-9091-g0a6a5f8656ccf9.
gcc/analyzer/ChangeLog:
PR analyzer/113999
* analyzer.h (get_string_cst_size): New decl.
* region
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-9090-g79d4c7ddc83e00.
gcc/analyzer/ChangeLog:
PR analyzer/113998
* ranges.cc (symbolic_byte_range::intersection): Handle empty
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR asks that our -Wuninitialized for mem-initializers does
not warn when binding a reference to an uninitialized data member.
We already check !INDIRECT_TYPE_P in find_uninit_fields_r, but
that won't catch binding a paramet
[Changes from v2:
- Fix incorrectly passing a location instead of OPT_W* for warning ().
- Reword warning/error message and test accordingly. ]
[Changes from v1: Jose's review comments, all of which I agree with.
- Fix 'implments' typo in commit message.
- Change check that alignment is CON
On 2/20/24 12:37, Jose E. Marchesi wrote:
>
> Hi Faust.
>
>> +bool
>> +bpf_expand_cpymem (rtx *operands, bool is_move)
>> +{
>> + /* Size must be constant for this expansion to work. */
>> + if (!CONST_INT_P (operands[2]))
>> +{
>> + const char *name = is_move ? "memmove" : "memcpy
On Tue, Feb 20, 2024 at 01:49:30PM -0600, Peter Bergner wrote:
> I think this will become less fragile after we fix PR114004 which is
You call it "fragile". I call it the testcase found the exact kind of
bug this testcase was meant to find!
Yes, the test should become quieter when the compiler h
This patch optimizes the compilation performance of std::is_invocable
by dispatching to the new __is_invocable built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_invocable): Use __is_invocable
built-in trait.
* testsuite/20_util/is_invocable/incomplete_a
The testcase pr113742.c is failing for 32 bit targets due to the following cc1
error:
cc1: error: ABI requries '-march=rv64'
Specify '-march=rv64gc' with '-mtune=sifive-p600-series'
V1: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645609.html
PR target/113742
gcc/testsuite/Ch
> On 20 Feb 2024, at 20:50, David Malcolm wrote:
>
> On Thu, 2024-02-15 at 17:08 -0500, Antoni Boucher wrote:
>> Hi.
>> This patch adds a new option to allow special characters like . and $
>> in function names.
>> This is useful to allow for mangling using those characters.
>> Thanks for the
On Thu, 2024-02-15 at 17:08 -0500, Antoni Boucher wrote:
> Hi.
> This patch adds a new option to allow special characters like . and $
> in function names.
> This is useful to allow for mangling using those characters.
> Thanks for the review.
Thanks for the patch.
> diff --git a/gcc/jit/docs/top
Hi Cupertino,
On 2/20/24 02:24, Cupertino Miranda wrote:
> Dissociated .BTF.ext from the CO-RE relocations creation. Improvement of
> allocation/deallocation of BTF structures. Moving deallocation to final
> when needed.
>
> gcc/ChangeLog:
>
> * config/bpf/bpf.cc (bpf_option_override): Mak
Hi Faust.
> +bool
> +bpf_expand_cpymem (rtx *operands, bool is_move)
> +{
> + /* Size must be constant for this expansion to work. */
> + if (!CONST_INT_P (operands[2]))
> +{
> + const char *name = is_move ? "memmove" : "memcpy";
> + if (flag_building_libgcc)
> + warning (RT
Iain Sandoe writes:
> Andrew Pinski pointed out on irc, that the current implementation of the
> heap trampoline code fragment would make the instruction byte order follow
> memory byte order for BE AArch64, which is not what is required.
>
> This patch revises the initializers so that instruction
On Tue, Feb 20, 2024 at 08:53:37PM +0100, Harald Anlauf wrote:
> On 2/19/24 16:19, Peter Hill wrote:
> > Hi Harald,
> >
> > Thanks for your help, please see the updated and signed-off patch below.
>
> Pushed: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2
>
Harald, Thanks for ta
On 2/20/24 02:24, Cupertino Miranda wrote:
> This patch correct the aditition of +1 on the type id, which originally
> was done in the wrong location and leaded to func_sts->dtd_type for
> BTF_KIND_FUNCS struct data to contain the type id of the previous entry.
>
> gcc/ChangeLog:
> * btfo
On 2/19/24 16:19, Peter Hill wrote:
Hi Harald,
Thanks for your help, please see the updated and signed-off patch below.
Pushed: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2
On 2/20/24 3:29 AM, Kewen.Lin wrote:
> on 2024/2/20 06:35, Peter Bergner wrote:
>> rs6000: Update instruction counts due to combine changes [PR112103]
>>
>> The PR91865 combine fix changed instruction counts slightly for rlwinm-0.c.
>> Adjust expected instruction counts accordingly.
>>
>> This pass
[Changes from v1: Jose's review comments, all of which I agree with.
- Fix 'implments' typo in commit message.
- Change check that alignment is CONST_INT to gcc_assert ().
- Change default case in alignment switch to gcc_unreachable ().
- Reword error message for non-constant size memmove/memcp
On Tue, 20 Feb 2024 at 18:43, François Dumont wrote:
>
>libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_wrap behavior
>
> In _GLIBCXX_DEBUG mode the std::__niter_base can remove 2 layers, the
> __gnu_debug::_Safe_iterator<> and the __gnu_cxx::__normal_iterator<>.
> When std::__niter_wr
libstdc++: [_GLIBCXX_DEBUG] Fix std::__niter_wrap behavior
In _GLIBCXX_DEBUG mode the std::__niter_base can remove 2 layers, the
__gnu_debug::_Safe_iterator<> and the __gnu_cxx::__normal_iterator<>.
When std::__niter_wrap is called to build a
__gnu_debug::_Safe_iterator<>
fro
GCC maintainers:
The patch changes the vec-cmpne.c from a compile only test to a runnable test.
The macros to create the functions needed to test the built-ins and verify the
restults are all there in the include file. The .c file just needed to have
the macro definitions inserted and chang
GCC maintainers:
The patch adds test cases for the __builtin_vec_init* and __builtin_vec_set*
built-ins.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acceptable for mainline. Thanks.
Carl
GCC maintainers:
The patch adds test cases for the vec_cmpne of built-ins.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acceptable for mainline. Thanks.
Carl
rs
GCC maintainers:
The patch adds documentation and test case for the __builtin_vsx_xvcmpeq[sp,
dp, sp_p] built-ins.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acceptable for mainline. Thanks.
Carl
--
GCC maintainers:
There are a number of undocumented built-ins that are duplicates of other
documented built-ins. This patch removes the duplicates so users will only use
the documented built-in.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acc
GCC maintainers:
The patch adds documentation a number of built-ins.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acceptable for mainline. Thanks.
Carl
rs60
GCC maintainers:
The patch expands an existing comment to document that the duplicates are
covered by an overloaded built-in. I am wondering if we should just go ahead
and remove the duplicates?
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acc
GCC maintainers:
The patch adds documentation and test case for the __builtin_vsx_xxpermdi_1ti
built-in.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acceptable for mainline. Thanks.
Carl
GCC maintainers:
The patch adds documentation and test cases for the __builtin_vsx_xvnegsp,
__builtin_vsx_xvnegdp built-ins.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acceptable for mainline. Thanks.
Carl
GCC maintainers:
This patch fixes the return type for the __builtin_vsx_xvcvdpuxws and
__builtin_vsx_xvcvspuxds built-ins. They were defined as signed but should
have been defined as unsigned.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is ac
GCC maintainers:
This patch fixes the arguments and return type for the various
__builtin_vsx_cmple* built-ins. They were defined as signed but should have
been defined as unsigned.
The patch has been tested on Power 10 with no regressions.
Please let me know if this patch is acceptable for
On Tue, Feb 20, 2024 at 7:35 AM Jose E. Marchesi
wrote:
>
>
> Hello Will.
>
> Thanks for the patch.
> I just installed it on your behalf.
Thank you!
>
> > Add documentation describing the meaning and values for the -mcpu
> > command-line option.
> >
> > Tested for bpf-unknown-none on x86_64-linu
GCC maintainers:
The following series of patches cleanup some of the rs6000 built-in support.
Some of the first patches fix errors in the definition of a few of the
built-ins. The built-ins are supposed to have unsigned arguments but are
listed as signed. Some of the built-ins are supposed t
On Tue, Feb 20, 2024 at 05:39:39PM +0100, Tobias Burnus wrote:
> clang/lib/Headers/openmp_wrappers/complex:device = {arch(amdgcn, nvptx,
> nvptx64)}, \
That one doesn't really need the nvptx64 support.
> --- a/gcc/config/nvptx/nvptx.cc
> +++ b/gcc/config/nvpt
I just encountered 'arch(nvptx64)'. I think it makes sense to support
it as alias for 'nvptx' in the context selector for better compatibility.
Comments, remarks, suggestions?
Tobias
PS: See the LLVM documentation below. I do note that those are not identical
as LLVM uses 'nvptx' for 32bit whil
This patch implements built-in trait for std::is_invocable.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_invocable.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_INVOCABLE.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.
This came up recently as Edwin was looking through the test suite. A
few of us were talking about this during the patchwork meeting and were
surprised. Looks like this is the desired behavior, so let's at least
document it.
gcc/ChangeLog:
* doc/invoke.texi: Document -mcpu.
Signed-off-b
AVR: Use types of exact size and signedness in built-ins.
The AVR built-ins used types like "int" or "char" that don't
have exact signedness or type size which depend on -mint8
and -f[no-][un-]signed-char etc. As the built-ins are modelling
machine instructions of given type sizes and signedness
On Mon, Feb 19, 2024 at 11:36 PM Alexandre Oliva wrote:
>
> This backport for gcc-13 is the first of two required for the
> g++.dg/pch/line-map-3.C test to stop hitting a variant of the known
> problem mentioned in that testcase: on riscv64-elf and riscv32-elf,
> after restoring the PCH, the locat
On Feb 20, 2024, Jeff Law wrote:
> On 2/19/24 21:26, Alexandre Oliva wrote:
>> This backport for gcc-13 is required for pr90838.c to get the expected
>> count of andi instructions on riscv64-elf
.
> In general, shouldn't backports be focused on correctness issues?
*nod*.
> It's unclear what the
LGTM :)
On Tue, Feb 20, 2024 at 12:03 PM Alexandre Oliva wrote:
>
> This testcase is failing with riscv64-elf and riscv32-elf in the gcc-13
> branch, if configured to use an assembler that supports -misa-spec; with
> an assembler that doesn't, the test passes both with and without the
> following
On Tue, Feb 20, 2024 at 11:27 AM Iain Sandoe wrote:
>
> Tested on aarch64-linux-gnu, aarch64-darwin by me and on aarch64-linux-musl
> by Sam James (thanks!). OK for trunk?
OK
> thanks
> Iain
>
> --- 8< ---
>
>
> This allows the same trampoline pattern to be used on all linux variants
> rather t
This patch uses @defbuiltin to document built-in
functions so that the functions are listed in the index.
Previously, @table @code was used.
Johann
--
AVR: extend.texi - Use @defbuiltin to document built-ins.
gcc/
* doc/extend.texi (AVR Built-in Functions): Use @defbuiltin
inst
Hello Will.
Thanks for the patch.
I just installed it on your behalf.
> Add documentation describing the meaning and values for the -mcpu
> command-line option.
>
> Tested for bpf-unknown-none on x86_64-linux-gnu host.
>
> gcc/ChangeLog:
>
> * config/bpf/bpf.opt: Add help information for
在 2024/2/20 下午7:54, Xi Ruoyao 写道:
On Tue, 2024-02-20 at 19:50 +0800, chenglulu wrote:
在 2024/2/20 下午7:31, Xi Ruoyao 写道:
On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote:
On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote:
So I think that without worrying about performance and ensuring th
On Tue, 2024-02-20 at 19:50 +0800, chenglulu wrote:
>
> 在 2024/2/20 下午7:31, Xi Ruoyao 写道:
> > On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote:
> > > On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote:
> > >
> > > > So I think that without worrying about performance and ensuring that
> > > > th
在 2024/2/20 下午7:31, Xi Ruoyao 写道:
On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote:
On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote:
So I think that without worrying about performance and ensuring that
there is no problem
with binutils, I think we can make the following modifications:
On Tue, 2024-02-20 at 19:25 +0800, Xi Ruoyao wrote:
> On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote:
>
> > So I think that without worrying about performance and ensuring that
> > there is no problem
> >
> > with binutils, I think we can make the following modifications:
> >
> > -/* "nop
This patch makes -mtrack-speculation work on streaming-compatible
functions. There were two related issues. The first is that the
streaming-compatible code was using TB(N)Z unconditionally, whereas
those instructions are not allowed with speculation tracking.
That part can be fixed in a similar w
On Tue, 2024-02-20 at 10:07 +0800, chenglulu wrote:
> So I think that without worrying about performance and ensuring that
> there is no problem
>
> with binutils, I think we can make the following modifications:
>
> -/* "nop" instruction 54525952 (andi $r0,$r0,0) is
> - used for paddin
On Tue, Feb 20, 2024 at 05:27:07PM +0800, Kewen.Lin wrote:
> > -mcpu=power8 implies -mvsx already.
>
> Yes, but users can specify -mno-vsx in RUNTESTFLAGS, dejagnu
> framework can have different behaviors (options order) for
> different versions, this explicit -mvsx is mainly for the
> consistency
Hi Mike,
Sorry for late reply (just back from vacation).
on 2024/2/8 03:58, Michael Meissner wrote:
> On Wed, Feb 07, 2024 at 05:21:10PM +0800, Kewen.Lin wrote:
>> on 2024/2/6 14:01, Michael Meissner wrote:
>> Sorry for the possible confusion here, the "tune_proc" that I referred to is
>> the var
Andrew Pinski pointed out on irc, that the current implementation of the
heap trampoline code fragment would make the instruction byte order follow
memory byte order for BE AArch64, which is not what is required.
This patch revises the initializers so that instruction byte order is
independent of
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Thursday, February 1, 2024 4:42 PM
>> To: Tamar Christina
>> Cc: Andrew Pinski ; gcc-patches@gcc.gnu.org; nd
>> ; Richard Earnshaw ; Marcus
>> Shawcroft ; Kyrylo Tkachov
>>
>> Subject: Re: [PATCH]AArch64:
On Tue, Feb 20, 2024 at 11:11:22AM +0100, Richard Biener wrote:
> > --- gcc/c-family/c-common.cc.jj 2024-02-17 16:40:42.831571693 +0100
> > +++ gcc/c-family/c-common.cc2024-02-20 10:58:56.599865656 +0100
> > @@ -7793,9 +7793,14 @@ resolve_overloaded_atomic_exchange (loca
> >/* Conve
Tested on aarch64-linux-gnu, aarch64-darwin by me and on aarch64-linux-musl
by Sam James (thanks!). OK for trunk?
thanks
Iain
--- 8< ---
This allows the same trampoline pattern to be used on all linux variants
rather than restricting it to linux gnu.
PR target/113971.
libgcc/ChangeLog
Kernel verifier complains in some particular cases for missing func_info
implementation in .BTF.ext. This patch implements it.
Strings are cached locally in coreout.cc to avoid adding duplicated
strings in the string list. This string deduplication should eventually
be moved to the CTFC functions
gcc/ChangeLog:
* config.gcc (target_gtfiles): changed coreout to btfext-out.
(extra_objs): changed coreout to btfext-out.
* config/bpf/coreout.cc: Renamed to btfext-out.cc
* config/bpf/btfext-out.cc: Added
* config/bpf/coreout.h: Renamed to btfext-out.h
Dissociated .BTF.ext from the CO-RE relocations creation. Improvement of
allocation/deallocation of BTF structures. Moving deallocation to final
when needed.
gcc/ChangeLog:
* config/bpf/bpf.cc (bpf_option_override): Make BTF.ext enabled
by default for BPF.
(btf_asm_init_se
Added a traversal function to traverse all BTF_KIND_FUNC nodes with a
callback function. Used for .BTF.ext section content creation.
gcc/ChangeLog
* btfout.cc (output_btf_func_types): use FOR_EACH_VEC_ELT.
(traverse_btf_func_types): Defined function.
* ctfc.h (funcs_traver
This patch correct the aditition of +1 on the type id, which originally
was done in the wrong location and leaded to func_sts->dtd_type for
BTF_KIND_FUNCS struct data to contain the type id of the previous entry.
gcc/ChangeLog:
* btfout.cc (btf_collect_dataset): Corrected BTF type id.
---
Good morning,
This is a patch series with the implementation of func_info region
within bpf target .BTF.ext section.
Considering the required changes it also implied some changes in BTF and
in the original CO-RE implementation, more specifically the structure
used and how the relocations were crea
> On Tue, Feb 13 2024, Martin Jambor wrote:
> > On Mon, Feb 12 2024, Jan Hubicka wrote:
> >>> Believe it or not, even though I have re-worked the internals of the
> >>> lattices completely, the array itself is older than my involvement with
> >>> GCC (or at least with ipa-cp.c ;-).
> >>>
> >>> So
On Tue, 20 Feb 2024, Jakub Jelinek wrote:
> On Tue, Feb 20, 2024 at 09:01:10AM +0100, Richard Biener wrote:
> > I'm not sure those would be really equivalent (MEM_REF vs. V_C_E
> > as well as combined vs. split). It really depends how RTL expansion
> > handles this (as you can see padding can be
Alex Coplan writes:
> On 14/02/2024 11:18, Richard Sandiford wrote:
>> Alex Coplan writes:
>> > This is a backport of the GCC 13 fix for PR111677 to the GCC 12 branch.
>> > The only part of the patch that isn't a straight cherry-pick is due to
>> > the TX iterator lacking TDmode for GCC 12, so th
Tamar Christina writes:
> Hi, this I a new version of the patch updating some additional tests
> because some of the LTO tests required a newer binutils than my distro had.
>
> ---
>
> The Arm Architectural Reference Manual (Version J.a, section A2.9 on
> FEAT_LS64)
> shows that ls64 is an optio
On Tue, Feb 20, 2024 at 09:01:10AM +0100, Richard Biener wrote:
> I'm not sure those would be really equivalent (MEM_REF vs. V_C_E
> as well as combined vs. split). It really depends how RTL expansion
> handles this (as you can see padding can be fun here).
>
> So I'd be nervous for a match.pd ru
Victor Do Nascimento writes:
> [...]
> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
> index 157a0b9dfa5..45e901cda64 100644
> --- a/gcc/config/aarch64/aarch64.h
> +++ b/gcc/config/aarch64/aarch64.h
> @@ -297,6 +297,26 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE =
> A
Hi!
Already previously instantiated const variable templates had
cp_apply_type_quals_to_decl called when they were instantiated,
but if they need runtime initialization, their TREE_READONLY flag
has been subsequently cleared.
Explicit variable template instantiation calls grokdeclarator which
call
On Mon, Feb 19, 2024 at 01:33:33PM -0800, Andrew Pinski wrote:
> * gcc.dg/analyzer/torture/vector-extract-1.c: New test.
The testcase fails on i686-linux with
.../gcc/testsuite/gcc.dg/analyzer/torture/vector-extract-1.c:11:1: warning: MMX
vector return without MMX enabled changes the ABI [-
Hi David.
Thanks for the patch.
See a couple of comments regarding error handling below.
> BPF programs are not typically linked, which means we cannot fall back
> on library calls to implement __builtin_{memmove,memcpy} and should
> always expand them inline if possible.
>
> GCC already succes
Hi Edwin,
I think just replace to:
/* { dg-options "-O2 -finstrument-functions -mabi=lp64d -march=rv64gc
-mtune=sifive-p600-series" } */
On Thu, Feb 15, 2024 at 7:43 PM Robin Dapp wrote:
> > Ah oops I glanced over the /* { dg-do compile } */part. It should be
> > fine to add '-march=rv64gc' inst
1 - 100 of 108 matches
Mail list logo
