So alternative v won't be igored in record_reg_classess.
Similar for *r alternatives in some vector patterns.
It helps testcase in the PR, also RA now makes better decisions for
gcc.target/i386/extract-insert-combining.c
movd%esi, %xmm0
movd%edi, %xmm1
- movl%es
On Tue, Jun 07, 2022 at 08:12:26AM +0200, Jan Beulich via Gcc-patches wrote:
> > This regressed
> > Executing on host: /home/jakub/src/gcc/obj44/gcc/xgcc
> > -B/home/jakub/src/gcc/obj44/gcc/ -fdiagnostics-plain-output -flto -g
> > -gsplit-dwarf -c -o c_lto_pr83719_0.o
> > /home/jakub/src
On Tue, Jun 7, 2022 at 3:41 PM liuhongt via Gcc-patches
wrote:
>
> So alternative v won't be igored in record_reg_classess.
>
> Similar for *r alternatives in some vector patterns.
>
> It helps testcase in the PR, also RA now makes better decisions for
> gcc.target/i386/extract-insert-combining.c
thank you to the reviewers of the patch sets 01 though 09. As a brief
followup/summary I propose rewriting linking as per Richard's
suggestion:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595782.html
Aside from the many technical advantages, logistically it also means:
* the gm2 dri
>> + (mult:c (plus:c@4 (mult:c@5 @0 INTEGER_CST@1) INTEGER_CST@2) INTEGER_CST@3)
>since canonicalization puts INTEGER_CSTs last the :c should not be necessary.
Changed.
>> + (if (single_use (@4)
>> + && single_use (@5))
>since the resulting expression is not simple using :s instead of
>sin
From: yulong
We changed builtins format about zicbom and zicboz subextensions and added test
cases.
diff with the previous version:
1.We deleted the RLT mode's second input operand.
2.We modified the type of builtins from RISCV_BUILTIN_DIRECT to
RISCV_BUILTIN_DIRECT_NO_TARGET.
3.We modified the
> The (proposed) solution is to export store_constructor (and it's helper
> function int_expr_size) from expr.cc, by removing their static qualifier
> and prototyping both functions in expr.h, so they can be called directly
> from load_register_parameters in calls.cc. This cures both ICEs, but
> a
Hi,
This patch replaces shift and ior insns with one rotate and mask
insn for the split patterns which are for DI byte swap on Power6. The
test cases shows the optimization.
Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thank
On 07.06.2022 09:41, Jakub Jelinek wrote:
> On Tue, Jun 07, 2022 at 08:12:26AM +0200, Jan Beulich via Gcc-patches wrote:
>>> This regressed
>>> Executing on host: /home/jakub/src/gcc/obj44/gcc/xgcc
>>> -B/home/jakub/src/gcc/obj44/gcc/ -fdiagnostics-plain-output -flto -g
>>> -gsplit-dwarf
On Tue, Jun 7, 2022 at 9:41 AM liuhongt wrote:
>
> So alternative v won't be igored in record_reg_classess.
>
> Similar for *r alternatives in some vector patterns.
>
> It helps testcase in the PR, also RA now makes better decisions for
> gcc.target/i386/extract-insert-combining.c
>
> movd
On Mon, 2022-06-06 at 09:28 +, Dimitrije Milosevic wrote:
> Fix the ASAN shadow offset hook for the n32 ABI.
>
> gcc/ChangeLog:
>
> * config/mips/mips.cc (mips_asan_shadow_offset): Reformat
> to handle the N32 ABI.
> * config/mips/mips.h (SUBTARGET_SHADOW_OFFSET): Remo
Joel Hutton writes:
>> > Patches attached. They already incorporated the .cc rename, now
>> > rebased to be after the change to tree.h
>>
>> @@ -1412,8 +1412,7 @@ vect_recog_widen_op_pattern (vec_info *vinfo,
>>2, oprnd, half_type, unprom, vectype);
>>
>>tree var = vect
Hi!
The syntax for linear clause changed in 5.2, the original syntax
which is still valid is:
linear (var1, var2)
linear (var3, var4 : step1)
The 4.5 syntax with modifiers like:
linear (val (var5, var6))
linear (val (var7, var8) : step2)
is still supported in 5.2, but is deprecated there.
Instead,
On Mon, 2022-05-30 at 07:10 +, Dimitrije Milosevic wrote:
> Hi Xi, thanks for pointing this out. I'd definitely say that the
> https://clang.llvm.org/docs/ThreadSanitizer.html documentation is
> outdated. According
> tohttps://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual#s
> uppor
Thanks Richard,
> I thought the potential problem with the above is that gimple_build is a
> folding interface, so in principle it's allowed to return an existing SSA_NAME
> set by an existing statement (or even a constant).
> I think in this context we do need to force a new statement to be creat
On Tue, Jun 7, 2022 at 6:56 AM liuhongt via Gcc-patches
wrote:
>
> 21114(define_insn_and_split "ssse3_palignrdi"
> 21115 [(set (match_operand:DI 0 "register_operand" "=y,x,Yv")
> 21116(unspec:DI [(match_operand:DI 1 "register_operand" "0,0,Yv")
> 21117(match_operand:DI
Hello Joseph and all,
here is a preliminary patch the implements the proposed
tag compatibility rules for C23 in GCC (N2863). It works
by tweaking the diagnostics in the FE and by recording
structs/union types to be able to set TYPE_CANONICAL to
a canonical definition (as per previous discussio
On Tue, Jun 07, 2022 at 12:21:25AM +0200, Ahmed Sayed Mousse via Gcc-patches
wrote:
> This patch is the initial implementation of OpenMP-API specs book section
> 20.5.5 with title "Thread Handles"
>
> libgomp/ChangeLog
>
> 2022-05-06 Ahmed Sayed
Two spaces should separate the date and name and
On Tue, Jun 7, 2022 at 4:04 PM wrote:
>
> From: yulong
>
> We changed builtins format about zicbom and zicboz subextensions and added
> test cases.
> diff with the previous version:
> 1.We deleted the RLT mode's second input operand.
> 2.We modified the type of builtins from RISCV_BUILTIN_DIRECT
Correct, it should be committed very soon.
From: Xi Ruoyao
Sent: Tuesday, June 7, 2022 10:17 AM
To: Dimitrije Milosevic ;
gcc-patches@gcc.gnu.org
Cc: Djordje Todorovic
Subject: Re: [PATCH] Mips: Fix the ASAN shadow offset hook for the n32 ABI
On Mon, 2022-06-06
Definitely, a patch is on the way.
From: Xi Ruoyao
Sent: Tuesday, June 7, 2022 10:20 AM
To: Dimitrije Milosevic ;
gcc-patches@gcc.gnu.org
Cc: Djordje Todorovic
Subject: Re: [PATCH] Mips: Enable asynchronous unwind tables with both ASAN and
TSAN
On Mon, 2022-05
On Wed, May 25, 2022 at 5:47 AM Philipp Tomsich
wrote:
>
> The current method of treating shifts of extended values on RISC-V
> frequently causes sequences of 3 shifts, despite the presence of the
> 'zero_extendsidi2_shifted' pattern.
>
> Consider:
> unsigned long f(unsigned int a, unsigned lo
LGTM, you can commit that without [3/3] if you like :)
On Wed, May 25, 2022 at 5:47 AM Philipp Tomsich
wrote:
>
> When encountering a prescaled (biased) value as a candidate for
> sh[123]add.uw, the combine pass will present this as shifted by the
> aggregate amount (prescale + shift-amount) with
LGTM
On Wed, May 25, 2022 at 5:48 AM Philipp Tomsich
wrote:
>
> Provide an easy way to constrain for constants that are a a single,
> consecutive run of ones.
>
> gcc/ChangeLog:
>
> * config/riscv/predicates.md (consecutive_bits_operand):
> Implement new predicate.
>
> Signed-o
> OK for backport?
OK, it seems no issue after a week :)
>
> On Thu, 2 Jun 2022 at 21:23, Philipp Tomsich wrote:
> >
> > Thanks, applied to trunk!
> >
> > On Thu, 2 Jun 2022 at 15:17, Kito Cheng wrote:
> > >
> > > LGTM
> > >
> > > On Mon, May 30, 2022 at 5:52 AM Philipp Tomsich
> > > wrote:
>
On Mon, 6 Jun 2022 at 16:29, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> >> > {
> >> >/* The pattern matching functions above are written to look for a
> >> > small
> >> > number to begin the sequence (0, 1, N/2). If we begin with an
> >> > index
> >> > @@ -24084,6 +2
On Tue, 7 Jun 2022 at 12:24, Kito Cheng wrote:
>
> On Wed, May 25, 2022 at 5:47 AM Philipp Tomsich
> wrote:
> >
> > The current method of treating shifts of extended values on RISC-V
> > frequently causes sequences of 3 shifts, despite the presence of the
> > 'zero_extendsidi2_shifted' pattern.
>
Prathamesh Kulkarni writes:
> On Mon, 6 Jun 2022 at 16:29, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> >> > {
>> >> >/* The pattern matching functions above are written to look for a
>> >> > small
>> >> > number to begin the sequence (0, 1, N/2). If we begin with
Following some feedback from users of the OG11 branch I think I need to
withdraw this patch, for now.
The memory pinned via the mlock call does not give the expected
performance boost. I had not expected that it would do much in my test
setup, given that the machine has a lot of RAM and my ben
This patch, in response to PR105090, makes some general improvements
to the code generation when BFI and BFC instructions are available.
Firstly we handle more cases where the RTL does not generate an INSV
operation due to a lack of a tie between the input and output, but we
nevertheless need to e
On Tue, Jun 07, 2022 at 12:05:40PM +0100, Andrew Stubbs wrote:
> Following some feedback from users of the OG11 branch I think I need to
> withdraw this patch, for now.
>
> The memory pinned via the mlock call does not give the expected performance
> boost. I had not expected that it would do much
On 07/06/2022 13:10, Jakub Jelinek wrote:
On Tue, Jun 07, 2022 at 12:05:40PM +0100, Andrew Stubbs wrote:
Following some feedback from users of the OG11 branch I think I need to
withdraw this patch, for now.
The memory pinned via the mlock call does not give the expected performance
boost. I had
On Tue, Jun 07, 2022 at 01:28:33PM +0100, Andrew Stubbs wrote:
> > For performance boost of what kind of code?
> > I don't understand how Cuda API could be useful (or can be used at all) if
> > offloading to NVPTX isn't involved. The fact that somebody asks for host
> > memory allocation with omp_
Using the same pseudo register makes one longer live range instead of
two shorter live ranges, that's not good when inst. scheduler try to
separate those two instructions, and I think register allocator has
more complete knowledge to decide which way is better - using the same
or different, so I pr
On Mon, 6 Jun 2022, Jason Merrill wrote:
> On 6/6/22 14:27, Patrick Palka wrote:
> > On Thu, 7 Oct 2021, Jason Merrill wrote:
> >
> > > On 10/7/21 11:17, Patrick Palka wrote:
> > > > On Wed, 6 Oct 2021, Jason Merrill wrote:
> > > >
> > > > > On 10/6/21 15:52, Patrick Palka wrote:
> > > > > > On
gcc/cp/ChangeLog:
* cp-tree.h (mark_used): Remove single-parameter overload. Add
default argument to the two-parameter overload.
* decl2.cc (mark_used): Likewise.
---
gcc/cp/cp-tree.h | 3 +--
gcc/cp/decl2.cc | 8 +---
2 files changed, 2 insertions(+), 9 deletions(-)
On Tue, 7 Jun 2022, Martin Uecker wrote:
> here is a preliminary patch the implements the proposed
> tag compatibility rules for C23 in GCC (N2863). It works
I don't see any response on the reflector to my comments on that proposal
(message 21374, Fri, 14 Jan 2022 23:32:47 +). Nor do I see
Am Dienstag, den 07.06.2022, 14:22 + schrieb Joseph Myers:
> On Tue, 7 Jun 2022, Martin Uecker wrote:
>
> > here is a preliminary patch the implements the proposed
> > tag compatibility rules for C23 in GCC (N2863). It works
>
> I don't see any response on the reflector to my comments on that
Hi David, and Markus!
On 2022-06-02T15:46:20-0400, David Malcolm via Gcc-patches
wrote:
> This patch adds support to gcc's diagnostic subsystem for emitting
> diagnostics in SARIF, aka the Static Analysis Results Interchange Format:
> https://sarifweb.azurewebsites.net/
> by extending -fdiagno
Hi!
On 2022-05-30T09:06:21+0200, Tobias Burnus wrote:
> On 29.05.22 22:49, Thomas Schwinge wrote:
>> Not sure if that's what you had in mind, but what do you think about the
>> attached "nvptx: forward '-v' command-line option to assembler, linker"?
>> OK to push to GCC master branch (after mergi
Hi!
On Tue, Jun 07, 2022 at 04:07:58PM +0800, HAO CHEN GUI wrote:
> This patch replaces shift and ior insns with one rotate and mask
> insn for the split patterns which are for DI byte swap on Power6. The
> test cases shows the optimization.
Nice :-)
> - emit_insn (gen_ashldi3 (op3, op3, GEN_
On Tue, Jun 07, 2022 at 04:07:58PM +0800, HAO CHEN GUI wrote:
> Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.
One further thing: please make sure you have tested on -m32 as well,
especially for integer stuff lik
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated,
I've reworked my patch for this PR, so this one is obsolete.
The new one is:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596326.html
On 5/10/22 17:02, Christophe Lyon wrote:
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) wh
On Tue, 2022-06-07 at 10:50 +0800, Kewen.Lin wrote:
> Hi Will,
Hi!
>
> The whole series looks good to me, thanks!
:-)
> IMHO one place can be
> further
refactored, not sure if it's worth to updating together in
> this series, it's ...
Additional comments below
Hi all,
This lowers vcombine intrinsics to a GIMPLE vector constructor, which enables
better optimisation during GIMPLE passes.
Bootstrapped and tested on aarch64-none-linux-gnu, and tested for
aarch64_be-none-linux-gnu via cross-compilation.
gcc/
* config/aarch64/aarch64-builtins.c
Christophe Lyon via Gcc-patches writes:
> While working on enabling DFP for AArch64, I noticed new failures in
> gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
> caused by DFP types handling. These tests are generated during 'make
> check' and enabling DFP made generation differe
On 6/7/22 09:24, Patrick Palka wrote:
On Mon, 6 Jun 2022, Jason Merrill wrote:
On 6/6/22 14:27, Patrick Palka wrote:
On Thu, 7 Oct 2021, Jason Merrill wrote:
On 10/7/21 11:17, Patrick Palka wrote:
On Wed, 6 Oct 2021, Jason Merrill wrote:
On 10/6/21 15:52, Patrick Palka wrote:
On Wed, 6 O
On 6/7/22 10:16, Patrick Palka wrote:
gcc/cp/ChangeLog:
* cp-tree.h (mark_used): Remove single-parameter overload. Add
default argument to the two-parameter overload.
* decl2.cc (mark_used): Likewise.
OK.
---
gcc/cp/cp-tree.h | 3 +--
gcc/cp/decl2.cc | 8 +---
On Wed, 23 Mar 2022, Jason Merrill wrote:
> On 3/22/22 14:31, Patrick Palka wrote:
> > On Tue, 22 Mar 2022, Patrick Palka wrote:
> >
> > > Here we're neglecting to clear cp_unevaluated_operand when substituting
> > > into the arguments of the alias template-id skip<(T(), 0), T> with T=A,
> > > wh
On Mon, 06 Jun 2022 19:51:20 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
If -mcpu or -march is specified and there is no -mabi, we will calculate
default ABI from arch string provided by -march or defined in CPU info.
IMO this is generally a good idea and we've talked about it before, but
just
Add -fextra-libc-function=memcmpeq to map
extern int __memcmpeq (const void *, const void *, size_t);
which was added to GLIBC 2.35, to __builtin_memcmp_eq.
gcc/
* builtins.cc: Include "opts.h".
(expand_builtin): Generate BUILT_IN_MEMCMP_EQ if __memcmpeq is
available.
On Tue, Jun 07, 2022 at 11:45:13AM -0500, will schmidt wrote:
> Additional comments below.
> I've made note of the comments, and request (ask) that this be
> approved, with a pinky promise that I intend to follow up on the
> suggestions in my next patch series.
Suggestions aren't requirements :-
On Tue, 7 Jun 2022, Jason Merrill wrote:
> On 6/7/22 09:24, Patrick Palka wrote:
> > On Mon, 6 Jun 2022, Jason Merrill wrote:
> >
> > > On 6/6/22 14:27, Patrick Palka wrote:
> > > > On Thu, 7 Oct 2021, Jason Merrill wrote:
> > > >
> > > > > On 10/7/21 11:17, Patrick Palka wrote:
> > > > > > On W
On Mon, 2022-06-06 at 20:31 -0400, Michael Meissner wrote:
> Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target
> 99293.
>
> This is version 3 of the patch. The original patch was:
>
> > Date: Mon, 28 Mar 2022 12:26:02 -0400
> > Subject: [PATCH 1/4] Optimize vec_splats of const
On Linux/x86_64,
c4320bde42c6497b701e2e6b8f1c5069bed19818 is the first bad commit
commit c4320bde42c6497b701e2e6b8f1c5069bed19818
Author: Roger Sayle
Date: Tue Jun 7 07:49:40 2022 +0100
Recognize vpcmov in combine with -mxop on x86.
caused
FAIL: gcc.target/i386/xop-pcmov3.c scan-assemble
On Linux/x86_64,
cd22395457f063824c839fd1c0077d15d3dccd6d is the first bad commit
commit cd22395457f063824c839fd1c0077d15d3dccd6d
Author: liuhongt
Date: Mon Jun 6 13:39:19 2022 +0800
Fix insn does not satisfy its constraints: sse2_lshrv1ti3
caused
FAIL: gcc.target/i386/pr105854.c (test f
Hi
Is this less ambitious version ok ?
Thanks
On 25/05/22 07:09, François Dumont wrote:
Here is the patch to fix just what is described in PR 105714.
libstdc++: [_Hashtable] Insert range of types convertible to
value_type PR 105714
Fix insertion of range of types convertible to val
On 6/7/22 15:18, Patrick Palka wrote:
On Tue, 7 Jun 2022, Jason Merrill wrote:
On 6/7/22 09:24, Patrick Palka wrote:
On Mon, 6 Jun 2022, Jason Merrill wrote:
On 6/6/22 14:27, Patrick Palka wrote:
On Thu, 7 Oct 2021, Jason Merrill wrote:
On 10/7/21 11:17, Patrick Palka wrote:
On Wed, 6 Oc
On 6/7/22 14:25, Patrick Palka wrote:
On Wed, 23 Mar 2022, Jason Merrill wrote:
On 3/22/22 14:31, Patrick Palka wrote:
On Tue, 22 Mar 2022, Patrick Palka wrote:
Here we're neglecting to clear cp_unevaluated_operand when substituting
into the arguments of the alias template-id skip<(T(), 0),
On Tue, Jun 07, 2022 at 02:26:17PM -0500, will schmidt wrote:
> On Mon, 2022-06-06 at 20:31 -0400, Michael Meissner wrote:
> > (define_insn "vsx_xxspltd_"
> >[(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa")
> > -(unspec:VSX_D [(match_operand:VSX_D 1 "vsx_register_operand"
> >
On Mon, 2022-06-06 at 20:55 -0400, Michael Meissner wrote:
> [PATCH 2/3] Disable generating load/store vector pairs for block copies.
>
> If the store vector pair instruction is disabled, do not generate block
> copies that use load and store vector pair instructions.
>
> I have built bootstrap c
On Mon, 2022-06-06 at 20:55 -0400, Michael Meissner wrote:
> [PATCH 1/3] Disable generating store vector pair.
>
> Testing has revealed that the power10 has some slowdowns if the store
> vector pair instruction is generated in some cases. This patch disables
> generating the store vector pair ins
On Mon, 2022-06-06 at 20:56 -0400, Michael Meissner wrote:
> [PATCH 3/3] Adjust MMA tests to account for no store vector pair.
>
> In changing the default for generating the store vector pair instructions,
> I had to adjust several of the MMA tests to remove checking for these
> instructions. Mos
On Tue, 2022-06-07 at 15:21 -0500, Segher Boessenkool wrote:
> On Tue, Jun 07, 2022 at 02:26:17PM -0500, will schmidt wrote:
> > On Mon, 2022-06-06 at 20:31 -0400, Michael Meissner wrote:
> > > (define_insn "vsx_xxspltd_"
> > >[(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa")
> > > -
Hi!
On Tue, Jun 07, 2022 at 09:51:43AM +0800, HAO CHEN GUI wrote:
> On 2/6/2022 上午 5:01, Segher Boessenkool wrote:
> > On Wed, May 18, 2022 at 04:52:26PM +0800, HAO CHEN GUI wrote:
> >>const double __builtin_vsx_xsmaxdp (double, double);
> >> -XSMAXDP smaxdf3 {}
> >> +XSMAXDP fmaxdf3 {
On 6/6/22 7:55 PM, Michael Meissner wrote:
> gcc/
[snip]
> * config/rs6000/rs6000.opt (-mstore-vector-pair): New option.
[snip]
> diff --git a/gcc/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt
> index 4931d781c4e..79ceec6e6a5 100644
> --- a/gcc/config/rs6000/rs6000.opt
> +++ b/gcc/c
On Tue, 2022-06-07 at 17:10 +0200, Thomas Schwinge wrote:
> Hi David, and Markus!
>
> On 2022-06-02T15:46:20-0400, David Malcolm via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > This patch adds support to gcc's diagnostic subsystem for emitting
> > diagnostics in SARIF, aka the Static Analy
On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote:
> I think I mentioned this offline, but I'd prefer a negative target flag,
> something like TARGET_NO_STORE_VECTOR_PAIR that defaults to off, meaning we'd
> generate stxvp by default.
NAK. All negatives should be -mno-xxx with -mxxx t
On 6/2/22 19:04, Yonghong Song wrote:
>
>
> On 5/27/22 12:56 PM, David Faust wrote:
>>
>>
>> On 5/26/22 00:29, Yonghong Song wrote:
>>>
>>>
>>> On 5/24/22 10:04 AM, David Faust wrote:
On 5/24/22 09:03, Yonghong Song wrote:
>
>
> On 5/24/22 8:53 AM, David Faust wrote:
gcc/
* dwarf2out.cc (dw_get_die_parent): New function.
* dwarf2out.h (dw_get_die_parent): Declare it here.
---
gcc/dwarf2out.cc | 8
gcc/dwarf2out.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 29f32ec6939..9c61026bb34 1
Hello,
This patch series adds support for:
- Two new C-language-level attributes that allow to associate (to "annotate" or
to "tag") particular declarations and types with arbitrary strings. As
explained below, this is intended to be used to, for example, characterize
certain pointer types.
include/
* btf.h: Add BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG defines. Update
comments.
(struct btf_decl_tag): New.
* dwarf2.def: Add new DWARF extension DW_TAG_GNU_annotation.
---
include/btf.h | 17 +++--
include/dwarf2.def | 4
2 files cha
This patch adds attribute handlers for two new attributes:
"debug_annotate_decl" and "debug_annotate_type". Both attributes accept
a single string argument, and are used to add arbitrary annotations to
debug information generated for the decls or types to which they apply.
gcc/c-family/
*
BTF generation currently relies on the internal CTF representation to
convert debug info from DWARF dies. This patch adds a new internal
header, "ctf-int.h", which defines CTF kinds to be used internally to
represent BTF tags which must pass through the CTF container. It also
adds a new type for re
This patch updates btfout.cc to be aware of debug annotations, convert
them to BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG records, and output them
appropriately.
gcc/
* btfout.cc (get_btf_kind): Handle TYPE_TAG and DECL_TAG kinds.
(btf_calc_num_vbytes): Likewise.
(btf_asm_typ
The "debug_annotate_decl" and "debug_annotate_type" attributes are
handled by constructing DW_TAG_GNU_annotation DIEs. These DIEs are
children of the declarations or types which they annotate, and convey
the information via a string constant.
gcc/
* dwarf2out.cc (gen_decl_annotation_dies)
This patch makes the DWARF-to-CTF conversion process aware of the new
DW_TAG_GNU annotation DIEs. The DIEs are converted to an internal-only
CTF representation as appropriate and added to the compilation unit CTF
container.
gcc/
* dwarf2ctf.cc (handle_debug_annotations): New function.
This patch adds tests for debug annotations, in BTF and in DWARF.
gcc/testsuite/
* gcc.dg/debug/btf/btf-decltag-func.c: New test.
* gcc.dg/debug/btf/btf-decltag-sou.c: Likewise.
* gcc.dg/debug/btf/btf-decltag-typedef.c: Likewise.
* gcc.dg/debug/btf/btf-typetag-1.c:
gcc/
* doc/extend.texi (Common Function Attributes): Document
debug_annotate_decl attribute.
(Common Variable Attributes): Likewise.
(Common Type Attributes): Likewise. Also document
debug_annotate_type attribute.
---
gcc/doc/extend.texi | 106 +
On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote:
> On 6/6/22 7:55 PM, Michael Meissner wrote:
> > gcc/
> [snip]
> > * config/rs6000/rs6000.opt (-mstore-vector-pair): New option.
> [snip]
> > diff --git a/gcc/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt
> > index 4931d78
On 6/7/22 4:24 PM, Segher Boessenkool wrote:
> On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote:
>> I think I mentioned this offline, but I'd prefer a negative target flag,
>> something like TARGET_NO_STORE_VECTOR_PAIR that defaults to off, meaning we'd
>> generate stxvp by default.
>
From: yulong
We changed builtins format about zicbom and zicboz subextensions and modified
test cases.
diff with the previous version:
1.We modified the FUNCTION_TYPE from RISCV_VOID_FTYPE_SI/DI to
RISCV_VOID_FTYPE_VOID_PTR.
2.We added a new RISCV_ATYPE_VOID_PTR in riscv-builtins.cc and a new
Pushed as abvious patch.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr105854.c: Add target int128 and dfp.
---
gcc/testsuite/gcc.target/i386/pr105854.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr105854.c
b/gcc/testsuite/gcc.targ
On Tue, Jun 07, 2022 at 07:59:34PM -0500, Peter Bergner wrote:
> On 6/7/22 4:24 PM, Segher Boessenkool wrote:
> > On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote:
> >> I think I mentioned this offline, but I'd prefer a negative target flag,
> >> something like TARGET_NO_STORE_VECTOR_P
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate xs[min/max]
> -Original Message-
> From: Hongtao Liu
> Sent: Monday, June 6, 2022 1:25 PM
> To: H.J. Lu
> Cc: Cui, Lili ; Liu, Hongtao ; GCC
> Patches
> Subject: Re: [PATCH] Update {skylake,icelake,alderlake}_cost to add a bit
> preference to vector store.
> >
> > Should we add some tests to verify
This is based on Chung-Lin's patch at
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563393.html
This is about code like:
#pragma omp requires unified_shared_memory
!$omp requires reverse_offload
which before was rejected with a sorry during parsing and is now
handled in libgomp (by
Hi!
As the following testcase shows, BIT_FIELD_REF result doesn't have to have
just integral type, it can also have vector type. And in that case
cxx_eval_bit_field_ref just ICEs on it because it is unprepared for that
case, creates the initial value with build_int_cst (sure, that one could be
ea
On Mon, 2022-06-06 at 18:33 -0400, David Malcolm wrote:
> > On Thu, 2022-05-19 at 16:10 +0800, Yang Yujie wrote:
> > > This patch does not affect any other target architecture than
> > > loongarch,
> > > and has been bootstrapped and regression-tested on loongarch64-
> > > linux-
> > > gnuf64
> > >
90 matches
Mail list logo
