On Tue, Jun 18, 2024 at 2:11 AM David Malcolm wrote:
>
> Be explicit when we use "cfun".
>
> No functional change intended.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> OK for trunk?
>
> gcc/ChangeLog:
> * dominance.cc (compute_dom_fast_query): Replace uses of
>
> Hi,
>
> > -Original Message-
> > From: Pengxuan Zheng
> > Sent: Friday, June 14, 2024 12:57 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Pengxuan Zheng
> > Subject: [PATCH v3] aarch64: Add vector popcount besides QImode
> > [PR113859]
> >
> > This patch improves GCC’s vectorization of __
This patch improves GCC’s vectorization of __builtin_popcount for aarch64 target
by adding popcount patterns for vector modes besides QImode, i.e., HImode,
SImode and DImode.
With this patch, we now generate the following for V8HI:
cnt v1.16b, v0.16b
uaddlp v2.8h, v1.16b
For V4HI, we gen
Tested on x86_64-linux-gnu (also -m32 and -mx32), aarch64-linux-gnu, and arm-
linux-gnueabi(hf).
OK for trunk and backports? OK, to go for GCC 11.5 as early as possible?
--- 8< ---
With the change to the AVX512 find_last_set implementation, the change
to A
On Mon, 17 Jun 2024, Richard Sandiford wrote:
> Richard Biener writes:
> > On Fri, 14 Jun 2024, Richard Biener wrote:
> >
> >> On Fri, 14 Jun 2024, Richard Sandiford wrote:
> >>
> >> > Richard Biener writes:
> >> > > On Fri, 14 Jun 2024, Richard Sandiford wrote:
> >> > >
> >> > >> Richard Biene
On Tue, 18 Jun 2024, Pengxuan Zheng (QUIC) wrote:
> > Pengxuan Zheng writes:
> > > This patch adds the fix_truncv4sfv4hi2 (V4SF->V4HI) pattern which is
> > > implemented using fix_truncv4sfv4si2 (V4SF->V4SI) and then truncv4siv4hi2
> > (V4SI->V4HI).
> > >
> > > PR target/113882
> > >
> > > gcc/
So more work in the ongoing effort to make better use of the Zbs
extension. This time we're trying to exploit knowledge of the shift
count/bit position to allow us to use a bset instruction.
Consider this expression in SImode
(1 << (pos & 0xf)
None of the resulting values will have bit 3
When 'a' is put into riscv_combine_info, 'a' will only be added into
arch string only if zaamo *AND* zalrsc is there, so zalrsc only won't
trigger that.
On Tue, Jun 18, 2024 at 1:35 PM Patrick O'Neill wrote:
>
>
>
> On Mon, Jun 17, 2024 at 5:51 PM Kito Cheng wrote:
>>
>> Maybe just add 'a' to ri
On Mon, Jun 17, 2024 at 5:51 PM Kito Cheng wrote:
> Maybe just add 'a' to riscv_combine_info and other logic to keep the
> same (e.g. keep the logic for skip_zaamo_zalrsc)?
I did consider unconditionally upgrading zaamo/zalrsc to ‘a’ (I think
that’s what you’re suggesting w/ riscv_combine_info)
Since r7-6575-g71aba51d6460ff, thunderxt88 has been the same as thunderxt88p1
so let's make
them a true alias and remove the odd variant handling and moves it below
thunderxt88.
Bootstrapped and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
* config/aarch64/aarch64-co
Since these were already aliases just make it clear on that.
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def: Add comment
saying thunderxt81/t83 are aliases of octeontx81/83.
Signed-off-by: Andrew Pinski
---
gcc/config/aarch64/aarch64-cores.def | 1 +
1 file changed, 1 insert
While thinking the variant patch I had posted, I went back to
look at the original cores which used the variant and saw there
was small cleanup for them since thunderx was no longer considered
a V8.1-a core but rather just a V8-a one; when I did that change
I didn't do the cleanups like is done in
On 6/17/24 7:57 PM, Segher Boessenkool wrote:
> On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
>> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
>> Yeah, I didn't write that, I only moved it, but I can try to come up with
>> an explanation of why we need to disable it now. That said
Hi,
on 2024/6/18 00:08, Peter Bergner wrote:
> On 6/14/24 1:37 PM, Carl Love wrote:
>> Per the additional feedback after patch:
>>
>> commit c892525813c94b018464d5a4edc17f79186606b7
>> Author: Carl Love
>> Date: Tue Jun 11 14:01:16 2024 -0400
>>
>> rs6000, altivec-2-runnable.c shou
Hi Haochen,
on 2024/6/17 16:59, HAO CHEN GUI wrote:
> Hi,
> This patch creates an insn_and_split pattern which helps the duplicated
> constant vector replace the source pseudo of store insn in fwprop pass.
> Thus the store can be implemented by a single stxvd2x and it eliminates the
> unnecessar
on 2024/6/17 20:57, Peter Bergner wrote:
> On 6/16/24 9:40 PM, Kewen.Lin wrote:
>> on 2024/6/17 10:31, Peter Bergner wrote:
>>> On 6/16/24 9:10 PM, Kewen.Lin wrote:
on 2024/6/15 01:05, Peter Bergner wrote:
> That said, the --with-cpu=power5 build without fortran did bootstrap and
> reg
This is OK for trunk?
Thanks,
Di Zhao
> -Original Message-
> From: Di Zhao OS
> Sent: Thursday, May 23, 2024 5:55 PM
> To: Jeff Law
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] [tree-optimization/110279] fix testcase pr110279-1.c
>
> > -Original Message-
> > From: Jeff
I think that's fine.
Thanks!
在 2024/6/16 下午5:11, Xi Ruoyao 写道:
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_print_operand_reloc):
Dedup and sort the comment describing modifiers.
---
It's a non-functional change thus I've not tested it. Ok for trunk?
gcc/confi
Hi!
On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> >> - /* If we are inserting ROP-protect instructions, disable shrink wrap.
> >> */
> >> - if (rs6000_rop_protect)
> >> -flag_shrink_wrap = 0;
> >> }
> >
> > (Yes, I know t
Maybe just add 'a' to riscv_combine_info and other logic to keep the
same (e.g. keep the logic for skip_zaamo_zalrsc)?
On Tue, Jun 18, 2024 at 8:03 AM Patrick O'Neill wrote:
>
> Binutils 2.42 and before don't support Zaamo/Zalrsc. Promote Zaamo/Zalrsc to
> 'a' in the -march string when assembling
While auditing our ROP code generation for some test cases I wrote, I noticed
a few issues which I'm tracking in PR114759. The first issue I noticed is we
disable shrink-wrapping when using -mrop-protect, even in the cases where we
never emit the ROP instructions because they're not needed. The p
Hi,
This patch replaces rtx_cost with insn_cost in forward propagation.
In the PR, one constant vector should be propagated and replace a
pseudo in a store insn if we know it's a duplicated constant vector.
It reduces the insn cost but not rtx cost. In this case, the cost is
determined by destina
Translates DW_TAG_subroutine_type DIEs into LF_PROCEDURE symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_procedure and lf_arglist
to union.
(write_lf_procedure, write_lf_arglist): New functions.
(write_cust
Translates DW_TAG_array_type DIEs into LF_ARRAY symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_array to union.
(write_lf_array): New function.
(write_custom_types): Call write_lf_array.
(get_type_num_array_typ
Translates DW_TAG_union_type DIEs into LF_UNION symbols.
gcc/
* dwarf2codeview.cc (write_lf_union): New function.
(write_custom_types): Call write_lf_union.
(add_struct_forward_def): Handle DW_TAG_union_type DIEs.
(get_type_num_struct): Handle un
Translates DW_TAG_enumeration_type DIEs into LF_ENUM symbols.
gcc/
* dwarf2codeview.cc (MAX_FIELDLIST_SIZE): Define.
(struct codeview_integer): New structure.
(struct codeview_subtype): Likewise
(struct codeview_custom_type): Add lf_fieldlist and
On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> "ROP insns" are the instructions used in such exploits, not what you
> mean here :-)
>
> The instructions are called "hash*"C, so maybe call tbem "hash insns"
> or "ROP protect hash insns"?.
Ok, that bad verbiage was in the extra commentary not part
Adds a get_type_num function to translate type DIEs into CodeView
numbers, along with a hash table for this. For now we just deal with
the base types (integers, Unicode chars, floats, and bools).
gcc/
* dwarf2codeview.cc (struct codeview_type): New structure.
(struct d
On 6/14/24 20:03, Jakub Jelinek wrote:
Also wonder about the
// { dg-additional-options "-march=z14" { target s390*-*-* } }
line, doesn't that mean the test will FAIL on all pre-z14 HW?
Shouldn't it use some z14_runtime or similar effective target, or
check in main (in that case copied over to g+
gcc/
* dwarf2codeview.cc (get_type_num): Handle typedefs.
---
gcc/dwarf2codeview.cc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/dwarf2codeview.cc b/gcc/dwarf2codeview.cc
index eb7c1270e31..5006a176260 100644
--- a/gcc/dwarf2codeview.cc
+++ b/gcc/dwarf2codeview.cc
Translates structure members with DW_AT_data_bit_offset set in DWARF
into LF_BITFIELD symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_bitfield to union.
(write_lf_bitfield): New function.
(write_custom_types): Call write_l
Translate DW_TAG_const_type and DW_TAG_volatile_type DIEs into
LF_MODIFIER symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_modifier to union.
(write_cv_padding, write_lf_modifier): New functions.
(write_custom_types): Call
Translates DW_TAG_structure_type DIEs into LF_STRUCTURE symbols, and
DW_TAG_class_type DIEs into LF_CLASS symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_type): Add is_fwd_ref member.
(struct codeview_subtype): Add lf_member to union.
(struct
Parse the DW_TAG_variable DIEs, and outputs S_GDATA32 (for global variables)
and S_LDATA32 (static global variables) symbols into the .debug$S section.
gcc/
* dwarf2codeview.cc (S_LDATA32, S_GDATA32): Define.
(struct codeview_symbol): New structure.
(sym, la
Translates DW_TAG_pointer_type DIEs into LF_POINTER symbols, which get
output into the .debug$T section.
gcc/
* dwarf2codeview.cc (FIRST_TYPE): Define.
(struct codeview_custom_type): New structure.
(custom_types, last_custom_type): New variables.
This patch series adds support for outputting global variables when the
-gcodeview option is provided, along with the type system to go along
with this.
As with previous patches, the best way to see the output is run
Microsoft's cvdump.exe against the object file:
https://github.com/microsoft/micr
Be explicit when we use "cfun".
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/ChangeLog:
* dominance.cc (compute_dom_fast_query): Replace uses of
"dom_computed" macro with explicit use of cfun.
(compute_do
> Pengxuan Zheng writes:
> > This patch adds the fix_truncv4sfv4hi2 (V4SF->V4HI) pattern which is
> > implemented using fix_truncv4sfv4si2 (V4SF->V4SI) and then truncv4siv4hi2
> (V4SI->V4HI).
> >
> > PR target/113882
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64-simd.md (fix_trun
Binutils 2.42 and before don't support Zaamo/Zalrsc. Promote Zaamo/Zalrsc to
'a' in the -march string when assembling.
This change respects Zaamo/Zalrsc when generating code.
Testcases that check for the default isa string will fail with the old binutils
since zaamo/zalrsc aren't emitted anymore.
This aarch64 sve specific code was fixed by r15-917-gc9842f99042454
which added a riscv specific testcase so adding an aarch64 one to test
the fix does not regress is a good idea.
Committed as obvious after testing the testcase for aarch64-linux-gnu.
PR tree-optimization/97405
gcc/testsu
On 6/17/24 12:33 PM, Edwin Lu wrote:
When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this sc
On 6/17/24 12:33 PM, Edwin Lu wrote:
On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded insn
operand's mode (Pmode == SI). Ensure that mode of
On 6/16/24 9:40 PM, Kewen.Lin wrote:
> on 2024/6/17 10:31, Peter Bergner wrote:
>> On 6/16/24 9:10 PM, Kewen.Lin wrote:
>>> on 2024/6/15 01:05, Peter Bergner wrote:
That said, the --with-cpu=power5 build without fortran did bootstrap and
regtest with no regressions, so the build did test
Hi!
On Mon, Jun 17, 2024 at 05:26:39PM -0500, Peter Bergner wrote:
> While auditing our ROP code generation for some test cases I wrote, I noticed
> a few issues which I'm tracking in PR114759. The first issue I noticed is we
> disable shrink-wrapping when using -mrop-protect, even in the cases w
Hi!
Thanks for posting this again. Much easier to find that way :-)
On Mon, Jun 17, 2024 at 07:15:48PM +0200, Jakub Jelinek wrote:
> While my r15-1001-g4cf2de9b5268224 PCH PIE power fix change decreased the
> .data section sizes (219792 -> 189336), it increased the size of already
> huge rs6000_
The original link gives a "301 Moved Permanently", easily fixed by
appending a slash.
Pushed.
Gerald
---
htdocs/backends.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/backends.html b/htdocs/backends.html
index 1f7c85d7..d86783a6 100644
--- a/htdocs/backend
On Sat, 15 Jun 2024, Georg-Johann Lay wrote:
> Applied this one:
Cool.
> +SimulAVR at https://www.nongnu.org/simulavr";
This one gives a http response of "301 Moved Permanently" redirecting to
https://www.nongnu.org/simulavr/ . I'll fix this in a minute.
On a related note, though, can we u
This is a new version of the patch. This adds the -fno-short-enums flag
to the tests. I will commit it if the CI for am does not claim this time.
Bootstrapped and regression tested on x86_64.
c23: Fix for redeclared enumerator initialized with different type
[PR115109]
c23 spec
On Mon, Jun 17, 2024 at 2:29 PM Eric Botcazou wrote:
>
> Tested on x86-64/Linux, applied on the mainline.
>
>
> 2024-06-17 Eric Botcazou
>
> c-family/
> * c-ada-spec.cc (is_float16): New predicate.
> (dump_ada_node) : Call it.
Hmm, is_float16 seems to be me would be _Float16 ra
Tested on x86-64/Linux, applied on the mainline.
2024-06-17 Eric Botcazou
c-family/
* c-ada-spec.cc (is_float16): New predicate.
(dump_ada_node) : Call it.
--
Eric Botcazoudiff --git a/gcc/c-family/c-ada-spec.cc b/gcc/c-family/c-ada-spec.cc
index a41e93aeafb..e1b1b2a4b73 100
Hi Suwa-san,
On Mon, Jun 17, 2024 at 04:17:15PM +0900, Takayuki 'January June' Suwa wrote:
> The previous constant synthesis logic had some issues that were non-fatal
> but worth considering:
>
> - It didn't work with DFmode literals, because those were cast to SImode
> rather SFmode when split
Hi Richi,
on 2024/6/14 18:31, Richard Biener wrote:
> The following retires vcond{,u,eq} optabs by stopping to use them
> from the middle-end. Targets instead (should) implement vcond_mask
> and vec_cmp{,u,eq} optabs. The PR this change refers to lists
> possibly affected targets - those impleme
On Mon, 17 Jun 2024, Jakub Jelinek wrote:
> 2024-06-17 Jakub Jelinek
>
> PR driver/115440
> * opts-common.cc (add_misspelling_candidates): If opt1 is non-NULL,
> add a space and opt1 to the alternative suggestion text.
>
> * g++.dg/cpp1z/pr115440.C: New test.
OK.
--
C2Y has adopted support for alignof applied to incomplete array types
(N3273). Add this support to GCC. As the relevant checks are in
c-family code that doesn't have access to functions such as
pedwarn_c23, this remains a hard error for older versions and isn't
handled by -Wc23-c2y-compat, althou
Hi Andre,
Am 17.06.24 um 09:51 schrieb Andre Vehreschild:
Regarding your question on the coarray-tests that are not in the
coarray-directory: These test in most cases test only one method of
implementing coarrays. I.e., they are either testing just -fcoarray=single or
-fcoarray=lib -lcaf_single,
On 17.06.24 20:53, Jonathan Wakely wrote:
On Mon, 17 Jun 2024 at 19:03, Joseph Myers wrote:
On Fri, 14 Jun 2024, Jonathan Wakely wrote:
Both, ideally. The libstdc++ test should definitely be fixed because
it fails with released versions of glibc already in the wild. But
glibc should also be
On Mon, Jun 17, 2024 at 09:09:37PM +0200, Andreas Krebbel wrote:
> On 6/14/24 20:03, Jakub Jelinek wrote:
> > Also wonder about the
> > // { dg-additional-options "-march=z14" { target s390*-*-* } }
> > line, doesn't that mean the test will FAIL on all pre-z14 HW?
> > Shouldn't it use some z14_runt
On 6/16/24 9:10 PM, Kewen.Lin wrote:
> on 2024/6/15 01:05, Peter Bergner wrote:
>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>> regtest with no regressions, so the build did test that code path and
>> exposed no problems.
>
> OK, nice! Thanks!
I assume this means y
On Sat, 15 Jun 2024, Martin Uecker wrote:
> The patch fails on arm because the tests make assumptions
> about enums that are not true everywhere. Should we just
> limit the tests to x86?
For compilation tests, using -fno-short-enums should work. That won't
work for link / execute tests, but in
On Mon, 17 Jun 2024 at 19:03, Joseph Myers wrote:
>
> On Fri, 14 Jun 2024, Jonathan Wakely wrote:
>
> > Both, ideally. The libstdc++ test should definitely be fixed because
> > it fails with released versions of glibc already in the wild. But
> > glibc should also be fixed because it's a standards
When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this scenario, it will always
assume that mode =
On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded insn
operand's mode (Pmode == SI). Ensure that mode of the operands match
Tested on rv32/64 gcv
The following testcases have been failing on rv32 targets since
r15-953-gaf4bf422a69:
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (internal compiler
error: in maybe_legitimize_operand, at optabs.cc:8056)
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (test for excess
errors)
Fix the bu
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
In r13-272 we hardened the *_PACK_EXPANSION and *_ARGUMENT_PACK macros.
That trips up here because make_pack_expansion returns error_mark_node
and we access that with PACK_EXPANSION_LOCAL_P.
PR c++/115425
gcc/cp/Change
Thanks Kewen.
Given that background, the patch is OK.
paul
> On Jun 16, 2024, at 10:01 PM, Kewen.Lin wrote:
>
> Hi Paul,
>
> on 2024/6/14 23:20, Paul Koning wrote:
>> Ok, I understand better now. But if those macros are supposed to be
>> replaced by hook functions, could you make th
On Fri, 14 Jun 2024, Jonathan Wakely wrote:
> Both, ideally. The libstdc++ test should definitely be fixed because
> it fails with released versions of glibc already in the wild. But
> glibc should also be fixed because it's a standards conformance issue.
The __ctx macro used in various sys/ucont
On 6/14/24 1:37 PM, Carl Love wrote:
> Per the additional feedback after patch:
>
> commit c892525813c94b018464d5a4edc17f79186606b7
> Author: Carl Love
> Date: Tue Jun 11 14:01:16 2024 -0400
>
> rs6000, altivec-2-runnable.c should be a runnable test
>
> The test case ha
Hi,
On Thu, Jun 6, 2024 at 7:05 PM Andrew Pinski wrote:
>
> On Thu, Jun 6, 2024 at 9:00 AM David Malcolm wrote:
> >
> > On Thu, 2024-06-06 at 08:40 -0700, Andrew Pinski wrote:
> > > On Thu, Jun 6, 2024 at 6:02 AM Bert Wesarg
> > > wrote:
> > > >
> > > > Dear David,
> > > >
> > > > On Tue, May 2
On Mon, Jun 17, 2024 at 07:09:03PM +0200, Jakub Jelinek wrote:
> Hi!
>
> The warning code uses %D to print the ARRAY_REF first operands.
> That works in the most common case where those operands are decls, but
> as can be seen on the following testcase, they can be other expressions
> with array t
Hi!
While my r15-1001-g4cf2de9b5268224 PCH PIE power fix change decreased the
.data section sizes (219792 -> 189336), it increased the size of already
huge rs6000_init_generated_builtins generated function, from 218328
to 228668 bytes. That is because there are thousands of array references
to gl
On Mon, Jun 17, 2024 at 08:16:34AM +0200, Richard Biener wrote:
> On Mon, 17 Jun 2024, Kewen.Lin wrote:
>
> > Hi Richi,
> >
> > on 2024/6/14 18:31, Richard Biener wrote:
> > > The following retires vcond{,u,eq} optabs by stopping to use them
> > > from the middle-end. Targets instead (should) im
Hi Paul,
on 2024/6/14 23:20, Paul Koning wrote:
> Ok, I understand better now. But if those macros are supposed to be replaced
> by hook functions, could you make that replacement part of the proposed patch?
The default implementation of the introduced hook mode_for_floating_type
returns SFmode
Hi!
The warning code uses %D to print the ARRAY_REF first operands.
That works in the most common case where those operands are decls, but
as can be seen on the following testcase, they can be other expressions
with array type.
Just changing %D to %E isn't enough, because then the diagnostics can
Hi!
On AVR and SH with some options sizeof (float) == sizeof (double) and
the 2 types have the same set of values.
http://eel.is/c++draft/conv.rank#2.2 for this says that double still
has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2
says that extended type with the same set of v
on 2024/6/15 01:05, Peter Bergner wrote:
> On 6/13/24 10:26 PM, Peter Bergner wrote:
>> On 6/13/24 9:26 PM, Kewen.Lin wrote:
> I understand this is just copied from the if arm, but if I read this
> right, it can be
> simplified as:
Ok, I'll retest with that simplification.
>>
On 6/13/24 13:02, Jeff Law wrote:
On 6/12/24 5:20 PM, Patrick O'Neill wrote:
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Zalrsc in the arch string when the
assember does not support it.
gcc/ChangeLog:
* common/config/riscv/riscv-
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Zalrsc in the arch string when the
assember does not support it.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::to_string): Skip zaamo/zalrsc when not
Hi!
The option_map array for most entries contains just non-NULL opt0
{ "-Wno-", NULL, "-W", false, true },
{ "-fno-", NULL, "-f", false, true },
{ "-gno-", NULL, "-g", false, true },
{ "-mno-", NULL, "-m", false, true },
{ "--debug=", NULL, "-g", false, false },
{ "--machi
On Mon, Jun 17, 2024 at 03:26:52PM +0200, Jakub Jelinek wrote:
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html
> patch. While the committed and backported patch fixed PCH on PIE
> cc1/cc1plus etc. on PowerPC, it grew up the size of the
> rs6000_init_generat
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652991.html
Thanks
Gui Haochen
在 2024/6/3 10:37, HAO CHEN GUI 写道:
> Hi,
> All issues were addressed. Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652991.html
>
> Thanks
> Gui Haochen
>
> 在 2024/5/
Hi,
Gently ping the series of patches.
[PATCH-1v3, rs6000] Implement optab_isinf for SFDF and IEEE128
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652593.html
[PATCH-2v3, rs6000] Implement optab_isfinite for SFDF and IEEE128
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652594.htm
on 2024/6/17 10:31, Peter Bergner wrote:
> On 6/16/24 9:10 PM, Kewen.Lin wrote:
>> on 2024/6/15 01:05, Peter Bergner wrote:
>>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>>> regtest with no regressions, so the build did test that code path and
>>> exposed no problems.
on 2024/6/17 14:16, Richard Biener wrote:
> On Mon, 17 Jun 2024, Kewen.Lin wrote:
>
>> Hi Richi,
>>
>> on 2024/6/14 18:31, Richard Biener wrote:
>>> The following retires vcond{,u,eq} optabs by stopping to use them
>>> from the middle-end. Targets instead (should) implement vcond_mask
>>> and vec
From: Pan Li
After the middle-end support the form 8 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 8.
Form 8:
#define DEF_VEC_SAT_U_ADD_FMT_8(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 6 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 6.
Form 6:
#define DEF_VEC_SAT_U_ADD_FMT_6(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 7 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 7.
Form 7:
#define DEF_VEC_SAT_U_ADD_FMT_7(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 5 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 5.
Form 5:
#define DEF_VEC_SAT_U_ADD_FMT_5(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 4 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 4.
Form 4:
#define DEF_VEC_SAT_U_ADD_FMT_4(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 2 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 2.
Form 2:
#define DEF_VEC_SAT_U_ADD_FMT_2(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 3 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 3.
Form 3:
#define DEF_VEC_SAT_U_ADD_FMT_3(T) \
void __attribute__((noinline))
On Mon, Jun 17, 2024, 5:59 AM Tamar Christina
wrote:
> Hi,
>
> > -Original Message-
> > From: Pengxuan Zheng
> > Sent: Friday, June 14, 2024 12:57 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Pengxuan Zheng
> > Subject: [PATCH v3] aarch64: Add vector popcount besides QImode
> [PR113859]
>
Automatic arrays that are not address-taken should not be subject to
store data races. This applies to OMP SIMD in-branch lowered
functions result array which for the testcase otherwise prevents
vectorization with SSE and for AVX and AVX512 ends up with spurious
.MASK_STORE to the stack surviving.
The following fixes a bad final value being used when doing single-lane
SLP integer induction cond reduction vectorization.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/115493
* tree-vect-loop.cc (vect_create_epilog_for_reduction): Use
th
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html
patch. While the committed and backported patch fixed PCH on PIE
cc1/cc1plus etc. on PowerPC, it grew up the size of the
rs6000_init_generated_builtins function quite a lot.
The above patch decreases it back,
Combine will use zero_extract destinations for certain bitfield
insertions. If the bitfield is a single bit constant, then we can use
bset/bclr.
In this case we are only dealing with word_mode objects, so we don't
have to worry about the SI->DI extension issues for TARGET_64BIT.
The testcas
Pushed. (The diff is a bit larger due to line breaks.)
Gerald
gcc:
* doc/install.texi (Configuration): Mark up __cxa_atexit as @code.
---
gcc/doc/install.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 298
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653001.html
Thanks
Gui Haochen
在 2024/6/3 10:37, HAO CHEN GUI 写道:
> Hi,
> All issues were addressed. Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653001.html
>
> Thanks
> Gui Haochen
>
>
> 在 2024
Hi,
> -Original Message-
> From: Pengxuan Zheng
> Sent: Friday, June 14, 2024 12:57 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Pengxuan Zheng
> Subject: [PATCH v3] aarch64: Add vector popcount besides QImode [PR113859]
>
> This patch improves GCC’s vectorization of __builtin_popcount for aa
Hi Siarahei,
On 16/06/2024 09:51, Siarhei Volkau wrote:
> If the address register is dead after load/store operation it looks
> beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions,
> at least if optimizing for size.
>
> E.g.
> ldr r0, [r3, #0]
> ldr r1, [r3, #4] @ r3 is dead
When there's a permute after an extern vector we can run into a case
that didn't consider the scheduled node being a permute which lacks
a representative.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/115508
* tree-vect-slp.cc (vect_schedule_slp
1 - 100 of 123 matches
Mail list logo
