Jerry DeLisle [Fri, 5 Jun 2026 20:19:58 +0000 (13:19 -0700)]
fortran: ALLOCATE of parameterized derived-type array initializes only first element
gfc_trans_allocate passed expr->rank to gfc_allocate_pdt_comp and
gfc_deallocate_pdt_comp for array allocations of parameterized derived
types. For an allocate-shape-spec expression (e.g. "allocate(a(n))"),
expr->rank is 0 even though the symbol is an array; the rank is carried on
the symbol rather than on the allocate expression. With rank 0 the loop
that initialises each element's allocatable components ran zero times, so
only element zero was initialised. Subsequent accesses to elements 1..N-1
used garbage pointers and crashed.
Fix: when se.expr is a GFC array descriptor, take the rank from the
descriptor via GFC_TYPE_ARRAY_RANK instead of from expr->rank. Apply the
same correction to the CLASS path and to the matching deallocate calls in
gfc_trans_deallocate.
Assisted by: Claude Sonnet 4.6
PR fortran/125534
gcc/fortran/ChangeLog:
* trans-stmt.cc (gfc_trans_allocate): Use GFC_TYPE_ARRAY_RANK from
the GFC descriptor type when se.expr is a descriptor, rather than
expr->rank, for the rank passed to gfc_allocate_pdt_comp. Apply
the same fix to the CLASS path.
(gfc_trans_deallocate): Likewise for gfc_deallocate_pdt_comp.
Andrew Burgess [Tue, 14 Apr 2026 10:20:55 +0000 (11:20 +0100)]
libiberty: avoid exponential back reference issue in D demangler
We had a bug reported against Fedora GDB where a particular D symbol
was causing an out of memory error. I believe that the symbol is
valid (see below for details), but I'm not sure if it is possible to
successfully demangle it, so this patch aims to avoid the out of
memory error.
The symbol in question can be found in the newly added test case.
The symbol in question makes heavy use of back references to compress
the demangled string. The back references are nested to ~57 levels of
depth, but that's not the real problem. The real issue is that many
of these nested levels of back reference refer, multiple times, to the
earlier levels. If the innermost level of back reference results in a
1 byte string (it doesn't, the resulting string is longer), and each
level of back reference refers to the next inner level just twice
(it's usually more), then by 30 levels the resulting string is 1G in
size. This is an absolute lower bound of the required size. By 40
levels we have, at a minimum, a 1024G string.
My plan for fixing this is to count nested back references, resetting
the counter at the "top level", i.e. at a nesting depth of 0. If we
see too many (based on some arbitrary limit) nested back references,
then we'll abort the demangle, and return NULL.
Now, this isn't purely a recursion problem. The theoretical maximum
depth is just 57, but the problem is the cumulative work that ends up
being done due to the exponential growth of each level referencing the
earlier levels.
However, I wanted to avoid adding a separate flag for this to the
demangler, and I figured that this problem is close enough to
recursion that we can reuse the existing recursion limit flag here
too.
And so, the solution I propose is that each time we encounter a nested
back reference we increment a counter. If we see more than
DEMANGLE_RECURSION_LIMIT nested back references then we abort the
demangle, even if these back references are not all nested one inside
the other. A second counter tracks the current depth of nested back
references. If we are at depth 0 then the first counter, the nested
back reference counter, is reset back to 0.
With this fix in place, when passed the problematic mangled symbol,
the demangler returns NULL. The c++filt tool will just re-print the
mangled symbol. The D demangler tests are extended to include the
problematic symbol.
Side note: I mentioned above that I think this symbol is valid. To
reach this conclusion I implemented a hack where I cached the result
of evaluating a back reference. The first time a back reference is
processed I actually processed the input to check the string demangled
correctly, but I never added this demangled string to the final
result. The second time the same back reference is requested, I spot
the cached entry and return, again adding nothing to the result string.
Thus, the final result string contains only the content from the top
level. None of the back referenced content is included. The input
string (mangled) is 2695 bytes, while the output string was 42kB, but
this skips all the nested content. However, we did get to the end of
the input string, and returned a non-NULL value. The full string
would be multiple GB given the exponential growth.
* d-demangle.c (struct dlang_info::options): New field,
carries options passed to the demangler.
(struct dlang_info::num_backrefs): Count total number of back
referenced types that have been processed.
(struct dlang_info::backref_depth): Count the depth of
recursive back references.
(dlang_type_backref): Track recursive back reference depth,
and the total number of back references encountered. Bail out
early if the total number gets too high.
(dlang_demangle_init_info): Initialise new 'struct dlang_info'
fields.
(dlang_demangle): Pass demangler options to
dlang_demangle_init_info.
* testsuite/d-demangle-expected: Add new test.
It's easy to forget that i386 check-function-bodies tests require:
{ dg-add-options check_function_bodies }
This patch makes:
{ dg-final { check-function-bodies ... } }
add the options automatically.
This means that the dg-final must come after the final dg-options (like
the dg-add-options must). That already seemed to be the case for every
test in the patch.
gcc/
* doc/sourcebuild.texi: Document that check-function-bodies
automatically adds the check_function_bodies options.
Paul Thomas [Sun, 7 Jun 2026 08:11:13 +0000 (09:11 +0100)]
Fortran: Fix regression caused by first patch [PR125527]
2026-06-07 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/125527
* class.cc (gfc_find_derived_vtab): Stash module namespace and
use it as the last place to search for the vtab before building
a new one.
Paul Thomas [Sun, 7 Jun 2026 14:11:20 +0000 (15:11 +0100)]
Fortran: require MODULE prefix for separate module procedures [PR121379]
set_syms_host_assoc clears the 'external' attribute on module procedures
when making them accessible via host association in a submodule. The
existing check in get_proc_name for a missing MODULE prefix used
'sym->attr.external' as a guard, so the diagnostic was silently
suppressed and gfortran accepted — and incorrectly linked — a bare
function definition as if it were a valid separate module procedure.
Replace 'sym->attr.external' with 'sym->attr.module_procedure', which is
not cleared by set_syms_host_assoc, to restore the intended diagnostic.
Also update the error message to be clearer about what is required.
Both errors have been corrected to avoid returning any value, thereby
avoiding an error cascade. After all, these are OK for further
processing and argument mismatches etc. can be caught. Additionally, a
number of existing testcases contained this error. In order to avoid
masking the intended fix, this has been corrected in all cases.
2026-06-07 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/121379
* decl.cc (get_proc_name): Use module_procedure attr. instead
of external to guard the missing-MODULE-prefix diagnostic. Use
gfc_error_now and do not return, so that an error cascade does
not occur.
Andrew Pinski [Fri, 5 Jun 2026 01:16:44 +0000 (18:16 -0700)]
cselim: Prevent cselim doing store sinking when there are loads in the middle bb [PR125612]
r17-1273-g391ee229b737eb added support for the case where the middle bb was non-empty but
with a trailing store. This meant if there was a load in the middle bb, it might cause
nontrapping to have the lhs in it. So we now need to check for a load in the middle-bb
to reject this case.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/125612
gcc/ChangeLog:
* tree-ssa-phiopt.cc (cond_store_replacement): For the case where
lhs is "known" to be nontrapping make sure there are no loads in
the middle bb.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr125612-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Jeff Law [Sun, 7 Jun 2026 04:53:09 +0000 (22:53 -0600)]
Restore building for SH after bswap related changes
Recent changes result in triggering a compile-time error if the bswap pattern
FAILs. This tripped on the SH port where one of the bswap patterns FAILs if we
can't create new pseudos. We can restore building for SH by moving the check
into the pattern's condition.
Tested by building sh3-linux-gnu/sh3eb-linux-gnu where the compiler builds
again and there are no testsuite regressions relative to the last clean build a
few days ago. sh4/sh4eb, which bootstrap, will run sometime over the coming
days.
Pushing to the trunk.
gcc/
* config/sh/sh.md (bswapsi2): Move check for can_create_pseudos_p
into condition rather than FAILing.
John Ericson [Sun, 7 Jun 2026 04:16:16 +0000 (22:16 -0600)]
[PATCH v6 2/4] driver: Simplify `find_a_program` and `find_a_file`
Now that `find_a_program` and `find_a_file` have been separated, we can
make a number of simplification in both of them. Most notably, we don't
need a mode parameter, because one is always doing `R_OK`, and the other
is always doing `X_OK`.
This change also proves that some of the code I removed from
`find_a_file` in the previous commit is actually dead.
gcc/ChangeLog:
* gcc.cc (find_a_file): Remove mode parameter, because always
R_OK. Skip suffix logic, because suffix is always empty in that
case.
(read_specs): Remove mode from find_a_file call.
(find_a_program): Suffix is unconditional, inline mode constant.
(end_going_arg): Remove mode from find_a_file call.
(find_file): Remove mode from find_a_file call.
(driver::set_up_specs): Remove mode from find_a_file call.
(include_spec_function): Remove mode from find_a_file call.
John Ericson [Sun, 7 Jun 2026 04:15:17 +0000 (22:15 -0600)]
[PATCH v6 1/4] find_a_program: Separate from find_a_file
Do this by inlining (a copy of) find_a_file into find_a_program.
This separation continues what I started in way back in 5fee8a0a9223d030c66d53c104fb0a431369248f --- there should be
executable-specific logic cluttering up find_a_file either, but instead
there is a clean separation.
This commit is pure duplication (for easy reading) but the rest of the
series will remove a bunch of dead code / extraneous parameters, until
there is hardly any duplication.
gcc/ChangeLog:
* gcc.cc (find_a_program): Inline find_a_file, instead of
calling.
openmp, fortran: Add support for iterators in OpenMP 'target update' constructs (Fortran)
This adds Fortran support for iterators in 'to' and 'from' clauses in the
'target update' OpenMP directive.
gcc/fortran/
* dump-parse-tree.cc (show_omp_namelist): Add iterator support for
OMP_LIST_TO and OMP_LIST_FROM.
* match.cc (gfc_free_omp_namelist): Free namespace for OMP_LIST_TO
and OMP_LIST_FROM.
* openmp.cc (gfc_match_motion_var_list): Parse 'iterator' modifier.
(resolve_omp_clauses): Resolve iterators for OMP_LIST_TO and
OMP_LIST_FROM.
* trans-openmp.cc (gfc_trans_omp_clauses): Handle iterators in
OMP_LIST_TO and OMP_LIST_FROM clauses. Add expressions to
iter_block rather than block.
openmp, fortran: Add support for map iterators in OpenMP target construct (Fortran)
This adds support for iterators in map clauses within OpenMP
'target' constructs in Fortran.
Some special handling for struct field maps has been added to libgomp in
order to handle arrays of derived types.
gcc/fortran/
* dump-parse-tree.cc (show_omp_namelist): Add iterator support for
OMP_LIST_MAP.
* match.cc (gfc_free_omp_namelist): Free namespace in namelist for
OMP_LIST_MAP.
* openmp.cc (gfc_match_omp_clauses): Parse 'iterator' modifier for
'map' clause.
(resolve_omp_clauses): Resolve iterators for OMP_LIST_MAP.
* trans-openmp.cc: Include tree-ssa-loop-niter.h.
(gfc_trans_omp_array_section): Add iterator argument. Replace
instances of iterator variables with the initial value when
computing biases.
(gfc_trans_omp_clauses): Handle iterators in OMP_LIST_MAP clauses.
Add expressions to iter_block rather than block. Do not apply
iterators to firstprivate maps. Pass iterator to
gfc_trans_omp_array_section.
gcc/
* gimplify.cc (compute_omp_iterator_count): Account for difference
in loop boundaries in Fortran.
(build_omp_iterator_loop): Change upper boundary condition for
Fortran. Insert block statements into innermost loop.
(remove_unused_omp_iterator_vars): Copy block subblocks of old
iterator to new iterator and remove original.
(extract_base_bit_offset): Add iterator argument. Remove iterator
variables from base.
(omp_accumulate_sibling_list): Add iterator argument to
extract_base_bit_offset.
* tree-pretty-print.cc (dump_block_node): Ignore BLOCK_SUBBLOCKS
containing iterator block statements.
openmp, fortran: Move udm field of gfc_omp_namelist into a new union
This patch moves u2.udm into u3.udm.
This is necessary to avoid clashes when mappers are used together with
iterators, which uses u2.ns.
gcc/fortran/
* gfortran.h (struct gfc_omp_namelist): Move udm field into a new
union u3.
* match.cc (gfc_free_omp_namelist): Change reference to u2.udm to
u3.udm.
* openmp.cc (gfc_match_omp_clauses): Likewise.
Martin Uecker [Sat, 6 Jun 2026 13:08:19 +0000 (15:08 +0200)]
c: fix wrong encoding for zero-sized arrays [PR125618]
This reverts one change from 106970adca69c9c577e6c75f4e69a08cd9ea2df0
that replaced build_range_type with build_index_type. In the function
complete_array_type this breaks zero-sized arrays created from an empty
initializer which there are represented using the C++ FE way [0, -1]
causing issues on 32 bit architectures.
After this partial revert this representation remains inconsistent to
the usual C FE representation [0, NULL_TREE] (as before by change).
PR c/125618
gcc/c-family/ChangeLog:
* c-common.cc (complete_array_type): Change back to using
build_range_type.
Harald Anlauf [Sat, 6 Jun 2026 19:59:49 +0000 (21:59 +0200)]
Fortran: fix ICE on LOC intrinsic with polymorphic argument [PR125606]
The fix for PR122977 improved the gfc_is_simply_contiguous check for
associate variables, but had a side effect when using the LOC() intrinsic
on SELECT TYPE temporaries where gfc_is_simply_contiguous could return
false. Fall back to simply taking the address of the variable's address.
PR fortran/125606
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (gfc_conv_intrinsic_loc): When the argument
of LOC() is not scalar or known to be simply contiguous, simply
take the address of the argument array's first element.
Jerry DeLisle [Sat, 6 Jun 2026 17:06:17 +0000 (10:06 -0700)]
fortran: wrong-code in DO CONCURRENT with ASSOCIATE
When an ASSOCIATE body references inline type-spec iterator,
replace_in_code_recursive lacked a case for EXEC_BLOCK
(associate constructs). So, it silently skipped both
the ASSOCIATE selector expressions and the body when
replacing shadow iterator references.
Add case EXEC_BLOCK to iterate over each selector's target
expression via replace_in_expr_recursive and recurse into
the body namespace's code list via replace_in_code_recursive.
PR fortran/125532
Assisted by: Claude Sonnet 4.6
gcc/fortran/ChangeLog:
* resolve.cc (replace_in_code_recursive): Add EXEC_BLOCK case to
replace shadow iterator references in ASSOCIATE selector expressions
and the ASSOCIATE body namespace.
gcc/testsuite/ChangeLog:
* gfortran.dg/do_concurrent_assoc_iter_1.f90: New test.
Jerry DeLisle [Sat, 6 Jun 2026 16:47:59 +0000 (09:47 -0700)]
fortran: inferred-type ASSOCIATE name giving spurious "Expected argument list"
In gfc_match_varspec, when parsing component references on an
inferred-type ASSOCIATE name, the parser incorrectly matched the
component name as a type-bound procedure .
For inferred-type ASSOCIATE names the parse-time candidate type may
differ from the final resolved type. If gfc_find_component fails with the
default access check, retry with noaccess=true; the resolution pass
will substitute the correct type.
Assisted by: Claude Sonnet 4.6
PR fortran/125531
gcc/fortran/ChangeLog:
* primary.cc (gfc_match_varspec): Before erroring on a zero-argument
COMPCALL, check for a same-named data component and fall back to the
data-component path. For inferred-type ASSOCIATE names, retry
gfc_find_component with noaccess=true when the normal search fails.
gcc/testsuite/ChangeLog:
* gfortran.dg/associate_infer_program_type.f90: New test.
Iain Sandoe [Mon, 1 Jun 2026 23:10:43 +0000 (00:10 +0100)]
testsuite, c++, Darwin: Do not duplicate asan and pthread libs.
The linker on newer versions of Darwin complains about duplicate libaries,
The asan library is already provided by the relevant specs and pthreads are
included in libSystem.
gcc/testsuite/ChangeLog:
* g++.dg/asan/deep-thread-stack-1.C: Omit duplicate libraries
for Darwin.
Iain Sandoe [Mon, 1 Jun 2026 23:13:07 +0000 (00:13 +0100)]
testsuite, c, Darwin: Fix suprious fails in mk*temp* tests.
Since there is a mixture of Posix and unspecified functions in this
group, it appears to have precipitated placement in two different
headers (stdlib and unistd). Include both to cater for this.
Darwin also emits a deprecation warning for mktemp.
optabs: Fix can_open_code_p handling of abs and neg
As noticed by Jakub in the discussion about yesterday's bswap changes.
The change should be a no-op in practice since AND and XOR don't have
libgcc2 functions; we'd always split into word-mode operations instead.
Even so, it doesn't make conceptual sense for can_open_code_p to call
can_implement_p.
The fact that this seems to be a recurring blind spot for me suggests
that I didn't choose good names...
gcc/
* optabs-query.cc (can_open_code_p): Use can_open_code_p rather
than can_implement_p when testing for AND and XOR.
I'm not sure that the removed builtin_decl_explicit_p (BUILT_IN_BSWAP32)
calls are necessary, since the code would go on to use a BSWAP64
rather than a BSWAP32.
This fixes gcc.dg/optimize-bswapsi-6.c on RISC-V.
gcc/
* optabs-query.cc (can_open_code_p): Handle more bswap cases,
incorporating logic from...
* gimple-ssa-store-merging.cc (maybe_optimize_vector_constructor)
(pass_optimize_bswap::execute)
(imm_store_chain_info::try_coalesce_bswap): ...here. Use
can_open_code_p instead of direct optab_handler checks.
Jakub Jelinek [Sat, 6 Jun 2026 07:50:35 +0000 (09:50 +0200)]
i386: Fix up predicates on <ssse3_avx2>_pmulhrsw<mode>3, smulhrs<mode>3 expanders [PR125611]
The following testcase ICEs since r6-6060-gacf93f1edc9 aka PR68991 fix.
THe problem is that the commit has changed the predicates on
*<ssse3_avx2>_pmulhrsw<mode>3<mask_name> pattern from nonimmediate_operand
to vector_operand but kept the old predicates on the corresponding
expanders. With TARGET_AVX that makes no difference (so I've left
the <ssse3_avx2>_pmulhrsw<mode>3_mask expander as is, that is only
TARGET_AVX512BW && TARGET_AVX512VL), but without it if there is unaligned
memory the expander can just expand it as memory without forcing into REG
while the pattern will not match.
2026-06-06 Jakub Jelinek <jakub@redhat.com>
PR target/125611
* config/i386/sse.md (<ssse3_avx2>_pmulhrsw<mode>3, smulhrs<mode>3):
Use vector_operand instead of nonimmediate_operand.
Tested with a csky-linux-uclibc gcc 15.2.0 cross compiler against uClibc-ng,
running its NPTL test suite on qemu-system-cskyv2: without the fix eight
cancellation tests abort (tst-cancel1/10/11/13/15/16/18, tst-cleanup4); with
it all pass and the rest of the suite is unchanged.
openmp: Remove warning about unused iterator variable in map clauses
The gimplifier currently issues a warning about unused iterator
variables in map clauses, implemented by doing a code walk to search
for uses. Unfortunately this is too late; the front ends can optimize
away explicit references to variables, for example by using fold_build*
expression constructors. This leads to false positives.
Additionally the Fortran front end constructs implicit map clauses for
array descriptors that may be associated with iterators but don't reference
the iterator variable. Warning about these is just confusing.
Probably, if we are going to warn about this, it should happen in the
front ends. But it's probably not important enough to justify the amount
of work required, so for now, let's just remove it from the gimplifier.
gcc/ChangeLog
* gimplify.cc (remove_unused_omp_iterator_vars): Don't warn about
possibly-unused iterator variables. Simplify control flow of
remaining code.
Sandra Loosemore [Thu, 28 May 2026 15:37:11 +0000 (15:37 +0000)]
C++, OpenMP: Handle ARRAY_TYPE array sections, not just pointers
This patch is a bug fix for commit gcc-17-202-g3f8c7483112, 'OpenMP:
Expand "declare mapper" mappers for target {enter,exit,} data
directives'. The ChangeLog for that patch indicated that
cxx_omp_map_array_section was supposed to accept both arrays and
pointers as the base expression, but the code actually only allowed
pointers. OTOH, both the error-checking in handle_omp_array_sections_1
and the code generation in build_array_ref allow ARRAY_TYPE, and code with
such expressions is actually coming in to the function.
There is no test case included with this patch, but I ran across this
in the two new test cases included with the OpenMP iterators patch
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689071.html which
I am preparing to resubmit.
gcc/cp/ChangeLog
* semantics.cc (cxx_omp_map_array_section): Allow ARRAY_TYPE
expressions, not just pointers.
Patrick Palka [Fri, 5 Jun 2026 21:05:33 +0000 (17:05 -0400)]
c++/modules: disable dependent ADL inside header unit [PR125334]
This PR reports that building <bits/stdc++.h> as a header unit later
slows down initial std module stream-in by around 2x compared to if
the std module is built without the header unit, i.e.
g++ -fmodules -fsearch-include-path bits/std.cc
g++ -fmodules testcase.C # 15% slower vs before r16-6311
vs
g++ -fmodules -fsearch-include-path bits/stdc++.h bits/std.cc
g++ -fmodules testcase.C # 100% slower vs before r16-6311
This happens after the dependent ADL patch r16-6311. My initial theory
for the slowdown was that the ADL step adds in many more dependency edges
between entities and results in larger SCC clusters, making lazy loading
less lazy, but the number of overall clusters doesn't seem to significantly
before/after the patch. So I have no idea why there's such a big slowdown
and why header units are affected more.
But my basic understanding of the dependent ADL part of reachability
analysis is that it's not really needed when building a header unit
because header units don't discard or hide any entities.
So this patch disables it for header units which restores std module
stream-in back to pre r16-6311 levels when <bits/stdc++.h> is built as a
header unit. When built without the header unit then std module stream-in
is still about 15% slower. Maybe there's ways to safely speed up that
case too (e.g. only add dependency edges to GMF entities?) but I'll
leave that as future work.
PR c++/125334
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_dependent_adl_entities):
Disable when inside a header unit.
Patrick Palka [Fri, 5 Jun 2026 21:05:26 +0000 (17:05 -0400)]
c++/modules: some dependent ADL fixes
When looking at the stream-in performance regression PR c++/125334
(caused by the dependent ADL patch r16-6311) I spotted some issues with
add_dependent_adl_entities:
1. Fix memory leak in add_dependent_adl_entities when it exits early.
2. Only consider type-dependent calls/operator expressions.
3. Fix early exit test for when all args are type-dependent.
4. Add assert verifying recursive name lookup does not happen with
tentative/dependent ADL since it avoids type completion.
Plugging the memory leak reduces max memory usage by 3% when building
the std module, besides that no significant effect towards the
regression.
gcc/cp/ChangeLog:
* module.cc (dep_adl_info::args): Initializer to nullptr
instead of immediately allocating.
(depset::hash::add_dependent_adl_entities): Exit early
for non-type-dependent calls and operator expressions.
Only allocate dep_adl_info::args if we're not exiting early.
Correct all-type-dependent args test.
* name-lookup.cc (name_lookup::preserve_state): Replace
propagation of tentative flag with assert that it's not
set.
Jonathan Wakely [Fri, 5 Jun 2026 14:54:44 +0000 (15:54 +0100)]
contrib: Use 'command -v' in download_prerequisites
If wget is not installed, this script prints a message to standard error
which makes it looks like something is wrong:
./contrib/download_prerequisites: line 53: type: wget: not found
But if curl is installed then the script works fine. The command should
also redirect stderr with 2>&1 but it seems preferable to just replace
the use of 'type' with 'command -v' which is silent when the command is
not found.
Also add an explicit check for curl and print a more helpful error if
not found.
contrib/ChangeLog:
* download_prerequisites: use 'command -v' to check for wget and
curl.
Andrew MacLeod [Wed, 3 Jun 2026 21:46:03 +0000 (17:46 -0400)]
DOM should not process unreachable if there is an SSA relation.
DOM should follow VRP's lead and not attempt o assign global values to
SSA names when the branch leading to a __builtin_unreachable () has
2 ssa-names. Relations elsewhere may lead to this being invalid.
PR tree-optimization/125501
gcc/
* tree-ssa-dom.cc (set_global_ranges_from_unreachable_edges): Abort
if there are 2 SSA_NAMES on the branch condition.
gcc/testsuite/
* gcc.dg/pr125501.c: New.
Many forge instances support a CODEOWNERS file as a way of automatically
requesting reviewers. Forgejo is no different, though the syntax is not
the same as some other forge instances; so put this in the .forgejo
directory.
This version is for experimenting with the format. I expect to want this
file to be autogenerated from other data at a later stage.
Jerry DeLisle [Fri, 5 Jun 2026 16:22:55 +0000 (09:22 -0700)]
fortran: Refactor the commit for 60576
PR fortran/60576
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_resize_assumed_rank_dim_field): New
function extracted from gfc_conv_array_parameter.
(gfc_conv_array_parameter): Use the new function.
Robert Dubner [Fri, 5 Jun 2026 15:43:59 +0000 (11:43 -0400)]
cobol: Properly DISPLAY COMP-1/-2 variables when "-dialect ibm" is in effect. [PR125616]
Instead of GCOBOL's idiosyncratic display of COMP-1 and COMP-2 floating-point
variables, these changes result in IBM's specified format when "-dialect ibm"
is in effect.
The specification says
• Internal floating-point numbers are converted to external floating-point
numbers for display such that:
– A COMP-1 item will display as if it had an external floating-point
PICTURE clause of -.9(8)E-99.
– A COMP-2 item will display as if it had an external floating-point
PICTURE clause of -.9(17)E-99.
That's what these changes implement.
PR cobol/125616
gcc/cobol/ChangeLog:
* genapi.cc (parser_enter_file): New __gg__dialects variable.
(parser_division): Likewise.
* genutil.cc: Likewise.
* genutil.h: Likewise.
* lang.opt.urls: Updated.
* symbols.h (enum cbl_dialect_t): Move this enum to common-defs.h.
libgcobol/ChangeLog:
* common-defs.h (enum cbl_dialect_t): Move cbl_dialect_t here.
* intrinsic.cc (__gg__trim_1): Make a formal parameter const.
* libgcobol.cc (format_for_display_internal): Change the formatting
of COMP-1/COMP2 when "-dialect ibm" is in force.
(default_exception_handler): Whitespace formatting.
(ec_type_disposition): Likewise.
(ec_is_fatal): Likewise.
gcc/testsuite/ChangeLog:
* cobol.dg/group2/DISPLAY_IBM-formatted_COMP-1_and_COMP-2.cob: New test.
* cobol.dg/group2/DISPLAY_IBM-formatted_COMP-1_and_COMP-2.out: New test.
avoid-store-forwarding: Re-apply extension after bit insert sequence [PR124713]
The avoid-store-forwarding pass loses SIGN_EXTEND/ZERO_EXTEND
semantics when the forwarding target is an extending load that is
not fully eliminated. The bit-field insert operates on the
full-width destination register, but does not re-apply the
extension, leaving stale upper bits from the original load.
Fix by emitting the corresponding extension after the bit insert
sequence for non-eliminated extending loads, mirroring what the
load-elimination path already does.
PR rtl-optimization/124713
gcc/ChangeLog:
* avoid-store-forwarding.cc (process_store_forwarding): Re-apply
SIGN_EXTEND/ZERO_EXTEND after bit insert sequence when the load is
not eliminated.
Jakub Jelinek [Fri, 5 Jun 2026 15:16:59 +0000 (17:16 +0200)]
store-merging, riscv: Consider widen_bswap_or_bitreverse in store-merging decisions and fix up riscv build
On Fri, Jun 05, 2026 at 02:22:25PM +0200, Andreas Schwab wrote:
> This breaks riscv:
>
> ../../gcc/config/riscv/riscv.md:5297:14: error: bswapsi2 cannot FAIL
> ../../gcc/config/riscv/bitmanip.md:543:5: note: in expansion of macro 'FAIL'
> 543 | FAIL;
> | ^~~~
wtw mentioned that on IRC.
In the way IFN_BSWAP/IFN_BITREVERSE are used currently (i.e. only used
for large/huge _BitInt or in the C++ FE, but not making it to expansion)
there is no reason why FAIL wouldn't be allowed (like before my changes),
though I find the riscv hack really ugly.
Instead of adding a workaround, this patch removes the riscv hack and
instead adjusts store-merging pass to take into account
widen_bswap_or_bitreverse; currently it already takes into account
expand_doubleword_bswap_or_bitreverse (on 32-bit word targets which have
bswapsi2 expanders expects __builtin_bswap64 to be cheap). With this
patch, it expects __builtin_bswap32 to be cheap if bswapdi2 expander
is present, because widen_bswap_or_bitreverse will handle it as
(subreg:SI (lshiftrt:DI (bswap:DI (subreg:DI (arg:SI) 0)) (const_int 32)) low)
2026-06-05 Jakub Jelinek <jakub@redhat.com>
* gimple-ssa-store-merging.cc (maybe_optimize_vector_constructor):
Also support bswap32 if bswapdi2 expander is present. Add comment
about bswap64 support on 32-bit targets with bswapsi2 expander.
(pass_optimize_bswap::execute): Likewise.
* config/riscv/bitmanip.md (bswapsi2): Change condition to disable
the expander on TARGET_64BIT without TARGET_XTHEADBB, never FAIL.
Reviewed-by: Richard Sandiford <rdsandiford@googlemail.com> Reviewed-by: Richard Biener <rguenth@suse.de>
Roger Sayle [Fri, 5 Jun 2026 13:53:27 +0000 (14:53 +0100)]
PR target/56102: Improve rtx_costs from -mthumb on ARM.
This patch provides improved (more accurate) RTX costs for -mthumb on ARM.
My recent patch for double word multiplication, PR 122871, revealed that
the current costs for THUMB code on ARM are... let's say a little dubious.
To demonstrate the code generation improvements provided by better
thumb1_rtx_costs consider the function below (from PR middle-end/122871).
long long foo (long long a)
{
long long c = a << 33;
c += a;
return c;
}
With the ARM backend's current costs, this produces 11 instructions with
-O2 -mthumb.
Artemiy Volkov [Thu, 4 Jun 2026 14:47:17 +0000 (14:47 +0000)]
aarch64: define duplication into sub-64-bit AdvSIMD vectors [PR125538]
This is a second attempt to deal with the ICE reported in PR125538,
triggering when we generate a (vec_duplicate:V4QI (reg:QI)) expression
for which we currently lack RTL support. More specifically, this occurs
when doing a splat of the most common element in
aarch64_expand_vector_init_fallback () at aarch64.cc:25876.
This is the alternative approach mentioned in the original commit message
at [0], whereby we simply define vec_duplicate patterns for 16-bit and 32-bit
destinations.
Same tests are added as in [0] (a full test reduced in the comments to the
PR, as well as some new vector constructor element combinations in
vec_init_5.c and vec-init-23.c).
Yuao Ma [Fri, 5 Jun 2026 11:50:54 +0000 (19:50 +0800)]
libstdc++: avoid ill-formed nested generator
This was approved as LWG 4119.
libstdc++-v3/ChangeLog:
* include/std/generator (generator::yield_value): Change the
second template parameter from range_value_t<R> to void.
* testsuite/24_iterators/range_generators/lwg4119.cc: New test.
Jakub Jelinek [Fri, 5 Jun 2026 09:01:13 +0000 (11:01 +0200)]
testsuite: Improve enum argument testing of __builtin_{clz,ctz,clrsb,ffs,parity,popcount,bswap,bitreverse}g
On Wed, Jun 03, 2026 at 06:14:53PM +0000, Joseph Myers wrote:
> The enumerated type error seems to be tested only for C++ (likewise for
> __builtin_bitreverseg). Presumably it could be tested for C with a cast
> to or variable of enumerated type, or by using an enumeration with fixed
> underlying type.
I've followed what was tested for the other builtins
(clt/ctz/clrsb/ffs/parity/popcount).
So, here is an incremental patch to extend the testing of enumeral
arguments for all those builtins, including enums with fixed underlying
type.
2026-06-05 Jakub Jelinek <jakub@redhat.com>
* c-c++-common/builtin-bswapg-2.c: Add further enum related tests.
* c-c++-common/builtin-bitreverseg-2.c: Likewise.
* c-c++-common/pr111309-2.c: Likewise.
* c-c++-common/pr111309-3.c: New test.
Richard Biener [Fri, 5 Jun 2026 07:56:09 +0000 (09:56 +0200)]
tree-optimization/125602 - avoid negating the most negative signed value
The following rewrites another case in niter analysis where we might
end up using fold to negate the most negative signed value and expect
that to be an INTEGER_CST. Like elsewhere we should swap negation
and conversion to niter_type with the speciality that the affected
path creates an assumption check in the original type. But for
its construction we can avoid the negation.
PR tree-optimization/125602
* tree-ssa-loop-niter.cc (number_of_iterations_until_wrap):
Avoid double negation for assumption condition. Compute
negated step in niter_type.
I've noticed that we emit terrible code for the following testcase (all
functions). We copy the _BitInt values from memory to a temporary and
perform the bit query or bswap/bitreverse operations on the temporary when
it could be done on the value in memory directly, and for bswap/bitreverse
we can also merge it with a following store to (non-bitfield) memory.
The only exception is that we need some temporary for the
x = __builtin_{bswap,bitreverse}g (x);
cases, when they load from the same memory as they store to. Because the
implementation loops over all the limbs and swaps them, we need one
temporary in that case. This is similar to e.g. multiplication/division.
The bit-query ifns return a small integer scalar, so they don't need any
merging with a store.
The following patch implements this.
2026-06-05 Jakub Jelinek <jakub@redhat.com>
* gimple-lower-bitint.cc (bitint_large_huge::lower_bswap_bitreverse):
Add OBJ argument, use it instead of m_vars[part] if non-NULL. Don't
gsi_remove stmt.
(bitint_large_huge::lower_call): Adjust caller.
(bitint_large_huge::lower_stmt): Handle store of
IFN_BSWAP/IFN_BITREVERSE result.
(stmt_needs_operand_addr): Return true also for
IFN_BSWAP/IFN_BITREVERSE.
(build_bitint_stmt_ssa_conflicts): Formatting fix.
(gimple_lower_bitint): Allow merging IFN_BSWAP/IFN_BITREVERSE with
subsequent non-bitfield store. Allow merging load of
IFN_{CLZ,CTZ,CLRSB,FFS,PARITY,POPCOUNT,BSWAP,BITREVERSE} argument
with the call.
Clang has added recently type-generic versions of __builtin_bswap{16,32,64}
and __builtin_bitreverse{8,16,32,64} builtins.
The following patch adds them to GCC as well.
Unlike the other __builtin_*g type-generic builtins, these are different in
that the return type is not fixed (usually int or unsigned int), but is the
same as the argument type, so these can't be handled as normal builtins
and are handled in the C and C++ parsers instead.
For consistency with the other __builtin_*g builtins, these only accept
unsigned INTEGER_TYPE (or for C BITINT_TYPE) - users can use various ways
to request unsigned variant of arbitrary types. For __builtin_bswapg
additionally this requires the type to have precision which is a multiple of
8 (unlike clang, which for some strange reason requires multiple of 16).
2026-06-05 Jakub Jelinek <jakub@redhat.com>
PR c/122731
gcc/
* doc/extend.texi (__builtin_bswapg, __builtin_bitreverseg): Document.
* internal-fn.def (DEF_INTERNAL_INTSZ_FN): Define.
(DEF_INTERNAL_INTSZ_EXT_FN): Define.
(BSWAP): New internal fn.
(BITREVERSE): Likewise.
* internal-fn.h (expand_BSWAP, expand_BITREVERSE): Declare.
* internal-fn.cc (DEF_INTERNAL_INTSZ_EXT_FN): Define.
(expand_BSWAP, expand_BITREVERSE): New functions.
* builtins.h (fold_build_builtin_bswapg_bitreverseg): Declare.
* builtins.cc (fold_build_builtin_bswapg_bitreverseg): New function.
* wide-int.h (wi::bswap): Fix up docs that only multiple of 8 bits
is required.
* gimple-match-exports.cc (build_call_internal): Handle IFN_BSWAP
and IFN_BITREVERSE.
* gencfn-macros.cc (internal_fn_intsz_names): New variable.
(intsz_suffixes): Likewise.
(suffix_lists): Add intsz_suffixes.
(main): Handle internal_fn_intsz_names.
* match.pd (BSWAP, BITREVERSE): Remove.
(popcount(bswap(x)) is popcount(x)): Use BSWAP BITREVERSE
op lists.
* tree-ssa-phiopt.cc (empty_bb_or_one_feeding_into_p): Use
CASE_CFN_BSWAP and CASE_CFN_BITREVERSE.
(cond_removal_in_builtin_zero_pattern): Likewise.
* fold-const-call.cc (fold_const_call_ss): Likewise.
* fold-const.cc (tree_call_nonnegative_p): Likewise.
* gimple-lower-bitint.cc (struct bitint_large_huge): Declare
lower_bswap_bitreverse method.
(bitint_large_huge::lower_bswap_bitreverse): New method.
(bitint_large_huge::lower_call): Call it.
(build_bitint_stmt_ssa_conflicts): Set muldiv_p for IFN_BSWAP
and IFN_BITREVERSE.
gcc/c-family/
* c-common.h (enum rid): Add RID_BUILTIN_BSWAPG and
RID_BUILTIN_BITREVERSEG.
* c-common.cc (c_common_reswords): Add __builtin_bswapg
and __builtin_bitreverseg.
gcc/c/
* c-parser.cc (c_parser_postfix_expression): Parse
__builtin_bswapg and __builtin_bitreverseg.
gcc/cp/
* parser.cc (cp_parser_postfix_expression): Parse
__builtin_bswapg and __builtin_bitreverseg.
* typeck.cc (build_x_bswapg_bitreverseg): New function.
* cp-tree.h (build_x_bswapg_bitreverseg): Declare.
* pt.cc (tsubst_expr): Handle IFN_BSWAP and IFN_BITREVERSE.
* constexpr.cc (cxx_eval_internal_function): Likewise.
(potential_constant_expression_1): Likewise.
* cp-gimplify.cc (cp_gimplify_expr): Likewise.
gcc/testsuite/
* c-c++-common/builtin-bswapg-1.c: New test.
* c-c++-common/builtin-bswapg-2.c: New test.
* c-c++-common/builtin-bswapg-3.c: New test.
* c-c++-common/builtin-bitreverseg-1.c: New test.
* c-c++-common/builtin-bitreverseg-2.c: New test.
Reviewed-by: Richard Biener <rguenth@suse.de> Reviewed-by: Joseph Myers <josmyers@redhat.com> Reviewed-by: Jason Merrill <jason@redhat.com>
backprop: Calculate transitive closures of replacements [PR125599]
This PR had the equivalent of:
L1:
x = PHI(1, z)
y = -x
...
L2:
z = PHI(x, y)
where z could be simplified to:
z = PHI(x, x)
i.e. to x. Changing z triggered a need to replace x with a new SSA name,
but z was left being replaced with x, rather than x's replacement.
Since the replacement values are (of course) restricted to using
dominating definitions, a single RPO pass is enough to calculate the
transitive closure of replacement values.
gcc/
PR tree-optimization/125599
* gimple-ssa-backprop.cc (backprop::execute): Calculate the
transitive closure of replacement values.
gcc/testsuite/
PR tree-optimization/125599
* g++.dg/torture/pr125599.C: New test.
Andrew Pinski [Fri, 5 Jun 2026 07:43:28 +0000 (00:43 -0700)]
Fix EXECUTE_IF_SET_IN_HARD_REG_SET usage in rtl-ssa/insns.cc [PR122992]
r17-1279-gf6103f3a1e42fe had a mistake when converting over to use
EXECUTE_IF_SET_IN_HARD_REG_SET. EXECUTE_IF_SET_IN_HARD_REG_SET does not work
with a temporary as that temporary lifetime will end after the initialization
part of the for loop ends. So the variable becomes garbage or in some cases
GCC will delete the needed stores.
The fix is to create a variable to extend the liftime of that temporary and
pass that to EXECUTE_IF_SET_IN_HARD_REG_SET.
Pushed as obvious after a bootstrap on aarch64-linux-gnu which was failing before.
Eric Botcazou [Wed, 27 May 2026 11:03:51 +0000 (13:03 +0200)]
ada: Robustify error recovery of structural instantiation in generic formal part
The previous attempt didn't address the root cause of the cascading errors,
so this rewinds it and starts from scratch.
gcc/ada/ChangeLog:
* sem_ch3.adb (Analyze_Private_Extension_Declaration): Revert latest
change.
(Find_Type_Of_Subtype_Indic): Return Any_Type if Find_Type fails to
resolve the type.
* sem_ch12.adb (Analyze_Formal_Derived_Type): Restore more specific
error recovery path.
Mathias Aparicio [Mon, 18 May 2026 12:48:48 +0000 (14:48 +0200)]
ada: Change Constraint_Error into Data_Error in Text_IO to respect ARM
Before the patch, Get_Upper_Half_Char_Immed and Get_Upper_Half_Char would
both raise a Constraint_Error when the input exceeded a bound. However,
ARM A.13 (13) states that the procedure Get should propagate the
Data_Error exception if the input value does not belong to the range of
the required subtype.
Now propagate Data_Error.
gcc/ada/ChangeLog:
* libgnat/a-textio.adb
(Get_Upper_Half_Char, Get_Upper_Half_Char_Immed): Replace
Constraint_Error with Data_Error
Viljar Indus [Mon, 25 May 2026 11:29:56 +0000 (14:29 +0300)]
ada: Avoid suspicious index warnings in expanded code
Some expansions and optimizations wrap the existing code in
functions that loose the range constraints of the original
variable. We should avoid triggering bogus errors in such scenarios.
gcc/ada/ChangeLog:
* sem_warn.adb (Warn_On_Suspicious_Index): Only check elements
that are coming from source.
Eric Botcazou [Mon, 25 May 2026 20:40:20 +0000 (22:40 +0200)]
ada: Reject structural instantiation in generic formal part
The structural instance would amount to a formal package in this context,
and that's totally unsupported by the current implementation.
gcc/ada/ChangeLog:
* sem_ch3.adb (Analyze_Private_Extension_Declaration): Be prepared
for Find_Type_Of_Subtype_Indic returning no type.
* sem_ch4.adb (Process_Generic_Instantiation): Give an error if the
generic instantation is referenced in a generic formal part.
* sem_ch12.adb (Analyze_Formal_Derived_Type): Return early in every
case of serious errors.
Kito Cheng [Thu, 4 Jun 2026 14:49:37 +0000 (22:49 +0800)]
RISC-V: Specify cmodel in OPTION_DEFAULT_SPECS
We have supported --with-cmodel for a while and set the default via
TARGET_DEFAULT_CMODEL. That works well in general, but not for
multilib, because GCC cannot detect the cmodel for the current multilib
correctly that way. So we still need to specify the default cmodel in
OPTION_DEFAULT_SPECS.
Jerry DeLisle [Thu, 28 May 2026 04:00:19 +0000 (21:00 -0700)]
fortran: ICE in DO CONCURRENT with DEFAULT(NONE) inside ASSOCIATE
Two bugs in check_default_none_expr caused a segfault when a DO CONCURRENT
with inline type-spec iterators (e.g. "integer :: i = 1:10") contained an
ASSOCIATE construct.
Bug 1: sym->ns->code was used to locate the ext.concur.forall_iterator
list. When a symbol's namespace is an ASSOCIATE body, sym->ns->code is an
EXEC_BLOCK node, not the DO CONCURRENT node; reading ext.concur from it
interprets the wrong union member and yields a garbage pointer. Fix: use
d->code instead, the DO CONCURRENT gfc_code node passed through the walker's
data parameter, which is always the correct node.
Bug 2: inline type-spec iterators are shadow iterators, stored internally
with a leading underscore prepended to the name. The comparison of the
iterator's symtree name against the user-visible sym->name must skip that
underscore by advancing iter_name one character when iter->shadow is set.
PR fortran/125529
Assisted by: Claude Sonnet 4.6
gcc/fortran/ChangeLog:
PR fortran/125529
* resolve.cc (check_default_none_expr): Use d->code instead of
sym->ns->code to locate the DO CONCURRENT forall_iterator list,
avoiding a wrong-union-member read when the symbol's namespace is
an ASSOCIATE body. Skip leading underscore when comparing iterator
names for shadow iterators.
gcc/testsuite/ChangeLog:
PR fortran/125529
* gfortran.dg/do_concurrent_assoc_default_none.f90: New test.
Jerry DeLisle [Wed, 27 May 2026 22:10:07 +0000 (15:10 -0700)]
fortran: ICE or wrong-code for ASSOCIATE selector that is a type-bound user-defined operator
Three related bugs prevented ASSOCIATE selectors that are type-bound
user-defined operator expressions from compiling correctly.
Bug 1 (class.cc): find_typebound_proc_uop returned NULL immediately when
the derived type has no f2k_derived namespace, bypassing the parent-type
inheritance walk. This caused inherited UDOs to be silently not found.
Fix: set root = NULL and let the loop reach the parent type instead.
Bug 2 (resolve.cc): resolve_typebound_procedures called resolve_symbol on
the parent type only after an early return that fires when the derived type
has no direct type-bound bindings. This left parent-type bindings
unresolved when searched via gfc_find_typebound_user_op.
Fix: move resolve_symbol(super_type) before the early return.
Bug 3 (match.cc): match_association_list did not handle ASSOCIATE selectors
of the form .uop. expr or the nested case .uop2. (.uop1. expr). When the
selector's type was BT_UNKNOWN at parse time the name of the associate
variable was left untyped, producing a "Syntax error in expression" ICE in
the body of the ASSOCIATE construct.
Fix: add three helpers before match_association_list:
- resolve_assoc_operand: attempts gfc_resolve_expr on EXPR_FUNCTION
operands and falls back to gfc_find_dt_in_generic for constructor calls
whose argument types are not yet known.
- infer_typebound_uop_type: reads the return type of a type-bound UDO
directly from specific_st->n.tb->u.specific->n.sym without calling
gfc_resolve_symbol, avoiding a resolve_symbol_called race condition.
- extend_assoc_op: walks the expression tree bottom-up, propagating
types through INTRINSIC_PARENTHESES wrappers before calling the two
helpers above on each INTRINSIC_USER node.
When the selector is an INTRINSIC_USER EXPR_OP with BT_UNKNOWN type,
call extend_assoc_op on the operands, then gfc_extend_expr (errors
suppressed). Accept the result when gfc_extend_expr returns MATCH_YES or
when it returns MATCH_ERROR but has already converted the node to
EXPR_COMPCALL with a known type (the full resolution pass finishes it).
Assisted by: Claude Sonnet 4.6
PR fortran/125528
gcc/fortran/ChangeLog:
PR fortran/125528
* class.cc (find_typebound_proc_uop): Set root = NULL instead of
returning NULL when derived type lacks f2k_derived, so parent-type
type-bound procedures and operators are still found via inheritance.
* match.cc (resolve_assoc_operand): New helper.
(infer_typebound_uop_type): New helper.
(extend_assoc_op): New helper.
(match_association_list): Handle ASSOCIATE selectors that are
type-bound user-defined operator expressions, including nested cases.
* resolve.cc (resolve_typebound_procedures): Move resolve_symbol
call for the parent type before the early return so inherited
type-bound bindings are resolved even when the child type has none
of its own.
gcc/testsuite/ChangeLog:
PR fortran/125528
* gfortran.dg/associate_80.f90: New test.
Marek Polacek [Wed, 3 Jun 2026 19:01:33 +0000 (15:01 -0400)]
c++: CWG 1704, type checking in explicit inst of var tmpl [PR125575]
While working on something else I noticed that we compile
template<typename T>
constexpr int vt = 42;
template float vt<int>;
but we shouldn't due to the float/int mismatch. Andrew found
98524 which is the same problem. This turned out to be CWG 1704.
For explicit specialization of functions, determine_specialization
already performs the checking; see the various same_type_p, compparms,
comp_template_parms etc. checks. Except I do believe it doesn't check
exception specification as it should:
* pt.cc (check_explicit_inst_of_var_template): New.
(check_explicit_specialization): Use it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ90.C: New test.
* g++.dg/cpp1y/var-templ91.C: New test.
* g++.dg/cpp1y/var-templ92.C: New test.
* g++.dg/cpp1y/var-templ93.C: New test.
Martin Uecker [Thu, 4 Jun 2026 17:19:33 +0000 (19:19 +0200)]
c: wrong code generated with counted_by on pointer + ubsan [PR125072]
When a pointer is accessed with a constant offset, this has to be split into
the size of the element type and the index to be able to instrument the
index. The code failed to re-apply the element size after this.
Martin Uecker [Wed, 3 Jun 2026 15:57:30 +0000 (17:57 +0200)]
c: harmonize handling of arrays
This code harmonizes the handling of arrays in C by consistently
using build_index_type instead of build_range_type when creating
arrays and using top_array_vla_p to detect top-level VLAs.
gcc/c-family/ChangeLog:
* c-common.cc (complete_array_type): Use build_index_type.
* c-ubsan.cc (ubsan_instrument_bounds_pointer_address): Likewise.
gcc/c/ChangeLog:
* c-decl.cc (grokdeclarator): Likewise.
* c-typeck.cc (c_verify_type,c_build_array_type,
c_expr_countof_expr,comptypes_internal): Use top_array_vla_p.
(top_array_vla_p): Rename to use _p convention and simplify.
Jerry DeLisle [Thu, 4 Jun 2026 19:11:37 +0000 (12:11 -0700)]
Fortran: fix stack-buffer-overflow passing type to assumed-rank class [PR60576]
Two code paths copied a full GFC_MAX_DIMENSIONS dim[] array from a
descriptor that physically holds only dtype.rank dimensions, triggering
a stack-buffer-overflow detected by AddressSanitizer.
Case 1 - assumed-rank type(T) dummy passed to class(T) assumed-rank:
The caller only allocates storage for dtype.rank dimensions. The code
generated a static GFC_MAX_DIMENSIONS struct copy of the dim[] array,
reading past the physical end of the descriptor. Fix by checking
expr->rank == -1 and replacing the static copy with a runtime-sized
__builtin_memcpy of dtype.rank * sizeof(descriptor_dimension) bytes.
Case 2 - fixed-rank type(T) actual passed directly to class(T) assumed-rank:
gfortran uses a rank-specific descriptor type for fixed-rank type arrays
(dim[rank] rather than dim[GFC_MAX_DIMENSIONS]). The class assumed-rank
formal's descriptor has dim_t[GFC_MAX_DIMENSIONS]. The call to
gfc_class_array_data_assign with lhs_type=true keyed the ARRAY_RANGE_REF
off TREE_TYPE(lhs_dim) = dim_t[GFC_MAX_DIMENSIONS], reading 15*24 = 360
bytes from a descriptor that physically has only rank*24 bytes for the
dim[] array. Fix by checking CLASS_DATA(fsym)->as->rank == -1 and
passing lhs_type=false so the ARRAY_RANGE_REF is sized by
TREE_TYPE(rhs_dim) = dim_t[rank], copying only the physically present
entries. Fixed-rank class formals retain lhs_type=true.
Assisted by: Claude Sonnet 4.6
PR fortran/60576
gcc/fortran/ChangeLog:
PR fortran/60576
* trans-array.cc (gfc_conv_array_parameter): For an assumed-rank
actual argument passed to a CLASS assumed-rank formal, use a
runtime-sized memcpy for the dim[] entries instead of a full
GFC_MAX_DIMENSIONS static copy. For a fixed-rank actual to a
CLASS assumed-rank formal, pass lhs_type=false to
gfc_class_array_data_assign so the dim[] copy is sized by the
RHS descriptor type (dim_t[rank]). Fixed-rank class formals
retain lhs_type=true.
* trans-expr.cc (gfc_conv_derived_to_class): For an assumed-rank
actual, use a runtime-sized memcpy for the derived_array descriptor
dim[] copy instead of a full GFC_MAX_DIMENSIONS static copy.
gcc/testsuite/ChangeLog:
PR fortran/60576
* gfortran.dg/asan/assumed_rank_26.f90: New test covering both
assumed-rank and fixed-rank type actuals passed to a CLASS
assumed-rank dummy.
Robert Dubner [Thu, 4 Jun 2026 17:53:14 +0000 (13:53 -0400)]
cobol: Bring TRIM into accordance with the COBOL specification.
The COBOL TRIM function can take optional additional characters to be
trimmed off the ends of a string, rather than just the default, which
trims away spaces. These changes implement that functionality.
gcc/cobol/ChangeLog:
* genapi.cc (handle_gg_trim): Provide an array of characters to the
library function.
(parser_trim): New function that handles the optional trim chars.
(parser_intrinsic_call_2): Remove __gg__handling from this routine.
* genapi.h (parser_trim): New declaration.
* parse.y: Calls parser_trim() with the list of trim chars.
libgcobol/ChangeLog:
* intrinsic.cc (__gg__formatted_date): Formatting change.
(change_case): Likewise.
(__gg__trim): Rename as __gg__trim_1.
(__gg__trim_1): Reworked to handle an array of single-byte chars.
(__gg__trim_a): Reworked to handle an array of multi-byte chars.
(iscasematch): Formatting change.
gcc/testsuite/ChangeLog:
* cobol.dg/group2/FUNCTION_TRIM_with_extra_characters.cob: New test.
* cobol.dg/group2/FUNCTION_TRIM_with_extra_characters.out: New test.
- a conversion to a list view
- a list clear operation
- a (trivial) conversion back to a tree view
We can do that directly without the need for splay operations.
Doing that removes the only case where bitmap_elt_clear_from is called
for a tree view. The function can therefore assert for a list view.
That in turn means that bitmap_list_view can inline
bitmap_tree_listify_from without having to handle a partial conversion.
The main optimisation here comes from avoiding the sorted_elements
array by building the list as we go.
We can also avoid the stack array by using the prev fields as a list
link. Avoiding the stack array might not always be a win, since the
bitmap elements are less compact and because cache locality for the
stack should be good while it remains locally allocated. My reasoning
was:
(1) The cache lines containing the stack prev fields are going to be
written to when adding the elements to the list.
(2) If the tree is balanced, it's relatively unlikely that those cache
lines would be evicted between the two updates.
(3) If the tree isn't well balanced and has a long left spine, we'd
end up allocating heap memory for the vector, which would add
a new set of overheads.
I'd be happy to switch back to a vector stack if that turns out
to be better after all.
It's possible to write this version of the algorithm in loop form,
but I thought the structure in the patch was easier to follow.
This gives a reproducible 20% improvement in an artificial test that
converts a tree containing 2,000,000 pseudo-random elements (keeping
the same sequence for all tests). This testing also ensured that
the resulting list view was correct.
gcc/
* bitmap.cc (bitmap_elt_clear_from): Make static. Require a
list view.
(bitmap_tree_listify_from): Delete.
(bitmap_list_view): Rewrite to avoid separate vectors.
(bitmap_clear): Switch to a list view before calling
bitmap_elt_clear_from and restore the original view afterwards.
bitmap: Avoid amortised O(E) behaviour for tree first/last bit
The comments in bitmap.h say that bitmap_first_set_bit and
bitmap_last_set_bit are amortised O(logE) and worst-case O(E).
But the implementation just does a simple pointer chase,
without any splaying. This can be amortised O(E) if, for example,
code sets bits in ascending order and then repeatedly tests for
the first bit. Nothing would then move the root away from the
last element or begin to balance the tree.
gcc/
* bitmap.cc: Include pretty-print.h and splay-tree-utils.h.
(bitmap_splay_tree_accessors): New class.
(bitmap_splay_tree): New type.
(bitmap_first_set_bit_worker): Use bitmap_splay_tree::min_node
for tree views.
(bitmap_last_set_bit_worker): Use bitmap_splay_tree::max_node
for tree views.
bitmap_tree_link_element first splays the tree to ensure that the
root is a neighbour of the element that we want to insert. But the
callers have already done the same kind of splay operation in order
to prove that no existing element has the required index.
Repeating the operation isn't free. For example, if the first splay
operation leaves the left neighbour N in the root, the second splay
operation would need to search N->right->left (N->next->prev),
and similarly in reverse for a right neighbour.
This gives a reproducible 20% improvement in an artificial test that
inserted 2,000,000 pseudo-random elements (keeping the same sequence
for all tests).
gcc/
* bitmap.cc (bitmap_tree_link_element): Require callers to have
done a splay operation. Avoid doing another one here.
Previously, this task was performed by the gcobol driver. However, prior
art from the Modula-2 front-end showed this was performed by the
compiler instead.
Now, and similarly to Modula-2, cobol1 will honor -B, as well as
-idirafter. While the %I spec is also honored, it will not be as useful
because -B options would only be expanded to -isystem by %I if the
"include/" and "include-fixed/" directories exist wherever -B points at.
However, system copybooks are currently installed on:
TODO: Some of the -i* options, such as -imultilib, are not supported
yet. Reportedly, only -I, -isystem and -idirafter are supported.
gcc/cobol/ChangeLog:
* Make-lang.in: Make $(libsubdir) available to cobol1.o.
* cobol1.cc (struct GTY): Add dir_separator.
(libcompat_copybook): New function.
(libposix_copybook): New function.
(append_copybook_prefix): New function.
(cobol_langhook_handle_option): New function.
(cobol_langhook_post_options): New function.
(LANG_HOOKS_POST_OPTIONS): New function.
* gcobolspec.cc (lang_specific_driver): Remove path searches.
* lang-specs.h: Honor %{B*} and %I.
* lang.opt: Support -B and -idirafter.
NOTE: Dash ('-') in the option name must replace with underline ('_'),
and leading dash should skip, e.g. `-fcf-protection=full` become
`fcf_protection=full`.
It will build a multilib with
`-march=rv64imafdc_zicfiss_zicfilp -mabi=lp64d -fcf-protection=full`
And will use `rv64imafdc_zicfiss_zicfilp/lp64d/cfi` as multilib folder.
gcc/ChangeLog:
* config/riscv/multilib-generator: Support extra options in the
multilib config string.
* doc/install.texi (--with-multilib-generator): Document the extra
options syntax.
Kito Cheng [Wed, 3 Jun 2026 07:01:19 +0000 (15:01 +0800)]
RISC-V: Sync extension of canonical order with spec
The canonical order has been adjusted a little bit [1-2]. Fortunately, the
affected extensions haven't been ratified yet, so there's no real impact.
Although P doesn't have an upstream yet, to avoid forgetting to update the
canonical order in the future, I've decided to update it now while I still
remember it.
* common/config/riscv/riscv-common.cc (riscv_supported_std_ext):
Move 'v' before 'p' and drop 'n' to match the spec.
* config/riscv/arch-canonicalize (CANONICAL_ORDER): Ditto.
Paul Thomas [Thu, 4 Jun 2026 10:55:50 +0000 (11:55 +0100)]
Fortran: fix always_explicit not copied by gfc_copy_attr [PR121204]
gfc_copy_attr omitted the always_explicit attribute, so when
gfc_copy_dummy_sym created a fresh copy of a dummy procedure symbol in
a submodule module procedure (gfc_match_submod_proc), the flag was
silently lost. At translation time nodesc_arg was set true for calls
through that dummy procedure, causing array constructors to be passed
as raw data pointers instead of array descriptors. Callers with
assumed-shape dummy arguments then read garbage bounds.
2026-06-04 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/121204
* symbol.cc (gfc_copy_attr): Copy the always_explicit attribute.
gcc/testsuite
PR fortran/121204
* gfortran.dg/submodule_38.f90: New test.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Paul Thomas [Thu, 4 Jun 2026 12:24:05 +0000 (13:24 +0100)]
Fortran: ICE with pointer result from submodule function [PR93424]
The declaration at line 41 of the testcase produced:
42 | class(c), pointer :: bp
| 1
Error: Unclassifiable statement at (1)
Followed by either an ICE (gcc-13 and gcc-17) or
"(null):0: confused by earlier errors, bailing out"
for the other active branches.
It is the error that is key, the aftermath is a distraction especially
in examining the entrails for clues.
The fix recognises 'bp', in the offending line, to be the implicit
result of the module procedure, redeclared in the submodule contained
function. MATCH_YES is emitted and the potential new symbol is not
commited by jumping straight to cleanup.
2026-06-04 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/93424
* decl.cc (variable_decl): Do not commit the symbol if it is
the implicit result of a module procedure being declared in a
function, used in a submodule.
gcc/testsuite/
PR fortran/93424
* gfortran.dg/submodule_37.f90: New test.
Raphael Zinsly [Thu, 4 Jun 2026 13:08:08 +0000 (07:08 -0600)]
[V2][PR target/125387][RISC-V] Properly cost mulh for RISC-V
Bah. Sent the wrong version. The integer multiply cost in the tuning
structure already has COSTS_N_INSNS applied, so no need to apply it again
(which causes the costs to skyrocket and the code generation we want to see not
happen).
--
This is a patch Raphael wrote a few years back, but which never got upstreamed.
I can vaguely recall evaluating the patch and concluding to drop it both
internally and from the queue of things to upstream. But the details of how I
reached that conclusion are lost.
The core problem is we didn't recognize the fairly complex widening multiply
RTL, so it got costed by recursion which is painful on its own. To add insult
to injury the input operands are TI mode which, IIRC, also increased the cost
of the mulh insn.
The net was a totally bogus cost, it was totally off the charts which in turn
discouraged using multiplies for division-by-constant operations as can be seen
in the BZ.
This patch from Raphael fixes recognition of the mulh RTL and uses the integer
multiply cost out of the costing structure. This results in sensible costs for
the multiply and using a multiply-by-reciprocal instead of division in more
cases.
It's been tested on riscv32-elf and riscv64-elf without regressions. I haven't
bootstrapped it as I had my system disabled yesterday for "reasons". I'll
obviously wait for the pre-commit verdict.
Jeevitha [Thu, 4 Jun 2026 10:11:35 +0000 (05:11 -0500)]
testsuite: Add PowerPC future hardware compiler support checks
Add new effective-target procs to help write tests for future powerpc.
"check_effective_target_powerpc_future_compile_ok" checks whether the
compiler recognizes -mcpu=future (i.e., defines _ARCH_FUTURE).
"check_effective_target_powerpc_future_assemble_ok" checks whether the
assembler supports "powerpc future" instructions under -mcpu=future.
"check_powerpc_future_hw_available" checks at runtime whether the
hardware supports executing "powerpc future" instructions.
Viljar Indus [Wed, 6 May 2026 10:05:22 +0000 (13:05 +0300)]
ada: Remove conversion to an if-statement
There is no need to convert the ignored pragmas into if-statements
with a statically false condition and a null body since the
ignored ghost node removal should take care of this removal
from now on.
This simplifies the detection of those ignored pragmas and
makes the code more easily identifiable and common with ignored
ghost code that should behave similarly to ignored asseritons.
gcc/ada/ChangeLog:
* expander.adb: Handle pragma statements in the expander.
* sem_ch6.adb (Check_Statement_Sequence): Handle cases where
an ignored assertion pragma is at the end of a function body
that is known to trigger an assertion.
* sem_prag.adb (Analyze_Pragma): Remove the if-statement
creation for ignored pragmas. Relocate checks for assertion
pragma conditions that were performed on these transformed
if-statements here.
* sem_res.adb (Resolve_Short_Circuit): Remove the code for
ignored assertion pragmas.
* sem_util.adb (Original_Aspect_Pragma_Name): use the identifier
name for pragma Check only when it did not come from source.
* tbuild.adb (Make_Implicit_Loop_Statement): Adjust the code
for ignored Check pragmas.
Artur Pietrek [Thu, 21 May 2026 13:29:10 +0000 (15:29 +0200)]
ada: Fix finalize address for arrays of protected types
Make_Address_For_Finalize emits a -Descriptor_Size shift whenever
the array's first subtype is unconstrained, but does not check whether
the object has a controlled component. For arrays of protected types
Has_Controlled_Component is False so no dope vector is allocated, but
at scope exit the incorrect finalize address is dereferenced, which
may lead to EXCEPTION_ACCESS_VIOLATION, or silent error.
gcc/ada/ChangeLog:
* exp_ch7.adb (Make_Address_For_Finalize): check
Has_Controlled_Component predicate before emitting the shift to be
consistant with what Is_Constr_Array_Subt_With_Bounds says.
Eric Botcazou [Wed, 20 May 2026 17:19:42 +0000 (19:19 +0200)]
ada: Fix again internal error on abstract primitive with access result
The previous fix was papering over the root cause, which is that the itype
built for the anonymous access result type of a derived subprogram is given
the subprogram itself as Scope, instead of the scope of the subprogram. The
incorrect code also temporarily sets the Scope of the subprogram to itself!
gcc/ada/ChangeLog:
* accessibility.adb (Type_Access_Level): Revert ealier change.
* sem_ch3.adb (Derive_Subprogram.Replace_Type): Set the Scope of
the new anonymous access type to the scope of the derived type.
Do not (temporarily) sets the Scope of the subprogram to itself.
Piotr Trojanek [Wed, 20 May 2026 14:53:34 +0000 (16:53 +0200)]
ada: Check intrinsic subprograms specified by an aspect
We only checked intrinsic subprograms specified by pragmas that come from
source, but this missed subprograms specified by an aspect (because its
internally generated corresponding pragma doesn't come from source).
gcc/ada/ChangeLog:
* sem_intr.adb (Check_Intrinsic_Subprogram): Recognize pragmas that
do not come from source because they come from aspect specification.
The routine is also used for Ada 2012's stand-alone objects of an anonymous
access type, that is to say not only for access parameters. It is invoked on
an explicit or implicit conversion of the object to another access type.
Eric Botcazou [Mon, 18 May 2026 22:54:00 +0000 (00:54 +0200)]
ada: Set Is_Local_Anonymous_Access on the anonymous access type of return objects
It is already set on the anonymous access type of function results and will
prevent return objects from being treated as Ada 2012's stand-alone objects,
thus make it easier to enforce the RM 3.10.2(13.2) rule.
gcc/ada/ChangeLog:
* einfo.ads (Is_Local_Anonymous_Access): Mention return objects.
* accessibility.adb (Type_Access_Level): Call Enclosing_Subprogram.
* sem_ch3.adb (Find_Type_Of_Object): Set Is_Local_Anonymous_Access
on the anonymous access type of return objects.
Steve Baird [Mon, 18 May 2026 21:55:38 +0000 (14:55 -0700)]
ada: Null pointer dereference in Adjust for bounded indefinite holders.
In the Adjust procedure for Ada.Containers.Bounded_Indefinite_Holders.Holder,
check to see whether the holder is empty before trying to copy its
(possibly nonexistent) element value.
Eric Botcazou [Wed, 13 May 2026 07:46:31 +0000 (09:46 +0200)]
ada: Fix missing error for too deep accessibility level in aggregate return
The issue occurs when an access discriminant in an aggregate return is set
to a value obtained by means of a function call written in prefixed form.
The change also adjusts the implementation of the RM 6.5(5.9) rule, which
was hijacking the machinery of dynamic accessibility checks for a static
accessibility check, thus incorrectly flagging stand-alone objects of an
anonymous access type in Ada 2012 and later, per the RM 3.10.2(19.2) rule.
It also merges the implementations of the RM 3.10.2(28) rule for named and
anonymous access types in a single block of code.
gcc/ada/ChangeLog:
* einfo.ads (Is_Local_Anonymous_Access): Mention access results.
* accessibility.adb (Accessibility_Level): Add missing guard on
the entity for error cases. In the component cases, retrieve the
function call if the prefix is a captured function call. Remove
the bypass returning the library level in a return context if the
prefix is a function call. Call Function_Call_Or_Allocator_Level
in this case when the level of the prefix is tied to that of the
result of the enclosing function.
(Check_Return_Construct_Accessibility): Change the implementation
to do a bona-fide static accessibility check.
* sem_attr.adb (Resolve_Attribute) <Attribute_Access>: Merge the
implementations of the RM 3.10.2(28) rule for named and anonymous
access types.
* sem_ch6.adb (Analyze_Expression_Function): Set the Ekind of the
entity created for the body very early.
* sem_util.adb (In_Return_Value): Fix typo in comment.
ada: Fix ICE on static predicate when all case alternatives are False
Before this patch, creating a pragma predicate with the static keyword
whose body included a case-expression where every alternative was
statically evaluated to false leads to an ICE.
When the case expression had all alternatives resolved to False,
Build_Discrete_Static_Predicate.Get_Rlist returned an Empty list and
later in the code Next was called on the Empty List.
Now return false_range in this case.
gcc/ada/ChangeLog:
* sem_ch13.adb (Build_Discrete_Static_Predicate.Get_RList): If
case expression alternatives are False return False_Range.
Eric Botcazou [Sat, 16 May 2026 16:58:41 +0000 (18:58 +0200)]
ada: Get rid of Effective_Extra_Accessibility function
The computation of accessibility levels does not consistently look through
object renamings when extra accessibility objects are used. This attempts
to address the issue by making Extra_Accessibility do it automatically.
Eric Botcazou [Sat, 16 May 2026 12:09:54 +0000 (14:09 +0200)]
ada: Disable a couple of static accessibility checks in dynamic cases
In accordance with the RM 3.10.2(19,19.1,19.2) rules.
gcc/ada/ChangeLog:
* exp_ch4.adb (Expand_Allocator_Expression): In the case of access
discriminants, pass Zero_On_Dynamic_Level to compute the static
accessibility level of the expression.
* sem_res.adb (Check_Aliased_Parameter): Pass Zero_On_Dynamic_Level
to compute the static accessibility level of actual parameters.
Eric Botcazou [Sat, 16 May 2026 11:35:22 +0000 (13:35 +0200)]
ada: Fix small inaccuracy in Function_Call_Or_Allocator_Level
In the case of an object declaration, the function returns the depth of the
enclosing static scope, instead of that of the enclosing dynamic scope like
its parent function Accessibility_Level.
The change contains a couple of cleanups in the expander, which resort to
calling Accessibility_Level in more cases instead of doing manual work.
gcc/ada/ChangeLog:
* accessibility.ads (Accessibility_Level_Kind): Tweak description.
* accessibility.adb (Function_Call_Or_Allocator_Level): Recurse on
the defining identifier for an N_Object_Declaration node.
(Accessibility_Level): Minor tweaks.
* exp_ch3.adb (Expand_N_Object_Declaration): Do not special case
function calls in the computation of accessibility levels.
* exp_ch5.adb (Expand_N_Assignment_Statement): Do not manually
compute the accessibility level of the LHS.
Piotr Trojanek [Wed, 13 May 2026 14:56:03 +0000 (16:56 +0200)]
ada: Inline for proof without creating extra objects
When inlining subprogram calls in GNATprove mode, we were creating object
declarations only to force checks that would be otherwise missed with object
renamings. Now ghat GNATprove emits those checks for object renamings anyway
(as required by Ada 2022), we no longer need those extra objects.
gcc/ada/ChangeLog:
* inline.adb (Establish_Actual_Mapping_For_Inlined_Call): Do not create
object declarations when actual is captured in an object renaming.
Piotr Trojanek [Tue, 14 Apr 2026 10:18:09 +0000 (12:18 +0200)]
ada: Move gnatmake-specific logic from libgnat to gnatmake
We had a complicated, ancient workaround for gnatmake that simply hardcoded
library names to "libXXX.a".
Note: if we ever wanted to make this platform-specific, it should probably use
__gnat_object_library_extension, which is currently used by gnatlink, but is
equal to "libXXX.a" on every platform except for VMS, which is unsupported.
gcc/ada/ChangeLog:
* adaint.c (__gnat_library_template): Move logic to gnatmake.
* make.adb (Get_Library_File): Use simple single template.
projects / thirdparty / gcc.git / log
