I noted that all memory spaces are supported, some by falling
back to the default ("malloc") - except for omp_high_bw_mem_space
(unless the memkind lib is available).
I think it makes more sense to fallback to 'malloc' also for
omp_high_bw_mem_space.
Additionally, I updated the documentation to
On Mon, Jul 10, 2023 at 03:10:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jul 10, 2023 at 03:59:44PM -0400, Michael Meissner wrote:
> > In doing other work, I noticed that there was an insn:
> >
> > vsx_extract_v4sf__load
> >
> > Which did not have an iterator. I removed the
Peter:
On Mon, 2023-07-10 at 16:57 -0500, Peter Bergner wrote:
> On 7/10/23 2:18 PM, Carl Love wrote:
> > + /* Get the current FPSCR fields, bits 29:31 (DRN) and bits 56:63
> > (VE, OE, UE,
> > + ZE, XE, NI, RN) from the FPSCR and return them. */
>
> The 'Z' above should line up directly
on 2023/7/11 07:11, Peter Bergner wrote:
> On 6/29/23 4:31 AM, Kewen.Lin via Gcc-patches wrote:
>> This is okay for trunk (no backports needed btw), this fix can even be
>> taken as obvious, thanks!
>>
>>>
>>> 2023-06-07 Jeevitha Palanisamy
>>>
>>> gcc/
>>> PR target/106907
>>
>> One
Attached is an updated version of the patch.
Based on Philipp's review, some changes:
1. Defined new enum fma_state to describe the state of FMA candidates
for a list of operands. (Since the tests seems simple after the
change, I didn't add predicates on it.)
2. Changed return type of
From: Christoph Müllner
Recently, two identical XTheadCondMov tests have been added, which both fail.
Let's fix that by changing the following:
* Merge both files into one (no need for separate tests for rv32 and rv64)
* Drop unrelated attribute check test (we already test for `th.mveqz`
and
Hi Carl,
Excepting for Peter's review comments, some nits are inline below.
on 2023/7/11 03:18, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 3, Renamed the patch per comments on ver 2. Previous subject line
> was " [PATCH ver 2] rs6000, __builtin_set_fpscr_rn add retrun value".
> Fixed
Please ignore this patch, I'm testing another patch to separate non
swap operands case where a setcc is not needed in the peephole2.
On Tue, Jul 11, 2023 at 11:14 AM liuhongt via Gcc-patches
wrote:
>
> Similar like we did for cmpxchg, but extended to all
> ix86_comparison_int_operator since
Hi Juzhe,
> Hi, Kewen.
>
> You mean COND_LEN_* family I added is unlikely used by power in the future?
Since AFAIK there is no plan to extend len family on Power, it's very likely
that
Power will have no chance to leverage them, so yes.
> Could you revise them to make it possible used by
On 6/29/23 4:31 AM, Kewen.Lin via Gcc-patches wrote:
> This is okay for trunk (no backports needed btw), this fix can even be
> taken as obvious, thanks!
>
>>
>> 2023-06-07 Jeevitha Palanisamy
>>
>> gcc/
>> PR target/106907
>
> One curious question is that this PR106907 seemed not to
Here's updated patch.
1. use optimize_insn_for_speed_p instead of using optimize_function_for_speed_p.
2. explicitly move memory to dest register to avoid false dependence in
one_cmpl pattern.
False dependency happens when destination is only updated by
pternlog. There is no false dependency
On 7/10/23 11:47 AM, Peter Bergner wrote:
> While helping someone on the team debug an issue, I noticed some redundant
> tests in a couple of our predicates which can be removed. I'm going to
> commit the following as obvious once bootstrap and regtesting come back
> clean.
>
> Peter
>
>
>
Hi all,
Currently on trunk, both usage of intrin and builtin for 128 bit VAES
ISA will result in ICE since we did not check AVX512VL until pattern,
which is not user expected. This patch aims to fix that ICE and throw
an error under this scenario.
Regtested on x86-64-linux-gnu{-m32,}. Ok for
On Tue, Jul 11, 2023 at 11:40 AM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> Currently on trunk, both usage of intrin and builtin for 128 bit VAES
> ISA will result in ICE since we did not check AVX512VL until pattern,
> which is not user expected. This patch aims to fix that ICE and
Hi Carl,
on 2023/7/8 04:40, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 5. Removed -compile from the names of the compile only tests. Fixed
> up the reference to the compile file names in the .h file headers.
> Replaced powerpc_vsx_ok with vsx_hw in the run test files. Removed the
>
Hi, Kewen.
You mean COND_LEN_* family I added is unlikely used by power in the future?
Could you revise them to make it possible used by power in the future so that
we won't duplicate to many patterns.
For example, COND_LEN_* has mask operand, is it possible that power can also
use it with
on 2023/7/10 18:40, Richard Biener wrote:
> On Fri, 7 Jul 2023, juzhe.zh...@rivai.ai wrote:
>
>> From: Ju-Zhe Zhong
>>
>> Hi, Richard and Richi.
>>
>> This patch is adding cond_len_* operations pattern for target support
>> loop control with length.
>
> It looks mostly OK - the probably
On 7/10/23 2:18 PM, Carl Love wrote:
> + /* Get the current FPSCR fields, bits 29:31 (DRN) and bits 56:63 (VE, OE,
> UE,
> + ZE, XE, NI, RN) from the FPSCR and return them. */
The 'Z' above should line up directly under the 'G' in Get.
> - /* Insert new RN mode into FSCPR. */
> -
on 2023/7/11 03:18, Carl Love wrote:
> On Fri, 2023-07-07 at 12:06 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> Some more minor comments are inline below on top of Peter's
>> insightful
>> review comments.
>>
>> on 2023/7/1 08:58, Carl Love wrote:
>>> GCC maintainers:
>>>
>>> Ver 2, Went back thru
Bootstraped and Regression on X86 last night with no surprise fails.
This patch has already included 'BIAS' argument.
Ok for trunk ?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-07-10 19:35
To: gcc-patches
CC: richard.sandiford; rguenther; Ju-Zhe Zhong
Subject: [PATCH V2] VECT: Add
Similar like we did for cmpxchg, but extended to all
ix86_comparison_int_operator since cmpccxadd set EFLAGS exactly same
as CMP.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,},
Ok for trunk?
gcc/ChangeLog:
PR target/110591
* config/i386/sync.md (cmpccxadd_): Add a new
On Tue, Jul 11, 2023 at 12:24 AM Alexander Monakov via Gcc-patches
wrote:
>
>
> On Mon, 10 Jul 2023, liuhongt via Gcc-patches wrote:
>
> > False dependency happens when destination is only updated by
> > pternlog. There is no false dependency when destination is also used
> > in source. So either
On Mon, 10 Jul 2023, Jan Hubicka wrote:
> Hi,
> over weekend I found that vectorizer is missing scale_loop_profile for
> epilogues. It already adjusts loop_info to set max iteraitons, so
> adding it was easy. However now predicts the first loop to iterate at
> most once (which is too much, I
Hi,
over weekend I found that vectorizer is missing scale_loop_profile for
epilogues. It already adjusts loop_info to set max iteraitons, so
adding it was easy. However now predicts the first loop to iterate at
most once (which is too much, I suppose it forgets to divide by epilogue
unrolling
On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
wrote:
>
> On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> wrote:
> >
> > As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
> >
> > (gdb) list
> > 469 if (code == SUBREG)
> > 470 {
> > 471
On Fri, 7 Jul 2023, Xi Ruoyao wrote:
> If a bit-field is signed and it's wider than the output type, we must
> ensure the extracted result sign-extended. But this was not handled
> correctly.
>
> For example:
>
> int x : 8;
> long y : 55;
> bool z : 1;
>
> The vectorized
On Fri, 7 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richard and Richi.
>
> This patch is adding cond_len_* operations pattern for target support
> loop control with length.
It looks mostly OK - the probably obvious question is with rearding
to the "missing" bias
On Mon, 2023-07-10 at 10:33 +, Richard Biener wrote:
> On Fri, 7 Jul 2023, Xi Ruoyao wrote:
>
> > If a bit-field is signed and it's wider than the output type, we
> > must
> > ensure the extracted result sign-extended. But this was not handled
> > correctly.
> >
> > For example:
> >
> >
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch is adding cond_len_* operations pattern for target support loop
control with length.
These patterns will be used in these following case:
1. Integer division:
void
f (int32_t *restrict a, int32_t *restrict b, int32_t *restrict c, int
On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
wrote:
>
> As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
>
> (gdb) list
> 469 if (code == SUBREG)
> 470 {
> 471 op0 = simplify_replace_fn_rtx (SUBREG_REG (x),
> old_rtx, fn,
On Mon, 10 Jul 2023, Jan Hubicka wrote:
> > On Fri, 7 Jul 2023, Jan Hubicka wrote:
> >
> > > >
> > > > Looks good, but I wonder what we can do to at least make the
> > > > multiple exit case behave reasonably? The vectorizer keeps track
> > >
> > > > of a "canonical" exit, would it be
On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
>
> On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> wrote:
> >
> > On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> > wrote:
> > >
> > > As shown in the PR, simplify_gen_subreg call in simplify_replace_fn_rtx:
> > >
> > > (gdb)
Thanks Richi.
I added "BIAS" for you:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623978.html
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-10 18:40
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford; linkw; krebbel
Subject: Re: [PATCH] VECT: Add COND_LEN_*
> On Fri, 7 Jul 2023, Jan Hubicka wrote:
>
> > >
> > > Looks good, but I wonder what we can do to at least make the
> > > multiple exit case behave reasonably? The vectorizer keeps track
> >
> > > of a "canonical" exit, would it be possible to pass in the main
> > > exit edge and use that
On Fri, Jul 7, 2023 at 5:14 PM H.J. Lu via Gcc-patches
wrote:
>
> Don't assume that stack slots can only be accessed by stack or frame
> registers. We first find all registers defined by stack or frame
> registers. Then check memory accesses by such registers, including
> stack and frame
On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
wrote:
>
> On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
> >
> > On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> > wrote:
> > >
> > > On Sun, Jul 9, 2023 at 10:53 AM Uros Bizjak via Gcc-patches
> > > wrote:
> > > >
> > > > As shown in the
From: Ju-Zhe Zhong
Since VSETVL PASS in RISC-V port is using common part of
'insert_insn_end_basic_block (struct gcse_expr *expr, basic_block bb)'
and we will also this helper function in riscv.cc for the following patches.
So extract the common part codes of 'insert_insn_end_basic_block
Thanks Richi.
I have sent V2 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623964.html
which is fixing the comments for you:
-/* Add EXPR to the end of basic block BB.
-
- This is used by both the PRE and code hoisting. */
+/* Return the INSN which is added at the end of the
On Sun, Jul 9, 2023 at 10:35 PM Roger Sayle wrote:
>
>
> Following Uros' suggestion, this patch adds support for AVX512VL's
> vpro[lr][dq] instructions to the recently added scalar-to-vector (STV)
> enhancements to handle DImode and SImode rotations by a constant.
>
> For the test cases:
>
>
On Sun, Jul 9, 2023 at 11:30 PM Roger Sayle wrote:
>
>
> This patch implements another of Uros' suggestions, to investigate a
> insvti_lowpart_1 pattern to improve TImode parameter passing on x86_64.
> In PR 88873, the RTL the middle-end expands for passing V2DF in TImode
> is subtly different
On Fri, 7 Jul 2023, Jan Hubicka wrote:
> >
> > Looks good, but I wonder what we can do to at least make the
> > multiple exit case behave reasonably? The vectorizer keeps track
>
> > of a "canonical" exit, would it be possible to pass in the main
> > exit edge and use that instead of
From: Ju-Zhe Zhong
Since 'add_lable_notes' is a generic helper function which is used by
riscv-vsetvl.cc
in RISC-V port backend. And it's also will be used by riscv.cc too by the
following patches.
Export it as global helper function.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc
On Mon, 10 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Since 'add_lable_notes' is a generic helper function which is used by
> riscv-vsetvl.cc
> in RISC-V port backend. And it's also will be used by riscv.cc too by the
> following patches.
> Export it as global helper
On Fri, Jul 7, 2023 at 7:57 PM Andrew Pinski via Gcc-patches
wrote:
>
> When I moved two_value to match.pd, I removed the check for the {0,+-1}
> as I had placed it after the {0,+-1} case for cond in match.pd.
> In the case of {0,+-1} and non boolean, before we would optmize those
> case to just
Hi, Richard.
I find out I just only need to export 'insert_insn_end_basic_block' for global
used by RISC-V port (current riscv-vsetvl.cc and future riscv.cc).
Does it look more reasonable ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-10 15:25
To: Ju-Zhe Zhong
CC:
Sorry, I forget to add the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623960.html
juzhe.zh...@rivai.ai
From: juzhe.zh...@rivai.ai
Date: 2023-07-10 15:58
To: rguenther
CC: gcc-patches; jeffreyalaw
Subject: Re: Re: [PATCH] GCSE: Export add_label_notes as global function
Hi,
On Mon, 10 Jul 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richard.
>
> I find out I just only need to export 'insert_insn_end_basic_block' for
> global used by RISC-V port (current riscv-vsetvl.cc and future riscv.cc).
>
> Does it look more reasonable ?
Yes, it looks more reasonable - I'll leave
From: Ju-Zhe Zhong
Since VSETVL PASS in RISC-V port is using common part of
'insert_insn_end_basic_block (struct gcse_expr *expr, basic_block bb)'
and we will also this helper function in riscv.cc for the following patches.
So extract the common part codes of 'insert_insn_end_basic_block
On Mon, Jul 10, 2023 at 1:01 PM Uros Bizjak wrote:
>
> On Mon, Jul 10, 2023 at 11:47 AM Richard Biener
> wrote:
> >
> > On Mon, Jul 10, 2023 at 11:26 AM Uros Bizjak wrote:
> > >
> > > On Mon, Jul 10, 2023 at 11:17 AM Richard Biener
> > > wrote:
> > > >
> > > > On Sun, Jul 9, 2023 at 10:53 AM
From: Tom Tromey
A future patch will change sname.h-tmpl to use enums rather than
preprocessor defines. In order to do this, first introduce some
typedefs that can be used in gcc-interface.
gcc/ada/
* snames.h-tmpl (Name_Id, Attribute_Id, Convention_Id)
(Pragma_Id): New
From: Alexandre Oliva
Adjust documentation to reflect the introduction of
-fhardcfr-check-noreturn-calls=no-xthrow.
gcc/ada/
* doc/gnat_rm/security_hardening_features.rst (Control Flow
Redundancy): Add -fhardcfr-check-noreturn-calls=no-xthrow.
* gnat_rm.texi:
On Wed, 28 Jun 2023 at 08:56, Jan Hubicka wrote:
>
> > I think the __throw_bad_alloc() and __throw_bad_array_new_length()
> > functions should always be rare, so marking them cold seems fine (users who
> > define their own allocators that want to throw bad_alloc "often" will
> > probably throw it
> -Original Message-
> From: Christophe Lyon
> Sent: Monday, July 10, 2023 2:09 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw
> Cc: Christophe Lyon
> Subject: [PATCH v2] arm: Fix MVE intrinsics support with LTO (PR
> target/110268)
>
> After the recent MVE
On 7/10/23 02:12, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
Since VSETVL PASS in RISC-V port is using common part of
'insert_insn_end_basic_block (struct gcse_expr *expr, basic_block bb)'
and we will also this helper function in riscv.cc for the following patches.
So extract the
On 7/10/23 08:19, Kito Cheng wrote:
Document `z` and `i` operand modifiers, we have much more modifiers
other than those two, but they are the only two implement on both
GCC and LLVM, consider the compatibility I would like to document those
two first, and then review other modifiers later to
From: Alexandre Oliva
Document -fhardcfr-skip-leaf.
gcc/ada/
* doc/gnat_rm/security_hardening_features.rst (Control Flow
Hardening): Document -fhardcfr-skip-leaf.
* gnat_rm.texi: Regenerate.
Tested on x86_64-pc-linux-gnu, committed on master.
---
On Mon, 10 Jul 2023 at 15:46, Kyrylo Tkachov wrote:
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Friday, July 7, 2023 8:52 AM
> > To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> > Richard Earnshaw
> > Cc: Christophe Lyon
> > Subject: [PATCH] testsuite: Add _link
> -Original Message-
> From: Christophe Lyon
> Sent: Monday, July 10, 2023 2:59 PM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
>
> Subject: Re: [PATCH] testsuite: Add _link flavor for several arm_arch* and
> arm* effective-targets
>
>
>
> On Mon, 10 Jul
From: Alexandre Oliva
Document leafy mode.
gcc/ada/
* doc/gnat_rm/security_hardening_features.rst (Register
Scrubbing): Document leafy mode.
* gnat_rm.texi: Regenerate.
Tested on x86_64-pc-linux-gnu, committed on master.
---
From: Bob Duff
This patch documents the new feature that allows declarations mixed with
statements, primarily by referring to the RFC.
gcc/ada/
* doc/gnat_rm/gnat_language_extensions.rst
(Local Declarations Without Block): Document the feature very
briefly, and refer
After the recent MVE intrinsics re-implementation, LTO stopped working
because the intrinsics would no longer be defined.
The main part of the patch is simple and similar to what we do for
AArch64:
- call handle_arm_mve_h() from arm_init_mve_builtins to declare the
intrinsics when the compiler
> -Original Message-
> From: Christophe Lyon
> Sent: Friday, July 7, 2023 8:52 AM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw
> Cc: Christophe Lyon
> Subject: [PATCH] doc: Document arm_v8_1m_main_cde_mve_fp
>
> The arm_v8_1m_main_cde_mve_fp family of effective
From: Yannick Moy
The proof of System.Arith_Double still required the use of
CVC4, now replaced by its successor cvc5. Adapt the proof to be
able to remove CVC4 in the proof of run-time units.
gcc/ada/
* libgnat/s-aridou.adb (Lemma_Div_Mult): New simple lemma.
From: Yannick Moy
CodePeer is correctly warning on a test always true in an assertion.
It can be rewritten without loss of proof to avoid that message.
gcc/ada/
* libgnat/s-aridou.adb (Lemma_Powers_Of_2_Commutation): Rewrite
assertion.
Tested on x86_64-pc-linux-gnu, committed
From: Eric Botcazou
It turns out that adaint.c includes other Windows header files than just
windows.h, so defining WIN32_LEAN_AND_MEAN is not sufficient for it.
gcc/ada/
* adaint.c [_WIN32]: Undefine 'abort' macro.
Tested on x86_64-pc-linux-gnu, committed on master.
---
> -Original Message-
> From: Christophe Lyon
> Sent: Friday, July 7, 2023 8:52 AM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ;
> Richard Earnshaw
> Cc: Christophe Lyon
> Subject: [PATCH] testsuite: Add _link flavor for several arm_arch* and arm*
> effective-targets
>
> For arm
Document `z` and `i` operand modifiers, we have much more modifiers
other than those two, but they are the only two implement on both
GCC and LLVM, consider the compatibility I would like to document those
two first, and then review other modifiers later to see if any other should
expose and
On Mon, 10 Jul 2023, liuhongt via Gcc-patches wrote:
> False dependency happens when destination is only updated by
> pternlog. There is no false dependency when destination is also used
> in source. So either a pxor should be inserted, or input operand
> should be set with constraint '0'.
>
>
> > - *type_out = STMT_VINFO_VECTYPE (stmt_info);
> > + if (cond_cst)
> > +{
> > + append_pattern_def_seq (vinfo, stmt_info, pattern_stmt, vectype);
> > + pattern_stmt
> > + = gimple_build_cond (gimple_cond_code (cond_stmt),
> > +gimple_get_lhs
Hi all,
while browsing the pdt meta-bug I came across 102003 and thought to myself:
Well, that one is easy. How foolish of me...
Anyway, the solution attached prevents a pdt_len (or pdt_kind) expression in a
function call (e.g. len() or kind()) to mark the whole expression as a pdt one.
The
thanks, pushed to trunk :)
On Mon, Jul 10, 2023 at 10:33 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 7/10/23 08:19, Kito Cheng wrote:
> > Document `z` and `i` operand modifiers, we have much more modifiers
> > other than those two, but they are the only two implement on both
> > GCC and LLVM,
Tested on x86_64-pc-linux-gnu, pushed to trunk as obvious.
-- >8 --
Now that we cache level-lowered ttps we can end up processing the same
ttp multiple times via (multiple calls to) redeclare_class_template, so
we can't assume a ttp's DECL_CONTEXT is initially empty.
PR c++/110523
Committed, thanks Jeff and Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Jeff Law via Gcc-patches
Sent: Monday, July 10, 2023 10:08 PM
To: juzhe.zh...@rivai.ai; gcc-patches@gcc.gnu.org
Cc: rguent...@suse.de
Subject: Re: [PATCH v2] GCSE: Export
Hello,
the ELF psABI for x86-64 doesn't have any callee-saved SSE
registers (there were actual reasons for that, but those don't
matter anymore). This starts to hurt some uses, as it means that
as soon as you have a call (say to memmove/memcpy, even if
implicit as libcall) in a loop that
Hi Thomas,
this patch contains support for the 'readonly' modifier in copyin clauses
and the cache directive.
As we discussed earlier, the work for actually linking this to middle-end
points-to analysis is a somewhat non-trivial issue. This first patch allows
the language feature to be used in
Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path
in find_fde_tail").
libgcc/
PR libgcc/110179
* unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid
implicit conversion of pointer value to integer.
---
libgcc/unwind-dw2-fde-dip.c | 2 +-
1 file
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type pdt(n)
integer, len :: n = 8
character(len=n) :: c
end type pdt
type(pdt(42)) :: p
integer, parameter ::
On Mon, 10 Jul 2023, Michael Matz via Gcc-patches wrote:
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you have a call
Hi,
This is the change for the GCC14 releaes Notes on the deprecating of a C
extension about flexible array members.
Okay for committing?
thanks.
Qing
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
extension about flexible array members.
---
On Thu, 2023-07-06 at 17:54 -0500, Peter Bergner wrote:
> On 6/30/23 7:58 PM, Carl Love via Gcc-patches wrote:
> > rs6000, __builtin_set_fpscr_rn add retrun value
>
> s/retrun/return/
>
> Maybe better written as:
>
> rs6000: Add return value to __builtin_set_fpscr_rn
Changed subject, fixed
GCC maintainers:
Ver 3, Renamed the patch per comments on ver 2. Previous subject line
was " [PATCH ver 2] rs6000, __builtin_set_fpscr_rn add retrun value".
Fixed spelling mistakes and formatting. Updated define_expand
"rs6000_set_fpscr_rn to have the rs6000_get_fpscr_fields and
On Fri, 2023-07-07 at 12:06 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> Some more minor comments are inline below on top of Peter's
> insightful
> review comments.
>
> on 2023/7/1 08:58, Carl Love wrote:
> > GCC maintainers:
> >
> > Ver 2, Went back thru the requirements and emails. Not sure where
While helping someone on the team debug an issue, I noticed some redundant
tests in a couple of our predicates which can be removed. I'm going to
commit the following as obvious once bootstrap and regtesting come back
clean.
Peter
rs6000: Remove redundant MEM_P predicate usage
The
> Am 10.07.2023 um 17:56 schrieb Michael Matz via Gcc-patches
> :
>
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you
On Mon, Jul 10, 2023 at 08:54:54PM +0200, Florian Weimer via Gcc-patches wrote:
> Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path
> in find_fde_tail").
>
> libgcc/
>
> PR libgcc/110179
> * unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid
> implicit
Hi Harald,
I do get why this happens. I still don't get why I have to do this
'optimization' manually. I mean, this rewriting of expressions is needed in
more than one location and most probably already present somewhere. So who
can point me in the right direction?
Regards,
Andre
Andre
On Sat, 1 Jul 2023, Nathaniel Shead wrote:
> This is an update of the patch series at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614811.html
>
> Changes since v2:
>
> - Use a separate 'hash_set' to track expired variables instead of
> adding a flag to 'lang_decl_base'.
> - Use
This patch optimizes cases like:
vector double v1, v2;
/* ... */
v2 = vec_splats (vec_extract (v1, 0); /* or */
v2 = vec_splats (vec_extract (v1, 1);
Previously:
vector long long
splat_dup_l_0 (vector long long v)
{
return
If we are converting an unsigned DImode to a TImode value, and the TImode value
will go in a vector register, GCC currently does the DImode to TImode conversion
in GPR registers, and then moves the value to the vector register via a mtvsrdd
instruction.
This patch adds a new zero_extendditi2 insn
Also change some internal variables and function arguments from int to bool.
gcc/ChangeLog:
* reorg.cc (stop_search_p): Change return type from int to bool
and adjust function body accordingly.
(resource_conflicts_p): Ditto.
(insn_references_resource_p): Change return type from
In doing other work, I noticed that there was an insn:
vsx_extract_v4sf__load
Which did not have an iterator. I removed the useless .
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE,
I forgot to add:
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE, --with-cpu=power10, IBM 128-bit long double
* Power9, LE, --with-cpu=power9, IBM 128-bit long double
* Power9, LE,
I forgot to add:
I have tested this patch on the following systems and there was no degration.
Can I check it into the trunk branch?
* Power10, LE, --with-cpu=power10, IBM 128-bit long double
* Power9, LE, --with-cpu=power9, IBM 128-bit long double
* Power9, LE,
Hi!
On Mon, Jul 10, 2023 at 03:59:44PM -0400, Michael Meissner wrote:
> In doing other work, I noticed that there was an insn:
>
> vsx_extract_v4sf__load
>
> Which did not have an iterator. I removed the useless .
This patch does that, you mean.
> --- a/gcc/config/rs6000/vsx.md
> +++
Running
$ make check-g++
RUNTESTFLAGS='--target_board=unix\{-D_GLIBCXX_USE_CXX11_ABI=0,\}
dg.exp=allocator-opt1.C'
yields:
FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++98 scan-tree-dump-times gimple
"struct allocator D" 1
FAIL: g++.dg/tree-ssa/allocator-opt1.C -std=c++14
On Mon, 10 Jul 2023, Alexander Monakov wrote:
> > I chose to make it possible to write function definitions with that
> > attribute with GCC adding the necessary callee save/restore code in
> > the xlogue itself.
>
> But you can't trivially restore if the callee is sibcalling — what
> happens
96 matches
Mail list logo
