aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2025-05-11tree-optimization/120143 - ICE with failed early break store moveRichard Biener2-1/+18
The early break vectorization store moving was incorrectly trying to move the pattern stmt instead of the original one which failed to register and then confused virtual SSA form due to the update triggered by a degenerate virtual PHI. PR tree-optimization/120143 * tree-vect-data-refs.cc (vect_analyze_early_break_dependences): Move/update the original stmts, not the pattern stmts which lack virtual operands and are not in the IL. * gcc.dg/vect/vect-early-break_135-pr120143.c: New testcase. (cherry picked from commit da377e7ebf84a05943fb768eaeb7d682dee865fa)
2025-05-11tree-optimization/120089 - force all PHIs live for early-break vectRichard Biener3-15/+87
The following makes sure to even mark unsupported PHIs live when doing early-break vectorization since otherwise we fail to validate we can vectorize those and generate wrong code based on the scalar PHIs which would only work with a vectorization factor of one. PR tree-optimization/120089 * tree-vect-stmts.cc (vect_stmt_relevant_p): Mark all PHIs live when not already so and doing early-break vectorization. (vect_mark_stmts_to_be_vectorized): Skip virtual PHIs. * tree-vect-slp.cc (vect_analyze_slp): Robustify handling of early-break forced IVs. * gcc.dg/vect/vect-early-break_134-pr120089.c: New testcase. (cherry picked from commit 9def392a1b63a198d15d972f73b4afc888389d7c)
2025-05-11tree-optimization/120043 - bogus conditional store eliminationRichard Biener2-1/+17
The following fixes conditional store elimination to properly check for conditional stores to readonly memory which we can obviously not store to unconditionally. The tree_could_trap_p predicate used is only considering rvalues and the chosen approach mimics that of loop store motion. PR tree-optimization/120043 * tree-ssa-phiopt.cc (cond_store_replacement): Check whether the store is to readonly memory. * gcc.dg/torture/pr120043.c: New testcase. (cherry picked from commit 93586e5d51188bf71f4f8fae4ee94ff631740f24)
2025-05-11Fix PR 119928, formal arguments used to wrongly inferred for CLASS.Thomas Koenig2-62/+143
The problem was indeed that generating a formal from an actual arglist is a bad idea when classes are involved. Fixed in the attached patch. I think it still makes sense to remove the checks when the other attributes are present (or PR96073 may come back in different guise, even if I have to test case at present). I have also converted the test to a run-time check. gcc/fortran/ChangeLog: PR fortran/119928 * interface.cc (gfc_check_dummy_characteristics): Do not issue error if one dummy symbol has been generated from an actual argument and the other one has OPTIONAL, INTENT, ALLOCATABLE, POINTER, TARGET, VALUE, ASYNCHRONOUS or CONTIGUOUS. (gfc_get_formal_from_actual_arglist): Do nothing if symbol is a class. gcc/testsuite/ChangeLog: PR fortran/119928 * gfortran.dg/interface_60.f90: New test.
2025-05-11Daily bump.GCC Administrator2-1/+9
2025-05-10testsuite: Fix pr119131-1.c for targets which emit a psabi warning for ↵Andrew Pinski1-0/+1
vectors of DFP [PR119909] On PowerPC, there is a psabi warning for argument passing of a DFP vector. We are not expecting this warning and we get a failure due to it. Adding -Wno-psabi fixes the testcase. Committed as obvious after a quick test. gcc/testsuite/ChangeLog: PR testsuite/119909 * gcc.dg/torture/pr119131-1.c: Add -Wno-psabi. Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com> (cherry picked from commit bfb61bf309ed207694a97adabc454bfd0936b269)
2025-05-10Daily bump.GCC Administrator4-1/+51
2025-05-09Fortran: parsing issue with DO CONCURRENT;ENDDO on same line [PR120179]Harald Anlauf2-3/+7
PR fortran/120179 gcc/fortran/ChangeLog: * match.cc (gfc_match_do): Do not attempt to match end-of-statement twice. gcc/testsuite/ChangeLog: * gfortran.dg/do_concurrent_basic.f90: Extend testcase. (cherry picked from commit 6ce73ad4370c143a7d1e6a13b1d353db5884213f)
2025-05-09Fortran: array subreferences and components of derived types [PR119986]Harald Anlauf3-4/+113
PR fortran/119986 gcc/fortran/ChangeLog: * expr.cc (is_subref_array): When searching for array references, do not terminate early so that inquiry references to complex components work. * primary.cc (gfc_variable_attr): A substring reference can refer to either a scalar or array character variable. Adjust search accordingly. gcc/testsuite/ChangeLog: * gfortran.dg/actual_array_subref.f90: New test. (cherry picked from commit fceb6022798b587c9111d0241aaff72602dcd626)
2025-05-09Fix wrong optimization of complex boolean expressionEric Botcazou6-4/+92
The VRP2 pass turns: # prephitmp_3 = PHI <0(4)> _1 = prephitmp_3 == 0; _5 = stretch_14(D) ^ 1; _39 = _1 & _5; _40 = _39 | last_20(D); into _5 = stretch_14(D) ^ 1; _42 = ~stretch_14(D); _39 = _42; _40 = last_20(D) | _39; using the following step: Folding statement: _1 = prephitmp_3 == 0; Queued stmt for removal. Folds to: 1 Folding statement: _5 = stretch_14(D) ^ 1; Not folded Folding statement: _39 = _1 & _5; gimple_simplified to _42 = ~stretch_14(D); _39 = _42 & 1; Folded into: _39 = _42; Folding statement: _40 = _39 | last_20(D); Folded into: _40 = last_20(D) | _39; but stretch_14 is a 8-bit boolean so the two forms are not equivalent, that is to say dropping the "& 1" is wrong. It's another instance of the issue: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558537.html Here it's the reverse case: the bitwise NOT (~) is treated as logical by the machinery in range-op.cc but the bitwise AND (&) is *not* treated as logical by that of vr-values.cc, leading to the same problematic outcome. gcc/ * vr-values.cc (simplify_using_ranges::simplify) <BIT_AND_EXPR>: Do not call simplify_bit_ops_using_ranges for boolean types whose precision is not 1. gcc/testsuite/ * gnat.dg/opt106.adb: New test. * gnat.dg/opt106_pkg1.ads, gnat.dg/opt106_pkg1.adb: New helper. * gnat.dg/opt106_pkg2.ads, gnat.dg/opt106_pkg2.adb: Likewise.
2025-05-09Daily bump.GCC Administrator2-1/+34
2025-05-08fortran: Add testcases for PR120152, PR120153 and PR120158Jakub Jelinek4-0/+183
The following patch adds testcase coverage for the 3 recently fixed libgfortran PRs. On trunk before those fixes I'm getting with -m32 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) and with -m64 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120158.f90 -O0 execution test FAIL: gfortran.dg/pr120158.f90 -O1 execution test FAIL: gfortran.dg/pr120158.f90 -O2 execution test FAIL: gfortran.dg/pr120158.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/pr120158.f90 -O3 -g execution test FAIL: gfortran.dg/pr120158.f90 -Os execution test On latest trunk everything PASSes. 2025-05-08 Jakub Jelinek <jakub@redhat.com> PR libfortran/120152 PR libfortran/120153 PR libfortran/120158 * gfortran.dg/pr120152_1.f90: New test. * gfortran.dg/pr120152_2.f90: New test. * gfortran.dg/pr120153.f90: New test. * gfortran.dg/pr120158.f90: New test. (cherry picked from commit 66f5f03853035cc917627e7d044bff8ccd9eca3f)
2025-05-08libcpp: Further fixes for incorrect line numbers in large files [PR120061]Jakub Jelinek8-4/+40
The backport of the PR108900 fix to 14 branch broke building chromium because static_assert (__LINE__ == expected_line_number, ""); now triggers as the __LINE__ values are off by one. This isn't the case on the trunk and 15 branch because we've switched to 64-bit location_t and so one actually needs far longer header files to trigger it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 contain (large) testcases in patch form which show on the 14 branch that the first one used to fail before the PR108900 backport and now works correctly, while the second one attempts to match the chromium behavior and it used to pass before the PR108900 backport and now it FAILs. The two testcases show rare problematic cases, because do_include_common -> parse_include -> check_eol -> check_eol_1 -> cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start triggers there /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ if (line_delta < 0 || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) || ( /* We can't reuse the map if the line offset is sufficiently large to cause overflow when computing location_t values. */ (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) || range_bits < map->m_range_bits) map = linemap_check_ordinary (const_cast <line_map *> (linemap_add (set, LC_RENAME, ORDINARY_MAP_IN_SYSTEM_HEADER_P (map), ORDINARY_MAP_FILE_NAME (map), to_line))); and so creates a new ordinary map on the line right after the (problematic) #include line. Now, in the spot that r14-11679-g8a884140c2bcb7 patched, pfile->line_table->highest_location in all 3 tests (also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13 ) is before the decrement the start of the line after the #include line and so the decrement is really desirable in that case to put highest_location somewhere on the line where the #include actually is. But at the same time it is also undesirable, because if we do decrement it, then linemap_add LC_ENTER called from _cpp_do_file_change will then /* Generate a start_location above the current highest_location. If possible, make the low range bits be zero. */ location_t start_location = set->highest_location + 1; unsigned range_bits = 0; if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS) range_bits = set->default_range_bits; start_location += (1 << range_bits) - 1; start_location &= ~((1 << range_bits) - 1); linemap_assert (!LINEMAPS_ORDINARY_USED (set) || (start_location >= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP (set)))); and we can end up with the new LC_ENTER ordinary map having the same start_location as the preceding LC_RENAME one. Next thing that happens is computation of included_from: if (reason == LC_ENTER) { if (set->depth == 0) map->included_from = 0; else /* The location of the end of the just-closed map. */ map->included_from = (((map[0].start_location - 1 - map[-1].start_location) & ~((1 << map[-1].m_column_and_range_bits) - 1)) + map[-1].start_location); The normal case (e.g. with the testcase included at the start of this comment) is that map[-1] starts somewhere earlier and so map->included_from computation above nicely computes location_t which expands to the start of the #include line. With r14-11679 reverted, for #c11 as well as #c12 map[0].start_location == map[-1].start_location above, and so it is ((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1))) + map[-1].start_location, which happens to be start of the #include line. For #c11 map[0].start_location is 0x500003a0 and map[-1] has m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and map[0].included_from is set to 0x50000320. For #c12 map[0].start_location is 0x606c0402 and map[-2].start_location is 0x606c0400 and m_column_and_range_bits is 0 for all 3 maps. map[0].included_from is set to 0x606c0401. The last important part is again in linemap_add when doing LC_LEAVE: /* (MAP - 1) points to the map we are leaving. The map from which (MAP - 1) got included should be the map that comes right before MAP in the same file. */ from = linemap_included_from_linemap (set, map - 1); /* A TO_FILE of NULL is special - we use the natural values. */ if (to_file == NULL) { to_file = ORDINARY_MAP_FILE_NAME (from); to_line = SOURCE_LINE (from, from[1].start_location); sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from); } Here it wants to compute the right to_line which ought to be the line after the #include directive. On the #c11 testcase that doesn't work correctly though, because map[-1].included_from is 0x50000320, from[0] for that is LC_ENTER with start_location 0x4080 and m_column_and_range_bits 12 but note that we've earlier computed map[-1].start_location + (-1 & 0xffffff80) and so only decreased by 7 bits, so to_line is still on the line with #include and not after it. In the #c12 that doesn't happen, all the ordinary maps involved there had 0 m_column_and_range_bits and so this computes correct line. Below is a fix for the trunk including testcases using the location_overflow_plugin hack to simulate the bugs without needing huge files (in the 14 case it is just 330KB and almost 10MB, but in the 15 case it would need to be far bigger). The pre- r15-9018 trunk has FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*6[^\n\r]*== 6 and current trunk FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*6[^\n\r]*== 6 FAIL: gcc.dg/plugin/location-overflow-test-pr120061.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*5[^\n\r]*== 5 and with the patch everything PASSes. I'll post afterwards a 14 version of the patch. The patch reverts the r15-9018 change, because it is incorrect, we really need to decrement it even when crossing ordinary map boundaries, so that the location is not on the line after the #include line but somewhere on the #include line. It also patches two spots in linemap_add mentioned above to make sure we get correct locations both in the included_from location_t when doing LC_ENTER (second line-map.cc hunk) and when doing LC_LEAVE to compute the right to_line (first line-map.cc hunk), both in presence of an added LC_RENAME with the same start_location as the following LC_ENTER (i.e. the problematic cases). The LC_ENTER hunk is mostly to ensure included_form location_t is at the start of the #include line (column 0), without it we can decrease include_from not enough and end up at some random column in the middle of the line, because it is masking away map[-1].m_column_and_range_bits bits even when in the end the resulting include_from location_t will be found in map[-2] map with perhaps different m_column_and_range_bits. That alone doesn't fix the bug though. The more important is the LC_LEAVE hunk and the problem there is caused by linemap_line_start not actually doing r = set->highest_line + (line_delta << map->m_column_and_range_bits); when adding a new map (the LC_RENAME one because we need to switch to different number of directly encoded ranges, or columns, etc.). So, in the original PR108900 case that to_line = SOURCE_LINE (from, from[1].start_location); doesn't do the right thing, from there is the last < 0x50000000 map with m_column_and_range_bits 12, from[1] is the first one above it and map[-1].included_from is the correct location of column 0 on the #include line, but as the new LC_RENAME map has been created without actually increasing highest_location to be on the new line (we've just set to_line of the new LC_RENAME map to the correct line), to_line = SOURCE_LINE (from, from[1].start_location); stays on the same source line. I've tried to just replace that with to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; i.e. just find out the #include line from map[-1].included_from and add 1 to it, unfortunately that breaks the c-c++-common/cpp/line-4.c test where we expect to stay on the same 0 line for LC_LEAVE from <command line> and gcc.dg/cpp/trad/Wunused.c, gcc.dg/cpp/trad/builtins.c and c-c++-common/analyzer/named-constants-via-macros-traditional.c tests all with -traditional-cpp preprocessing where to_line is also off-by-one from the expected one. So, this patch instead conditionalizes it, uses the to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; way only if from[1] is a LC_RENAME map (rather than the usual LC_ENTER one), that should limit it to the problematic cases of when parse_include peeked after EOL and had to create LC_RENAME map with the same start_location as the LC_ENTER after it. Some further justification for the LC_ENTER hunk, using the https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682774.html testcase (old is 14 before r14-11679, vanilla current 14 and new with the 14 patch) I get $ /usr/src/gcc-14/obj/gcc/cc1.old -quiet -std=c23 pr116047.c -nostdinc In file included from pr116047-1.h:327677:21, from pr116047.c:4: pr116047-2.h:1:1: error: unknown type name ‘a’ 1 | a b c; | ^ pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ 1 | a b c; | ^ pr116047-1.h:327677:1: error: static assertion failed: "" 327677 | #include "pr116047-2.h" | ^~~~~~~~~~~~~ $ /usr/src/gcc-14/obj/gcc/cc1.vanilla -quiet -std=c23 pr116047.c -nostdinc In file included from pr116047-1.h:327678, from pr116047.c:4: pr116047-2.h:1:1: error: unknown type name ‘a’ 1 | a b c; | ^ pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ 1 | a b c; | ^ $ /usr/src/gcc-14/obj/gcc/cc1.new -quiet -std=c23 pr116047.c -nostdinc In file included from pr116047-1.h:327677, from pr116047.c:4: pr116047-2.h:1:1: error: unknown type name ‘a’ 1 | a b c; | ^ pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ 1 | a b c; | ^ pr116047-1.h has on lines 327677+327678: #include "pr116047-2.h" static_assert (__LINE__ == 327678, ""); so the static_assert failure is something that was dealt mainly in the LC_LEAVE hunk and files.cc reversion, but please have a look at the In file included from lines. 14.2 emits correct line (#include "pr116047-2.h" is indeed on line 327677) but some random column in there (which is not normally printed for smaller headers; 21 is the . before extension in the filename). Current trunk emits incorrect line (327678 instead of 327677, clearly it didn't decrement). And the patched compiler emits the right line with no column, as would be printed if I remove e.g. 300000 newlines from the file. 2025-05-07 Jakub Jelinek <jakub@redhat.com> PR preprocessor/108900 PR preprocessor/116047 PR preprocessor/120061 * files.cc (_cpp_stack_file): Revert 2025-03-28 change. * line-map.cc (linemap_add): Use SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; instead of SOURCE_LINE (from, from[1].start_location); to compute to_line for LC_LEAVE. For LC_ENTER included_from computation, look at map[-2] or even lower if map[-1] has the same start_location as map[0]. * gcc.dg/plugin/plugin.exp: Add location-overflow-test-pr116047.c and location-overflow-test-pr120061.c. * gcc.dg/plugin/location_overflow_plugin.cc (plugin_init): Don't error on unknown values, instead just break. Handle 0x4fHHHHHH arguments differently. * gcc.dg/plugin/location-overflow-test-pr116047.c: New test. * gcc.dg/plugin/location-overflow-test-pr116047-1.h: New test. * gcc.dg/plugin/location-overflow-test-pr116047-2.h: New test. * gcc.dg/plugin/location-overflow-test-pr120061.c: New test. * gcc.dg/plugin/location-overflow-test-pr120061-1.h: New test. * gcc.dg/plugin/location-overflow-test-pr120061-2.h: New test. (cherry picked from commit edf745dc519ddbfef127e2789bf11bfbacd300b7)
2025-05-08Daily bump.GCC Administrator5-1/+53
2025-05-07c++: C++17/20 class layout divergence [PR120012]Jason Merrill4-12/+95
C++20 made a class with only explicitly defaulted constructors no longer aggregate, and this wrongly affected whether the class is considered "POD for layout purposes" under the ABI. Conveniently, we already have check_non_pod_aggregate to diagnose cases where this makes a difference, due to PR103681 around a C++14 aggregate change. This backport is the same code change as the trunk version, but since -fabi-version=21 cannot be selected, the fix is not available, only the warning, so the first testcase is different. PR c++/120012 gcc/cp/ChangeLog: * cp-tree.h (struct lang_type): Add non_aggregate_pod. (CLASSTYPE_NON_AGGREGATE_POD): New. * class.cc (check_bases_and_members): Set it. (check_non_pod_aggregate): Diagnose it. gcc/testsuite/ChangeLog: * g++.dg/abi/base-defaulted1.C: New test. * g++.dg/abi/base-defaulted1a.C: New test. (cherry picked from commit e6e3b0772ed40cc65a544bbe744ece62d8b9713e)
2025-05-07c++: let plain -Wabi warn about future changesJason Merrill1-15/+17
c_common_post_options limits flag_abi_version and flag_abi_compat_version to actual ABI version numbers, but let's not do that for warn_abi_version; we might want to add a warning relative to a future ABI version that isn't available in the current release, such backporting the PR120012 warning. Also allow plain -Wabi to include such a warning without complaining that it's useless. Also warn about an unsupported -fabi-version argument. gcc/c-family/ChangeLog: * c-opts.cc (c_common_post_options): Let plain -Wabi warn about changes in a future version. (cherry picked from commit 11e62bc6d9f8109a98facd1f90d4602869eb12e7)
2025-05-07ipa: Do not emit info about temporary clones to ipa-clones dump (PR119852)Martin Jambor2-1/+59
As described in PR 119852, the output of -fdump-ipa-clones can contain "(null)" as the suffix/reason for cloning when we need to create a clone to hold the original function during recursive inlining. Such clone is never output and so should not be part of the dump output either. gcc/ChangeLog: 2025-04-23 Martin Jambor <mjambor@suse.cz> PR ipa/119852 * cgraphclones.cc (dump_callgraph_transformation): Document the function. Do not dump if suffix is NULL. gcc/testsuite/ChangeLog: 2025-04-23 Martin Jambor <mjambor@suse.cz> PR ipa/119852 * gcc.dg/ipa/pr119852.c: New test. (cherry picked from commit fb5829a01651d427a63a12c44ecc8baa47dbfc83)
2025-05-07Document option -fdump-ipa-clonesMartin Jambor1-0/+87
I have noticed that the option -fdump-ipa-clones is not documented although there are users who depend on it. This patch adds the missing documentation along with the description of the information it dumps and the format it uses. I am never quite sure which of the texinfo mark-ups is the most appropriate in which situation, I'll of course incorporate any feedback on this as well as the general wording of the text. After we settle on a version, I'd like to backport the documentation also at least to GCC 15, 14 and 13. Is it perhaps OK for master and the branches or what would better be changed? Thanks, Martin gcc/ChangeLog: 2025-04-23 Martin Jambor <mjambor@suse.cz> * doc/invoke.texi (Developer Options): Document -fdump-ipa-clones. (cherry picked from commit 6ecc2fee06bdd60da0e9b3fe6660b553dbdca3ca)
2025-05-07Daily bump.GCC Administrator3-1/+30
2025-05-06Allow IPA_CP to handle UNDEFINED as VARYING.Andrew MacLeod2-0/+22
When applying a bitmask to reflect ranges, it is sometimes deferred and this can result in an UNDEFINED result. IPA is not expecting this, and add a check for it, and convert to VARYING if encountered. PR tree-optimization/120048 gcc/ * ipa-cp.cc (ipcp_store_vr_results): Check for UNDEFINED. gcc/testsuite/ * gcc.dg/pr120048.c: New.
2025-05-06gimple-fold: Fix fold_truth_andor_for_ifcombine [PR120074]Jakub Jelinek2-1/+25
The following testcase ICEs because of a mismatch between wide_int precision, in particular lr_and_mask has 32-bit precision while sign has 16-bit. decode_field_reference ensures that {ll,lr,rl,rr}_and_mask has {ll,lr,rl,rr}_bitsize precision, so the ll_and_mask |= sign; and rl_and_mask |= sign; and ll_and_mask &= sign; and rl_and_mask &= sign; cases should work right, sign has in those cases {ll,rl}_bitsize precision. The problem is that nothing until much later guarantees that ll_bitsize == lr_bitsize or rl_bitsize == rr_bitsize. In the testcase there is ((b ^ a) & 3) < 0 where a is 16-bit and b is 32-bit, so it is the lsignbit handling, and because of the xor the xor operand is moved to the *r_and_mask, so with ll_and_mask being 16-bit 3 and lr_and_mask being 32-bit 3. Now, either b in the above case would be INTEGER_CST, in that case if rr_arg was also INTEGER_CST we'd use the l_const && r_const case and try to handle it, or we'd run into (though much later) if (ll_bitsize != lr_bitsize || rl_bitsize != rr_bitsize ... return 0; One possibility is dealing with a different precision using wide_int::from. Another option used in this patch as it is safest is + if (ll_bitsize != lr_bitsize) + return 0; if (!lr_and_mask.get_precision ()) lr_and_mask = sign; else lr_and_mask &= sign; and similarly in the other hunk, i.e. punt if there is a mismatch early. And yet another option would be to compute the sign wide_int sign = wi::mask (ll_bitsize - 1, true, ll_bitsize); /* If ll_arg is zero-extended and we're testing the sign bit, we know what the result should be. Shifting the sign bit out of sign will get us to mask the entire field out, yielding zero, i.e., the sign bit of the zero-extended value. We know the masked value is being compared with zero, so the compare will get us the result we're looking for: TRUE if EQ_EXPR, FALSE if NE_EXPR. */ if (lsignbit > ll_bitsize && ll_unsignedp) sign <<= 1; once again for the lr_and_mask and rr_and_mask cases using rl_bitsize. As we just return 0; anyway unless l_const && r_const, if l_const & r_const are false it doesn't really matter what is chosen, but for the const cases it matters and I'm not sure what is right. So the second option might be safest. 2025-05-06 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/120074 * gimple-fold.cc (fold_truth_andor_for_ifcombine): For lsignbit && l_xor case, punt if ll_bitsize != lr_bitsize. Similarly for rsignbit && r_xor case, punt if rl_bitsize != rr_bitsize. Formatting fix. * gcc.dg/pr120074.c: New test. (cherry picked from commit 81475602c3dd57ff6987e5f902814e8e3a0a0dde)
2025-05-06Daily bump.GCC Administrator4-1/+47
2025-05-05ipa/120006 - wrong code with IPA PTARichard Biener2-0/+67
When PTA gets support for special-handling more builtins in find_func_aliases the corresponding code in find_func_clobbers needs updating as well since for unhandled cases it assumes the former will populate ESCAPED accordingly. The following fixes a few omissions, the testcase runs into the missing strdup handling. I believe the more advanced handling using modref results and fnspecs opened a larger gap, the proper fix is to merge both functions, gating the clobber/use part on a parameter to avoid diverging. PR ipa/120006 * tree-ssa-structalias.cc (find_func_clobbers): Handle strdup, strndup, realloc, index, strchr, strrchr, memchr, strstr, strpbrk builtins like find_func_aliases does. * gcc.dg/torture/pr120006.c: New testcase. (cherry picked from commit a85b89e26b1f50997701eb428c2dd71668f216ff)
2025-05-05ipa/119973 - IPA PTA issue with global initializersRichard Biener2-5/+44
For global initializers with IPA PTA we initialize them from the IPA reference data but that lacks references to the constant pool. The following conservatively considers the whole initializer. PR ipa/119973 * tree-ssa-structalias.cc (create_variable_info_for): Build constraints from DECL_INITIAL directly rather than the IPA reference list which is incomplete. * gcc.dg/torture/pr119973.c: New testcase. (cherry picked from commit 7a16ef443b13fff9537baa533597836c57131262)
2025-05-05Ada: Fix assertion failure on Finalizable aspect for tagged record typeEric Botcazou2-11/+30
This is a (benign) assertion failure on the mainline for the new Finalizable aspect put on a tagged record type when not all the primitives are declared. This compiles and runs on the 15 branch because assertions are disabled. gcc/ada/ PR ada/120104 * exp_ch3.adb (Expand_Freeze_Record_Type): For a controlled tagged type, freeze only the controlled primitives that are present. gcc/testsuite/ * gnat.dg/specs/finalizable1.ads: New test.
2025-05-05Daily bump.GCC Administrator1-1/+1
2025-05-04Daily bump.GCC Administrator3-1/+26
2025-05-03Fortran: fix procedure pointer handling with -fcheck=pointer [PR102900]Harald Anlauf4-7/+46
PR fortran/102900 gcc/fortran/ChangeLog: * trans-decl.cc (gfc_generate_function_code): Use sym->result when generating fake result decl for functions returning allocatable or pointer results. * trans-expr.cc (gfc_conv_procedure_call): When checking the pointer status of an actual argument passed to a non-allocatable, non-pointer dummy which is of type CLASS, do not check the class container of the actual if it is just a procedure pointer. (gfc_trans_pointer_assignment): Fix treatment of assignment to NULL of a procedure pointer. gcc/testsuite/ChangeLog: * gfortran.dg/proc_ptr_52.f90: Add -fcheck=pointer to options. * gfortran.dg/proc_ptr_57.f90: New test. (cherry picked from commit cc8d86ee4680d56eefeb76a8f2f752282e2631e3)
2025-05-03Daily bump.GCC Administrator3-1/+19
2025-05-02c: Fix up RAW_DATA_CST handling in check_constexpr_init [PR120057]Jakub Jelinek4-2/+54
The pr120057-1.c testcase is incorrectly rejected since r15-4377 (and for a while it also ICEd after the error), i.e. the optimization of large C initializers using RAW_DATA_CST. Similarly, the embed-18.c testcase is incorrectly rejected since the embed support has been introduced and RAW_DATA_CST used for that. The callers of check_constexpr_init (store_init_value and output_init_element) compute int_const_expr as int_const_expr = (TREE_CODE (init) == INTEGER_CST && !TREE_OVERFLOW (init) && INTEGRAL_TYPE_P (TREE_TYPE (init))); but that is only passed through down to check_constexpr_init. I think tweaking those 2 callers to also allow RAW_DATA_CST for int_const_expr when check_constexpr_init needs top special case it no matter what would be larger, so the patch just changes check_constexpr_init to deal with RAW_DATA_CST in the initializers. For TYPE_UNSIGNED char precision integral types RAW_DATA_CST is always valid, for !TYPE_UNSIGNED we need to check for 128-255 values being turned into negative ones. 2025-05-02 Jakub Jelinek <jakub@redhat.com> PR c/120057 * c-typeck.cc (check_constexpr_init): Handle RAW_DATA_CST. * gcc.dg/cpp/embed-18.c: New test. * gcc.dg/pr120057-1.c: New test. * gcc.dg/pr120057-2.c: New test. (cherry picked from commit e81f2f4855876c5d85ab9870c5a150ee1a59ee73)
2025-05-02Daily bump.GCC Administrator3-1/+59
2025-05-01c++/modules: Ensure deduction guides for imported types are reachable [PR120023]Nathaniel Shead4-0/+38
In the linked PR, because the deduction guides depend on an imported type, we never walk the type and so never call add_deduction_guides. This patch ensures that we make bindings for deduction guides if we saw any deduction guide at all. PR c++/120023 gcc/cp/ChangeLog: * module.cc (depset::hash::find_dependencies): Also call add_deduction_guides when walking one. gcc/testsuite/ChangeLog: * g++.dg/modules/dguide-7_a.C: New test. * g++.dg/modules/dguide-7_b.C: New test. * g++.dg/modules/dguide-7_c.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit fb4583566afdee50aad12e1219610813b44bdff4)
2025-05-01c++/modules: Fix imported CNTTPs being considered non-constant [PR119938]Nathaniel Shead3-1/+30
When importing a CNTTP object, since r15-3031-g0b7904e274fbd6 we shortcut the processing of the generated NTTP so that we don't attempt to recursively load pendings. However, due to an oversight we do not properly set TREE_CONSTANT or DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P on the decl, which confuses later processing. This patch ensures that this happens correctly. PR c++/119938 gcc/cp/ChangeLog: * pt.cc (get_template_parm_object): When !check_init, add assert that expr really is constant and mark decl as such. gcc/testsuite/ChangeLog: * g++.dg/modules/tpl-nttp-2_a.H: New test. * g++.dg/modules/tpl-nttp-2_b.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit d613678c94f06809656e56b37f314501b37a5ddd)
2025-05-01c++/modules: Catch exposures of TU-local values through inline references ↵Nathaniel Shead2-7/+53
[PR119996] In r15-9136-g0210bedf481a9f we started erroring for inline variables that exposed TU-local entities in their definition, as such variables would need to have their definitions emitted in importers but would not know about the TU-local entities they referenced. A case we mised was potentially-constant references, which disable streaming of their definitions in make_dependency so as to comply with [expr.const] p9.2. This meant that we didn't see the definition referencing a TU-local entity, leading to nonsensical results. PR c++/119551 PR c++/119996 gcc/cp/ChangeLog: * module.cc (depset::hash::make_dependency): Also mark inline variables referencing TU-local values as exposures here. (depset::hash::finalize_dependencies): Add error message for inline variables. gcc/testsuite/ChangeLog: * g++.dg/modules/internal-13.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 22ccaded63e96e5a42f4e3676dbbb57aa05b36f9)
2025-05-01Daily bump.GCC Administrator6-1/+92
2025-04-30Update gcc .po filesJoseph Myers20-92971/+96411
* 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-30Always reflect lower bits from mask in subranges.Andrew MacLeod6-41/+61
During intersection, we expand the subranges to exclude the lower values from a bitmask with trailing zeros. This leads to inconsistant evaluations and in this case of this PR, that lead to an infinite cycle. Always expand the lower subranges in set_range_from_bitmask instead. PR tree-optimization/119712 gcc/ * value-range.cc (range_bitmask::adjust_range): Delete. (irange::set_range_from_bitmask): Integrate adjust_range. (irange::update_bitmask): Do nothing if bitmask doesnt change. (irange:intersect_bitmask): Do not call adjust_range. Exit if there is no second bitmask. * value-range.h (adjust_range): Remove prototype. gcc/testsuite/ * gcc.dg/pr119712.c: New. * gcc.dg/pr83072-2.c: Adjust. * gcc.dg/tree-ssa/phi-opt-value-5.c: Adjust. * gcc.dg/tree-ssa/vrp122.c: Adjust
2025-04-30testsuite: Force -mcmodel=small for gcc.target/aarch64/pr115258.cRichard Sandiford1-1/+1
The test implicitly assumed the default code model and so failed for -mcmodel=tiny. gcc/testsuite/ * gcc.target/aarch64/pr115258.c: Add -mcmodel=small. (cherry picked from commit 3584aab37f54bcd220c7061568af777e37f4f6ed)
2025-04-30c++: UNBOUND_CLASS_TEMPLATE context substitution [PR119981]Patrick Palka2-7/+30
In r15-123 and r14-11434 we unconditionally set processing_template_decl when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to handle instantiation of the dependently scoped friend declaration template<int N> template<class T> friend class A<N>::B; where the scope A<N> remains dependent after instantiation. But this turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below testcase representing g<[]{}>::template fn since with the flag set substituting the args of test3 into the lambda causes us to defer the substitution and yield a lambda that still looks dependent, which in turn makes g<[]{}> still dependent and not suitable for qualified name lookup. This patch restricts setting processing_template_decl during UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple levels of introduced template parameters, as in the friend declaration. (This means we need to substitute the template parameter list(s) first, which makes sense since they lexically appear first.) PR c++/119981 PR c++/119378 gcc/cp/ChangeLog: * pt.cc (tsubst) <case UNBOUND_CLASS_TEMPLATE>: Substitute into template parameter list first. When substituting the context, only set processing_template_decl if there's more than one level of introduced template parameters. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/lambda-targ15.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 05ea8baf6ff96c77a9a2467d5c45b1ed575fca92)
2025-04-30Fix GNAT build failure for x86/FreeBSDEric Botcazou2-0/+173
gcc/ada/ PR ada/112958 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific version of s-dorepr.adb. * libgnat/s-dorepr__freebsd.adb: New file.
2025-04-30AVR: fxload_<mode>_libgcc: Use REG_ prefix.Georg-Johann Lay1-3/+3
gcc/ * config/avr/avr.md (fxload_<mode>_libgcc): Use REG_ prefix for magix register numbers (aligns with trunk).
2025-04-30AVR: target/119989 - Add missing clobbers to xload_<mode>_libgcc.Georg-Johann Lay10-1/+98
libgcc's __xload_1...4 is clobbering Z (and also R21 is some cases), but avr.md had clobbers of respective GPRs only up to reload. Outcome was that code reading from the same __memx address twice could be wrong. This patch adds respective clobbers. Forward-port from 2025-04-30 r14-11703 PR target/119989 gcc/ * config/avr/avr.md (xload_<mode>_libgcc): Clobber R21, Z. gcc/testsuite/ * gcc.target/avr/torture/pr119989.h: New file. * gcc.target/avr/torture/pr119989-memx-1.c: New test. * gcc.target/avr/torture/pr119989-memx-2.c: New test. * gcc.target/avr/torture/pr119989-memx-3.c: New test. * gcc.target/avr/torture/pr119989-memx-4.c: New test. * gcc.target/avr/torture/pr119989-flashx-1.c: New test. * gcc.target/avr/torture/pr119989-flashx-2.c: New test. * gcc.target/avr/torture/pr119989-flashx-3.c: New test. * gcc.target/avr/torture/pr119989-flashx-4.c: New test. (cherry picked from commit 1ca1c1fc3b58ae5e1d3db4f5a2014132fe69f82a)
2025-04-30Fix compilation failure on FreeBSDEric Botcazou1-1/+1
[changelog] PR ada/112958 * init.c (__gnat_error_handler) [__FreeBSD__]: Fix typo.
2025-04-30Daily bump.GCC Administrator3-1/+33
2025-04-29aarch64: Fix CFA offsets in non-initial stack probes [PR119610]Richard Sandiford3-26/+78
PR119610 is about incorrect CFI output for a stack probe when that probe is not the initial allocation. The main aarch64 stack probe function, aarch64_allocate_and_probe_stack_space, implicitly assumed that the incoming stack pointer pointed to the top of the frame, and thus held the CFA. aarch64_save_callee_saves and aarch64_restore_callee_saves use a parameter called bytes_below_sp to track how far the stack pointer is above the base of the static frame. This patch does the same thing for aarch64_allocate_and_probe_stack_space. Also, I noticed that the SVE path was attaching the first CFA note to the wrong instruction: it was attaching the note to the calculation of the stack size, rather than to the r11<-sp copy. gcc/ PR target/119610 * config/aarch64/aarch64.cc (aarch64_allocate_and_probe_stack_space): Add a bytes_below_sp parameter and use it to calculate the CFA offsets. Attach the first SVE CFA note to the move into the associated temporary register. (aarch64_allocate_and_probe_stack_space): Update calls accordingly. Start out with bytes_per_sp set to the frame size and decrement it after each allocation. gcc/testsuite/ PR target/119610 * g++.dg/torture/pr119610.C: New test. * g++.target/aarch64/sve/pr119610-sve.C: Likewise. (cherry picked from commit fa61afef18a8566d1907a5ae0e7754e1eac207d9)
2025-04-29Remove other processors from X86_TUNE_DEST_FALSE_DEP_FOR_GLC except GLCliuhongt1-3/+1
Since the tune if only for GLC(sapphirerapids and alderlake-P). gcc/ChangeLog: * config/i386/x86-tune.def (X86_TUNE_DEST_FALSE_DEP_FOR_GLC): Remove other processor except for GLC since this one is only for GLC. (cherry picked from commit 1ad6e171b126a82f38b1e8cbfd207f1d91c58a59)
2025-04-29Daily bump.GCC Administrator1-1/+1
2025-04-28Daily bump.GCC Administrator3-1/+41
2025-04-27c++/modules: Ensure DECL_FRIEND_CONTEXT is streamed [PR119939]Nathaniel Shead3-2/+20
An instantiated friend function relies on DECL_FRIEND_CONTEXT being set to be able to recover the template arguments of the class that instantiated it, despite not being a template itself. This patch ensures that this data is streamed even when DECL_CLASS_SCOPE_P is not true. PR c++/119939 gcc/cp/ChangeLog: * module.cc (trees_out::lang_decl_vals): Also stream lang->u.fn.context when DECL_UNIQUE_FRIEND_P. (trees_in::lang_decl_vals): Likewise. gcc/testsuite/ChangeLog: * g++.dg/modules/concept-11_a.H: New test. * g++.dg/modules/concept-11_b.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> (cherry picked from commit 1c5cf7cc82d3a2afa5d4fb90049456be408c2a7a)
2025-04-27c++/modules: Find non-exported reachable decls when instantiating friend ↵Nathaniel Shead4-20/+67
classes [PR119863] In r15-9029-geb26b667518c95, we started checking for conflicting declarations with any reachable decl attached to the same originating module. This exposed the issue in the PR, where we would always create a new type even if a matching type existed in the original module. This patch reworks lookup_imported_hidden_friend to handle this case better, by first checking for any reachable decl in the attached module before looking in the mergeable decl slots. PR c++/119863 gcc/cp/ChangeLog: * name-lookup.cc (get_mergeable_namespace_binding): Remove no-longer-used function. (lookup_imported_hidden_friend): Also look for hidden imported decls in an attached decl's module. gcc/testsuite/ChangeLog: * g++.dg/modules/tpl-friend-18_a.C: New test. * g++.dg/modules/tpl-friend-18_b.C: New test. * g++.dg/modules/tpl-friend-18_c.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> (cherry picked from commit 948ea8766780f7e44f39ccde3f2436ac2fec80da)
generated by cgit v1.1 at 2025-08-07 04:53:04 +0000