As discussed in libstdc++/124268, the std module relies on exporting
using-declarations for various entities, but on some targets the
relevant declarations have internal linkage.
Given we already support exposures of such internal linkage entities for
migration purposes, it seems reasonable to allow the same for
using-declarations.
PR libstdc++/124268
gcc/ChangeLog:
* doc/invoke.texi: Note that -Wexpose-global-module-tu-local
also applies to 'export using' declarations.
gcc/cp/ChangeLog:
* module.cc (instantiating_tu_local_entity): Use pedwarn instead
of warning.
(depset::hash::add_binding_entity): Don't skip exported
using-decls as TU-local entities.
(depset::hash::finalize_dependencies): Don't attempt to complain
again about using-decls referencing TU-local entities.
* name-lookup.cc (check_can_export_using_decl): Demote the error
to a warning for using-decls of GMF vars or functions.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-34_a.C: New test.
* g++.dg/modules/using-34_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
Like with implicit constexpr, we need to handle cases where we import an
function declaration with undeduced auto, but we already have a
definition available with deduced auto. In this case we can just keep
the existing declaration's type.
PR c++/124735
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Handle importing
undeduced auto when existing is already deduced.
gcc/testsuite/ChangeLog:
* g++.dg/modules/auto-8_a.H: New test.
* g++.dg/modules/auto-8_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
We call 'set_originating_module' before we call pushdecl, which means
that for function-scope entities we might not have set DECL_CONTEXT yet.
Usually this doesn't matter, we only look at DECL_MODULE_EXPORT/ATTACH_P
on namespace-scope entities to begin with, but in the case in the linked
PR it causes issues because declarations in an unevaluated lambda appear
to be in an internal context.
Fixed by only considering non-null DECL_CONTEXT as being namespace scope
within set_originating_module.
As a drive-by improvement, ensured that we only talk about unnamed
namespaces in the diagnostic within check_module_decl_linkage if we're
actually within an anonymous namespace; this should be equivalent but
will lead to a slightly clearer diagnostic if a similar bug crops up
again later.
PR c++/124781
gcc/cp/ChangeLog:
* module.cc (set_originating_module): Add a function comment,
only set attachment/exporting for entities with non-NULL
DECL_CONTEXT.
(check_module_decl_linkage): Use decl_anon_ns_mem_p instead of
decl_internal_context_p.
gcc/testsuite/ChangeLog:
* g++.dg/modules/export-7.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
We triggered a checking assertion because when propagating deduced
noexcept, we were updating the type of the existing TEMPLATE_DECL but
not the type of its DECL_TEMPLATE_RESULT, violating assumptions made
later on during modules streaming.
But actually there was nothing to propagate here anyway, these
declarations are identical, so this patch also fixes the condition for
checking whether we need to propagate anything. And so now I don't
think there is ever a case we should have a noexcept-spec to propagate
for a TEMPLATE_DECL, so add an assertion to validate this.
PR c++/124785
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Narrow condition for
when noexcept propagation occurs; assert that we don't propagate
noexcept-specs for TEMPLATE_DECLs.
gcc/testsuite/ChangeLog:
* g++.dg/modules/noexcept-5.h: New test.
* g++.dg/modules/noexcept-5_a.C: New test.
* g++.dg/modules/noexcept-5_b.C: New test.
* g++.dg/modules/noexcept-5_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
In r15-4861-g4a99443c5dd9a235022652ba0fb143c6370ea99d we added support
to handle recursive dependency clusters, where we need to find the
"entry" dependency that all other entities will hook off to ensure that
we stream merge keys in the correct order on read-in.
The logic I'd used to track the entry bit was not completely correct
however, leading to assertion failures in 'sort_cluster' where we found
that entities were not marked maybe_recursive when they should have
been, or multiple entities were marked as the entry point.
Consider a cycle of three entities in a cluster, 'A', 'B', and 'C',
where 'A' is the entry point. By definition we walk into 'A' first, and
find one of the other entities, 'B'. The old logic marked 'A' as the
entry and 'B' as maybe-recursive; so far this is correct.
But then if we walk into 'B' and find 'C' is maybe-recursive, the old
logic would mark 'B' as the entry point (again!). And likewise when we
walk into 'C' and find 'A'. So we would end up with three entry points.
Similar issues could happen with other arrangements of dependencies.
Instead, by aggressively marking everything we see as maybe-recursive,
and only marking an entry point if nothing we see is maybe-recursive, we
avoid this issue. We should only be able to discover these other
entities through the entry point (A) and so this 'flood fill' behaviour
should ensure that all entities are correctly marked maybe-recursive,
and only A is marked as an entry-point.
PR c++/118630
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_dependency): Correct entry point
corection for recursive clusters.
gcc/testsuite/ChangeLog:
* g++.dg/modules/late-ret-5.h: New test.
* g++.dg/modules/late-ret-5_a.H: New test.
* g++.dg/modules/late-ret-5_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
The following testcase is rejected, because we don't set all the needed
flags on range_decl in cp_parser_expansion_statement. During parsing
of the expansion stmt body, it should be treated as if there is a decl
with value dependent initializer in a template, because the value it will
have is yet to be determined (and possibly different in each instantiation
of the body).
For such decls, cp_finish_decl normally conservatively sets
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (because it might be initialized
by constant expression) and for non-references also sets TREE_CONSTANT
if decl_maybe_constant_var_p. Furthermore, those have a value dependent
initializer and DECL_DEPENDENT_INIT_P is set on those too.
The following patch arranges all of that for the range_decl.
2026-04-06 Jakub Jelinek <jakub@redhat.com>
PR c++/124488
* parser.cc (cp_parser_expansion_statement): Set
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P, DECL_DEPENDENT_INIT_P and
if maybe constant non-reference TREE_CONSTANT on range_decl.
* pt.cc (tsubst_stmt) <case TEMPLATE_FOR_STMT>: Set
DECL_DEPENDENT_INIT_P on decl.
* g++.dg/cpp26/expansion-stmt33.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
The current behavior of GCC is that we list all annotations gathered from
all the PARM_DECLs merged together on ^^fnparm or
variable_of (parameters_of (^^fn)[0]) and throw on annotations_of
on parameters_of (^^fn)[0]. The paper requires that the last one works
like we currently handle the former two, and for the former two we
filter out annotations that have not appeared on the function definition.
The following patch marks the annotations in grokfndecl before pushdecl
etc. merges it with other decls.
2026-04-06 Jakub Jelinek <jakub@redhat.com>
* decl.cc (grokfndecl): For -freflection mark annotations of
PARM_DECLs in a function definition.
* reflect.cc (eval_annotations_of): Allow annotations_of on
function parameters. For r which is a PARM_DECL without REFLECT_PARM,
filter out annotations not marked by grokfndecl.
(reflection_mangle_prefix): Preserve the grokfndecl marking of
annotations during mangling.
* g++.dg/reflect/annotations15.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
The Solaris installation information in install.texi urgently needed a
rewrite. It was highly repetitive, with information spread over both a
generic Solaris section and several separate ones for the different
configurations, and contained lots of cruft that's no longer relevant.
This patch merges all of them into a single Solaris section and attempts
a concise documentation of the requirements, configuration options and
quirks.
Tested on i386-pc-solaris2.11.
2026-03-26 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc:
* doc/install.texi (Specific, amd64-*-solaris2*, i?86-*-solaris2*)
(sparc-sun-solaris2*, sparc64-*-solaris2*, sparcv9-*-solaris2*)
(x86_64-*-solaris2*): Remove. Fold into ...
(Specific, *-*-solaris2*): ... this.
Rewrite.
When a parameter array declaration such as
character(*), parameter :: z(2) = [character(n) :: 'x', 'y']
is rejected, declaration-local charlen nodes from that statement can remain on
cl_list and later be resolved again. The charlen's length expression still
references the symbol 'n' whose symtree was already freed by gfc_undo_symbols,
causing a heap-use-after-free in resolve_charlen.
Clean up those statement-local charlens at the rejection point in decl.cc,
after clearing the surviving owners in that path.
PR fortran/79524
gcc/fortran/ChangeLog:
PR fortran/79524
* decl.cc (discard_pending_charlens): New helper.
(add_init_expr_to_sym): Drop statement-local charlens when
rejecting variable-length parameter arrays.
(variable_decl, do_parm, enumerator_decl): Save the current
namespace charlen list before parsing declarations with
initializers.
(match_procedure_decl): Adjust call to add_init_expr_to_sym.
gcc/testsuite/ChangeLog:
PR fortran/79524
* gfortran.dg/pr79524.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
[expr.unary.op] paragraph 9 says that the operand is
contextually converted to bool, so this should be legal.
PR c++/123087
gcc/cp/ChangeLog:
* typeck.cc (cp_build_unary_op): For TRUTH_NOT_EXPR, replace
call to perform_implicit_conversion with call to
contextual_conv_bool.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr1423.C: Additonal test.
Reviewed-by: Jason Merrill <jason@redhat.com>
Tests that use dg-do-if ERROR when the target selector matches, e.g.
ERROR: gcc.dg/vect/vect-simd-clone-16f.c -flto -ffat-lto-objects: compile: syntax error for " dg-do-if 1 compile { target { sse2_runtime && { ! sse4_runtime } } } "
While the error message isn't particularly helpful, it's from dg.exp
(dg-do): like the other dg-* procs it expects the line number to be the
first argument. However, dg-do-if strips that, so dg-do gets the target
selector instead of the expected action keyword.
Fixed by no longer stripping the line number.
Tested on amd64-pc-freebsd15.0 (sse2_runtime && !sse4_runtime),
i386-pc-solaris2.11 and x86_64-pc-linux-gnu (sse2_runtime &&
sse4_runtime).
2026-04-04 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
* lib/target-supports-dg.exp (dg-do-if): Don't strip line number
from args.
I knew this was coming, but hoped it would come later ;)
Basically, when one preprocesses <meta> + some reflection code and
attempts to fuzz it, we can ICE in various ways as we expect a sane
<meta>. In various places we've already tried to be defensive, error
out e.g. when we don't find the members we are looking for in <meta>
classes etc., plus when adding metafns.gperf I've added to the details
about each metafn the types of arguments and return type (which was
only partially used to evaluate e.g. the arguments in different ways
and prepare for the eval_* handlers, but checking of the types
wasn't actually done.
This patch introduces some limited checking of the return type and
argument types to make sure they are sane. Plus I've noticed the
can_substitute marking said incorrectly it returns info when it returns
bool.
The reflection_range/input_range arguments aren't checked, because they
can be all kinds of things and get_range_elts already does a lot of
checking. Similarly METAFN_KIND_ARG_TEMPLATE_PARM*, those aren't even
argument types, just a hack to tell the code that it needs to supply
the template parameter to the eval_* handlers.
2026-04-05 Jakub Jelinek <jakub@redhat.com>
PR c++/124689
* metafns.gperf (enum metafn_kind): Add
METAFN_KIND_BOOL_INFO_REFLECTION_RANGE.
(can_substitute): Use METAFN_KIND_BOOL_INFO_REFLECTION_RANGE
instead of METAFN_KIND_INFO_INFO_REFLECTION_RANGE.
(METAFN_KIND_ARG): Add MINFO argument.
(METAFN_KIND_RET): Define.
* reflect.cc (is_std_meta_class): New function.
(get_info): Add LOC argument, diagnose invalid argument type instead
of failing assertion.
(check_metafn_arg_type): New function.
(check_metafn_return_type): New function.
(process_metafunction): Diagnose clearly invalid return
or argument types. Use rettype variable instead of TREE_TYPE (call).
* metafns.h: Regenerate.
* g++.dg/reflect/pr124689.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
Copy the SPREAD intrinsic descriptor before specializing the character
formal argument type so other uses keep the generic signature.
PR fortran/109788
gcc/fortran/ChangeLog:
* iresolve.cc (copy_intrinsic_sym): New helper.
(gfc_resolve_spread): Copy the intrinsic descriptor before
specializing the character formal argument type.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr109788.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
This is a regression present on the mainline and 15 branch. The problematic
allocation may occur when the result type of the function is a discriminated
record type with defaulted discriminants. Although it had been present for
a long time when the type is limited, the problem was recently propagated
to nonlimited types because of an optimization.
While the fix is a one-liner, the change also makes it so that SS_Allocate
raises a Storage_Error when the size overflows, like the other allocators.
gcc/ada/
* exp_ch6.adb (Expand_Simple_Function_Return): Use a constant return
object when the simple return is rewritten as an extended one.
* libgnat/s-secsta.adb (SS_Allocate): Raise Storage_Error if the
requested size is negative.
* libgnat/s-secsta__cheri.adb (SS_Allocate): Likewise.
gcc/testsuite/
* gnat.dg/aggr35.adb: New test.
* gnat.dg/aggr35_pkg.ads, gnat.dg/aggr35_pkg.adb: New helper.
The documentation for Picolibc options was inserted at the top level
within the GCC options section. It really should be classified with
the target-specific options; that's where we document other options
specific to the runtime configuration, including MinGW, Darwin,
Gnu/Linux, etc.
gcc/ChangeLog
* doc/invoke.texi (GCC Command Options): Move Picolibc Options
section to Target-Specific Options.
(Option Summary): Likewise.
The node name "Submodel Options" is not meaningful, and the section name
"Machine-Dependent Options" is misleading since this section also contains
subsections documenting options for the software environment on the target
as well as its hardware -- for example, Windows/Cygwin/MinGW, Darwin, etc.
"Target-Specific Options" is a better name for it as we already use that
phrasing elsewhere, e.g. "Target-Specific Attributes".
gcc/ChangeLog
* doc/extend.texi (Common Attributes): Fix cross-reference for
renamed "Submodel Options" -> "Target-Specific Options".
* doc/invoke.texi (Invoking GCC): Likewise for the menu.
(Option Summary): Likewise for the use here.
(Submodel Options): Rename to Target-Specific Options. Leave
an anchor with the old name. Add better index entries. Rewrite
introductory text.
(Precompiled Headers): Fix another cross-reference.
The CX16 extension seems to have been omitted from the documentation
entries for a couple of early CPUs that supported it, which were
subsequently cut-and-pasted for newer models. I checked the code
against the list of CPUs in the issue and found one more (novalake)
affected CPU that was added since then.
gcc/ChangeLog
PR target/107337
* doc/invoke.texi (x86 Options): Add CX16 feature to nocona,
alderlake, arrowlake, arrowlake-s, pantherlake, novalake,
bonnell, sierraforest, grandridge, clearwaterforest, and amdfam10
family processors.
The following splits the standard pattern names section into two
(for now), listing vector related patterns separately. It also
adds a separate index for the many standard pattern names we have,
something long overdue.
* doc/gccint.texi: Add named pattern index with @mdindex.
* doc/md.texi (Standard Pattern Names For Generation): Split
table into two using subsections, splitting out vectorizer
related standard patterns. Use @mdindex for all standard
pattern names.
This patch addresses PR c++/124573 by making finish_enum_value_list more
robust to DECL_INITIAL being NULL, which I believe only occurs in the
event of an error, and treating it as integer_zero_node for the purposes
of error recovery.
2026-04-04 Roger Sayle <roger@nextmovesoftware.com>
gcc/cp/ChangeLog
PR c++/124573
* decl.cc (finish_enum_value_list): Defend against a DECL_INITIAL
being NULL during error recovery.
gcc/testsuite/ChangeLog
PR c++/124573
* g++.dg/other/enum4.C: New test case.
The following patch implements the proposed resolution of
https://wg21.link/cwg3119
Temporarily setting processing_template_decl around the
cp_parser_simple_declaration causes all kinds of ICEs and miscompilations,
this patch just sets in_expansion_stmt around it and allows the sb
pack in that case.
2026-04-04 Jakub Jelinek <jakub@redhat.com>
* parser.cc (cp_parser_expansion_statement): Temporarily set
in_expansion_stmt to true around cp_parser_simple_declaration
for range_decl.
(cp_parser_decomposition_declaration): Don't reject structured binding
packs if in_expansion_stmt is set.
* g++.dg/cpp26/expansion-stmt34.C: New test.
The rest of this test is still relevant, thus only the (b)float16_t
tests are made optional rather than skipping the whole test via
dg-effective-target.
libstdc++-v3/ChangeLog:
PR libstdc++/124722
* testsuite/std/simd/traits_impl.cc: Add __STDCPP_FLOAT16_T__
and __STDCPP_BFLOAT16_T__ guards.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
I still haven't figured out how to correctly mangle the case
in pack-indexing9.C where write_type is called with PACK_INDEX_TYPE
where PACK_INDEX_PACK is TREE_VEC of types, i.e. already expanded pack,
but given that right now we sorry on mangling of all PACK_INDEX_TYPE
or PACK_INDEX_EXPR trees, I think the following patch is an incremental
progress in the right direction and just mangles what is clearly specified
in the proposal.
This patch relies on the PR124198 patch I've just posted, because the
casts to size_t change mangling of pack...[1] from having i1 in it
to m1 (on x86_64, j1 on ia32, ...).
2026-04-04 Jakub Jelinek <jakub@redhat.com>
PR c++/124487
* mangle.cc (write_type) <case PACK_INDEX_TYPE>: Handle pack index
mangling unless (for now) PACK_INDEX_PACK is a TREE_VEC.
(write_expression): Handle PACK_INDEX_EXPR.
* g++.dg/cpp26/pack-indexing7.C: Don't xfail dg-bogus.
* g++.dg/cpp26/pack-indexing22.C: New test.
https://eel.is/c++draft/expr.prim.pack.index#2 says:
The constant-expression shall be a converted constant expression of type
std::size_t whose value V, termed the index, is such that 0<=V<sizeof...(P).
But we actually don't implement it like that, instead just error out if
the index doesn't have an integral type or is negative.
Because of this we don't call mark_rvalue_use on it, so on pack-indexing20.C
we report a bogus warning that the var used in the index is unused but set,
and more importantly we reject the IMHO valid testcase pack-indexing21.C.
The following patch calls build_converted_constant_expr to make sure it
is converted, marked as read, if not possible to be converted diagnostics
is emitted.
2026-04-04 Jakub Jelinek <jakub@redhat.com>
PR c++/124198
* parser.cc (cp_parser_pack_index): If index is not type dependent,
call build_converted_constant_expr on it. Return error_mark_node
if index is error_operand_p.
* pt.cc (tsubst_pack_index): Likewise.
* g++.dg/cpp26/pack-indexing2.C (getT2, badtype4): Expect different
diagnostics.
* g++.dg/cpp26/pack-indexing20.C: New test.
* g++.dg/cpp26/pack-indexing21.C: New test.
Fix undefined reference error when compiling with -O0.
libstdc++-v3/ChangeLog:
* testsuite/20_util/optional/ref/access.cc: Provide
definition for foo().
Previously, address displacement mitigation measures for exceeding machine
instruction limits involved using only one ADDMI machine instruction
(adding an immediate value that is a multiple of 256) to cover approxi-
mately 32 kilobytes before and after the address.
This patch expands the range covered by the mitigation by doubling it by
using just one more ADDMI instruction, slightly more advantageous than the
result without the mitigation, ie., covering the displacement amount by
loading from constant pool or using CONST16 instruction pair.
/* example */
int test(int a[]) {
return a[4] + a[16032];
}
;; before (-O2 -mconst16)
test:
entry sp, 32
movi.n a8, 0 ;; 3 instructions
const16 a8, 64128 ;;
add.n a8, a2, a8 ;;
l32i.n a8, a8, 0
l32i.n a2, a2, 16
add.n a2, a2, a8
retw.n
;; after (-O2 -mconst16)
test:
entry sp, 32
addmi a8, a2, 0x7b00 ;; 2 instructions
addmi a8, a8, 0x7f00 ;;
l32i.n a2, a2, 16
l32i a8, a8, 128
add.n a2, a2, a8
retw.n
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_legitimize_address):
Add code to legitimize the displacement of 64 kilobytes before and
after using two ADDMI instructions.
The previously added alternative negsf2 pattern (for cases where both
source and destination are GP registers) directly specified multiple
machine instructions in the output template, but this patch replaces
that with an RTL representation using the split pattern, to increase
opportunities for instruction reordering.
gcc/ChangeLog:
* config/xtensa/xtensa.md (negsf2):
Change define_insn to define_insn_and_split, and replace the
corresponding output template with the split pattern.
Since the previous commit 6924c00c87 ("xtensa:
Make all memory constraints special"), it has been discovered that the
definition of TARGET_DIFFERENT_ADDR_DISPLACEMENT_P, which was previously
introduced to obtain appropriate memory reference displacements (commit
211459e121), is no longer necessary. In other
words:
- The order of the movsi_internal MD pattern alternatives has been re-
arranged so that memory references with shorter displacements take
precedence
- Furthermore, since all memory constraints are now "special," address
reload operations that explicitly add the displacement to the base
register and then adopt a 0-displacement reference are no longer
performed and are simply skipped
Therefore, this patch removes the definition of
TARGET_DIFFERENT_ADDR_DISPLACEMENT_P.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (TARGET_DIFFERENT_ADDR_DISPLACEMENT_P):
Remove.
If the memory constraint definition includes (match_code "MEM"), then
the subsequent 'op' is undoubtedly MEM rtx, and all that remains is to
determine if 'XEXP (op, 0)' is the address corresponding to that
definition using (match_test "...").
This patch eliminates the need to call MEM_P() again in the predicate
function called from (match_test "...") in the memory constraint
definitions.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (smalloffset_mem_p):
Rename it to smalloffset_address_p and remove the result check
of MEM_P().
(constantpool_address_p): Change from static scope to global.
* config/xtensa/xtensa-protos.h (smalloffset_mem_p):
Rename it to smalloffset_address_p.
(constantpool_address_p): New function prototype.
* config/xtensa/constraints.md (R):
Change the call in (match_test "...") from smalloffset_mem_p()
to smalloffset_address_p().
(T, U): Change the call in (match_test "...") from
constantpool_mem_p() to constantpool_address_p().
When symbols from the intrinsic module ISO_C_BINDING were USEd indirectly,
the resolution of generic interfaces with procedures having dummies with
TYPE(C_PTR) or TYPE(C_FUNPTR) could fail when the actual argument was
C_LOC() or C_FUNLOC(). Amend checking of actual versus formal procedure
arguments to these cases.
PR fortran/66973
gcc/fortran/ChangeLog:
* interface.cc (gfc_compare_actual_formal): Check that C_LOC and
C_FUNLOC from ISO_C_BINDING as actual argument are passed to a
dummy argument of matching type C_PTR/C_FUNPTR.
gcc/testsuite/ChangeLog:
* gfortran.dg/generic_36-1.f90: New test.
* gfortran.dg/generic_36-2.f90: New test.
PR libfortran/124543
libgfortran/ChangeLog:
* io/inquire.c (inquire_via_unit): Adjust the logic to
treat formatted vs unformatted correctly.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr124543.f90: Set result to 'UNDEFINED' in two
places.
At first glance, the GCC manual's section documenting decimal floating
point support as a C extension appears to be bit-rotten, since this
feature is now standardized in ISO C23. In fact, though, GCC's
implementation is based on the older N1312 proposal, and full C23
support is not yet available. This patch makes the GCC manual say that
explicitly.
gcc/ChangeLog
PR c/123234
* doc/extend.texi (Decimal Float): Clarify that GCC really does
support only the older N1312 draft as documented here, not the
standard C23 functionality yet.
If the promise ctor throws, the EH cleanup will access refcount before
it is initialized. Initialize it to zero so that cleanups can take
place.
This seems very hard to hit on systems that ensure the stack starts
out zero-initialized, but on VxWorks in kernel mode, this hits more
often than not on various architectures.
for gcc/cp/ChangeLog
* coroutines.cc (cp_coroutine_transform::build_ramp_function):
Zero-initialize refcount.
PR target/123210 was fixed by
commit r16-7563-gb54533a28632482e91d7dfbbc47c75fb6d5e78bb
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Feb 17 09:51:58 2026 +0800
x86: Update stack alignment only if stack is used
Add a test to verify the fix.
PR target/123210
* gcc.target/i386/pr123210.c: New test.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
The following testcase ICEs because it tries to use a freed strinfo.
strinfo uses refcounting and vectors of pointers to those are either shared
in between bbs or unshared when some later bb needs to modify something.
The ICE is due to the second memcpy handling. Since r10-5451 it first
calls get_stridx on dst (&a), then get_strinfo with the returned index and
then get_stridx on src (&a + 24). &a has been referenced earlier and
the pass knows some details on its string length (let's ignore that the
testcase invokes UB for now, I think it can happen even on valid code,
just haven't managed to adjust the testcase, but supposedly the unreduced
original is valid), so the strinfo is shared with other bbs.
WHen get_stridx is called for &a + 24, it sees it doesn't know anything
about that yet and wants to create a strinfo for it. But related strinfos
are chained, so &a's next should be &a + 24 in this testcase, that means
we need to unshare the &a strinfo so that we can modify it while keeping
the one entry used by earlier bbs unmodified. The problem is that
handle_builtin_memcpy called get_strinfo before this, so it got hands on
the old still not unshared strinfo for &a and because it isn't refreshed
after the get_stridx call by another get_strinfo call, we try to unshare
it again and break the refcounting.
So, basically for calls which call get_stridx twice, we need top make sure
we do both get_stridx calls before the first get_strinfo call, or repeat
get_strinfo after the second get_stridx call.
In handle_builtin_memcpy it used to be right and got broken by r10-5451,
but I'm in strcpy/strcat handling I've screwed it up since the pass was
added.
Fixed thusly.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/124754
* tree-ssa-strlen.cc (strlen_pass::handle_builtin_strcpy): Make
sure both get_stridx calls are done before first get_strinfo call.
(strlen_pass::handle_builtin_memcpy): Likewise.
(strlen_pass::handle_builtin_strcat): Likewise.
* g++.dg/tree-ssa/strlenopt-3.C: New test.
Reviewed-by: Jeffrey Law <jeffrey.law@oss.qualcomm.com>
The following patch attempts to implement the
P3842R2 - A conservative fix for constexpr uncaught_exceptions()
and current_exception()
paper. std::current_exception() and std::uncaught_exceptions() aren't
constexpr anymore (admittedly, they weren't declared that way in the
headers before either, but the FE magically treated them as such),
instead two new FE builtins are introduced so that one can get their
behavior before this patch when needed. So, at constant evaluation
time they are constant evaluated and if they are not folded away,
they are transformed into std::current_exception() or
std::uncaught_exceptions() runtime calls during gimplification.
And nested_exception isn't constexpr anymore either.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
gcc/cp/
* cp-tree.h (enum cp_built_in_function): Add
CP_BUILT_IN_CURRENT_EXCEPTION and CP_BUILT_IN_UNCAUGHT_EXCEPTIONS.
* tree.cc (builtin_valid_in_constant_expr_p): Handle
those.
* decl.cc (cxx_init_decl_processing): Build
decls for CP_BUILT_IN_CURRENT_EXCEPTION and
CP_BUILT_IN_UNCAUGHT_EXCEPTIONS.
(require_deduced_type): Deduce CP_BUILT_IN_CURRENT_EXCEPTION
return type.
* cp-gimplify.cc (cp_gimplify_expr): Handle
CP_BUILT_IN_CURRENT_EXCEPTION and CP_BUILT_IN_UNCAUGHT_EXCEPTIONS.
* constexpr.cc (enum cxa_builtin): Remove STD_UNCAUGHT_EXCEPTIONS
and STD_CURRENT_EXCEPTION, add BUILTIN_UNCAUGHT_EXCEPTIONS and
BUILTIN_CURRENT_EXCEPTION, renumber some enumerators.
(cxx_cxa_builtin_fn_p): Don't check for std::uncaught_exceptions
nor std::current_exception.
(cxx_eval_cxa_builtin_fn): Handle BUILTIN_UNCAUGHT_EXCEPTIONS
and BUILTIN_CURRENT_EXCEPTION instead of STD_UNCAUGHT_EXCEPTIONS
and STD_CURRENT_EXCEPTION.
(cxx_eval_builtin_function_call): Handle
CP_BUILT_IN_CURRENT_EXCEPTION and CP_BUILT_IN_UNCAUGHT_EXCEPTIONS.
Do just one fndecl_builtin_p check for BUILT_IN_FRONTEND and
switch on DECL_FE_FUNCTION_CODE.
gcc/testsuite/
* g++.dg/cpp26/constexpr-eh3.C: Use __builtin_current_exception()
instead of std::current_exception() and
__builttin_uncaught_exceptions() instead of
std::uncaught_exceptions(). Remove nested_exception related parts
of the test.
* g++.dg/cpp26/constexpr-eh8.C: Use __builtin_current_exception()
instead of std::current_exception().
libstdc++-v3/
* libsupc++/exception_ptr.h (std::make_exception_ptr): Use
__builtin_current_exception() instead of current_exception() if
the builtin exists.
* libsupc++/nested_exception.h: Revert 2026-01-07 and 2025-07-10
changes.
* testsuite/18_support/exception_ptr/exception_ptr_cast.cc (test01):
Use __builtin_current_exception instead of std::current_exception
if __has_builtin(__builtin_current_exception). Otherwise don't
try to constant evaluate test01.
Reviewed-by: Jason Merrill <jason@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
The documentation of -Wchar-subscripts was missing cross-references to
discussion elsewhere in the manual about how the char type may be either
signed or unsigned. Besides adding the references, I've also done some
improvements to those two other sections.
gcc/ChangeLog
PR other/94182
* doc/implement-c.texi (Characters implementation): Add
cross-reference to more detailed discussion about signedness.
* doc/invoke.texi (C Dialect Options): Combine -fsigned-char
and -funsigned-char table entries since the following discussion
applies to both. Add an anchor so other things can point at it.
(Warning Options): Add cross-references to the above two places.
Clarify that the warning is given regardless of whether char is
signed or unsigned.
PR fortran/124652
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): Do not clobber a
procedure pointer intent(out) argument.
* trans-intrinsic.cc (conv_isocbinding_function): When passing to
C_FUNLOC a procedure pointer that is a dummy, dereference it.
gcc/testsuite/ChangeLog:
* gfortran.dg/c_funloc_tests_10.f90: New test.
The reproducer from the bug report compiles cleanly on current
trunk. Add a testcase to prevent future regressions.
PR fortran/98203
gcc/testsuite/ChangeLog:
PR fortran/98203
* gfortran.dg/gomp/pr98203.f90: New test.
Signed-off-by: Christopher Albert <albert@tugraz.at>
As written in https://wg21.link/lwg4517 , unnamed bit-fields shall not
be declared with cv-qualified types, so the following patch rejects it
when trying to create that in data_member_spec.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
* reflect.cc (eval_data_member_spec): Implement C++26 LWG4517
- data_member_spec should throw for cv-qualified unnamed bit-fields.
* g++.dg/reflect/data_member_spec2.C: Add tests for unnamed bit-fields
with const and/or volatile types.
Reviewed-by: Jason Merrill <jason@redhat.com>
Another testcase for something we already implement the desired way.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
* g++.dg/reflect/define_aggregate10.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
The issue clarifies what the *string_view points to is not valid for
template arguments with pointer type, the following testcase verifies
that we already reject it.
2026-04-03 Jakub Jelinek <jakub@redhat.com>
* g++.dg/reflect/lwg4556.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
