These pp_printf/pp_verbatim format strings should be gcc-internal-format,
they use the pretty-print.cc format specifier handling rather than libc
*printf, but pp_printf/pp_verbatim are intentionally not handled through
exgettext because not everything done through them should be translated
(e.g. its use for dump files shouldn't be).
In addition, composing translatable messages from
"in requirements " and later on "with " might make it harder to be
translated.
I've verified these strings (at least those which don't use format
specifiers added post GCC 4.3 which gettext doesn't handle) are properly
marked as gcc-internal-format in gcc.pot. The lack of that caused
ICEs on German translation of the "%s%s%sIn instantiation of %q#D:\n"
message because it contained too many %s.
2025-04-10 Jakub Jelinek <jakub@redhat.com>
PR translation/119684
* error.cc (cp_print_error_function): Use G_ instead of _ for
pp_printf arguments.
(function_category): Use G_ instead of _.
(print_instantiation_full_context): Use G_ instead of _ in pp_verbatim
arguments.
(print_location): Likewise.
(print_instantiation_partial_context): Likewise.
(maybe_print_constexpr_context): Likewise.
(print_constrained_decl_info): Use G_() around pp_verbatim argument.
(print_concept_check_info): Likewise.
(print_constraint_context_head): Likewise.
(print_requires_expression_info): Likewise. Merge separate pp_verbatim
"in requirements " and "with " into one with conditional messages.
The P3379R0 bump to __cpp_lib_constrained_equality relates to changes
that only affect std::expected, so there's no reason to define the
updated value in C++20.
This change restores the previous value (202403) for C++20, and only
uses the new value (202411) for C++23 and later.
Also remove the TODO comments, because I correctly predicted that the
final value would be 202411.
libstdc++-v3/ChangeLog:
* include/bits/version.def (constrained_equality): Only define
as 202411 for C++23 and later, use 202403 for C++20.
* include/bits/version.h: Regenerate.
* testsuite/20_util/expected/equality_constrained.cc: Remove
TODO comment.
Now that we have libquadmath support, we can enable for x86_64, at
least.
libgcobol/ChangeLog:
* configure.tgt: Enable for x86_64 Darwin.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
Here when we went to mangle the constraints of from<0>, the outer lambda has
no mangling scope, but the inner one was treated as having the outer one as
its scope. And mangling the outer one means mangling its constraints, which
include the inner one. So infinite recursion.
But a lambda closure type isn't a scope that anything should have for
mangling, the inner lambda should also have no mangling scope.
PR c++/119175
gcc/cp/ChangeLog:
* mangle.cc (decl_mangling_context): Look through lambda type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-lambda23.C: New test.
_GLIBCXX_USE_LONG_LONG is now defined by configure.
2025-04-05 John David Anglin <danglin@gcc.gnu.org>
libstdc++-v3/ChangeLog:
* config/os/hpux/os_defines.h: Remove _GLIBCXX_USE_LONG_LONG
define.
This just follows the common pattern used for other runtime libs.
gcc/ChangeLog:
* config/darwin.h (LINK_SPEC): Add support for
-static-libgcobol.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
We currently only INTEGER_CST, but not POLY_INT_CST, which leads
to the situation that when the POLY_INT_CST is only indrectly
present via a SSA def the IL is valid but when propagated it's not.
That's unsustainable.
PR middle-end/119706
* gimple-expr.cc (is_gimple_mem_ref_addr): Also allow
POLY_INT_CST.
Many of the changes are mechanical:
1. 'GCOB_FP128' in place of _Float128.
2. Using FP128_FUNC to represent the spelling of intrinsics.
3. Using GCOB_FP128_LITERAL() to choose the suffix for literals.
This allows for:
__float128 and 'q' as the suffix when libquadmath is configured.
_Float128 / 'f128' when IEC-60559 is available in libc
long double / 'l' when long double is ieee753 128b.
Add libquadmath to libgcobol.spec and its dependencies where the
platform needs it.
PR cobol/119244
libgcobol/ChangeLog:
* Makefile.am: Add support for libquadmath.
* Makefile.in: Regenerate.
* acinclude.m4: Add support for libquadmath.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Configure libquadmath support.
* gmath.cc: Use GCOB_FP128 to represent the configured
128b floating point type. Use FP128_FUNC to represent
the naming of intrinsics in the configure 128b floating
point type. Render literals with GCOB_FP128_LITERAL.
* intrinsic.cc: Likewise.
* libgcobol.cc: Likewise.
* libgcobol.h: Likewise.
* libgcobol-fp.h: New file.
* gfileio.cc: Include libgcobol-fp.h.
* libgcobol.spec.in: Add libquadmath configure output.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
Even when we are using IEC 128b floating point, the quadmath library can
be pulled in 'as needed'.
gcc/testsuite/ChangeLog:
* lib/cobol.exp: Add libquadmath paths.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
In r10-4803-g8489e1f45b50600c I'd used POINTER_DIFF_EXPR to subtract
the two pointers involved in an overlap test. I'm not sure whether
I'd specifically chosen that over MINUS_EXPR or not; if so, the only
reason I can think of is that it is probably faster on targets with
PSImode pointers. Regardless, as the PR points out, subtracting
unrelated pointers using POINTER_DIFF_EXPR is undefined behaviour.
gcc/
PR tree-optimization/119399
* tree-data-ref.cc (create_waw_or_war_checks): Use a MINUS_EXPR
on two converted pointers, rather than converting a POINTER_DIFF_EXPR
on the pointers.
gcc/testsuite/
PR tree-optimization/119399
* gcc.dg/vect/pr119399.c: New test.
Large code model is only supported on RV64, so we don't need to
generate the multilibs for RV32 with --cmodel=large. And the compact
code model is something we don't supported on upstream (which is
accidentally added in the past), so we need to remove it.
gcc/ChangeLog:
* config/riscv/multilib-generator: Remove the compact code model
and check large code model for RV32.
It was proposed in PR112490 to also adjust basic_const_iterator's friend
operator-(sent, iter) overload alongside the r15-7757-g4342c50ca84ae5
adjustments to its comparison operators, but we lacked a concrete
testcase demonstrating fixable constraint recursion there. It turns out
Hewill Kang's PR115046 is such a testcase! So this patch makes the same
adjustments to that overload as well, fixing PR115046. The LWG 4218 P/R
will need to get adjusted too.
PR libstdc++/115046
PR libstdc++/112490
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (basic_const_iterator::operator-):
Replace non-dependent basic_const_iterator function parameter with
a dependent one of type basic_const_iterator<_It2> where _It2
matches _It.
* testsuite/std/ranges/adaptors/as_const/1.cc (test04): New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Here we substitute into the inner lambda twice, first during default
argument substitution for the outer template parameters, then during
that for the inner template parameters.
For the second testcase (which is easier to follow/debug), the first
substitution into the inner lambda is with the template arguments
{0, NULL_TREE}, which we defer because it's an incremental substitution.
For the second and final substitution we have the template arguments
{1, NULL_TREE}, which we try combining via add_extra_args and ICE on
the checking assert because TREE_STATIC isn't set on the deferred
arguments but the template arguments are considered dependent.
The template arguments aren't dependent however -- they're just
incomplete because when we deferred them we were in the middle of
deduction, and we consider a NULL_TREE template argument as dependent.
If we remove this checking assert, we go on to correctly merge the
template arguments into {{0, NULL_TREE}, {1, NULL_TREE}}. So this
patch just removes this imprecise assert.
PR c++/119574
gcc/cp/ChangeLog:
* pt.cc (add_extra_args): Remove checking assert.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ13.C: New test.
* g++.dg/cpp2a/lambda-targ13a.C: New test.
* g++.dg/cpp2a/lambda-targ13b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
gcc/cobol
PR cobol/119682
* genapi.cc: (cobol_compare): Change the call to __gg__compare().
libgcobol
PR cobol/119682
* common-defs.h: Define the REFER_T_REFMOD constant.
* intrinsic.cc: (__gg__max): Change the calls to __gg__compare_2(),
(__gg__min): Likewise, (__gg__ord_min): Likewise,
(__gg__ord_max): Likewise.
* libgcobol.cc: (__gg__compare_2): Change definition of calling
parameters, eliminate separate flag bit for ALL and ADDRESS_OF,
change comparison of alphanumeric to numeric when the numeric
is a refmod.
* libgcobol.h: Change declaration of __gg__compare_2.
I've noticed we talk about %Ns even when that isn't supported and
we actually only support %.Ns which the comment describes.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
* pretty-print.cc (pretty_printer::format): Use %.Ns instead of
%Ns in function comment.
During make gcc.pot I've noticed among tons of other warnings (e.g. because
can't appears in non-C/C++ style comment and so gettext considers it
unterminated) a warning where the lack of " looked unintentional.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
* gm2-compiler/M2MetaError.def: Fix comment typo, range" -> "range2".
Here is a cherry-pick from glibc [BZ #32411] fix.
As mentioned by the reporter in a pull request against gcc-mirror,
the THREEp96 constant in e_expl.c is incorrect, it is actually 0x3.p+94f128
rather than 0x3.p+96f128.
The algorithm uses that to compute the t2 integer (tval2), by whose
delta it adjusts the x+xl pair and then in the result uses the precomputed
exp value for that entry.
Using 0x3.p+94f128 rather than 0x3.p+96f128 results in tval2 sometimes
being one smaller, sometimes one larger than the desired value, thus can mean
the x+xl pair after adjustment will be larger in absolute value than it
should be.
DesWursters created a test program for this
https://github.com/DesWurstes/comparefloats
and his results were
total: 1135000000 not_equal: 4322 earlier_score: 674 later_score: 3648
I've modified this so with
https://sourceware.org/bugzilla/show_bug.cgi?id=32411#c3
so that it actually tests pseudo-random _Float128 values with range
(-16384.,16384) with strong bias on values larger than 0.0002 in absolute
value (so that tval1/tval2 aren't zero most of the time) and that gave
total: 10000000000 not_equal: 29861 earlier_score: 4606 later_score: 25255
So, in both cases, in most cases the change doesn't result in any differences,
and in those rare cases where does, about 85% have smaller ulp than without
the patch.
Additionally I've tried
https://sourceware.org/bugzilla/show_bug.cgi?id=32411#c4
and in 2 billion iterations it didn't find any case where x+xl after the
adjustments without this change would be smaller in absolute value compared
to x+xl after the adjustments with this change.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
* math/expq.c (C): Fix up THREEp96 constant.
r12-2601 has added this define_insn_and_split and corresponding
(define_insn ""
[(set (reg:CCZ CC_REG)
(eq (zero_extract:HSI (match_operand:HSI 0 "register_operand" "r")
(const_int 1)
(match_operand 1 "const_int_operand" "n"))
(const_int 0)))]
"INTVAL (operands[1]) < 16"
"btst %Z1,%Y0"
[(set_attr "length" "2")])
pattern into which the define_insn_and_split wants to splut in addition
to a conditional jump.
But as can be seen, the btst define_insn uses HSI mode iterator while
define_insn_and_split QHSI, so for QImode it splits into something that
can't be recognized.
This was probably latent since r12-2601 and on the attached testcase
is reproduceable starting with r15-1945 - a late combiner change.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
PR target/119664
* config/h8300/jumpcall.md (bit test and jump define_insn_and_split):
Use HSI iterator rather than QHSI.
* gcc.dg/pr119664.c: New test.
This was fixed with r15-9329-gf183ae0ae891a471764876eb but
only a RISC-V V testcase was added. So this adds an aarch64
SVE testcase too.
Pushed as obvious after a quick test to make sure it passes.
PR middle-end/116595
gcc/testsuite/ChangeLog:
* g++.target/aarch64/sve/pr116595.C: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Calling `rest_of_type_compilation' as the D types were built meant that
debug info was being emitted before all forward references were
resolved, resulting in DW_AT_name's to be missing.
Instead, defer outputting type debug information until all modules have
been parsed and generated in `d_finish_compilation'.
PR d/118309
gcc/d/ChangeLog:
* modules.cc: Include debug.h
(d_finish_compilation): Call debug_hooks->type_decl on all TYPE_DECLs.
* types.cc: Remove toplev.h include.
(finish_aggregate_type): Don't call rest_of_type_compilation or
rest_of_decl_compilation on type.
(TypeVisitor::visit (TypeEnum *)): Likewise.
gcc/testsuite/ChangeLog:
* gdc.dg/debug/dwarf2/pr118309.d: New test.
PR fortran/119656
gcc/fortran/ChangeLog:
* interface.cc (gfc_compare_actual_formal): Fix front-end memleak
when searching for matching interfaces.
* trans-expr.cc (gfc_conv_procedure_call): If there is a formal
dummy corresponding to an absent argument, use its type, and only
fall back to inferred type otherwise.
gcc/testsuite/ChangeLog:
* gfortran.dg/optional_absent_13.f90: New test.
Trivial fallout from the recent combine work. We end up with a srai rather
than an xor in some of the saturation sequences. Both variants look equally
performant, so I'm just adjusting the expected test output.
gcc/testsuite
* gcc.target/riscv/sat/sat_s_sub-1-i64.c: Update expected output.
* gcc.target/riscv/sat/sat_s_sub-2-i64.c: Likewise.
* gcc.target/riscv/sat/sat_s_sub-3-i64.c: Likewise.
* gcc.target/riscv/sat/sat_s_sub-4-i64.c: Likewise.
Asterisk in []* regexp applies to bracket expression. When asterisk is
a part of the word, then it needs to be escaped with \\.
Also use []+ instead of []* to match elements in bracket expression
one or more times.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr67215-1.c: Correctly escape
asterisk in scan-assembler dirctive.
* gcc.target/i386/pr67215-2.c: Ditto.
Warnings about pointer sizes cause the test to fail
incorrectly. A dummy return value is also added to
set_marker_internal for completeness to suppress a
-Wreturn-type warning even though gcc does not issue
it by default.
Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/testsuite/ChangeLog:
PR analyzer/113253
* gcc.dg/analyzer/deref-before-check-pr113253.c:
(ptrdiff_t): use stddef.h type.
(uintptr_t): ditto.
(EMACS_INT): ditto.
(set_marker_internal): Add dummy 0 to suppress -Wreturn-type.
The recent combine changes twiddled code generation ever so slightly on risc-v
and is causing pr117722.c to fail.
The relevant change is this sequence to perform an abs() across elements in a
vector:
> ! vwsubu.vv v1,v4,v3
> vsetvli zero,zero,e16,mf2,tu,ma
> - vrsub.vi v3,v1,0
> - vmax.vv v1,v1,v3
Turns into:
> ! vwsubu.vv v1,v3,v4
> ! vwsubu.vv v5,v4,v3
> vsetvli zero,zero,e16,mf2,tu,ma
> + vmax.vv v1,v1,v5
There's other trivial differences, but that highlights the key change in the
abs sequence.
The first sequence has lower register pressure since it synthesizes the
negation using vrsub.vi.
The second sequence is better from a data dependency standpoint as the two
vwsubu instructions can execute in parallel on designs with > 1 vector ALU.
I don't consider either sequence inherently better than the other. So I'm just
adjusting the test to accept our new code.
gcc/testsuite
* gcc.target/riscv/rvv/autovec/pr117722.c: Adjust expected output.
On Wed, Apr 09, 2025 at 02:38:01PM +0200, Mark Wielaard wrote:
> Unfortunately this seems to have broken the riscv bootstrap:
> https://builder.sourceware.org/buildbot/#/builders/337/builds/105
>
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_MAP’ not handled in switch [-Werror=switch]
> 4730 | switch (context)
> | ^
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_MAP_IMP_REF’ not handled in switch [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_PRIVATE’ not handled in switch [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_FIRSTPRIVATE’ not handled in switch [-Werror=switch]
> ../../gcc/gcc/config/riscv/riscv-vector-builtins.cc:4730:10: error: enumeration value ‘TCTX_OMP_DEVICE_ADDR’ not handled in switch [-Werror=switch]
> cc1plus: all warnings being treated as errors
Indeed, riscv-vector-builtins.cc IMHO needs pretty much the same
changes as aarch64, just with s/SVE/RVV/g.
I've also left out default: break; so that it is caught next time
somebody adds further enumerators.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
* config/riscv/riscv-vector-builtins.cc (verify_type_context):
Diagnose RVV types for a given OpenMP context.
The previous change to fix LRA rematerialization broke compare-debug
for i586 bootstrap. Fixed by using prev_nonnote_nondebug_insn
instead of prev_nonnote_insn.
PR rtl-optimization/119689
PR rtl-optimization/115568
* lra-remat.cc (create_cands): Use prev_nonnote_nondebug_insn
to check whether insn2 is directly before insn.
* g++.target/i386/pr119689.C: New testcase.
Adds a new wrapper function for `build_constructor', and calls it
instead to ensure that all CONSTRUCTOR nodes explicitly created by the
front-end have CONSTRUCTOR_ZERO_PADDING_BITS set.
Some places may not be necessary as it's guaranteed for there to be no
padding in the type, such as D dynamic arrays. Other places this gets
turned into a double-memset when optimizations are turned off, as the
front-end already generates a memset call to zero out all padding on
initializing a variable. The optimizer sees through this so will
correctly clear all bits once, so this can be improved later as-needed.
PR d/117832
gcc/d/ChangeLog:
* d-tree.h (build_padded_constructor): New prototype.
* d-codegen.cc (build_padded_constructor): New function.
(d_array_value): Call it.
(build_memset_call): Likewise.
(build_struct_literal): Likewise.
(underlying_complex_expr): Likewise.
(build_array_from_val): Likewise.
(build_array_from_exprs): Likewise.
(d_build_call): Likewise.
(get_frame_for_symbol): Likewise.
* d-convert.cc (convert_for_rvalue): Likewise.
(convert_for_assignment): Likewise.
* decl.cc (class DeclVisitor): Likewise.
* expr.cc (class ExprVisitor): Likewise.
* modules.cc (layout_moduleinfo): Likewise.
* typeinfo.cc (class TypeInfoVisitor): Likewise.
The following testcase ICEs after emitting one pedwarn (about using
__VA_ARGS__ in a place where it shouldn't be used) and one error.
The error is emitted by _cpp_save_parameter where it sees the node
has been used already earlier. But unlike the other _cpp_save_parameter
caller which does goto out; if it returns false, this call with explicit
__VA_ARGS__ doesn't and if it increments number of parameters etc. after
the error, we then try to unsave it twice.
The following patch fixes it by doing the goto out in that case too,
the macro will then not be considered as variable arguments macro,
but for error recovery I think that is fine.
The other option would be before the other _cpp_save_parameter caller
check if the node is pfile->spec_nodes.n__VA_ARGS__ and in that case
also error and goto out, but that seems more expensive than this for
the common case that the macro definition is correct.
2025-04-09 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/118674
* macro.cc (parse_params) <case CPP_ELLIPSIS>: If _cpp_save_parameter
failed for __VA_ARGS__, goto out.
* gcc.dg/cpp/pr118674.c: New test.
As usual, I forgot to add -mabi=lp64d to the test case. This patch adds
it. Going to push as obvious.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/autovec/pr116595.C: Add -mabi.
In categorize_ctor_elements_1 we do
VECTOR_CST_NELTS (value).to_constant ()
but VALUE's type can be a VLA vector (since r15-5780-g17b520a10cdaab).
This patch uses constant_lower_bound instead.
PR middle-end/116595
gcc/ChangeLog:
* expr.cc (categorize_ctor_elements_1): Use
constant_lower_bound.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/autovec/pr116595.C: New test.
2025-04-09 Paul Thomas <pault@gcc.gnu.org>
and Harald Anlauf <anlauf@gcc.gnu.org>
gcc/fortran
PR fortran/119460
* iresolve.cc (generate_reduce_op_wrapper): Increase the size
of 'tname'. Change intent of 'a' and 'b' to intent_in.
* trans-decl.cc (add_argument_checking): Do not test artificial
formal symbols.
* trans-expr.cc (gfc_conv_procedure_call): Remove reduce_scalar
and the blocks triggered by it.
* trans-intrinsic.cc (gfc_conv_intrinsic_function): Set the
result of non-character, scalar reduce to be allocatable.
gcc/testsuite/
PR fortran/119460
* gfortran.dg/reduce_2.f90: Add test to check that deferred len
characters cannot slip through.
* gfortran.dg/reduce_3.f90: New test
* gfortran.dg/reduce_4.f90: New test
libgfortran/
PR libfortran/119460
* intrinsics/reduce.c (reduce): Correct error message about
mismatch between dim and the rank of array. Output the values
of both. Correct the evaluation of the result stride and
extent.
(reduce_scalar): The front end treats the result as an
allocatable so eliminate memcpy and free. Return the base-addr
of the local descriptor.
(reduce_c): Correct the type of the string lengths.
(reduce_scalar_c): Correct the type of the string lengths.Test
to see if 'res' is allocated. If not then return the base_addr
of the local descriptor.
It seems that at least when cross-compiling at least collect2 pulls
in objects from libbacktrace.a which is linked via LIBDEPS. But
libbacktrace for the host is only built -fPIC with --enable-host-shared
but not -fPIE with --enable-host-pie so this fails. The following
teaches libbacktrace about --enable-host-pie and handles it similar
to libcpp.
PR bootstrap/119680
libbacktrace/
* configure.ac (--enable-host-pie): Handle by setting PIC_FLAG
to -fPIE.
* configure: Regenerate.
Implement LOCAL and LOCAL_INIT; we locally replace the tree declaration by
a local declaration of the outer variable. The 'local_init' then assigns
the value at the beginning of each loop iteration from the outer
declaration.
Note that the current implementation does not handle LOCAL with types that
have a default initializer and LOCAL/LOCAL_INIT for assumed-shape arrays;
this is diagnosed with a sorry error.
PR fortran/101602
gcc/fortran/ChangeLog:
* resolve.cc (resolve_locality_spec): Remove 'sorry, unimplemented'.
* trans-stmt.cc (struct symbol_and_tree_t): New.
(gfc_trans_concurrent_locality_spec): New.
(gfc_trans_forall_1): Call it; update to handle local and local_init.
* trans-decl.cc (gfc_start_saved_local_decls,
gfc_stop_saved_local_decls): New; moved code from ...
(gfc_process_block_locals): ... here. Call it.
* trans.h (gfc_start_saved_local_decls,
gfc_stop_saved_local_decls): Declare.
gcc/testsuite/ChangeLog:
* gfortran.dg/do_concurrent_8_f2023.f90: Update for removed 'sorry,
unimplemented'.
* gfortran.dg/do_concurrent_9.f90: Likewise.
* gfortran.dg/do_concurrent_all_clauses.f90: Likewise.
* gfortran.dg/do_concurrent_local_init.f90: Likewise.
* gfortran.dg/do_concurrent_locality_specs.f90: Likewise.
* gfortran.dg/do_concurrent_11.f90: New test.
* gfortran.dg/do_concurrent_12.f90: New test.
* gfortran.dg/do_concurrent_13.f90: New test.
* gfortran.dg/do_concurrent_14.f90: New test.
* gfortran.dg/do_concurrent_15.f90: New test.
When normalizing is_foo for <T>, we get to normalizing
callable<decltype(...),T> for <T,foo>, which means substituting <T,foo> into
<decltype(...),T>.
Since r14-9938, because in_template_context is false we return the lambda
unchanged, just with LAMBDA_EXPR_EXTRA_ARGS set, so the closure type still
refers to the is_specialization_of tparms in its CLASSTYPE_TEMPLATE_INFO.
So then in normalize_atom caching find_template_parameters walks over the
parameter mapping; any_template_parm_r walks into the TREE_TYPE of a
LAMBDA_EXPR without considering EXTRA_ARGS and finds a template parm from
the wrong parameter list.
But since r15-3530 we expect to set tf_partial when substituting with
dependent arguments, so we should set that when normalizing. And then
tf_partial causes TREE_STATIC to be set on the EXTRA_ARGS, meaning that
those args will replace all the template parms in the rest of the lambda, so
we can walk just the EXTRA_ARGS and ignore the rest.
PR c++/118698
gcc/cp/ChangeLog:
* constraint.cc (struct norm_info): Add tf_partial.
* pt.cc (any_template_parm_r): Handle LAMBDA_EXPR_EXTRA_ARGS.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-lambda22.C: New test.
Tested with nawk, mawk, and gawk.
gcc/ChangeLog:
* config/loongarch/genopts/gen-evolution.awk: remove
usage of "asort".
* config/loongarch/genopts/genstr.sh: replace sed with awk.
In previous years, I've tried to update the guality tests
so that they give clean results on aarch64-linux-gnu with
a recent version of GDB. This patch does the same thing for
GCC 15. The version of GDB I used was 16.2.
As before, there are no PRs for the XFAILs. The idea is that
anyone who is interested in working in this area can see the
current XFAILs by grepping the tests.
gcc/testsuite/
* gcc.dg/guality/pr36728-3.c: Update XFAILs for aarch64.
* gcc.dg/guality/pr41353-1.c: Likewise.
* gcc.dg/guality/pr54693-2.c: Likewise.
* gcc.dg/guality/pr68860-1.c: Likewise.
* gcc.dg/guality/pr68860-2.c: Likewise.
* gcc.dg/guality/sra-1.c: Likewise.
* gcc.dg/guality/vla-1.c: Likewise.
The aarch64_sve256_hw line forced the vector length, but didn't force
SVE itself. This meant that the associated:
/* { dg-final { scan-tree-dump "MASK_SCATTER_STORE" "vect" { target aarch64_sve256_hw } } } */
wouldn't always fire. I imagine this was tested with SVE enabled by
default, which would have masked the problem.
gcc/testsuite/
* gcc.dg/vect/pr99102.c: Force SVE when forcing the vector length.
The issue is specifically about a missing word, but I spotted other
copy-editing issues like misplaced hyphens in nearby text. I also
thought that the -Wimplicit example was anachronistic because it's a
hard error in modern C dialects rather than a warning, and replaced it
with something users are more likely to run into.
gcc/ChangeLog
PR c++/90468
* doc/invoke.texi (Warning Options): Clean up text describing
-Wno-xxx.
This reverts a change in the upstream D implementation of the compiler,
as the refactoring introduced a regression.
gcc/d/ChangeLog:
* dmd/MERGE: Merge upstream dmd 51816cd01d.
Reviewed-on: https://github.com/dlang/dmd/pull/21155
On top of
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680256.html
patch this brings make check-cobol when using the cross compiler from
32-bit host to x86_64-linux to the following:
Running /home/jakub/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/group1/declarative_1.cob -O0 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O1 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O2 execution test
FAIL: cobol.dg/group1/declarative_1.cob -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: cobol.dg/group1/declarative_1.cob -O3 -g execution test
FAIL: cobol.dg/group1/declarative_1.cob -Os execution test
=== cobol Summary ===
# of expected passes 3123
# of unexpected failures 6
# of expected failures 6
(which has some analysis but not a fix yet).
This patch fixes various cases where host size of various types
(void *, int, size_t, unsigned char) is used in place where
size of those types in bytes on the target should be used instead.
At least the size of void * and size_t actually differns between
ilp32 hosts and lp64 targets, int could be different in theory as well
but we actually don't support 16-bit ints on the host side and only support
lp64 targets right now for cobol, and finally sizeof(unsigned char) is
always 1, so there is no point to multiply by that and it is still
wrong to use host sizeof for the target decisions.
2025-04-08 Jakub Jelinek <jakub@redhat.com>
PR cobol/119364
* genapi.cc (function_handle_from_name): Use sizeof_pointer.
(parser_file_add): Use int_size_in_bytes(VOID_P) and
int_size_in_bytes(int).
(inspect_tally): Use int_size_in_bytes(VOID_P).
(inspect_replacing): Likewise.
(gg_array_of_field_pointers): Likewise.
(gg_array_of_file_pointers): Likewise.
(parser_set_pointers): Use sizeof_pointer.
* cobol1.cc (create_our_type_nodes_init): Use
int_size_in_bytes(SIZE_T) and int_size_in_bytes(VOID_P).
* gengen.cc (gg_array_of_size_t): Use int_size_in_bytes(SIZE_T).
(gg_array_of_bytes): Just use N, don't multiply it by
sizeof(unsigned char).
* parse.y: Include tree.h. Use int_size_in_bytes(ptr_type_node).
