aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2025-06-04Fortran: ICE due to missing locus with data statement for coarray [PR99838]Harald Anlauf2-1/+21
PR fortran/99838 gcc/fortran/ChangeLog: * data.cc (gfc_assign_data_value): For a new initializer use the location from the constructor as fallback. gcc/testsuite/ChangeLog: * gfortran.dg/coarray_data_2.f90: New test. (cherry picked from commit 0768ec0d32f570b1db13ca41b0a1506275c44053)
2025-06-04Daily bump.GCC Administrator3-1/+60
2025-06-03Fortran: parameter inquiries of constant complex arrays [PR102599,PR114022]Harald Anlauf3-4/+297
PR fortran/102599 PR fortran/114022 gcc/fortran/ChangeLog: * expr.cc (simplify_complex_array_inquiry_ref): Helper function for simplification of inquiry references (%re/%im) of constant complex arrays. (find_inquiry_ref): Use it for handling %re/%im inquiry references of complex arrays. (scalarize_intrinsic_call): Fix frontend memleak. * primary.cc (gfc_match_varspec): When the reference is NULL, the previous simplification has succeeded in evaluating inquiry references also of arrays. gcc/testsuite/ChangeLog: * gfortran.dg/inquiry_type_ref_8.f90: New test. (cherry picked from commit 490072b927dac2f57e541b0ee680896e23c5d998)
2025-06-03Fortran: fix regression introduced by commit r16-914-g787a8dec1acedfHarald Anlauf1-4/+5
A last-minute cleanup before patch submission reordered a change that should not have happened. This fixes it. PR fortran/101735 gcc/fortran/ChangeLog: * primary.cc (gfc_match_varspec): Correct order of logic. (cherry picked from commit 74a2281ae18c6dbbc640f0c79f7138a495ef8f0c)
2025-06-03Fortran: fix parsing of type parameter inquiries of substrings [PR101735]Harald Anlauf3-6/+142
Handling of type parameter inquiries of substrings failed to due either parsing issues or not following or handling reference chains properly. PR fortran/101735 gcc/fortran/ChangeLog: * expr.cc (find_inquiry_ref): If an inquiry reference applies to a substring, use that, and calculate substring length if needed. * primary.cc (extend_ref): Also handle attaching to end of reference chain for appending. (gfc_match_varspec): Discrimate between arrays of character and substrings of them. If a substring is taken from a character component of a derived type, get the proper typespec so that inquiry references work correctly. (gfc_match_rvalue): Handle corner case where we hit a seemingly dangling '%' and missed an inquiry reference. Try another match. gcc/testsuite/ChangeLog: * gfortran.dg/inquiry_type_ref_7.f90: New test. (cherry picked from commit 787a8dec1acedf5561c8ee43bed0b3653fca150d)
2025-06-03Daily bump.GCC Administrator4-1/+59
2025-06-02c++: lambda this capture and requires [PR120123]Jason Merrill2-4/+14
We shouldn't need to be within the lambda body to look through it to the enclosing non-static member function. This change is a small subset of r16-970. PR c++/120123 gcc/cp/ChangeLog: * lambda.cc (nonlambda_method_basetype): Look through lambdas even when current_class_ref is null. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda24.C: New test.
2025-06-02fortran: Fix debug info for unsigned(kind=1) and unsigned(kind=4) [PR120193]Jakub Jelinek2-14/+43
As the following testcase shows, debug info for unsigned(kind=1) and unsigned(kind=4) vars is wrong while unsigned(kind=2), unsigned(kind=8) and unsigned(kind=16) look right. Instead of objects having unsigned(kind=1) type they have character(kind=1) and instead of unsigned(kind=4) they have character(kind=4). This means in gdb e.g. unsigned(kind=1) :: a(2) variable initialized to 97 will print as 'aa' rather than (97, 97) etc. While there can be just one unsigned_char_type_node and one unsigned_type_node type, each can have arbitrary number of variants (e.g. consider C typedef unsigned char uc; where uc is a variant type to unsigned char) or even distinct types with different TYPE_MAIN_VARIANT. The following patch uses a variant of the character(kind=4) type for unsigned(kind=4) and a distinct type based on character(kind=1) type for unsigned(kind=1). The reason for the latter is that unsigned_char_type_node has TYPE_STRING_FLAG set on it, so it has DW_AT_encoding DW_ATE_unsigned_char rather than DW_ATE_unsigned and so the debugger then likes to print it as characters rather than numbers. That is IMHO in Fortran desirable for character(kind=1) but not for unsigned(kind=1). I've made sure TYPE_CANONICAL of the unsigned(kind=1) type is still character(kind=1), so they are considered compatible by the middle-end also e.g. for aliasing etc. 2025-05-10 Jakub Jelinek <jakub@redhat.com> PR fortran/120193 * trans-types.cc (gfc_init_types): For flag_unsigned use build_distinct_type_copy or build_variant_type_copy from gfc_character_types[index_char] if index_char > -1 instead of gfc_character_types[index_char] or gfc_build_unsigned_type (&gfc_unsigned_kinds[index]). * gfortran.dg/guality/pr120193.f90: New test. (cherry picked from commit 512371d786e70d27dbaef38d60e9036c11f458c6)
2025-06-02Merge branch 'releases/gcc-15' into devel/omp/gcc-15Tobias Burnus32-88/+595
Merge up to r15-9755-g21e0a742e7b70d (2nd July 2025)
2025-06-01Fortran: Fix handling of parsed format strings.Jerry DeLisle1-0/+15
Previously parsed strings with errors were being cached such that subsequent use of the format string were not being checked for errors. PR libfortran/119856 libgfortran/ChangeLog: * io/format.c (parse_format_list): Set the fmt->error message for missing comma. (parse_format): Do not cache the parsed format string if a previous error ocurred. gcc/testsuite/ChangeLog: * gfortran.dg/pr119856.f90: New test. (cherry picked from commit 5ff48aabf76c8913c013f233d3f42bb217a16e7b)
2025-06-01Fortran: Adjust handling of optional comma in FORMAT.Jerry DeLisle4-5/+7
This change adjusts the error messages for optional commas in format strings to give a warning at compile time unless -std=legacy is used. This is more consistant with the runtime library. A missing comma separator should not be encouraged as it is non-standard fortran. PR fortran/119856 gcc/fortran/ChangeLog: * io.cc: Set missing comma error checks to STD_STD_LEGACY. gcc/testsuite/ChangeLog: * gfortran.dg/comma_format_extension_1.f: Update dg-options to "-std=legacy". * gfortran.dg/comma_format_extension_3.f: Likewise. * gfortran.dg/continuation_13.f90: Likewise. (cherry picked from commit e2bf0b3910de7e65363435f0a7fa606e2448a677)
2025-06-02Daily bump.GCC Administrator1-1/+1
2025-06-01Daily bump.GCC Administrator3-1/+47
2025-05-31Fortran: Fix c_associated argument checks.Jerry DeLisle6-37/+164
PR fortran/120049 gcc/fortran/ChangeLog: * check.cc (gfc_check_c_associated): Use new helper functions. Only call check_c_ptr_1 if optional c_ptr_2 tests succeed. (check_c_ptr_1): Handle only c_ptr_1 checks. (check_c_ptr_2): Expand checks for c_ptr_2 and handle cases where there is no derived pointer in the gfc_expr and check the inmod_sym_id only if it exists. Rephrase error message. * misc.cc (gfc_typename): Handle the case for BT_VOID rather than throw an internal error. gcc/testsuite/ChangeLog: * gfortran.dg/pr120049_a.f90: Update test directives. * gfortran.dg/pr120049_b.f90: Update test directives * gfortran.dg/pr120049_2.f90: New test. * gfortran.dg/c_f_pointer_tests_6.f90: Adjust dg-error directive. Co-Authored-By: Steve Kargl <kargl@gcc.gnu.org> (cherry picked from commit 42983ffde6612b7f8a4e7ab3e76fa8b0d136e854)
2025-05-31Type mismatch for passed external functionThomas Koenig2-1/+47
This obvious and simple patch fixes a 15/16 regression where the typespec of a global function was in the RESULT clause and not in the symbol itself. gcc/fortran/ChangeLog: PR fortran/120355 * interface.cc (compare_parameter): If the global function has a result clause, take typespec from there for the comparison against the dummy argument. gcc/testsuite/ChangeLog: PR fortran/120355 * gfortran.dg/interface_62.f90: New test. (cherry picked from commit 0e77309047a7b479c89f03dcaf2994e050d0f33e)
2025-05-31Daily bump.GCC Administrator4-1/+69
2025-05-30OpenMP: Fix ICE and other issues in C/C++ metadirective error recovery.Sandra Loosemore4-35/+89
The new testcase included in this patch used to ICE in gcc after diagnosing the first error, and in g++ it only diagnosed the error in the first metadirective, ignoring the second one. The solution is to make error recovery in the C front end more like that in the C++ front end, and remove the code in both front ends that previously tried to skip all the way over the following statement (instead of just to the end of the metadirective pragma) after an error. gcc/c/ChangeLog * c-parser.cc (c_parser_skip_to_closing_brace): New, copied from the equivalent function in the C++ front end. (c_parser_skip_to_end_of_block_or_statement): Pass false to the error flag. (c_parser_omp_context_selector): Immediately return error_mark_node after giving an error that the integer trait property is invalid, similarly to C++ front end. (c_parser_omp_context_selector_specification): Likewise handle error return from c_parser_omp_context_selector similarly to C++. (c_parser_omp_metadirective): Do not call c_parser_skip_to_end_of_block_or_statement after an error. gcc/cp/ChangeLog * parser.cc (cp_parser_omp_metadirective): Do not call cp_parser_skip_to_end_of_block_or_statement after an error. gcc/testsuite/ChangeLog * c-c++-common/gomp/declare-variant-2.c: Adjust patterns now that C and C++ now behave similarly. * c-c++-common/gomp/metadirective-error-recovery.c: New. (cherry picked from commit 33b65e4d1c83808b54cd6b3fc97ebacc522b125d)
2025-05-30OpenMP: Fix ICE in metadirective recovery after error [PR120180]Sandra Loosemore3-6/+30
It's not clear whether a metadirective in a loop nest is supposed to be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it as an error. gcc/c/ChangeLog PR c/120180 * c-parser.cc (c_parser_omp_metadirective): Only consume the token if it is the expected close paren. gcc/cp/ChangeLog PR c/120180 * parser.cc (cp_parser_omp_metadirective): Only consume the token if it is the expected close paren. gcc/testsuite/ChangeLog PR c/120180 * c-c++-common/gomp/pr120180.c: New. (cherry picked from commit 65e0ed2310a1b0d1a3255583bbfb8a8d86c5aea5)
2025-05-30ChangeLog.omp bumpThomas Schwinge2-1/+10
2025-05-30Defuse 'RESULT_DECL' check in 'pass_nrv' (for offloading compilation) [PR119835]Thomas Schwinge1-7/+12
... to avoid running into ICEs per PR119835, until that's resolved properly. PR middle-end/119835 gcc/ * tree-nrv.cc (pass_nrv::execute): Defuse 'RESULT_DECL' check. libgomp/ * testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c: '#pragma GCC optimize "-fno-inline"'. * testsuite/libgomp.c-c++-common/target-abi-struct-1.c: New. * testsuite/libgomp.c-c++-common/target-abi-struct-1-O0.c: Adjust. Co-authored-by: Richard Biener <rguenther@suse.de> (cherry picked from commit 543f7e1d59f0b6628e0de6610ad5e1cf7150090b)
2025-05-30testsuite: Add testcase for GCC 13 branch s390 bug [PR120480]Jakub Jelinek1-0/+11
This got broken with r13-9727 and fixed with either of r13-9729 or r13-9728. 2025-05-30 Jakub Jelinek <jakub@redhat.com> PR target/120480 * gcc.dg/pr120480.c: New test. (cherry picked from commit c13d5b939fee565047394475952878dc5394fb74)
2025-05-30Daily bump.GCC Administrator2-1/+9
2025-05-29aarch64: Enable newly implemented features for FUJITSU-MONAKAYuta Mukai1-1/+1
This patch enables newly implemented features in GCC (FAMINMAX, FP8FMA, FP8DOT2, FP8DOT4, LUT) for FUJITSU-MONAKA processor (-mcpu=fujitsu-monaka). 2025-05-23 Yuta Mukai <mukai.yuta@fujitsu.com> gcc/ChangeLog: * config/aarch64/aarch64-cores.def (fujitsu-monaka): Update ISA features. (cherry picked from commit 33ee574a7444b238005d89fdfdf2f21f50b1fc6e)
2025-05-29Daily bump.GCC Administrator1-1/+1
2025-05-28Daily bump.GCC Administrator3-1/+21
2025-05-27Fix IPA-SRA issue with reverse SSO on specific patternEric Botcazou5-1/+57
IPA-SRA generally works fine in the presence of reverse Scalar_Storage_Order by propagating the relevant flag onto the newly generated MEM_REFs. However we have been recently faced with a specific Ada pattern that it does not handle correctly: the 'Valid attribute applied to a floating-point component of an aggregate type with reverse Scalar_Storage_Order. The attribute is implemented by a call to a specific routine of the runtime that expects a pointer to the object so, in the case of a component with reverse SSO, the compiler first loads it from the aggregate to get back the native storage order, but it does the load using an array of bytes instead of the floating-point type to prevent the FPU from fiddling with the value, which yields in the .original dump file: *(character[1:4] *) &F2b = VIEW_CONVERT_EXPR<character[1:4]>(item.f); Of course that's a bit convoluted, but it does not seem that another method would be simpler or even work, and using VIEW_CONVERT_EXPR to toggle the SSO is supposed to be supported in any case (unlike aliasing or type punning). The attached patch makes it work. While the call to storage_order_barrier_p from IPA-SRA is quite natural (the regular SRA has it too), the tweak to the predicate itself is needed to handle the scalar->aggregate conversion, which is admittedly awkward but again without clear alternative. gcc/ * ipa-sra.cc (scan_expr_access): Also disqualify storage order barriers from splitting. * tree.h (storage_order_barrier_p): Also return false if the operand of the VIEW_CONVERT_EXPR has reverse storage order. gcc/testsuite/ * gnat.dg/sso19.adb: New test. * gnat.dg/sso19_pkg.ads, gnat.dg/sso19_pkg.adb: New helper.
2025-05-27doc: Fix typo in description of nonstring attributeJonathan Wakely1-1/+1
gcc/ChangeLog: * doc/extend.texi (Common Variable Attributes): Fix typo in description of nonstring. (cherry picked from commit 351e60095cfaa73b5ac69222d00e0cd4ae5725d4)
2025-05-27Daily bump.GCC Administrator3-1/+31
2025-05-26Merge branch 'releases/gcc-15' into devel/omp/gcc-15Tobias Burnus42-38/+558
Merge up to r15-9731-gd390c7e5bd0349 (26th May 2025)
2025-05-26c-c++-common/gomp/{attrs-,}metadirective-3.c: Fix expected result [PR118694]Tobias Burnus2-6/+8
With compilation for nvptx enabled, two issues showed up: (a) "error: 'target' construct with nested 'teams' construct contains directives outside of the 'teams' construct" See PR comment 9 why this is difficult to fix. Solution: Add dg-bogus and accept/expect the error for 'target offload_nvptx'. (b) The assumptions about the dump for 'target offload_nvptx' were wrong as the metadirective was already expanded to a OMP_NEXT_VARIANT construct such that no 'omp metadirective' was left in either case. Solution: Check that no 'omp metadirective' is left; additionally, expect either OMP_NEXT_VARIANT (when offload_nvptx is available) or no 'teams' directive at all (if not). gcc/testsuite/ChangeLog: PR middle-end/118694 * c-c++-common/gomp/attrs-metadirective-3.c: Change to never expect 'omp metadirective' in the dump. If !offload_nvptx, check that no 'teams' shows up in the dump; for offload_nvptx, expect OMP_NEXT_VARIANT and an error about directive between 'target' and 'teams'. * c-c++-common/gomp/metadirective-3.c: Likewise. (cherry picked from commit 5d6ed6d604ff949b650e48fa4eaed3ec8b6489c1)
2025-05-26OpenMP/C++: Avoid ICE for BIND_EXPR with empty BIND_EXPR_BLOCK [PR120413]Tobias Burnus2-4/+26
PR c++/120413 gcc/cp/ChangeLog: * semantics.cc (finish_omp_target_clauses_r): Handle BIND_EXPR with empty BIND_EXPR_BLOCK. gcc/testsuite/ChangeLog: * g++.dg/gomp/target-4.C: New test. (cherry picked from commit 45b849d05b733a25ec7ce612229084b8f4b86d3d)
2025-05-26Daily bump.GCC Administrator2-1/+8
2025-05-25MicroBlaze does not support speculative execution (CVE-2017-5753)Michael J. Eager1-0/+4
gcc/ PR target/86772 Tracking CVE-2017-5753 * config/microblaze/microblaze.cc (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_save_value_not_needed
2025-05-25Daily bump.GCC Administrator1-1/+1
2025-05-24Daily bump.GCC Administrator3-1/+47
2025-05-24c++/modules: Fix merge of TLS init functions [PR120363]Nathaniel Shead10-3/+82
The PR notes that we missed setting DECL_CONTEXT on the TLS init function; we missed this initially because this function is not created in header units, only named modules. I also noticed that 'DECL_CONTEXT (fn) = DECL_CONTEXT (var)' was incorrect: for class members, this ends up having the modules merging machinery treat the decl as a member function, which breaks when attempting to dedup against an existing completed class type. Instead we can just use the global_namespace as the context, because the name of the function is already mangled appropriately so that we'll match the correct duplicates. PR c++/120363 gcc/cp/ChangeLog: * decl2.cc (get_tls_init_fn): Set context as global_namespace. (get_tls_wrapper_fn): Likewise. gcc/testsuite/ChangeLog: * g++.dg/modules/pr113292_a.H: Move to... * g++.dg/modules/tls-1_a.H: ...here. * g++.dg/modules/pr113292_b.C: Move to... * g++.dg/modules/tls-1_b.C: ...here. * g++.dg/modules/pr113292_c.C: Move to... * g++.dg/modules/tls-1_c.C: ...here. * g++.dg/modules/tls-2_a.C: New test. * g++.dg/modules/tls-2_b.C: New test. * g++.dg/modules/tls-2_c.C: New test. * g++.dg/modules/tls-3.h: New test. * g++.dg/modules/tls-3_a.H: New test. * g++.dg/modules/tls-3_b.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 66e9a4f3083356b064cc64651edad466a56f762b)
2025-05-24c++/modules: Fix stream-in of member using-decls [PR120414]Nathaniel Shead3-1/+25
When streaming in a reference to a data member, we have an oversight where we did not consider USING_DECLs, despite otherwise handling them here the same as fields. This patch corrects that mistake. PR c++/120414 gcc/cp/ChangeLog: * module.cc (trees_in::tree_node): Allow reading a USING_DECL when streaming tt_data_member. gcc/testsuite/ChangeLog: * g++.dg/modules/using-31_a.C: New test. * g++.dg/modules/using-31_b.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 43dddeef7a870ce4db7407f73660504b67a0a919)
2025-05-23Daily bump.GCC Administrator3-1/+23
2025-05-22Fortran: default-initialization and functions returning derived type [PR85750]Harald Anlauf7-13/+134
Functions with non-pointer, non-allocatable result and of derived type did not always get initialized although the type had default-initialization, and a derived type component had the allocatable or pointer attribute. Rearrange the logic when to apply default-initialization. PR fortran/85750 gcc/fortran/ChangeLog: * resolve.cc (resolve_symbol): Reorder conditions when to apply default-initializers. gcc/testsuite/ChangeLog: * gfortran.dg/alloc_comp_auto_array_3.f90: Adjust scan counts. * gfortran.dg/alloc_comp_class_3.f03: Remove bogus warnings. * gfortran.dg/alloc_comp_class_4.f03: Likewise. * gfortran.dg/allocate_with_source_14.f03: Adjust scan count. * gfortran.dg/derived_constructor_comps_6.f90: Likewise. * gfortran.dg/derived_result_5.f90: New test. (cherry picked from commit d31ab498b12ebbe4f50acb2aa240ff92c73f310c)
2025-05-22ChangeLog.omp bumpThomas Schwinge2-0/+22
2025-05-22'TYPE_EMPTY_P' vs. code offloading [PR120308]Thomas Schwinge5-3/+36
We've got 'gcc/stor-layout.cc:finalize_type_size': /* Handle empty records as per the x86-64 psABI. */ TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type); (Indeed x86_64 is still the only target to define 'TARGET_EMPTY_RECORD_P', calling 'gcc/tree.cc-default_is_empty_record'.) And so it happens that for an empty struct used in code offloaded from x86_64 host (but not powerpc64le host, for example), we get to see 'TYPE_EMPTY_P' in offloading compilation (where the offload targets (currently?) don't use it themselves, and therefore aren't prepared to handle it). For nvptx offloading compilation, this causes wrong code generation: 'ptxas [...] error : Call has wrong number of parameters', as nvptx code generation for function definition doesn't pay attention to this flag (say, in 'gcc/config/nvptx/nvptx.cc:pass_in_memory', or whereever else would be appropriate to handle that), but the generic code 'gcc/calls.cc:expand_call' via 'gcc/function.cc:aggregate_value_p' does pay attention to it, and we thus get mismatching function definition vs. function call. This issue apparently isn't a problem for GCN offloading, but I don't know if that's by design or by accident. Richard Biener: > It looks like TYPE_EMPTY_P is only used during RTL expansion for ABI > purposes, so computing it during layout_type is premature as shown here. > > I would suggest to simply re-compute it at offload stream-in time. (For avoidance of doubt, the additions to 'gcc.target/nvptx/abi-struct-arg.c', 'gcc.target/nvptx/abi-struct-ret.c' are not dependent on the offload streaming code changes, but are just to mirror the changes to 'libgomp.oacc-c-c++-common/abi-struct-1.c'.) PR lto/120308 gcc/ * lto-streamer-out.cc (hash_tree): Don't handle 'TYPE_EMPTY_P' for 'lto_stream_offload_p'. * tree-streamer-in.cc (unpack_ts_type_common_value_fields): Likewise. * tree-streamer-out.cc (pack_ts_type_common_value_fields): Likewise. libgomp/ * testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c: Add empty structure testing. gcc/testsuite/ * gcc.target/nvptx/abi-struct-arg.c: Add empty structure testing. * gcc.target/nvptx/abi-struct-ret.c: Likewise. (cherry picked from commit 9063810c86beee6274d745b91d8fb43a81c9683e)
2025-05-22ChangeLog.omp bumpTobias Burnus1-1/+1
2025-05-22Daily bump.GCC Administrator1-1/+1
2025-05-21Daily bump.GCC Administrator5-1/+91
2025-05-20Fortran: fix passing of inquiry ref of complex array to TRANSFER [PR102891]Harald Anlauf2-1/+53
PR fortran/102891 gcc/fortran/ChangeLog: * dependency.cc (gfc_ref_needs_temporary_p): Within an array reference, inquiry references of complex variables generally need a temporary. gcc/testsuite/ChangeLog: * gfortran.dg/transfer_array_subref.f90: New test. (cherry picked from commit 94fa992b60e53dcf807fc7055ab606d828b931d8)
2025-05-20tree-sra: Do not create stores into const aggregates (PR111873)Martin Jambor4-1/+52
This patch fixes (hopefully the) one remaining place where gimple SRA was still creating a load into const aggregates. It occurs when there is a replacement for a load but that replacement is not type compatible - typically because it is a single field structure. I have used testcases from duplicates because the original test-case no longer reproduces for me. gcc/ChangeLog: 2025-05-13 Martin Jambor <mjambor@suse.cz> PR tree-optimization/111873 * tree-sra.cc (sra_modify_expr): When processing a load which has a type-incompatible replacement, do not store the contents of the replacement into the original aggregate when that aggregate is const. gcc/testsuite/ChangeLog: 2025-05-13 Martin Jambor <mjambor@suse.cz> * gcc.dg/ipa/pr120044-1.c: New test. * gcc.dg/ipa/pr120044-2.c: Likewise. * gcc.dg/tree-ssa/pr114864.c: Likewise. (cherry picked from commit 9d039eff453f777c58642ff16178c1ce2a4be6ab)
2025-05-20ipa: Dump cgraph_node UID instead of order into ipa-clones dump fileMartin Jambor6-8/+8
Since starting from GCC 15 the order is not unique for any symtab_nodes but m_uid is, I believe we ought to dump the latter in the ipa-clones dump, if only so that people can reliably match entries about new clones to those about removed nodes (if any). This patch also contains a fixes to a few other places where we have so far dumped order to our ordinary dumps and which have been identified by Michal Jires. gcc/ChangeLog: 2025-05-16 Martin Jambor <mjambor@suse.cz> * cgraph.h (symtab_node): Make member function get_uid const. * cgraphclones.cc (dump_callgraph_transformation): Dump m_uid of the call graph nodes instead of order. * cgraph.cc (cgraph_node::remove): Likewise. * ipa-cp.cc (ipcp_lattice<valtype>::print): Likewise. * ipa-sra.cc (ipa_sra_summarize_function): Likewise. * symtab.cc (symtab_node::dump_base): Likewise. Co-Authored-By: Michal Jires <mjires@suse.cz> (cherry picked from commit 9fa534f0831892393885e64596a0d6ca8c4078b6)
2025-05-20Merge branch 'releases/gcc-15' into devel/omp/gcc-15Tobias Burnus60-340/+2079
Merge up to r15-9715-g911cfea5e59798 (May 20, 2025).
2025-05-20c++/modules: Fix ICE on merge of instantiation with partial spec [PR120013]Nathaniel Shead6-11/+72
When we import a pending instantiation that matches an existing partial specialisation, we don't find the slot in the entity map because for partial specialisations we register the TEMPLATE_DECL but for normal implicit instantiations we instead register the inner TYPE_DECL. Because the DECL_MODULE_ENTITY_P flag is set we correctly realise that it is in the entity map, but ICE when attempting to use that slot in partition handling. This patch fixes the issue by detecting this case and instead looking for the slot for the TEMPLATE_DECL. It doesn't matter that we never add a slot for the inner decl because we're about to discard it anyway. PR c++/120013 gcc/cp/ChangeLog: * module.cc (trees_in::install_entity): Handle re-registering the inner TYPE_DECL of a partial specialisation. gcc/testsuite/ChangeLog: * g++.dg/modules/partial-8.h: New test. * g++.dg/modules/partial-8_a.C: New test. * g++.dg/modules/partial-8_b.C: New test. * g++.dg/modules/partial-8_c.C: New test. * g++.dg/modules/partial-8_d.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit b0de7297f2b5670386472229ab795a577c288ecf)
2025-05-20c++/modules: Always mark tinfo vars as TREE_ADDRESSABLE [PR120350]Nathaniel Shead3-0/+16
We need to mark type info decls as addressable if we take them by reference; this is done by walking the declaration during parsing and marking the decl as needed. However, with modules we don't stream tinfo decls directly; rather we stream just their name and type and reconstruct them in the importer directly. This means that any addressable flags are not propagated, and we error because TREE_ADDRESSABLE is not set despite taking its address. But tinfo decls should always have TREE_ADDRESSABLE set, as any attempt to use the tinfo decl will go through build_address anyway. So this patch fixes the issue by eagerly marking the constructed decl as TREE_ADDRESSABLE so that modules gets this flag correctly set as well. PR c++/120350 gcc/cp/ChangeLog: * rtti.cc (get_tinfo_decl_direct): Mark TREE_ADDRESSABLE. gcc/testsuite/ChangeLog: * g++.dg/modules/tinfo-3_a.H: New test. * g++.dg/modules/tinfo-3_b.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 9a6e5a437f0416627ee516f6ef5929cb30c5e498)
generated by cgit v1.1 at 2025-09-18 13:06:03 +0000