Re: [PATCH 2/6] RISC-V: frm/mode-switch: remove TARGET_MODE_CONFLUENCE
On 5/14/25 12:06 PM, Vineet Gupta wrote: On 5/13/25 10:07, Vineet Gupta wrote: On 5/10/25 07:20, Jeff Law wrote: On 5/9/25 2:27 PM, Vineet Gupta wrote: This is effectively reverting e5d1f538bb7d "(RISC-V: Allow different dynamic floating point mode to be merged)" while retaining the testcase. The change itself is valid, however it obfuscates the deficiencies in current frm mode switching code. Also for a SPEC2017 -Ofast -march=rv64gcv build, it ends up generating net more FRM restores (writes) vs. the rest of this changeset. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_dynamic_frm_mode_p): Remove. (riscv_mode_confluence): Ditto. (TARGET_MODE_CONFLUENCE): Ditto. Unsure on this one. - /* FRM_DYN, FRM_DYN_CALL and FRM_DYN_EXIT are all compatible. - Although we already try to set the mode needed to FRM_DYN after a - function call, there are still some corner cases where both FRM_DYN - and FRM_DYN_CALL may appear on incoming edges. */ Do we have an understanding of these corner cases? That's my biggest worry with simply removing this code. Yes we do. [ ... ] Thanks. The more I think about, the more I think we're OK here.So I think this patch is good to go now. jeff
Re: [PATCH v1 0/1]RISC-V :The following changes enable P8700 MIPS processor for RISC-V.
On 5/12/25 5:20 AM, Umesh Kalappa wrote: --- gcc/config/riscv/mips-p8700.md | 139 +++ gcc/config/riscv/riscv-cores.def | 5 ++ gcc/config/riscv/riscv-opts.h| 3 +- gcc/config/riscv/riscv.cc| 22 + gcc/config/riscv/riscv.md| 3 +- 5 files changed, 170 insertions(+), 2 deletions(-) As I mentioned earlier, you still need to include an insn reservation for all the insn types mentioned in riscv.md -- even types not used by your design. The core problem is someone could ask for code generation using an extension you do not support on your design, but with your design's tuning. Concretely, someone could ask for the V extension via a -march flag but p8700 tuning via -mtune. That will trip an assert in the RISC-V backend. Go to riscv.md and fine this attribute: (define_attr "type" Every type listed in that attribute must have a mapping to a function unit in your scheduler model. (define_attr "type" As an example look at xiangshan.md and look for the reservation "xiangshan_alu_unknown". You need to so something similar for the p8700. Jeff
Re: [PATCH] libgcc SH: fix alignment for relaxation
On 5/10/25 11:12 AM, Quentin Boswank wrote: From 6462f1e6a2565c5d4756036d9bc2f39dce9bd768 Mon Sep 17 00:00:00 2001 From: QBos07 Date: Sat, 10 May 2025 16:56:28 + Subject: [PATCH] libgcc SH: fix alignment for relaxation when relaxation is enabled we can not infer the alignment from the position as that may change. This should not change non-relaxed builds as its allready aligned there. This was the missing piece to building an entire toolchain with -mrelax Credit goes to Oleg Endo: https://sourceware.org/bugzilla/show_bug.cgi? id=3298#c4 Given this is Oleg's work and his long history with the GCC project, I've committed this without deep analysis. Just fixed up some whitespace issues along the way. Thanks jeff
Re: [PATCH] ltmain.in: don't suppress output for PIC compilations
On 5/9/25 11:21 AM, Sam James wrote: Sam James writes: When working on xz, I set `-Werror=suggest-attribute=returns_nonnull`, and the build failed (as I expected it to), but with no visible error from the compiler. There's a mysterious '>/dev/null 2>&1' on the second line where liblzma_la-common.o is built without PIC. With -fPIC, IPA doesn't end up doing attribute discovery. Without it, it does. This behaviour is IMO undesirable and we should patch it out. This also affects building GCC and is particularly unfortunate if we hit an ICE. See https://bugs.gentoo.org/135865 and https://lists.gnu.org/archive/html/libtool-patches/2024-08/msg0.html. * ltmain.sh (func_mode_compile): Don't suppress stdout/stderr for no-PIC build. --- I've proposed this upstream and it ended up being bikeshedded a bit. I've been running this locally for nearly a year now and on IRC, others expressed interest in this, as it causes pain when debugging. ping Well, ideally we'd not deviate any more than absolutely necessary from upstream. Is there any final conclusion from the upstream discussion? jeff
[patch, fortran] PR120049 - ICE when using IS_C_ASSOCIATED ()
Hello all,
The attached patch revises the logic of the checks in
gfc_check_c_associated to handle previous cases that ICE'ed as seen in
the PR. There are multiple gotchas in these cases, particularly with the
optional c_ptr_2 argument.
I factored the logic into two new helper functions. This helps to see
what is happening and allows the c_ptr_1 checks to be performed
separately in the event the c_ptr_2 checks succeed.
In gfc_typename we did not handle the BT_VOID case which occurs in some
of the error conditions. I thought to possibly let it fall through to
"UNKNOWN". As it is with the patch I return "VOID".
I added a new test case.
I want to add Steve as Co-author as soon as I figure out how to do that
with the git machinery.
Regression tested on x86_64. OK for trunk and eventual backport to 15?
Regards,
Jerry
Author: Jerry DeLisle
Date: Sat May 17 09:45:14 2025 -0700
Fortran: Fix c_associated argument checks.
PR fortran/120049
gcc/fortran/ChangeLog:
* check.cc (gfc_check_c_associated): Use new helper functions.
Only call check_c_ptr_1 if optional c_ptr_2 tests succeed.
(check_c_ptr_1): Handle only c_ptr_1 checks.
(check_c_ptr_2): Expand checks for c_ptr_2 and handles cases
where there is no derived pointer in the gfc_expr and check
the inmod_sym_id only if it exists.
* misc.cc (gfc_typename): Handle the case for BT_VOID rather
than throw an internal error.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr120049_2.f90: New test.
commit a8ecfef37b221fc828ab8a91793fbdef3c56509b
Author: Jerry DeLisle
Date: Sat May 17 09:45:14 2025 -0700
Fortran: Fix c_associated argument checks.
PR fortran/120049
gcc/fortran/ChangeLog:
* check.cc (gfc_check_c_associated): Use new helper functions.
Only call check_c_ptr_1 if optional c_ptr_2 tests succeed.
(check_c_ptr_1): Handle only c_ptr_1 checks.
(check_c_ptr_2): Expand checks for c_ptr_2 and handles cases
where there is no derived pointer in the gfc_expr and check
the inmod_sym_id only if it exists.
* misc.cc (gfc_typename): Handle the case for BT_VOID rather
than throw an internal error.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr120049_2.f90: New test.
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index f02a2a33897..ab2828b0f70 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -5952,49 +5952,79 @@ gfc_check_c_sizeof (gfc_expr *arg)
}
-bool
-gfc_check_c_associated (gfc_expr *c_ptr_1, gfc_expr *c_ptr_2)
+/* Helper functions check_c_ptr_1 and check_c_ptr_2
+ used in gfc_check_c_associated. */
+
+static inline
+bool check_c_ptr_1 (gfc_expr *c_ptr_1)
{
- if (c_ptr_1)
-{
- if (c_ptr_1->expr_type == EXPR_FUNCTION && c_ptr_1->ts.type == BT_VOID)
- return true;
+ if (c_ptr_1->expr_type == EXPR_FUNCTION && c_ptr_1->ts.type == BT_VOID)
+return true;
- if (c_ptr_1->ts.type != BT_DERIVED
- || c_ptr_1->ts.u.derived->from_intmod != INTMOD_ISO_C_BINDING
- || (c_ptr_1->ts.u.derived->intmod_sym_id != ISOCBINDING_PTR
- && c_ptr_1->ts.u.derived->intmod_sym_id != ISOCBINDING_FUNPTR))
- {
- gfc_error ("Argument C_PTR_1 at %L to C_ASSOCIATED shall have the "
- "type TYPE(C_PTR) or TYPE(C_FUNPTR)", &c_ptr_1->where);
- return false;
- }
+ if (c_ptr_1->ts.type != BT_DERIVED
+ || c_ptr_1->ts.u.derived->from_intmod != INTMOD_ISO_C_BINDING
+ || (c_ptr_1->ts.u.derived->intmod_sym_id != ISOCBINDING_PTR
+ && c_ptr_1->ts.u.derived->intmod_sym_id != ISOCBINDING_FUNPTR))
+{
+ gfc_error ("Argument C_PTR_1 at %L to C_ASSOCIATED shall have the "
+ "type TYPE(C_PTR) or TYPE(C_FUNPTR)", &c_ptr_1->where);
+ return false;
}
- if (!scalar_check (c_ptr_1, 0))
-return false;
+ if (scalar_check (c_ptr_1, 0))
+return true;
- if (c_ptr_2)
+ return false;
+}
+
+static inline
+bool check_c_ptr_2 (gfc_expr *c_ptr_1, gfc_expr *c_ptr_2)
+{
+ if ((c_ptr_2->expr_type == EXPR_FUNCTION)
+ && (c_ptr_2->ts.type == BT_VOID))
+return true;
+
+ if (c_ptr_2->ts.type == BT_DERIVED)
{
- if (c_ptr_2->expr_type == EXPR_FUNCTION && c_ptr_2->ts.type == BT_VOID)
- return true;
+ if (c_ptr_2->ts.u.derived->from_intmod != INTMOD_ISO_C_BINDING)
+ goto check_2_error;
- if (c_ptr_2->ts.type != BT_DERIVED
- || c_ptr_2->ts.u.derived->from_intmod != INTMOD_ISO_C_BINDING
- || (c_ptr_1->ts.u.derived->intmod_sym_id
+ if (c_ptr_1->ts.type == BT_DERIVED
+ && (c_ptr_1->ts.u.derived->intmod_sym_id
!= c_ptr_2->ts.u.derived->intmod_sym_id))
- {
- gfc_error ("Argument C_PTR_2 at %L to C_ASSOCIATED shall have the "
- "same type as C_PTR_1: %s instead of %s", &c_ptr_1->where,
- gfc_typename (&c_ptr_1->ts), gfc_typename (&c_ptr_2->ts));
- return false;
- }
+
Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
On 5/14/25 2:22 PM, Joseph Myers wrote: On Wed, 14 May 2025, Yuao Ma wrote: Hi Joseph, I have updated the patch based on your review comments. I added the newly introduced builtin to extend.texi and mentioned the PR in the commit message. Could you please take another look when you have a moment? This version is OK in the absence of objections within 48 hours. I've pushed this to the trunk (two commits, I accidentally pushed the first version without the doc changes, then had to follow that up with the doc change). jeff
[to-be-committed][RISC-V] Fix ICE due to bogus use of gen_rtvec
Found this while setting up the risc-v coordination branch off of gcc-15. Not sure why I didn't use rtvec_alloc directly here since we're going to initialize the whole vector ourselves. Using gen_rtvec was just wrong as it's walking down a non-existent varargs list. Under the "right" circumstances it can walk off a page and fault. This was seen with a test already in the testsuite (I forget which test), so no new regression test. Tested in my tester and verified the failure on the coordination branch is resolved a well. Waiting on pre-commit CI to render a verdict. jeff gcc/ * config/riscv/riscv-vect-permconst.cc (vector_permconst:process_bb): Use rtvec_alloc, not gen_rtvec since we don't want/need to initialize the vector. diff --git a/gcc/config/riscv/riscv-vect-permconst.cc b/gcc/config/riscv/riscv-vect-permconst.cc index 8e13cf8d558..087f26aea8a 100644 --- a/gcc/config/riscv/riscv-vect-permconst.cc +++ b/gcc/config/riscv/riscv-vect-permconst.cc @@ -227,7 +227,7 @@ vector_permconst::process_bb (basic_block bb) normalize it to zero. XXX This violates structure sharing conventions. */ - rtvec_def *nvec = gen_rtvec (CONST_VECTOR_NUNITS (cvec).to_constant ()); + rtvec_def *nvec = rtvec_alloc (CONST_VECTOR_NUNITS (cvec).to_constant ()); for (i = 0; i < CONST_VECTOR_NUNITS (cvec).to_constant (); i++) nvec->elem[i] = GEN_INT (INTVAL (CONST_VECTOR_ELT (cvec, i)) - bias);
Re: [PATCH] RISC-V: Support Zilsd code gen
On 5/14/25 9:14 PM, Kito Cheng wrote:
This commit adds the code gen support for Zilsd, which is a
newly added extension for RISC-V. The Zilsd extension allows
for loading and storing 64-bit values using even-odd register
pairs.
We only try to do miminal code gen support for that, which means only
use the new instructions when the load store is 64 bits data, we can use
that to optimize the code gen of memcpy/memset/memmove and also the
prologue and epilogue of functions, but I think that probably should be
done in a follow up patch.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_move): Handle
load/store with odd-even reg pair.
(riscv_split_64bit_move_p): Don't split load/store if zilsd enabled.
(riscv_hard_regno_mode_ok): Only allow even reg can be used for
64 bits mode for zilsd.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zilsd-code-gen.c: New test.
---
gcc/config/riscv/riscv.cc | 38 +++
.../gcc.target/riscv/zilsd-code-gen.c | 18 +
2 files changed, 56 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/zilsd-code-gen.c
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index d28aee4b439..f5ee3ce9034 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3742,6 +3742,25 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx
src)
return true;
}
+ if (TARGET_ZILSD
+ && (GET_MODE_UNIT_SIZE (mode) == (UNITS_PER_WORD * 2))
+ && ((REG_P (dest) && MEM_P (src))
+ || (MEM_P (dest) && REG_P (src
+{
+ rtx reg = REG_P (dest) ? dest : src;
+ unsigned regno = REGNO (reg);
+ /* ZILSD require even-odd register pair, let RA to
+fix the constraint if the reg is hard reg and not even reg. */
+ if ((regno < FIRST_PSEUDO_REGISTER)
+ && (regno % 2) != 0)
+ {
+ rtx tmp = gen_reg_rtx (GET_MODE (reg));
+ emit_move_insn (tmp, src);
+ emit_move_insn (dest, tmp);
+ return true;
+ }
AFAICT this will only ever be called by the various movXX expanders, but
those can be called during IRA, so we probably should a bit safer here.
We could either add can_create_pseudo_p to the guard or we could assert
it's true. The former would be most appropriate if the rest of the code
will still do the right thing, the latter if not.
@@ -9799,6 +9831,12 @@ riscv_hard_regno_mode_ok (unsigned int regno,
machine_mode mode)
if (riscv_v_ext_mode_p (mode))
return false;
+ /* Zilsd require load/store with even-odd reg pair. */
+ if (TARGET_ZILSD
+ && (GET_MODE_UNIT_SIZE (mode) == (UNITS_PER_WORD * 2))
+ && ((regno % 2) != 0))
+ return false;
Do you need to check that you're working with a GPR here?
At a higher level, my understanding is zilsd is only for rv32. Do we
want to be extra safe and check TARGET_32BIT alongside TARGET_ZILSD?
Take the action you feel is appropriate on the above issues and the
result is pre-approved for the trunk.
Thanks,
jeff
Re: [PATCH] RISC-V: Add new operand constraint: cR
On 5/14/25 9:20 PM, Kito Cheng wrote: This commit introduces a new operand constraint `cR` for the RISC-V architecture, which allows the use of an even-odd RVC general purpose register (x8-x15) in inline asm. Ref: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/102 gcc/ChangeLog: * config/riscv/constraints.md (cR): New constraint. * doc/md.texi (Machine Constraints::RISC-V): Document the new cR constraint. gcc/testsuite/ChangeLog: * gcc.target/riscv/constraint-cR.c: New test case. OK jeff
Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
On Wed, May 14, 2025 at 02:22:23PM +, Yuao Ma wrote: > If approved, I suggest committing this foundational change first. Constant > folding for these builtins will be addressed in subsequent patches. Note, not just constant folding is needed, but I think the builtins should be handled in tree-call-cdce.cc (can_test_argument_range, edom_only_function, get_no_error_domain). Jakub
[PATCH] c++/modules: Fix ICE on merge of instantiation with partial spec [PR120013]
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
-- >8 --
When we import a pending instantiation that matches an existing partial
specialisation, we don't find the slot in the entity map because for
partial specialisations we register the TEMPLATE_DECL but for normal
implicit instantiations we instead register the inner TYPE_DECL.
Because the DECL_MODULE_ENTITY_P flag is set we correctly realise that
it is in the entity map, but ICE when attempting to use that slot in
partition handling.
This patch fixes the issue by detecting this case and instead looking
for the slot for the TEMPLATE_DECL. It doesn't matter that we never add
a slot for the inner decl because we're about to discard it anyway.
PR c++/120013
gcc/cp/ChangeLog:
* module.cc (trees_in::install_entity): Handle re-registering
the inner TYPE_DECL of a partial specialisation.
gcc/testsuite/ChangeLog:
* g++.dg/modules/partial-8.h: New test.
* g++.dg/modules/partial-8_a.C: New test.
* g++.dg/modules/partial-8_b.C: New test.
* g++.dg/modules/partial-8_c.C: New test.
* g++.dg/modules/partial-8_d.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/cp/module.cc | 41 --
gcc/testsuite/g++.dg/modules/partial-8.h | 8 +
gcc/testsuite/g++.dg/modules/partial-8_a.C | 10 ++
gcc/testsuite/g++.dg/modules/partial-8_b.C | 8 +
gcc/testsuite/g++.dg/modules/partial-8_c.C | 7
gcc/testsuite/g++.dg/modules/partial-8_d.C | 9 +
6 files changed, 72 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/partial-8.h
create mode 100644 gcc/testsuite/g++.dg/modules/partial-8_a.C
create mode 100644 gcc/testsuite/g++.dg/modules/partial-8_b.C
create mode 100644 gcc/testsuite/g++.dg/modules/partial-8_c.C
create mode 100644 gcc/testsuite/g++.dg/modules/partial-8_d.C
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 200e1c2deb3..f728275612e 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -8083,18 +8083,37 @@ trees_in::install_entity (tree decl)
gcc_checking_assert (!existed);
slot = ident;
}
- else if (state->is_partition ())
-{
- /* The decl is already in the entity map, but we see it again now from a
-partition: we want to overwrite if the original decl wasn't also from
-a (possibly different) partition. Otherwise, for things like template
-instantiations, make_dependency might not realise that this is also
-provided from a partition and should be considered part of this module
-(and thus always emitted into the primary interface's CMI). */
+ else
+{
unsigned *slot = entity_map->get (DECL_UID (decl));
- module_state *imp = import_entity_module (*slot);
- if (!imp->is_partition ())
- *slot = ident;
+
+ /* The entity must be in the entity map already. However, DECL may
+be the DECL_TEMPLATE_RESULT of an existing partial specialisation
+if we matched it while streaming another instantiation; in this
+case we already registered that TEMPLATE_DECL. */
+ if (!slot)
+ {
+ tree type = TREE_TYPE (decl);
+ gcc_checking_assert (TREE_CODE (decl) == TYPE_DECL
+ && CLASS_TYPE_P (type)
+ && CLASSTYPE_TEMPLATE_SPECIALIZATION (type));
+ slot = entity_map->get (DECL_UID (CLASSTYPE_TI_TEMPLATE (type)));
+ }
+ gcc_checking_assert (slot);
+
+ if (state->is_partition ())
+ {
+ /* The decl is already in the entity map, but we see it again now
+from a partition: we want to overwrite if the original decl
+wasn't also from a (possibly different) partition. Otherwise,
+for things like template instantiations, make_dependency might
+not realise that this is also provided from a partition and
+should be considered part of this module (and thus always
+emitted into the primary interface's CMI). */
+ module_state *imp = import_entity_module (*slot);
+ if (!imp->is_partition ())
+ *slot = ident;
+ }
}
return true;
diff --git a/gcc/testsuite/g++.dg/modules/partial-8.h
b/gcc/testsuite/g++.dg/modules/partial-8.h
new file mode 100644
index 000..d9a83a83e54
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/partial-8.h
@@ -0,0 +1,8 @@
+// PR c++/120013
+
+template struct tuple_element;
+template tuple_element get(T);
+
+// This case wasn't an issue for the PR, but worth double-checking
+template constexpr int var = 123;
+template void foo(T, int = var);
diff --git a/gcc/testsuite/g++.dg/modules/partial-8_a.C
b/gcc/testsuite/g++.dg/modules/partial-8_a.C
new file mode 100644
index 000..d6848c78360
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/partial-8_a.C
@@ -0,0 +1,10 @@
+// PR c++/120013
+// { dg-additional-options "-fmo
Re: [PATCH 0/6] RISC-V: frm state-machine improvements
On 5/10/25 9:46 PM, Vineet Gupta wrote:
Frankly I'm surprised we need FRM adjustments as much as we do, though
presumably there's some builtin or somesuch that we need to twiddle FRM
to implement and as a result if the builtin ever gets used it leads to
FRM games. But it still seems high.
The mode switching state machine executes even when there are just function
calls and returns and as we saw if there are bugs there, it just misfires.
e.g. The frm restore in 5/6 was kicking in even when static RM was never seen in
the function. Combined with our early preemptive save, we can get into a state
where both save/restore end up getting generated.
We ideally need a pre-scan of cfun for any RM changes, frm updates etc and if
none just exit early.
I don't know if that is what we would consider.
Possibly. Usually this kind of prescan would be an attempt to improve
compile-times. I wouldn't use it to work around implementation issues
generating too many FRM adjustments.
For example, what does xz do that
triggers any FRM adjustments, even statically?!?
__letf2 1 0 0
__printf_fp_buffer_1.isra.0 1 0 0
__printf_fphex_buffer 3 0 0
__unordtf2 1 0 0
Those are glibc routines for math emulation routines which are written using
templatized macros.
One of those FP_INIT_ROUNDMODE uses inline asm to do a FRM read - we need a
builtin for compiler to optimize away some of those reads.
# define FP_INIT_ROUNDMODE \
do { \
__asm__ volatile ("frrm %0" : "=r" (_frm)); \
} while (0)
Ugh.If we look at glibc I don't immediately see where we'd be
getting uses of FP_INIT_ROUNDMODE except via sqrt or 128-bit FP
emulation. I guess we could have 128-bit FP support inside some of the
*printf code, which could trigger pulling in letf2 and friends through
various non-obvious ways.
So let's set this question aside. That's enough to satisfy my curiosity
about the potential oddball ways we can get FRM adjustments.
Jeff
Re: Proposal: File-backed allocations support for ASan reducing dependency on system memory.
On Sat, May 17, 2025 at 5:04 AM Archit Jindal wrote: > > Hi GCC community, > > I'm working on a change to allow ASan to use file-backed memory allocations > for both the Primary and Secondary allocators. This would be particularly > helpful on systems with limited system memory, where ASan’s current use of > private anonymous mmaps puts direct pressure on available system memory. Some > systems may have other directories available that can be used by making > allocations to be file backed in those directories thus saving the system > memory. > > Has there been any prior work or discussion in this area? If not, I'm happy > to proceed with preparing and submitting a patch soon. GCC is not where the main development of the library used for ASAN happens. GCC pulls the asan library from the LLVM source base so you might want to work there first. If this is a compiler only change then GCC is the right place but I suspect this is a library change so LLVM is where the upstream sources are located. GCC tries to only have a few local patches to the asan library sources too. This is referenced in libsanitizer/README.gcc too: All non-trivial changes, functionality improvements, etc. should go through the upstream tree first and then be merged back to the GCC tree. Thanks, Andrew Pinski > > Thanks, > Archit
[PATCH] cobol: fix cbl_filed_t symbol error generation
Hi, I meet that symbol '__gg__space' generated '\x7f\x7fgg\x7f\x7fspace' in asm. I learn that _tolower to give the expected results, __isascii and isupper must both return nonzero. So consider use the TOLOWER in safe-ctype.h. gcc/cobol: * genapi.cc: replace _tolower with TOLOWER --- gcc/cobol/genapi.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc index c8911f964..7f0a07262 100644 --- a/gcc/cobol/genapi.cc +++ b/gcc/cobol/genapi.cc @@ -15877,7 +15877,7 @@ psa_global(cbl_field_t *new_var) strcat(ach, new_var->name); for(size_t i=0; iname); for(size_t i=0; i
Re: [PATCH 3/3] genemit: Use a byte encoding to generate insns
> Am 16.05.2025 um 19:37 schrieb Richard Sandiford :
>
> genemit has traditionally used open-coded gen_rtx_FOO sequences
> to build up the instruction pattern. This is now the source of
> quite a bit of bloat in the binary, and also a source of slow
> compile times.
>
> Two obvious ways of trying to deal with this are:
>
> (1) Try to identify rtxes that have a similar form and use shared
>routines to generate rtxes of that form.
>
> (2) Use a static table to encode the rtx and call a common routine
>to expand it.
>
> I did briefly look at (1). However, it's more complex than (2),
> and I think suffers from being the worst of both worlds, for reasons
> that I'll explain below. This patch therefore does (2).
>
> In theory, one of the advantages of open-coding the calls to
> gen_rtx_FOO is that the rtx can be populated using stores of known
> constants (for the rtx code, mode, unspec number, etc). However,
> the time spent constructing an rtx is likely to be dominated by
> the call to rtx_alloc, rather than by the stores to the fields.
>
> Option (1) above loses this advantage of storing constants.
> The shared routines would parameterise an rtx according to things
> like the modes on the rtx and its suboperands, so the code would
> need to fetch the parameters. In a sense, the rtx structure would
> be open-coded but the parameters would be table-encoded (albeit
> in a simple way).
>
> The expansion code also shouldn't be particularly hot. Anything that
> treats expand/discard cycles as very cheap would be misconceived,
> since each discarded expansion generates garbage memory that needs
> to be cleaned up later.
>
> Option (2) turns out to be pretty simple -- certainly simpler
> than (1) -- and seems to give a reasonable saving. Some numbers,
> all for --enable-checking=yes,rtl,extra:
>
> [A] size of the @progbits sections in insn-emit-*.o, new / old
> [B] size of the load segments in cc1, new / old
> [C] time to compile a typical insn-emit*.cc, new / old
>
> Target [A] [B] [C]
>
> native aarch64 0.5627 0.9585 0.5677
> native x86_64 0.5925 0.9467 0.6377
> aarch64-x-riscv64 0. 0.9066 0.2762
Nice. So how large is the tables, aka what’s the effect on .rodata of cc1?
One nice thing about the old way is that you can set breakpoints on the gen_*
routines. Can the tables be annotated with comments so it’s easy to lookup the
part for a particular .md entry and is there a place to break on conditional on
some table index to simulate the old way?
Richard
> To get an idea of the effect on the final compiler, I tried compiling
> fold-const.ii with -O0 (no -g), since that should give any slowdown
> less room to hide. I couldn't measure any difference in compile time
> before or after the patch for any of the three variants above.
>
> gcc/
>* gensupport.h (needs_barrier_p): Delete.
>* gensupport.cc (needs_barrier_p): Likewise.
>* rtl.h (always_void_p): Return true for PC, RETURN and SIMPLE_RETURN.
>(expand_opcode): New enum class.
>(expand_rtx, complete_seq): Declare.
>* emit-rtl.cc (rtx_expander): New class.
>(expand_rtx, complete_seq): New functions.
>* gengenrtl.cc (special_rtx, excluded_rtx): Add a cross-reference
>comment.
>* genemit.cc (FIRST_CODE): New constant.
>(print_code): Delete.
>(generator::file, generator::used, generator::sequence_type): Delete.
>(generator::bytes): New member variable.
>(generator::generator): Update accordingly.
>(generator::gen_rtx_scratch): Delete.
>(generator::add_uint, generator::add_opcode, generator::add_code)
>(generator::add_match_operator, generator::add_exp)
>(generator::add_vec, generator::gen_table): New member functions.
>(generator::gen_exp): Rewrite to use a bytecode expansion.
>(generator::gen_emit_seq): Likewise.
>(start_gen_insn): Return the C++ expression for the operands array.
>(gen_insn, gen_expand, gen_split): Update callers accordingly.
>(emit_c_code): Remove use of _val.
> ---
> gcc/emit-rtl.cc | 292 ++
> gcc/genemit.cc| 346 +++---
> gcc/gengenrtl.cc | 10 +-
> gcc/gensupport.cc | 10 --
> gcc/gensupport.h | 1 -
> gcc/rtl.h | 42 +-
> 6 files changed, 480 insertions(+), 221 deletions(-)
>
> diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc
> index fc7b6c7e297..57021fbb5ff 100644
> --- a/gcc/emit-rtl.cc
> +++ b/gcc/emit-rtl.cc
> @@ -64,6 +64,7 @@ along with GCC; see the file COPYING3. If not see
> #include "gimple.h"
> #include "gimple-ssa.h"
> #include "gimplify.h"
> +#include "bbitmap.h"
>
> struct target_rtl default_target_rtl;
> #if SWITCHABLE_TARGET
> @@ -6777,6 +6778,297 @@ gen_int_shift_amount (machine_mode, poly_int64 value)
> return gen_int_mode (value, shift_mode);
> }
>
> +namespace {
> +/* Helper class for expanding an rtx
Proposal: File-backed allocations support for ASan reducing dependency on system memory.
Hi GCC community, I'm working on a change to allow ASan to use file-backed memory allocations for both the Primary and Secondary allocators. This would be particularly helpful on systems with limited system memory, where ASan’s current use of private anonymous mmaps puts direct pressure on available system memory. Some systems may have other directories available that can be used by making allocations to be file backed in those directories thus saving the system memory. Has there been any prior work or discussion in this area? If not, I'm happy to proceed with preparing and submitting a patch soon. Thanks, Archit
Re: [PATCH] libgcc SH: fix alignment for relaxation
On Sat, 2025-05-17 at 10:55 -0600, Jeff Law wrote: > > On 5/10/25 11:12 AM, Quentin Boswank wrote: > > From 6462f1e6a2565c5d4756036d9bc2f39dce9bd768 Mon Sep 17 00:00:00 2001 > > From: QBos07 > > Date: Sat, 10 May 2025 16:56:28 + > > Subject: [PATCH] libgcc SH: fix alignment for relaxation > > > > when relaxation is enabled we can not infer the alignment > > from the position as that may change. This should not change > > non-relaxed builds as its allready aligned there. This was > > the missing piece to building an entire toolchain with -mrelax > > > > Credit goes to Oleg Endo: https://sourceware.org/bugzilla/show_bug.cgi? > > id=3298#c4 > Given this is Oleg's work and his long history with the GCC project, > I've committed this without deep analysis. Just fixed up some > whitespace issues along the way. > Thanks, Jeff! I was going to pick this up and commit it these days. I will try to respond to this kind of thing earlier in the future. I haven't done any excessive testing on those changes, but it looks trivial. Worst thing that can happen is libgcc gains a few bytes in size. Thanks, Quentin for digging in the SH relaxation issues! Best regards, Oleg Endo
Re: [PATCH 1/9] nds32: Avoid accessing beyond the operands[] array
On 5/16/25 11:32 AM, Jeff Law wrote: On 5/16/25 11:21 AM, Richard Sandiford wrote: This pattern used operands[2] to hold the shift amount, even though the pattern doesn't have an operand 2 (not even as a match_dup). This caused a build failure with -Werror: array subscript 2 is above array bounds of ‘rtx_def* [2]’ gcc/ * config/nds32/nds32-intrinsic.md (unspec_get_pending_int): Use a local variable instead of operands[2]. Obviously OK. IMHO you should just commit this kind of fix. You might consider looking at pr100837 which looks like it'd be fixed by this change. jeff
[PATCH] phiopt: Use mark_lhs_in_seq_for_dce instead of doing it inline
Right now phiopt has the same code as mark_lhs_in_seq_for_dce
inlined into match_simplify_replacement. Instead let's use the
function in gimple-fold that does the same thing.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* gimple-fold.cc (mark_lhs_in_seq_for_dce): Make
non-static.
* gimple-fold.h (mark_lhs_in_seq_for_dce): Declare.
* tree-ssa-phiopt.cc (match_simplify_replacement): Use
mark_lhs_in_seq_for_dce instead of manually looping.
Signed-off-by: Andrew Pinski
---
gcc/gimple-fold.cc | 2 +-
gcc/gimple-fold.h | 1 +
gcc/tree-ssa-phiopt.cc | 13 +++--
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index b74fb8bb50c..0f437616d77 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -6020,7 +6020,7 @@ has_use_on_stmt (tree name, gimple *stmt)
/* Add the lhs of each statement of SEQ to DCE_WORKLIST. */
-static void
+void
mark_lhs_in_seq_for_dce (bitmap dce_worklist, gimple_seq seq)
{
if (!dce_worklist)
diff --git a/gcc/gimple-fold.h b/gcc/gimple-fold.h
index afecbb8ceef..8b1e246b0c0 100644
--- a/gcc/gimple-fold.h
+++ b/gcc/gimple-fold.h
@@ -264,6 +264,7 @@ gimple_build_round_up (gimple_seq *seq, tree type, tree
old_size,
extern bool gimple_stmt_nonnegative_warnv_p (gimple *, bool *, int = 0);
extern bool gimple_stmt_integer_valued_real_p (gimple *, int = 0);
+extern void mark_lhs_in_seq_for_dce (bitmap, gimple_seq);
/* In gimple-match.cc. */
extern tree gimple_simplify (enum tree_code, tree, tree,
diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
index 9724040fc3d..8c5908e5bff 100644
--- a/gcc/tree-ssa-phiopt.cc
+++ b/gcc/tree-ssa-phiopt.cc
@@ -1001,16 +1001,9 @@ match_simplify_replacement (basic_block cond_bb,
basic_block middle_bb,
if (seq)
{
// Mark the lhs of the new statements maybe for dce
- gimple_stmt_iterator gsi1 = gsi_start (seq);
- for (; !gsi_end_p (gsi1); gsi_next (&gsi1))
- {
- gimple *stmt = gsi_stmt (gsi1);
- tree name = gimple_get_lhs (stmt);
- if (name && TREE_CODE (name) == SSA_NAME)
- bitmap_set_bit (exprs_maybe_dce, SSA_NAME_VERSION (name));
- }
-gsi_insert_seq_before (&gsi, seq, GSI_CONTINUE_LINKING);
- }
+ mark_lhs_in_seq_for_dce (exprs_maybe_dce, seq);
+ gsi_insert_seq_before (&gsi, seq, GSI_CONTINUE_LINKING);
+}
/* If there was a statement to move, move it to right before
the original conditional. */
--
2.43.0
