aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-04-10Darwin, libgcobol: Enable for x86_64 Darwin.Iain Sandoe1-1/+1
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>
2025-04-10cobol: New testcases for reference modification.Bob Dubner22-0/+244
gcc/testsuite * cobol.dg/group2/Dynamic_reference_modification.cob: New testcase. * cobol.dg/group2/Length_overflow__1_.cob: Likewise. * cobol.dg/group2/Length_overflow__2_.cob: Likewise. * cobol.dg/group2/Length_overflow_with_offset__1_.cob: Likewise. * cobol.dg/group2/Length_overflow_with_offset__2_.cob: Likewise. * cobol.dg/group2/Length_overflow_with_offset__3_.cob: Likewise. * cobol.dg/group2/Offset_overflow.cob: Likewise. * cobol.dg/group2/Offset_underflow.cob: Likewise. * cobol.dg/group2/Refmod__comparisons_inside_numeric-display.cob: Likewise. * cobol.dg/group2/Refmod_sources_are_figurative_constants.cob: Likewise. * cobol.dg/group2/Static_reference_modification.cob: Likewise. * cobol.dg/group2/Dynamic_reference_modification.out: New known-good result. * cobol.dg/group2/Length_overflow__1_.out: Likewise. * cobol.dg/group2/Length_overflow__2_.out: Likewise. * cobol.dg/group2/Length_overflow_with_offset__1_.out: Likewise. * cobol.dg/group2/Length_overflow_with_offset__2_.out: Likewise. * cobol.dg/group2/Length_overflow_with_offset__3_.out: Likewise. * cobol.dg/group2/Offset_overflow.out: Likewise. * cobol.dg/group2/Offset_underflow.out: Likewise. * cobol.dg/group2/Refmod__comparisons_inside_numeric-display.out: Likewise. * cobol.dg/group2/Refmod_sources_are_figurative_constants.out: Likewise. * cobol.dg/group2/Static_reference_modification.out: Likewise.
2025-04-10c++: lambda in constraint of lambda [PR119175]Jason Merrill2-0/+18
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.
2025-04-10libbacktrace: Add hpux fileline supportJohn David Anglin1-1/+35
Fixes libstdc++ stacktrace tests. 2025-04-10 John David Anglin <danglin@gcc.gnu.org> libbacktrace/ChangeLog: * fileline.c (hpux_get_executable_path): New. (fileline_initialize): Add pass to get hpux executable path.
2025-04-10hpux: Remove _GLIBCXX_USE_LONG_LONG define from hpux os_defines.hJohn David Anglin1-6/+1
_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.
2025-04-10Darwin: Add spec substitution for static-libgcobol.Iain Sandoe1-0/+1
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>
2025-04-10middle-end/119706 - allow POLY_INT_CST as is_gimple_mem_ref_addrRichard Biener1-1/+1
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.
2025-04-10libgcobol: Allow libgcobol to use libquadmath [PR119244].Iain Sandoe13-278/+1048
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>
2025-04-10testsuite, cobol: Add libquadmath paths.Iain Sandoe1-0/+9
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>
2025-04-10Avoid using POINTER_DIFF_EXPR for overlap checks [PR119399]Richard Sandiford2-3/+14
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.
2025-04-10RISC-V: Fix the behavior for multilib-generator with --cmodel=large on rv32Kito Cheng1-2/+2
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.
2025-04-10RISC-V: Include local riscv_vector.h in testsuiteKito Cheng35-35/+35
That could prevent us including stdint.h from glibc, and that will cause problem when the corresponding multilib isn't built. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-1.c: Include local riscv_vector.h. * gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-2.c: Ditto. * gcc.target/riscv/rvv/base/abi-callee-saved-1-save-restore.c: Ditto. * gcc.target/riscv/rvv/base/abi-callee-saved-1-zcmp.c: Ditto. * gcc.target/riscv/rvv/base/abi-callee-saved-1.c: Ditto. * gcc.target/riscv/rvv/base/abi-callee-saved-2-save-restore.c: Ditto. * gcc.target/riscv/rvv/base/abi-callee-saved-2-zcmp.c: Ditto. * gcc.target/riscv/rvv/base/abi-callee-saved-2.c: Ditto. * gcc.target/riscv/rvv/base/bug-10-2.c: Ditto. * gcc.target/riscv/rvv/base/bug-10.c: Ditto. * gcc.target/riscv/rvv/base/bug-7.c: Ditto. * gcc.target/riscv/rvv/base/bug-8.c: Ditto. * gcc.target/riscv/rvv/base/bug-9.c: Ditto. * gcc.target/riscv/rvv/base/pr110943.c: Ditto. * gcc.target/riscv/rvv/base/pr112431-21.c: Ditto. * gcc.target/riscv/rvv/base/pr114639-1.c: Ditto. * gcc.target/riscv/rvv/base/pr115068.c: Ditto. * gcc.target/riscv/rvv/base/pr117286.c: Ditto. * gcc.target/riscv/rvv/base/pr117544.c: Ditto. * gcc.target/riscv/rvv/base/pr117955.c: Ditto. * gcc.target/riscv/rvv/base/pr118872.c: Ditto. * gcc.target/riscv/rvv/base/vlmul_ext-1.c: Ditto. * gcc.target/riscv/rvv/base/vssubu-1.c: Ditto. * gcc.target/riscv/rvv/base/vssubu-2.c: Ditto. * gcc.target/riscv/rvv/base/vwaddsub-1.c: Ditto. * gcc.target/riscv/rvv/vsetvl/pr111234.c: Ditto. * gcc.target/riscv/rvv/vsetvl/pr115214.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vsetvl-24.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vsetvl_bug-3.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vsetvl_bug-4.c: Ditto. * gcc.target/riscv/rvv/xtheadvector/pr116591.c: Ditto. * gcc.target/riscv/rvv/xtheadvector/pr116592.c: Ditto. * gcc.target/riscv/rvv/xtheadvector/pr118357.c: Ditto. * gcc.target/riscv/rvv/xtheadvector/vsext.c: Ditto. * gcc.target/riscv/rvv/xtheadvector/vzext.c: Ditto.
2025-04-10Daily bump.GCC Administrator15-1/+305
2025-04-09libstdc++: Fix constraint recursion in basic_const_iterator operator- [PR115046]Patrick Palka2-2/+15
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>
2025-04-09c++: ICE with nested default targ lambdas [PR119574]Patrick Palka4-1/+23
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>
2025-04-09cobol: Proper comparison of alphanumeric to refmoded numeric-display [PR119682]Bob Dubner5-86/+77
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.
2025-04-09pretty-print: Fix format specifier descriptionJakub Jelinek1-1/+1
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.
2025-04-09modula2: FIx a comment typoJakub Jelinek1-1/+2
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".
2025-04-09libquadmath: Fix up THREEp96 constant in expqJakub Jelinek1-1/+1
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.
2025-04-09h8300: Fix up bit test and jump splitter [PR119664]Jakub Jelinek2-4/+19
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.
2025-04-09Update gcc de.poJoseph Myers1-237/+129
* de.po: Update.
2025-04-09aarch64: Add sve testcase for PR 116595 [PR116595]Andrew Pinski1-0/+7
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>
2025-04-09d: Fix forward referenced enums missing type names in debug info [PR118309]Iain Buclaw3-13/+47
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.
2025-04-09Update gcc.po filesJoseph Myers20-139295/+144504
* be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po, ja.po, ka.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po, zh_TW.po: Update.
2025-04-09Fortran: fix issue with impure elemental subroutine and interface [PR119656]Harald Anlauf3-7/+65
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.
2025-04-09[RISC-V] Fix more fallout from combine.c changesJeff Law4-4/+4
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.
2025-04-09testsuite/x86: Correctly escape asterisk in scan-assemblerUros Bizjak2-10/+10
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.
2025-04-09deref-before-check-pr113253.c: Fix bogus warnings on lp32Jonathan Yong1-4/+5
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.
2025-04-09[committed][RISC-V] Adjust expected output for rvv testJeff Law1-2/+1
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.
2025-04-09riscv: Fix r15-9270 fallout on RISC-VJakub Jelinek1-1/+33
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.
2025-04-09rtl-optimization/119689 - compare-debug failure with LRARichard Biener2-1/+45
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.
2025-04-09d: Use CONSTRUCTOR_ZERO_PADDING_BITS in the D FE [PR117832]Iain Buclaw7-28/+45
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.
2025-04-09Revert "RISC-V: Refine the testcases for cond_widen_complicate-3"Pan Li10-93/+36
This reverts commit f70f4b60debce4a223725781d1973c05d8d1dfa9.
2025-04-09libcpp: Fix error recovery after use of __VA_ARGS__ as macro argument [PR118674]Jakub Jelinek2-3/+9
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.
2025-04-09testsuite: Add -mabi to pr116595.CRobin Dapp1-1/+1
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.
2025-04-09expr: Use constant_lower_bound classifying constructor els [PR116595].Robin Dapp2-3/+13
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-09Fortran: Fix some problems with the reduce intrinsic [PR119460]Paul Thomas8-60/+168
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.
2025-04-09bootstrap/119680 - fix cross-compiler build with --enable-host-sharedRichard Biener2-5/+18
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.
2025-04-09Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]Tobias Burnus14-30/+807
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.
2025-04-08c++: lambda in concept [PR118698]Jason Merrill3-1/+34
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.
2025-04-09LoongArch: Fix awk / sed usage for compatibilityYang Yujie2-29/+40
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.
2025-04-09Daily bump.GCC Administrator12-1/+632
2025-04-08testsuite: Update guality XFAILs for aarch64Richard Sandiford7-8/+8
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.
2025-04-08testsuite: Fix gcc.dg/vect/pr99102.c command lineRichard Sandiford1-1/+1
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.
2025-04-08Doc: Copy-edit text about -Wno-xxx [PR90468]Sandra Loosemore1-12/+13
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.
2025-04-08libphobos: Merge with upstream phobos 35977c802Iain Buclaw6-36/+89
Synchronizes recent bug fixes targeted for v2.111.1. libphobos/ChangeLog: * src/MERGE: Merge upstream phobos 35977c802. * src/Makefile.am (PHOBOS_DSOURCES): Add std/internal/windows/bcrypt.d. * src/Makefile.in: Regenerate.
2025-04-08d: Fix infinite loop in isAliasThisTupleIain Buclaw3-14/+26
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
2025-04-08cobol: Further fixes for cobol cross-compilation from 32-bit arches [PR119364]Jakub Jelinek4-18/+28
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).
2025-04-08simplify-rtx: Fix up POPCOUNT optimization [PR119672]Jakub Jelinek1-2/+4
The gcc.dg/vect/pr113281-1.c test and many others ICE on riscv since presumably the r15-9238 change which allowed more cases of vector modes in simplify_const_relational_operation. In the testcase it is EQ of (popcount:SI (unspec:RVVMF32BI [ (and:RVVMF32BI (const_vector:RVVMF32BI repeat [ (const_int 1 [0x1]) ]) (reg:RVVMF32BI 147 [ mask__6.8_35 ])) (reg:SI 143 [ _41 ]) (const_int 0 [0]) (reg:SI 66 vl) (reg:SI 67 vtype) ] UNSPEC_VPREDICATE)) and (const_int 0 [0]) which it tries to fold as EQ comparison of (unspec:RVVMF32BI [ (and:RVVMF32BI (const_vector:RVVMF32BI repeat [ (const_int 1 [0x1]) ]) (reg:RVVMF32BI 147 [ mask__6.8_35 ])) (reg:SI 143 [ _41 ]) (const_int 0 [0]) (reg:SI 66 vl) (reg:SI 67 vtype) ] UNSPEC_VPREDICATE) with (const_int 0 [0]) which ICEs because const0_rtx isn't a vector. Fixed by using CONST0_RTX, so that we pass (const_vector:RVVMF32BI repeat [ (const_int 0 [0]) ]) instead. 2025-04-08 Jakub Jelinek <jakub@redhat.com> PR rtl-optimization/119672 * simplify-rtx.cc (simplify_context::simplify_relational_operation_1): For POPCOUNT == 0 or != 0 optimizations use CONST0_RTX (GET_MODE (XEXP (op0, 0))) rather than const0_rtx.
2025-04-08c: fix checking for a tag for variably modified tagged types [PR119612]Martin Uecker5-16/+64
The checking assertion added for PR118765 did not take into account that add_decl_expr can change TYPE_NAME to a TYPE_DECL with no name for certain cases of variably modified types. This also implies that we might sometimes not reliably detect the absence of a tag when only considering TYPE_NAME. This patch introduces a new helper function c_type_tag to reliable compute the tag for a tagged types and uses it for code where the switch to C23 may cause regressions. PR c/119612 gcc/c/ChangeLog: * c-tree.h (c_type_tag): Add prototype. * c-typeck.cc (c_type_tag): New function. (tagged_types_tu_compatible_p, composite_type_internal): Use c_type_tag. * c-decl.cc (c_struct_hasher::hash, previous_tag): Use c_type_tag. gcc/testsuite/ChangeLog: * gcc.dg/gnu23-tag-6.c: New test. * gcc.dg/pr119612.c: New test.
generated by cgit v1.1 at 2025-09-27 03:08:24 +0000