On Thu, 8 May 2025, H.J. Lu wrote:
> On Mon, Apr 28, 2025 at 8:57 PM H.J. Lu wrote:
> >
> > On x86, both stores with 32-bit immediate and register are supported:
> >
> >0: 48 c7 40 10 00 00 00 00 movq $0x0,0x10(%rax)
> >8: 48 89 50 10 movq %rdx,0x10(%rax)
> >
> > But store wi
Hi Jakub,
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
15.2?
OK. Thanks for catching and fixing this!
Best regards
Thomas König
This patch support zilsd and zclsd[1] extensions.
To enable GCC to recognize and process zilsd and zclsd extension
correctly at compile time.
[1] https://github.com/riscv/riscv-zilsd
Changes for v3:
- Fix the error of testcases and merge the fail testcases into one file
and rename the file.
Like the patch to phiopt (r15-4033-g1f619fe25925a5f7), this adds rewriting
of VCE to gimple_with_undefined_signed_overflow/rewrite_to_defined_overflow.
In the case of moving VCE of a bool from being conditional to unconditional,
it needs to be rewritten to not to use VCE but a normal cast. pr120122
As mentioned previously the rewrite in move_stmt should be
using gimple_needing_rewrite_undefined/rewrite_to_defined_unconditional
instead of just rewriting the VCE.
This moves move_stmt over to those APIs.
A few testcases needed to be updated due to ABS_EXPR rewrite that happens.
Bootstrapped an
x86 conditional branch (jcc) target can be either a label or a symbol.
Add a pass to fold tail call with jcc by turning:
jcc .L6
...
.L6:
jmp tailcall
into:
jcc tailcall
Immediately before the pass which turning REG_EH_REGION notes back into
NOTE_INSN_EH_REGI
Enhance fold sibcall pass to fold sibcall targets into jump table by
turning:
foo:
.cfi_startproc
cmpl$4, %edi
ja .L1
movl%edi, %edi
jmp *.L4(,%rdi,8)
.section.rodata
.L4:
.quad .L8
.quad .L7
.quad
Conditional and unconditional branch targets can be either a label or
a symbol. For conditional jump:
(jump_insn 7 6 14 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 23)
(pc))) "x.c":8:5 1458 {jcc}
(expr_list
Changes in v2:
1. Search backward from exit basic blocks with only sibcalls.
2. Add anycall_p to return true for call and conditional sibcall.
3. Replace CALL_P with anycall_p in except.cc to handle exceptions with
conditional sibcalls.
4. Update the gate function to follow the tree tailcall pass.
> Pengxuan Zheng writes:
> > Similar to the canonicalization done in combine, we canonicalize
> > vec_merge with swap_communattive_operands_p in
> simplify_ternary_operation too.
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64-protos.h (aarch64_exact_log2_inverse):
> New.
> > * con
Ok. I got it. Thank you sir.
On Thu, May 8, 2025, 4:26 AM Joseph Myers wrote:
> On Tue, 6 May 2025, SAKSHAM JOSHI wrote:
>
> > I am submitting a patch for the GCC compiler's "stdbool.h" to optimize
> the
> > size of the true and false macros in the C programming language.
> Currently,
> > the si
On Wed, May 7, 2025 at 4:10 AM Richard Biener
wrote:
>
> On Wed, May 7, 2025 at 3:55 AM Andrew Pinski wrote:
> >
> > Like the patch to phiopt (r15-4033-g1f619fe25925a5f7), this adds rewriting
> > of VCE to gimple_with_undefined_signed_overflow/rewrite_to_defined_overflow.
> > In the case of movin
On Tue, 6 May 2025, SAKSHAM JOSHI wrote:
> I am submitting a patch for the GCC compiler's "stdbool.h" to optimize the
> size of the true and false macros in the C programming language. Currently,
> the size of the true and false macros is 4 bytes, whereas the _Bool
> datatype is 1 byte in size. Th
On 5/1/25 7:03 AM, Richard Sandiford wrote:
Indu Bhagat writes:
[...]
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ffde9df85fd3..de651183a703 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17079,6 +17079,14 @@ and @option{-fsanitize=kernel-hwaddress}.
To disabl
On 5/1/25 12:01 PM, Richard Sandiford wrote:
Indu Bhagat writes:
In context of stack tagging, the AArch64 Memtag ABI Extension to ELF
specifies the usage of two dynamic tags for the dynamic loader to do the
necessary tasks:
- If DT_AARCH64_MEMTAG_MODE is present, the dynamic loader should (i
On Mon, Apr 28, 2025 at 8:57 PM H.J. Lu wrote:
>
> On x86, both stores with 32-bit immediate and register are supported:
>
>0: 48 c7 40 10 00 00 00 00 movq $0x0,0x10(%rax)
>8: 48 89 50 10 movq %rdx,0x10(%rax)
>
> But store with 32-bit immediate is 4 byte longer.
>
> Add UNSPEC
Hi!
When libgfortran is compiled, there are some -Woverflow warnings like
../../../libgfortran/generated/maxloc0_4_m1.c:99:14: warning: unsigned
conversion from ‘int’ to ‘GFC_UINTEGER_1’ {aka ‘unsigned char’} changes value
from ‘-255’ to ‘1’ [-Woverflow]
99 | maxval = -GFC_UINTEGER_1_HUGE
Indu Bhagat writes:
>>> starting bb 3
>>> 33: {cc:CC=cmp(r121:DI,0x10);r121:DI=r121:DI-0x10;}
>>> 32: r122:DI=r122:DI+0x10
>>> 31: [r122:DI+0]=unspec/v[[r122:DI+0],r120:DI] 17
>>> mem count failure
>>> mem count failure
>>
>> Yeah, we'd need to update auto-inc-dec for this case.
>>
libstdc++-v3/ChangeLog:
PR libstdc++/120159
* src/c++23/std.cc.in (is_layout_compatible_v): Export.
---
Tested x86_64-linux. Pushed to trunk and gcc-15.
libstdc++-v3/src/c++23/std.cc.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/libstdc++-v3/src/c++23/std.cc.in b/libstd
On 5/6/25 3:53 AM, Richard Sandiford wrote:
Indu Bhagat writes:
On 4/15/25 9:21 AM, Richard Sandiford wrote:
Indu Bhagat writes:
Store Allocation Tags (st2g) is an Armv8.5-A memory tagging (MTE)
instruction. It stores an allocation tag to two tag granules of memory.
TBD:
- Not too sure
On 4/18/25 2:46 AM, Dongyan Chen wrote:
This patch support zama16b extension[1].
To enable GCC to recognize and process zama16b extension correctly at compile
time.
[1] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc
gcc/ChangeLog:
* common/config/riscv/ris
Richard Earnshaw writes:
> On 07/05/2025 17:28, Richard Earnshaw (lists) wrote:
>> On 07/05/2025 16:54, Richard Sandiford wrote:
>>> Richard Earnshaw writes:
On 07/05/2025 13:57, Richard Sandiford wrote:
> Kyrylo Tkachov writes:
>>> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> Give the `define_insn` rules used in lowering `cbranch4` to RTL
> more descriptive and consistent names: from now on, each rule is named
> after the AArch64 instruction that it generates. Also add comments to
> document each rule.
>
> gcc/Chang
Hi,
This is the 2nd version of the patch for:
Evaluate the object size by the size of the pointee type when the type
is a structure with flexible array member which is annotated with
counted_by.
Per the following discussion: (Questions on replacing a structure
pointer reference to a call to .A
On Tue, 6 May 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > The following amends gcc-15/changes.html with a note that reload
> > is going to be removed for GCC 16.
> >
> > OK for www?
> >
> > * htdocs/gcc-15/changes.html: Mark GCC 15 as last release
> > supporting reload.
>
Hi Jakub,
While looking at PR120152, I have noticed that libgfortran.so doesn't
export 5 *m16* symbols I would have expected that should be exported.
This is caused by 2 issues, one filename was forgotten to be added in r15-4124
to i_maxloc1_c (guess because generated/maxloc1_16_i16.c was kept i
Hi Jakub,
The r15-4124-gc0002a675a92e76d change seems to have accidentally
dropped 5 sourcefiles from i_maxloc1_c, which resulted in dropping
15 GFORTRAN_8 symbols on x86_64 and 6 on i686.
The following patch adds it back, so that we export those symbols
again, fixing the ABI problem.
Bootstra
On 07/05/2025 16:54, Richard Sandiford wrote:
> Richard Earnshaw writes:
>> On 07/05/2025 13:57, Richard Sandiford wrote:
>>> Kyrylo Tkachov writes:
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> Commit the test file `cmpbr.c` before rules for generating the new
> instructions
To make hashing sensible we canonicalize constant vectors in the hash
table so that their first entry always has the value zero. That
normalization can result in a value that can't be represented in the
element mode.
So before entering anything into the hash table we need to verify the
nor
On 07/05/2025 17:28, Richard Earnshaw (lists) wrote:
> On 07/05/2025 16:54, Richard Sandiford wrote:
>> Richard Earnshaw writes:
>>> On 07/05/2025 13:57, Richard Sandiford wrote:
Kyrylo Tkachov writes:
>> On 7 May 2025, at 12:27, Karl Meakin wrote:
>>
>> Commit the test file `cm
Since we no-longer have any iwmxxt instructions, the iwmmxt-related
attributes can never be set. Consequently, the marvel-f-iwmmxt
scheduler is redundant as none of the pipes are ever used now.
gcc/ChangeLog:
* config/arm/arm.md (core_cycles): Remove iwmmxt attributes.
* config/a
Remove most of the remaining code for iWMMXT support, except for the
register allocation table entries.
gcc/ChangeLog:
* config/arm/arm-cpus.in (feature iwmmxt, feature iwmmxt2): Delete.
* config/arm/arm-protos.h (arm_output_iwmmxt_shift_immediate): Delete.
(arm_output_iw
Remove the various checks for TARGET_IWMMXT{,2} and
TARGET_REALLY_IWMMXT{,2} from the remaining machine description files.
These flags can never be true now.
gcc/ChangeLog:
* config/arm/arm.md(attr arch): Remove iwmmxt and iwmmxt2.
Remove checks based on TARGET_REALLY_IWMMXT2 from
Since we no-longer enable iWMMXT, these predefines are no-longer enabled
when preprocessing C. Remove them.
gcc/ChangeLog:
* config/arm/arm-c.cc (arm_cpu_builtins): Remove predefines
for __IWWMXT__, __IWMMXT2__ and __ARM_WMMX.
---
gcc/config/arm/arm-c.cc | 7 ---
1 file cha
Treat options that select iwmmxt variants as we would for xscale. We
leave the feature bits in for now, since they are still needed
elsewhere, but they are never enabled.
Also remove the remaining testsuite framework support for iwmmxt,
since this will never trigger now.
gcc/
* config/a
TARGET_IWMMXT, TARGET_IWMMXT2 and their _REALLY_ equivalents are never
true now, so the code using them can be simplified.
gcc/ChangeLog:
* config/arm/arm.cc (arm_option_check_internal): Remove
IWMMXT check.
(arm_options_perform_arch_sanity_checks): Likewise.
(use_
The iwmmxt ABI is a variant of the ABI that supported passing certain
parameters and results in iwmmxt registers. But since we no-longer
support the instructions that can read and write these registers, the
ABI variant can no-longer be used.
gcc/ChangeLog:
* config.gcc (arm, --with-abi):
This patch deletes the patterns relating to iwmmxt and iwmmxt2 and
updates the relevant dependencies.
gcc/ChangeLog:
* config/arm/arm.md: Don't include iwmmxt.md.
* config/arm/t-arm (MD_INCLUDES): Remove iwmmxt*.md.
* config/arm/iwmmxt.md: Removed.
* config/arm/iwm
These registers can no-longer be allocated, so remove them from the
various tables.
gcc/ChangeLog:
* config/arm/aout.h (REGISTER_NAMES): Remove iwmmxt registers.
* config/arm/arm.h (FIRST_IWMMXT_REGNUM): Delete.
(LAST_IWMMXT_REGNUM): Delete.
(FIRST_IWMMXT_GR_REGNUM
These two tests were specific to iWMMXT, but we're about to remove
that code, so the tests are now redundant.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mmx-1.c: Removed.
* gcc.target/arm/mmx-2.c: Removed.
* gcc.target/arm/pr64208.c: Removed.
* gcc.target/arm/pr7914
Mostly this is just removing references to iWMMXT in comments, but also remove
some now unused iterators and attributes.
gcc/ChangeLog:
* config/arm/iterators.md (VMMX, VMMX2): Remove mode iterators.
(MMX_char): Remove mode iterator attribute.
---
gcc/config/arm/iterators.md | 20
The header file for the Arm implementation of mmintrin.h was changed in GCC-15
to disable access to the intrinsics. This patch removes the internal code
as well.
We still allow -mcpu/-march options for the wmmx cpus, but they are now treated
in exactly the same way as XScale - generating code f
This is the first step of removing the various builtins for iwmmxt,
removing the builtins expansion code. It leaves a lot of code
elsewhere, but we'll clean that up in subsequent patches.
I'm not sure why safe_vector_operand would unconditionally try to
expand to an iwmmxt instruction if passed (
The flattened logic of these functions and the complexity of the
numerous clauses makes it very difficult to understand what's written
in these macros. Additionally, SECONDARY_INPUT_RELOAD_CLASS was not
laid out with the correct formatting.
Add some parenthesis and re-indent to make the logic cle
Richard Sandiford writes:
>> @@ -758,6 +781,58 @@ (define_expand "cbranchcc4"
>>""
>> )
>>
>> +;; Emit a `CB (register)` or `CB (immediate)` instruction.
>> +(define_insn "aarch64_cb"
>> + [(set (pc) (if_then_else (match_operator 0 "aarch64_comparison_operator"
>> +
Richard Earnshaw writes:
> On 07/05/2025 13:57, Richard Sandiford wrote:
>> Kyrylo Tkachov writes:
On 7 May 2025, at 12:27, Karl Meakin wrote:
Commit the test file `cmpbr.c` before rules for generating the new
instructions are added, so that the changes in codegen are more ob
> -Original Message-
> From: Rainer Orth
> Sent: Friday, April 11, 2025 04:43
> To: gcc-patches@gcc.gnu.org
> Cc: Robert Dubner ; James K. Lowden
>
> Subject: [PATCH] cobol: Don't require GLOB_BRACE etc. [PR119217]
>
> cdf-copy.cc doesn't compile on Solaris:
>
> /vol/gcc/src/hg/master/loc
> -Original Message-
> From: Rainer Orth
> Sent: Friday, April 11, 2025 04:50
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] cobol: Initialize regmatch_t portably [PR119217]
>
> The dts.h initialization of regmatch_t currently breaks Solaris
> compilation:
>
> In file included from /vol/
> -Original Message-
> From: Rainer Orth
> Sent: Friday, April 11, 2025 05:17
> To: gcc-patches@gcc.gnu.org
> Cc: Robert Dubner ; James K. Lowden
>
> Subject: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]
>
> All users of symbols.h fail to compile on Solaris:
>
> /vol/gcc/src/
> -Original Message-
> From: Rainer Orth
> Sent: Friday, April 11, 2025 05:26
> To: gcc-patches@gcc.gnu.org
> Cc: Robert Dubner ; James K. Lowden
>
> Subject: [PATCH] libgcobol: Heed --enable-libgcobol
>
> If some target isn't listed as supported in configure.tgt,
> --enable-libgcobol
Karl Meakin writes:
> Add rules for lowering `cbranch4` to CBB/CBH/CB when CMPBR
> extension is enabled.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (cbranch4): emit CMPBR
> instructions if possible.
> (cbranch4): new expand rule.
> (aarch64_cb): likewise.
> (a
On 5/7/25 1:50 AM, Jakub Jelinek wrote:
On Tue, May 06, 2025 at 05:11:51PM -0400, Jason Merrill wrote:
Well, that's all very complicated but seems to make sense. Can you also add
short rationale comments to the changes in linemap_add and plugin_init?
So like this?
That's great, thanks. Thi
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> The rules for conditional branches were spread throughout `aarch64.md`.
> Group them together so it is easier to understand how `cbranch4`
> is lowered to RTL.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (condjump): move.
> (*compare_co
Hi!
While looking at PR120152, I have noticed that libgfortran.so doesn't
export 5 *m16* symbols I would have expected that should be exported.
This is caused by 2 issues, one filename was forgotten to be added in r15-4124
to i_maxloc1_c (guess because generated/maxloc1_16_i16.c was kept in the
po
Hi!
The r15-4124-gc0002a675a92e76d change seems to have accidentally
dropped 5 sourcefiles from i_maxloc1_c, which resulted in dropping
15 GFORTRAN_8 symbols on x86_64 and 6 on i686.
The following patch adds it back, so that we export those symbols
again, fixing the ABI problem.
Bootstrapped/reg
On Tue, 2025-05-06 at 14:00 +0530, soum...@nvidia.com wrote:
> From: Soumya AR
>
> Hi,
>
> This RFC and subsequent patch series introduces support for printing
> and parsing
> of aarch64 tuning parameters in the form of JSON.
>
> It is important to note that this mechanism is specifically inten
I don't understand why they vanish when still refered to, but
lets deal with that in a conservative way.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
There's questions around the cgraph code in the PR, but the
patch is somewhat obvious at least.
Richard.
PR ipa/120146
> On 7 May 2025, at 13:35, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jennifer Schmitz writes:
>> @@ -3698,6 +3706,24 @@ aarch64_partial_ptrue_length (rtx_vector_builder
>> &builder,
>> return vl;
>> }
>>
>> +/* Return:
>> +
>> + * -1 if
Hi,
This patch adds pattern matching for float<->int conversions both as normal
statements and promote_demote. While updating promote_demote I noticed that
in cleanups I turned "stmt_cost =" into "int stmt_cost = " which turned
the existing FP costing to NOOP. I also added comment on how demotes a
On 07/05/2025 13:57, Richard Sandiford wrote:
Kyrylo Tkachov writes:
On 7 May 2025, at 12:27, Karl Meakin wrote:
Commit the test file `cmpbr.c` before rules for generating the new
instructions are added, so that the changes in codegen are more obvious
in the next commit.
I guess that’s an L
Kyrylo Tkachov writes:
>> On 7 May 2025, at 12:27, Karl Meakin wrote:
>>
>> Commit the test file `cmpbr.c` before rules for generating the new
>> instructions are added, so that the changes in codegen are more obvious
>> in the next commit.
>
> I guess that’s an LLVM best practice.
> In GCC sinc
Karl Meakin writes:
> Extract the hardcoded values for the minimum PC-relative displacements
> into named constants and document them.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (BRANCH_LEN_P_128MiB): New constant.
> (BRANCH_LEN_N_128MiB): likewise.
> (BRANCH_LEN_P_1MiB):
Thank you for the reminder, and accept my apologies for the delays.
Jim and I have been been distracted by an intense effort to rewrite
exception/declarative processing. There has also been a serious family
health issue that caused us significant delays as well.
I finished a sub-project yesterda
Kyrylo Tkachov writes:
>> On 7 May 2025, at 12:27, Karl Meakin wrote:
>>
>> Give the `define_insn` rules used in lowering `cbranch4` to RTL
>> more descriptive and consistent names: from now on, each rule is named
>> after the AArch64 instruction that it generates. Also add comments to
>> docume
Karl Meakin writes:
> Make the formatting of the RTL templates in the rules for branch
> instructions more consistent with each other.
One source of variation is the 80-character limit. It's a bit of a soft
limit for rtl, but it is still good to keep to it where that's easy.
So...
>
> gcc/Chang
On Tue, 2025-05-06 at 11:34 +0100, Richard Sandiford wrote:
> writes:
> > From: Soumya AR
> >
> > Hi,
> >
> > This RFC and subsequent patch series introduces support for
> > printing and parsing
> > of aarch64 tuning parameters in the form of JSON.
>
> Thanks for doing this. It looks really u
Hi Karl,
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> This patch series adds support for the CMPBR extension. It includes the
> new `+cmpbr` option and rules to generate the new instructions when
> lowering conditional branches.
Thanks for the series.
You didn’t state it explicitly, but ha
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> Add rules for lowering `cbranch4` to CBB/CBH/CB when CMPBR
> extension is enabled.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (cbranch4): emit CMPBR
> instructions if possible.
> (cbranch4): new expand rule.
> (aarch64_cb): likewise.
>
Committed asr16-445-g9565076f9b8105. This test supports mapping + accessing the vtab
of the polymorphic variable on the host. Obviously, this only works if
the host pointer is device accessible ("unified-shared memory"). In
principle, we want to check for this - and enable some subtests. The
en
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> Commit the test file `cmpbr.c` before rules for generating the new
> instructions are added, so that the changes in codegen are more obvious
> in the next commit.
I guess that’s an LLVM best practice.
In GCC since we have the check-function-bod
Okay, thanks.
Dongyan Chen
在 2025/5/7 7:11, Jeff Law 写道:
On 4/18/25 2:47 AM, Dongyan Chen wrote:
This patch support sdtrig and ssstrict extensions[1].
To enable GCC to recognize and process sdtrig and ssstrict extensions
correctly at compile time.
[1]https://github.com/riscv/riscv-profile
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> Add the `+cmpbr` option to enable the FEAT_CMPBR architectural
> extension.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-option-extensions.def (cmpbr): new
> option.
> * config/aarch64/aarch64.h (TARGET_CMPBR): new macro.
> * doc/invoke.tex
> On 6 May 2025, at 23:02, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jennifer Schmitz writes:
>> About the tests: Non-power-of-2 patterns are already being tested in
>> gcc.target/aarch64/sve/acle/general/whilelt_5.c.
>
> OK
>
>> For the ca
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> The `far_branch` attribute only ever takes the values 0 or 1, so make it
> a `no/yes` valued string attribute instead.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (far_branch): replace 0/1 with
> no/yes.
> (aarch64_bcond): handle renam
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> Extract the hardcoded values for the minimum PC-relative displacements
> into named constants and document them.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (BRANCH_LEN_P_128MiB): New constant.
> (BRANCH_LEN_N_128MiB): likewise.
> (BRA
Jennifer Schmitz writes:
> @@ -3698,6 +3706,24 @@ aarch64_partial_ptrue_length (rtx_vector_builder
> &builder,
>return vl;
> }
>
> +/* Return:
> +
> + * -1 if all bits of PRED are set
> + * N if PRED has N leading set bits followed by all clear bits
> + * 0 if PRED does not have any of
On Wed, May 7, 2025 at 1:01 PM Tomasz Kamiński wrote:
> Formatting code is extracted to _M_format_to function, that produced output
> to specified iterator. This function is now invoked either with __fc.out()
> directly (if width is not specified) or _Padding_sink::out().
>
> This avoid formattin
> On 7 May 2025, at 12:27, Karl Meakin wrote:
>
> Make the formatting of the RTL templates in the rules for branch
> instructions more consistent with each other.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (cbranch4): reformat.
> (cbranchcc4): likewise.
> (condjump): likewise.
> (*co
On Wed, May 7, 2025 at 3:50 AM Andrew Pinski wrote:
>
> While fixing up how rewrite_to_defined_overflow works, gcc.dg/Wrestrict-22.c
> started
> to fail. This is because `d p+ 2` would moved by LIM and then be rewritten
> not using
> pointer plus. The rewriting part is correct behavior. It only
On Wed, 30 Apr 2025 at 13:30, Luc Grosheintz wrote:
>
> This is the sixth interation and replaces:
> https://gcc.gnu.org/pipermail/libstdc++/2025-April/061190.html
>
> Changes since v5:
> * Removed superfluous braces.
> * Fixed std.cc.in
> * Fixed Copyright statement.
>
> Any layout related code ha
On Wed, May 7, 2025 at 3:55 AM Andrew Pinski wrote:
>
> Like the patch to phiopt (r15-4033-g1f619fe25925a5f7), this adds rewriting
> of VCE to gimple_with_undefined_signed_overflow/rewrite_to_defined_overflow.
> In the case of moving VCE of a bool from being conditional to unconditional,
> it need
Formatting code is extracted to _M_format_to function, that produced output
to specified iterator. This function is now invoked either with __fc.out()
directly (if width is not specified) or _Padding_sink::out().
This avoid formatting to temporary string if no padding is requested,
and minimize al
libstdc++-v3/ChangeLog:
* src/c++23/std.cc.in: Fix export for std::extents.
---
Lightly tested x86_64-linux. Pushed to trunk.
libstdc++-v3/src/c++23/std.cc.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libstdc++-v3/src/c++23/std.cc.in b/libstdc++-v3/src/c++23/std.cc.in
index
Thanks Jeff. I will rebase and update my patch. One question though, I
noticed that Pan's patch introduced a command-line parameter to tweak the
GR2VR cost; do we need something equivalent for FR2VR?
Yes, we need it in order to be able to test both paths, i.e. combining and not
combining. Als
For target VXE3 just emit a 128-bit comparison followed by a conditional
load. For targets prior VXE3, emulate the 128-bit comparison and make
use of a conditional load, too.
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_expand_cstoreti4): New
function.
* config/s390/s
Make the formatting of the RTL templates in the rules for branch
instructions more consistent with each other.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): reformat.
(cbranchcc4): likewise.
(condjump): likewise.
(*compare_condjump): likewise.
(aar
Add the `+cmpbr` option to enable the FEAT_CMPBR architectural
extension.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (cmpbr): new
option.
* config/aarch64/aarch64.h (TARGET_CMPBR): new macro.
* doc/invoke.texi (cmpbr): new option.
---
gcc/config
Extract the hardcoded values for the minimum PC-relative displacements
into named constants and document them.
gcc/ChangeLog:
* config/aarch64/aarch64.md (BRANCH_LEN_P_128MiB): New constant.
(BRANCH_LEN_N_128MiB): likewise.
(BRANCH_LEN_P_1MiB): likewise.
(BRANCH_LE
Commit the test file `cmpbr.c` before rules for generating the new
instructions are added, so that the changes in codegen are more obvious
in the next commit.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/cmpbr.c: New test.
---
gcc/testsuite/gcc.target/aarch64/cmpbr.c | 1378
The `far_branch` attribute only ever takes the values 0 or 1, so make it
a `no/yes` valued string attribute instead.
gcc/ChangeLog:
* config/aarch64/aarch64.md (far_branch): replace 0/1 with
no/yes.
(aarch64_bcond): handle rename.
(aarch64_cb1): likewise.
(
The rules for conditional branches were spread throughout `aarch64.md`.
Group them together so it is easier to understand how `cbranch4`
is lowered to RTL.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): move.
(*compare_condjump): likewise.
(aarch64_cb1): likewise.
Add rules for lowering `cbranch4` to CBB/CBH/CB when CMPBR
extension is enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): emit CMPBR
instructions if possible.
(cbranch4): new expand rule.
(aarch64_cb): likewise.
(aarch64_cb): likewise.
Give the `define_insn` rules used in lowering `cbranch4` to RTL
more descriptive and consistent names: from now on, each rule is named
after the AArch64 instruction that it generates. Also add comments to
document each rule.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): rename to
This patch series adds support for the CMPBR extension. It includes the
new `+cmpbr` option and rules to generate the new instructions when
lowering conditional branches.
Karl Meakin (8):
AArch64: place branch instruction rules together
AArch64: reformat branch instruction rules
AArch64: ren
Commit r16-427-g86627faec10da5 was using the new GLIBCXX_LANG_PUSH and
GLIBCXX_LANG_POP macros from a change that I haven't pushed yet,
resulting in changes to CXXFLAGS not being restored after the
GLIBCXX_ENABLE_BACKTRACE checks.
libstdc++-v3/ChangeLog:
PR libstdc++/120147
* acin
On 5/6/25 2:47 PM, Tomasz Kaminski wrote:
On Tue, May 6, 2025 at 1:39 PM Luc Grosheintz
wrote:
On 5/6/25 11:28 AM, Tomasz Kaminski wrote:
For better reference, here is illustration of the design I was thinking
about:
https://godbolt.org/z/7aTcM8fz4
I would also consider having left_mapping
On Tue, 6 May 2025, andre.simoesdiasvie...@arm.com wrote:
>
> Prunes code from the trivial true/false conditions.
- gcc_assert (vec_num == 1 || 1);
+ gcc_assert (vec_num == 1);
that looks like a now stronger assert, pruning would have removed
the assert instead?
if (ncopies > 1
- &&
On 06/05/2025 15:06, Jeff Law wrote:
diff --git gcc/config/riscv/riscv.cc gcc/config/riscv/riscv.cc
index 38f3ae7cd84..0f0cf04bdd9 100644
--- gcc/config/riscv/riscv.cc
+++ gcc/config/riscv/riscv.cc
@@ -3864,6 +3864,18 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
outer_code, int opno ATTRIBU
On Tue, 6 May 2025, andre.simoesdiasvie...@arm.com wrote:
> From: Andre Vieira
>
> Somewhat following richi's example of SLP cleanup, this patch series
> cleansup SLP code for vectorizable_reduction and friends.
>
> 1) fold trivially true/false conditions based on the slp_node argument
>
On Tue, 6 May 2025, andre.simoesdiasvie...@arm.com wrote:
>
> This removes the non-SLP paths from vectorizable_conversion and in the
> process eliminates uses of 'ncopies' and removes
> 'get_initial_def_for_reduction'. Not done anything about
> STMT_VINFO_VECTYPE as I'm not sure about its use
1 - 100 of 108 matches
Mail list logo
