For APX instruction with an NDD, the destination GPR will get the
instruction’s result in bits [OSIZE-1:0] and, if OSIZE < 64b, have its
upper bits [63:OSIZE] zeroed. Now supporting other NDD instructions.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
gcc/ChangeLog:
PR target/113729
* config/i386/i386.md (*subqi_1_zext): New
define_insn.
(*subhi_1_zext): Ditto.
(*addqi3_carry_zext): Ditto.
(*addhi3_carry_zext): Ditto.
(*addqi3_carry_
gcc/ChangeLog:
PR target/113729
* config/i386/i386.md (*andqi_1_zext):
New define_insn.
(*andhi_1_zext): Ditto.
(*qi_1_zext): Ditto.
(*hi_1_zext): Ditto.
(*negqi_1_zext): Ditto.
gcc/ChangeLog:
PR target/113729
* config/i386/i386.md (*ashlqi3_1_zext):
New define_insn.
(*ashlhi3_1_zext): Ditto.
(*qi3_1_zext): Ditto.
(*hi3_1_zext): Ditto.
(*qi3_1_zext): Ditto.
On Thu, Aug 1, 2024 at 3:50 PM Haochen Jiang wrote:
>
> Hi all,
>
> AVX10.2 tech details has been just published on July 31st in the
> following link:
>
> https://cdrdv2.intel.com/v1/dl/getContent/828965
>
> For new features and instructions, we could divide them into two parts.
> One is ymm round
On Thu, Aug 08, 2024 at 06:53:10PM -0700, H.J. Lu wrote:
> When we emit .p2align to align BB_HEAD, we must update BB_HEAD. Otherwise
> ENDBR will be inserted as the wrong place.
>
> gcc/
>
> PR target/116174
> * config/i386/i386.cc (ix86_align_loops): Update BB_HEAD when
> alig
> -Original Message-
> From: Thomas Schwinge
> Sent: Friday, August 9, 2024 12:55 AM
> To: Prathamesh Kulkarni
> Cc: Andrew Pinski ; Richard Biener
> ; gcc-patches@gcc.gnu.org; Jakub Jelinek
>
> Subject: Re: [nvptx] Pass -m32/-m64 to host_compiler if it has
> multilib support
>
> Exte
Add symbolic execution support.
Gives an opportunity to execute the code on bit level,
assigning symbolic values to the variables which don't have initial values.
Supports only CRC specific operations.
Example:
uint8_t crc;
uint8_t pol = 1;
crc = crc ^ pol;
during symbolic execution crc's value
On Thu, Aug 1, 2024, 00:38 Andrew Pinski wrote:
> On Wed, Jul 31, 2024 at 3:42 AM Mariam Arutunian
> wrote:
> >
> > Gives an opportunity to execute the code on bit level,
> >assigning symbolic values to the variables which don't have initial
> values.
> >Supports only CRC specific ope
Hi Jerry,
thanks for the review. Commited as gcc-15-2882-g8d8db21eb72.
Thanks again and regards,
Andre
On Fri, 9 Aug 2024 10:35:26 -0700
Jerry Delisle wrote:
> Ok and thanks.
>
> On Fri, Aug 9, 2024, 7:33 AM Andre Vehreschild wrote:
>
> > Ping!
> >
> > And the last ping in the series.
"Kewen.Lin" writes:
> Hi,
>
> Commit r15-2084 exposes one ICE in LRA. Firstly, before
> r15-2084 KFmode has 126 bit precision while V1TImode has 128
> bit precision, so the subreg (subreg:V1TI (reg:KF 131) 0) is
> paradoxical_subreg_p, which stops some passes from doing
> some optimization. Afte
Gerald Pfeifer writes:
> On Fri, 26 Apr 2024, Marc Poulhiès wrote:
>> Co-authored-by: Fernando Oleo Blanco
>> Co-authored-by: Piotr Trojanek
>> Signed-off-by: Marc Poulhiès
>> ---
>> htdocs/gcc-14/changes.html | 67 +-
>
> This is really great how thoroughly
Gerald Pfeifer writes:
> On Wed, 31 Jul 2024, liuhongt wrote:
>> + The _Float16 and __bf16 type are supported
>> +independent of SSE2. W/o SSE2, these types are storage-only, compiler
>> will
>> +issue an error when they're used in conversion, unary operation,
>> +binary operation,
"Robin Dapp" writes:
> This patch amends the documentation for masked loads (maskload,
> vec_mask_load_lanes, and mask_gather_load as well as their len
> counterparts) with an else operand.
>
> gcc/ChangeLog:
>
> * doc/md.texi: Document masked load else operand.
> ---
> gcc/doc/md.texi | 60
Richard Biener writes:
>> Am 09.08.2024 um 19:19 schrieb Richard Sandiford :
>>
>> This patch is an attempt to gauge opinion on one way of fixing PR30920.
>>
>> The PR points out that the libiberty splay tree implementation does
>> not implement the algorithm described by Sleator and Tarjan and
Hi Richard,
Thanks for the comments!
on 2024/8/12 16:55, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi,
>>
>> Commit r15-2084 exposes one ICE in LRA. Firstly, before
>> r15-2084 KFmode has 126 bit precision while V1TImode has 128
>> bit precision, so the subreg (subreg:V1TI (reg:KF 131)
>
>
> On Fri, Aug 2, 2024, 14:25 Richard Biener
> wrote:
> > On Wed, Jul 31, 2024 at 12:42 PM Mariam Arutunian
> > wrote:
> >
> > Gives an opportunity to execute the code on bit level,
> >assigning symbolic values to the variables which don't have initial
> values.
> >Supports only CR
On Mon, Aug 12, 2024 at 12:25 AM Jakub Jelinek wrote:
>
> On Thu, Aug 08, 2024 at 06:53:10PM -0700, H.J. Lu wrote:
> > When we emit .p2align to align BB_HEAD, we must update BB_HEAD. Otherwise
> > ENDBR will be inserted as the wrong place.
> >
> > gcc/
> >
> > PR target/116174
> > * c
On Mon, Aug 12, 2024 at 04:19:58AM -0700, H.J. Lu wrote:
> > This is wrong. As documented, BB_HEAD needs to be either a CODE_LABEL, or
> > NOTE_INSN_BASIC_BLOCK.
>
> ira.cc has
>
> new_insn = emit_insn_before (PATTERN (def_insn), use_insn);
> REG_NOTES (new_insn) = REG_NOTES
On Mon, Aug 12, 2024 at 4:25 AM Jakub Jelinek wrote:
>
> On Mon, Aug 12, 2024 at 04:19:58AM -0700, H.J. Lu wrote:
> > > This is wrong. As documented, BB_HEAD needs to be either a CODE_LABEL, or
> > > NOTE_INSN_BASIC_BLOCK.
> >
> > ira.cc has
> >
> > new_insn = emit_insn_before (PATTERN
Ajit Agarwal writes:
> [...]
> +static void
> +update_change (set_info *set)
> +{
> + if (!set->has_any_uses ())
> +return;
> +
> + auto *use = *set->all_uses ().begin ();
> + do
> +{
> + auto *next_use = use->next_use ();
> + if (use->is_in_phi ())
> + {
> + update_
Hi all,
the attached two patches fix ASSOCIATE for coarrays, i.e. that a coarray
associated to a variable is also a coarray in the block of the ASSOCIATE
command. The patch has two parts:
1. pr110033p1_1.patch: Adds a corank member to the gfc_expr structure. I
decided to add it here and keep trac
This fixes an unrecognizable insn ICE when alignments >= 128
were passed from setmemhi to clrmemqi*. Alignment is unused,
hence set it to 0 so that the patterns match for big alignments.
Johann
---
AVR: target/85624 - Fix non-matching alignment in clrmem* insns.
The clrmem* patterns don't use
On Thu, 11 Jul 2024 at 00:10, Jeff Law wrote:
>
>
>
> On 6/3/24 5:34 AM, Manolis Tsamis wrote:
> > Currently the operations allowed for if conversion of a basic block with
> > multiple sets are few, namely REG, SUBREG and CONST_INT (as controlled by
> > bb_ok_for_noce_convert_multiple_sets).
> >
>
"Kewen.Lin" writes:
> Hi Richard,
>
> Thanks for the comments!
>
> on 2024/8/12 16:55, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>> Hi,
>>>
>>> Commit r15-2084 exposes one ICE in LRA. Firstly, before
>>> r15-2084 KFmode has 126 bit precision while V1TImode has 128
>>> bit precision, so th
On 8/11/24 21:50, Kewen.Lin wrote:
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index 92b343fa99a..f355c6c6168 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -4742,7 +4742,9 @@ curr_insn_transform (bool check_only_p)
}
*loc = new_reg
On architectures where `size_t` is `unsigned int`, such as 32bit x86,
we encounter an issue with `PlaceId` and `FreeRegion` being aliases to
the same types. This poses an issue for overloading functions for these
two types, such as `push_subset` in that case. This commit renames one
of these `push_
gcc/rust/ChangeLog:
* checks/errors/borrowck/rust-bir-builder.h: Cast size_t values to
unsigned
long before printing.
* checks/errors/borrowck/rust-bir-fact-collector.h: Likewise.
---
gcc/rust/checks/errors/borrowck/rust-bir-builder.h| 3 ++-
gcc/rust/checks/error
When compiling an interface for rounding of type 'vfloat16*' without using zvfh
or zvfhmin, it is not enough to use FLOAT_MODE_P because the type does not
support
it. Although the subsequent riscv_validate_vector_type checks will still fail
and throw exceptions, I don't think we should have ICE he
So this is another nasty latent bug exposed by ext-dce.
Similar to the prior m68k failure it's another problem with how we
handle paradoxical subregs on big endian targets.
In this instance when we remove the hard subregs we take something like:
(subreg:DI (reg:SI 0) 0)
And turn it into
(r
On 8/9/24 4:43 PM, Segher Boessenkool wrote:
> On Fri, Aug 09, 2024 at 03:50:50PM -0500, Peter Bergner wrote:
>> I'm fine with the TARGET_P10_* macro, since it's more readable than saying
>> TARGET_POWER10 && TARGET_ALTIVEC && TARGET_VSX, especially when we use the
>> negated version.
>
> It is no
On 8/11/24 9:42 PM, Kewen.Lin wrote:
> One difference with this change is that previously users specify -mno-vsx to
> disable all vector insns (both VMX and VSX) on Power[89], now they should
> use -mno-altivec for that purpose. I think it's better as it matches the
> behaviors on Power7?
I hope
Hi, Richard,
Do we still need such improvement into GCC? Could you please take a look at the
patch and let me know
Any comment or suggestions?
thanks.
Qing
The 3rd ping for the following patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657150.html
> On Jul 29, 2024, at 11:32, Qing
Gentle ping on this simple patch.
thanks.
Qing
> On Aug 5, 2024, at 16:17, Qing Zhao wrote:
>
> Compared to the first version, the major changes are:
>
> 1. Changed the error as a warning with -Wattributes per Jakub and Jason's
> comments.
> 2. Update documentation accordingly.
> 3. Move
Hi all,
The fp reassociation width for Neoverse V2 was set to 6 since its
introduction and I guess it was empirically tuned. But since
AARCH64_EXTRA_TUNE_FULLY_PIPELINED_FMA was added the tree reassociation
pass seems to be more deliberate in forming FMAs and when that flag is
used it seems to mo
Hi Marc,
Patch looks good to me :) Thanks!
On 8/6/24 18:43, Marc Poulhiès wrote:
Save LIBS around calls to AC_SEARCH_LIBS to avoid clobbering $LIBS.
ChangeLog:
* configure: Regenerate.
* configure.ac: Save LIBS around calls to AC_SEARCH_LIBS.
Signed-off-by: Marc Poulhiès
Rev
> Are there any assumptions that BB_HEAD must be a note or label?
> Maybe we should move ix86_align_loops into a separate pass and insert
> the pass just before pass_final.
The patch inserts .p2align after endbr pass, it can also fix the issue.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m3
Hi!
On Mon, Aug 12, 2024 at 09:55:07AM +0100, Richard Sandiford wrote:
> "Kewen.Lin" writes:
> > (define_insn "*vsx_le_perm_store_"
> > [(set (match_operand:VSX_LE_128 0 "memory_operand" "=Z,Q")
> > (match_operand:VSX_LE_128 1 "vsx_register_operand" "+wa,r"))]
>
> Is it well-formed to
Hi Kyrill,
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, August 12, 2024 3:07 PM
> To: GCC Patches
> Cc: Tamar Christina ; Richard Sandiford
>
> Subject: [PATCH][RFC] aarch64: Reduce FP reassociation width for Neoverse V2
> and set AARCH64_EXTRA_TUNE_FULLY_PIPELINED_FMA
>
Hi Tamar,
> On 12 Aug 2024, at 16:48, Tamar Christina wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi Kyrill,
>
>> -Original Message-
>> From: Kyrylo Tkachov
>> Sent: Monday, August 12, 2024 3:07 PM
>> To: GCC Patches
>> Cc: Tamar Christina ; Richard San
Hi!
On Mon, Aug 12, 2024 at 10:42:48AM +0800, Kewen.Lin wrote:
> on 2024/8/10 05:43, Segher Boessenkool wrote:
> IIUC, we want to split TARGET_P[89]_VECTOR into TARGET_P[89]_ALTIVEC and
> TARGET_P[89]_VSX (or just TARGET_POWER[89] && TARGET_VSX or TARGET_ALTIVEC)
> according to the context (VMX or
On Mon, Aug 12, 2024 at 08:48:22AM -0500, Peter Bergner wrote:
> On 8/11/24 9:42 PM, Kewen.Lin wrote:
> > One difference with this change is that previously users specify -mno-vsx to
> > disable all vector insns (both VMX and VSX) on Power[89], now they should
> > use -mno-altivec for that purpose.
When deducing auto for `adc_return_type`, `adc_variable_type`, and
`adc_decomp_type` contexts (at the usage time), we try to resolve the outermost
template arguments to be used for satisfaction. This is done by one of the
following, depending on the scope:
1. Checking the `DECL_TEMPLATE_INFO` of t
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Monday, August 12, 2024 3:54 PM
> To: Tamar Christina
> Cc: GCC Patches ; Richard Sandiford
>
> Subject: Re: [PATCH][RFC] aarch64: Reduce FP reassociation width for Neoverse
> V2 and set AARCH64_EXTRA_TUNE_FULLY_PIPELINED_FMA
>
> Hi Ta
Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
Segher, this resolves the issues you mentioned in your review.
This was on the top of your patch review queue before, so maybe
we have queue overflow? ;-)
Peter
On 6/18/24 5:59 PM, Peter Bergner wrote:
> Updated pa
On Fri, Aug 2, 2024 at 2:12 PM Richard Biener
wrote:
> On Wed, Jul 31, 2024 at 10:15 AM Mariam Arutunian
> wrote:
> >
> > This patch adds a new compiler pass aimed at identifying naive CRC
> implementations,
> > characterized by the presence of a loop calculating a CRC (polynomial
> long divisi
On Mon, Aug 12, 2024 at 10:59:01AM -0500, Peter Bergner wrote:
> Ping * 3. [Message-ID: <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
>
> Segher, this resolves the issues you mentioned in your review.
> This was on the top of your patch review queue before, so maybe
> we have queue overf
The previous patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd
aimed to eliminate redundant MOV instructions by removing calling
emit_clobber in lower-subreg.cc's resolve_simple_move.
First, I found that another patch address this issue:
https://gcc.gnu.
Andi Kleen writes:
I wanted to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658729.html
> From: Andi Kleen
>
> ... that uses -march=native -mtune=native to build a compiler optimized
> for the host.
>
> config/ChangeLog:
>
> * bootstrap-native.mk: New file.
>
> g
Andi Kleen writes:
I wanted to ping this patch. It fixes test suite noise on various
targets.
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html
> From: Andi Kleen
>
> This is a new attempt to fix PR116080. The previous try was reverted
> because it just broke a bunch of tests, h
Thanks!
Edwin
On 8/8/2024 12:24 AM, Robin Dapp wrote:
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
index d150f20b5d9..02814183dbb 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
+++ b/gcc/
On 8/11/24 4:43 AM, pan2...@intel.com wrote:
+static rtx
+riscv_gen_zero_extend_rtx (rtx x, machine_mode mode)
+{
+ if (mode != HImode && mode != QImode)
+return gen_lowpart (Xmode, x);
Isn't this wrong for SImode on rv64? It seems to me the right test is
mode != word_mode?
Assuming
On 8/12/24 7:25 AM, Jin Ma wrote:
When compiling an interface for rounding of type 'vfloat16*' without using zvfh
or zvfhmin, it is not enough to use FLOAT_MODE_P because the type does not
support
it. Although the subsequent riscv_validate_vector_type checks will still fail
and throw exceptio
On 8/12/24 11:03 AM, Segher Boessenkool wrote:
> On Mon, Aug 12, 2024 at 10:59:01AM -0500, Peter Bergner wrote:
>> Ping * 3. [Message-ID:
>> <1e003d78-3b2e-4263-830a-7c00a3e9d...@linux.ibm.com>]
>>
>> Segher, this resolves the issues you mentioned in your review.
>> This was on the top of your p
Hi!
This is a v2 patch of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659968.html
that addresses Jakub's feedback.
FWIW, I tried to contrive a testcase where convert_from_reference kicks
in and we get called with an ANNOTATE_EXPR in maybe_convert_cond, but to
no avail. However, I did
On 8/9/24 5:51 PM, Vineet Gupta wrote:
As you mentioned above: positive values are already handled in
riscv_split_integer after
c104ef4b5eb1 ("RISC-V: improve codegen for large constants with same 32-bit lo and
hi")parts [2]
Weird. I would have swore we weren't seeing good code for those c
On 8/11/24 3:01 PM, Robin Dapp wrote:
This patch adds else operands to masked loads. Currently the default
else operand predicate accepts "undefined" (i.e. SCRATCH) as well as
all-ones values.
Note that this series introduces a large number of new RVV FAILs for
riscv. All of them are due to
On 8/11/24 3:00 PM, Robin Dapp wrote:
This patch adds a zero else operand to the masked loads.
gcc/ChangeLog:
* config/gcn/predicates.md (maskload_else_operand): New
predicate.
* config/gcn/gcn-valu.md: Use new predicate.
OK if the GCN maintainers don't chime in by th
On 8/11/24 3:00 PM, Robin Dapp wrote:
This patch adds else-operand handling to the internal functions.
gcc/ChangeLog:
* internal-fn.cc (add_mask_and_len_args): Rename...
(add_mask_else_and_len_args): ...to this and add else handling.
(expand_partial_load_optab_fn): Us
On Tue, 2024-06-18 01:17:02 +0100, Mark Harmstone wrote:
> 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.
[...]
> This ought to be fairly complete as far as C is concerned. Still to come
>
"H.J. Lu" writes:
> On Mon, Aug 12, 2024 at 4:25 AM Jakub Jelinek wrote:
>>
>> On Mon, Aug 12, 2024 at 04:19:58AM -0700, H.J. Lu wrote:
>> > > This is wrong. As documented, BB_HEAD needs to be either a CODE_LABEL,
>> > > or
>> > > NOTE_INSN_BASIC_BLOCK.
>> >
>> > ira.cc has
>> >
>> >
Jeff Law writes:
> So this is another nasty latent bug exposed by ext-dce.
>
> Similar to the prior m68k failure it's another problem with how we
> handle paradoxical subregs on big endian targets.
>
> In this instance when we remove the hard subregs we take something like:
>
> (subreg:DI (reg:SI
The testcase uses -march=rv64gcv and dg-do run, so should be
restricted to a riscv_v target.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr116202-run-1.c (dg-do run):
Add target riscv_v.
---
gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c | 2 +-
1 file changed,
On 8/12/24 1:49 PM, Richard Sandiford wrote:
- regno = subreg_regno (x);
+ /* A paradoxical should always be REGNO (y) + 0. Using subreg_regno
+for something like (subreg:DI (reg:SI N) 0) on a WORDS_BIG_ENDIAN
+target will return N-1 which is catastrophic
Jeff Law writes:
> On 8/12/24 1:49 PM, Richard Sandiford wrote:
>
>>>
>>> - regno = subreg_regno (x);
>>> + /* A paradoxical should always be REGNO (y) + 0. Using subreg_regno
>>> +for something like (subreg:DI (reg:SI N) 0) on a WORDS_BIG_ENDIAN
>>> +target will return
Initialize last_type to 0 to silence two spurious maybe-uninitialized warnings.
We issue an LF_INDEX continuation subtype for any LF_FIELDLISTs that
overflow, so LF_INDEXes will always have a subtype preceding them (and
thus last_type will always be set).
gcc/
* dwarf2codeview.cc (get_type
Thanks for this - I've just submitted a patch to fix these warnings.
Mark
On 12/08/2024 20:09, Jan-Benedict Glaw wrote:
Building with a really recent GCC on the host for
--target=i686-mingw32crt or --target=i686-cygwin --enable-threads=yes,
I get these new warnings (--enable-werror-always is in
On Fri, Aug 09, 2024 at 05:15:05PM -0400, Jason Merrill wrote:
> On 8/9/24 4:21 PM, Marek Polacek wrote:
> > On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote:
> > > On 8/8/24 1:37 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> >
Hi David,
I want to send an updated version of n2529. The original author didn't
respond to my mail, so I'll take over. I've been preparing a GCC patch
set for adding the feature to GCC, and have informed Clang developers
about it too.
The title would be
_Lengthof - New pointer-proof keywo
Hi Jakub,
On Sat, Aug 10, 2024 at 10:57:25AM GMT, Jakub Jelinek wrote:
> This is an obvious typo as can be seen in what the test does, what similar
> tests committed in the same commit do (all the others use sizeof (vals) /
> sizeof (vals[0])) and what the test originates from (i386/sse3-addsubps.
Outputs CodeView S_REGREL32 symbols for unoptimized local variables that
are stored on the stack. This includes a change to dwarf2out.cc to make
it easier to extract the function frame base without having to worry
about the function prologue or epilogue.
gcc/
* dwarf2codeview.cc (enum cv_s
Outputs CodeView S_LDATA32 symbols, for static variables within
functions, along with S_BLOCK32 and S_END for the beginning and end of
lexical blocks.
gcc/
* dwarf2codeview.cc (enum cv_sym_type): Add S_END and S_BLOCK32.
(write_local_s_ldata32): New function.
(write_unoptim
Outputs CodeView S_REGISTER symbols, representing local variables or
parameters that are held in a register.
gcc/
* dwarf2codeview.cc (enum cv_sym_type): Add S_REGISTER.
(enum cv_x86_register): New type.
(enum cv_amd64_register): New type.
(dwarf_reg_to_cv): New fun
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
-- >8 --
In r15-2210 we got rid of the unnecessary cast to lvalue reference when
passing *this to the promise type ctor, and as a drive-by change we also
simplified the code to use cp_build_fold_indirect_ref.
But cp_build_fold_indire
On 8/12/24 4:02 PM, Richard Sandiford wrote:
Jeff Law writes:
On 8/12/24 1:49 PM, Richard Sandiford wrote:
- regno = subreg_regno (x);
+ /* A paradoxical should always be REGNO (y) + 0. Using subreg_regno
+for something like (subreg:DI (reg:SI N) 0) on a WORDS_BI
> Isn't this wrong for SImode on rv64? It seems to me the right test is
> mode != word_mode?
> Assuming that works, it's OK for the trunk.
Thanks Jeff, Simode version of test file doesn't have this issue. Thus, only HI
and QI here.
I will add a new test for SImode in v3 to ensure this.
Pan
--
From: Pan Li
For QI/HImode of .SAT_ADD, the operands may be sign-extended and the
high bits of Xmode may be all 1 which is not expected. For example as
below code.
signed char b[1];
unsigned short c;
signed char *d = b;
int main() {
b[0] = -40;
c = ({ (unsigned short)d[0] < 0xFFF6 ? (unsig
2024-08-07 23:15 Jeff Law wrote:
>
>
>
>On 8/7/24 8:55 AM, Jakub Jelinek wrote:
>> On Wed, Aug 07, 2024 at 08:46:11AM -0600, Jeff Law wrote:
>>>
>>>
>>> On 8/7/24 1:16 AM, Jakub Jelinek wrote:
>>>
This looks all wrong to me.
On all the other targets that already do support __b
It's been a month. Ping!
I disabled late-combine for CRIS, so to expose the bug for
current master, you'll need to enable that pass explicitly
when testing, e.g like "make -k check-gcc-c
RUNTESTFLAGS=--target_board=cris-sim/-flate-combine-instructions\
cris.exp=rld-legit2.c"
I verified that the
On 7/11/24 7:17 PM, Hans-Peter Nilsson wrote:
CC to both the combine maintainer and the RA maintainer for
verdict on whether this is the true correction or just a
"fix"; whether REG_POINTER must be present or is just an
optimization hint. And I almost forgot, the late-combine
author! At leas
IOR part of the bug report was fixed by r13-4620-g4d9db4bdd458 but
that added only aarch64 specific testcases. This adds 4
generic testcases for this to check to make sure they are optimized.
The C++ testcases are the vector type versions.
PR tree-optimization/103660
gcc/testsuite/ChangeL
This adds a pattern to convert `(a ? b : 0) | (a ? 0 : c)` into `a ? b : c`
which is simplier. It adds both for cond and vec_cond; even though vec_cond is
handled via a different pattern currently but requires extra steps for matching
so this should be slightly faster.
Also handle it for xor and p
r13-4620-g4d9db4bdd458 Added a few patterns and some of them can be extended to
support XOR and PLUS.
This extends the patterns to support XOR and PLUS instead of just IOR.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/103660
gcc/ChangeLog:
* match.pd (`((a
Hi,
As mentioned in:
https://gcc.gnu.org/pipermail/gcc/2024-August/244581.html
AArch64 cl_optimization_stream_out streams out target-specific optimization
options like flag_aarch64_early_ldp_fusion, aarch64_early_ra etc, which breaks
AArch64/nvptx offloading,
since nvptx cl_optimization_stream_i
From: sunil dora
For excessively long environment variables i.e >128KB
Store the arguments in a temporary file and collect them back together in
collect2.
This commit patches for COLLECT_GCC_OPTIONS issue:
GCC should not limit the length of command line passed to collect2.
https://gcc.gnu.org/b
On Mon, Aug 12, 2024 at 10:36 PM Prathamesh Kulkarni
wrote:
>
> Hi,
> As mentioned in:
> https://gcc.gnu.org/pipermail/gcc/2024-August/244581.html
>
> AArch64 cl_optimization_stream_out streams out target-specific optimization
> options like flag_aarch64_early_ldp_fusion, aarch64_early_ra etc, wh
86 matches
Mail list logo
