[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #61 from GCC Commits ---
The releases/gcc-13 branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:1ab646f678a9d47b338424ed69e9ae5d774b06ae
commit r13-8527-g1ab646f678a9d47b338424ed69e9ae5d774b06ae
Author: Xi Ruoyao
Date: Wed Mar 20 15:09:21 2024 +0800
mips: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument. This is causing gcc.dg/c23-stdarg-{6,8,9}.c to
fail.
Fix the issue by checking if arg.type is NULL, as r14-9503 explains.
gcc/ChangeLog:
PR target/114175
* config/mips/mips.cc (mips_setup_incoming_varargs): Only skip
mips_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.
(cherry picked from commit 6fc84f680d098f82c1c43435fdb206099f0df4df)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #60 from GCC Commits --- The releases/gcc-13 branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:b73a6a20113ca607cf3073c751698b12aa167881 commit r13-8526-gb73a6a20113ca607cf3073c751698b12aa167881 Author: Xi Ruoyao Date: Mon Mar 18 17:18:34 2024 +0800 LoongArch: Fix C23 (...) functions returning large aggregates [PR114175] We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there is nothing to advance, but that is not the case for (...) functions returning by hidden reference which have one such artificial argument. This is causing gcc.dg/c23-stdarg-6.c and gcc.dg/c23-stdarg-8.c to fail. Fix the issue by checking if arg.type is NULL, as r14-9503 explains. gcc/ChangeLog: PR target/114175 * config/loongarch/loongarch.cc (loongarch_setup_incoming_varargs): Only skip loongarch_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit c1fd4589c2bf9fd8409d51b94df219cb75107762)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #32 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:85b2b99e56b6f54b3feb530b2492955486e3d389 commit r13-8522-g85b2b99e56b6f54b3feb530b2492955486e3d389 Author: Jakub Jelinek Date: Tue Mar 26 11:06:15 2024 +0100 tsan: Don't instrument non-generic AS accesses [PR111736] Similar to the asan and ubsan changes, we shouldn't instrument non-generic address space accesses with tsan, because we just have library functions which take address of the objects as generic address space pointers, so they can't handle anything else. 2024-03-26 Jakub Jelinek PR sanitizer/111736 * tsan.cc (instrument_expr): Punt on non-generic address space accesses. * gcc.dg/tsan/pr111736.c: New test. (cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #31 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:05de873353ab9e94cda2b9e9561a82ca4e061c3f commit r13-8520-g05de873353ab9e94cda2b9e9561a82ca4e061c3f Author: Jakub Jelinek Date: Fri Mar 22 09:23:44 2024 +0100 ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736] On x86 and avr some address spaces allow 0 pointers (on avr actually even generic as, but libsanitizer isn't ported to it and I'm not convinced we should completely kill -fsanitize=null in that case). The following patch makes sure those aren't diagnosed for -fsanitize=null, though they are still sanitized for -fsanitize=alignment. 2024-03-22 Jakub Jelinek PR sanitizer/111736 * ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid SANITIZE_NULL instrumentation for non-generic address spaces for which targetm.addr_space.zero_address_valid (as) is true. * gcc.dg/ubsan/pr111736.c: New test. (cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)
[Bug tree-optimization/109925] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu since GCC-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109925 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:43022dd24e82a8625895e35da2b7e5a45f3b7483 commit r13-8524-g43022dd24e82a8625895e35da2b7e5a45f3b7483 Author: Jakub Jelinek Date: Thu Mar 28 11:58:26 2024 +0100 testsuite: Add testcase for already fixed PR [PR109925] This testcase was made latent by r14-4089 and got fixed both on the trunk and 13 branch with PR113372 fix. Adding testcase to the testsuite and will close the PR as a dup. 2024-03-28 Jakub Jelinek PR tree-optimization/109925 * gcc.c-torture/execute/pr109925.c: New test. (cherry picked from commit 7942558f27038461f948ca10140a156ae678cdf8)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #59 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:01397f789866198ad4fae3893d8f6b0a1d96cd96 commit r13-8519-g01397f789866198ad4fae3893d8f6b0a1d96cd96 Author: Jakub Jelinek Date: Wed Mar 20 17:00:51 2024 +0100 visium: Fix up visium_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, visium seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/visium/visium.cc (visium_setup_incoming_varargs): Only skip TARGET_FUNCTION_ARG_ADVANCE for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit b05ee9b69e4644cefbb94a768c4ea302fd44b934)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #54 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fce980ba3802e1adc68cb34ae81d17bc8c9d13b9 commit r13-8514-gfce980ba3802e1adc68cb34ae81d17bc8c9d13b9 Author: Jakub Jelinek Date: Wed Mar 20 16:59:21 2024 +0100 epiphany: Fix up epiphany_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, epiphany seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/epiphany/epiphany.cc (epiphany_setup_incoming_varargs): Only skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit b089ceb365e5132e4b2a8acfb18127bbee2d0d00)
[Bug middle-end/111151] [12/13 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51 --- Comment #18 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:71a1ccc0378f18dfecb54bfa453c0334fbb76675 commit r13-8523-g71a1ccc0378f18dfecb54bfa453c0334fbb76675 Author: Jakub Jelinek Date: Tue Mar 26 11:21:38 2024 +0100 fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR51] As I've tried to explain in the comments, the extract_muldiv_1 MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR. If the multiplication is done in unsigned type or in signed type with -fwrapv, it is fairly obvious that max (a, b) * c in many cases isn't equivalent to max (a * c, b * c) (or min if c is negative) due to overflows, but even for signed with undefined overflow, the optimization could turn something without UB in it (where say a * c invokes UB, but max (or min) picks the other operand where b * c doesn't). As for division/modulo, I think it is in most cases safe, except if the problematic INT_MIN / -1 case could be triggered, but we can just punt for MAX_EXPR because for MIN_EXPR if one operand is INT_MIN, we'd pick that operand already. It is just for completeness, match.pd already has an optimization which turns x / -1 into -x, so the division by zero is mostly theoretical. That is also why in the testcase the i case isn't actually miscompiled without the patch, while the c and f cases are. 2024-03-26 Jakub Jelinek PR middle-end/51 * fold-const.cc (extract_muldiv_1) : Punt for MULT_EXPR altogether, or for MAX_EXPR if c is -1. * gcc.c-torture/execute/pr51.c: New test. (cherry picked from commit c4f2c84e8fa369856aee76679590eb613724bfb0)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #58 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:02f66c40fb626656b924c1c7af3b5ededf8963e5 commit r13-8518-g02f66c40fb626656b924c1c7af3b5ededf8963e5 Author: Jakub Jelinek Date: Wed Mar 20 17:00:08 2024 +0100 nios2: Fix up nios2_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, nios2 seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/nios2/nios2.cc (nios2_setup_incoming_varargs): Only skip nios2_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit 4c9d2810908004b7e04599b426aca5ee1bd16735)
[Bug tree-optimization/112303] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_flow_info failed since r14-3459-g0c78240fd7d519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
--- Comment #16 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:b7b4ef2ff20c5023a41ed663dd8f4724b4ff0f9c
commit r13-8525-gb7b4ef2ff20c5023a41ed663dd8f4724b4ff0f9c
Author: Jakub Jelinek
Date: Thu Mar 28 15:00:44 2024 +0100
profile-count: Avoid overflows into uninitialized [PR112303]
The testcase in the patch ICEs with
--- gcc/tree-scalar-evolution.cc
+++ gcc/tree-scalar-evolution.cc
@@ -3881,7 +3881,7 @@ final_value_replacement_loop (class loop *loop)
/* Propagate constants immediately, but leave an unused
initialization
around to avoid invalidating the SCEV cache. */
- if (CONSTANT_CLASS_P (def) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI
(rslt))
+ if (0 && CONSTANT_CLASS_P (def) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI
(rslt))
replace_uses_by (rslt, def);
/* Create the replacement statements. */
(the addition of the above made the ICE latent), because profile_count
addition doesn't check for overflows and if unlucky, we can even overflow
into the uninitialized value.
Getting really huge profile counts is very easy even when not using
recursive inlining in loops, e.g.
__attribute__((noipa)) void
bar (void)
{
__builtin_exit (0);
}
__attribute__((noipa)) void
foo (void)
{
for (int i = 0; i < 1000; ++i)
for (int j = 0; j < 1000; ++j)
for (int k = 0; k < 1000; ++k)
for (int l = 0; l < 1000; ++l)
for (int m = 0; m < 1000; ++m)
for (int n = 0; n < 1000; ++n)
for (int o = 0; o < 1000; ++o)
for (int p = 0; p < 1000; ++p)
for (int q = 0; q < 1000; ++q)
for (int r = 0; r < 1000; ++r)
for (int s = 0; s < 1000; ++s)
for (int t = 0; t < 1000; ++t)
for (int u = 0; u < 1000; ++u)
for (int v = 0; v < 1000; ++v)
for (int w = 0; w < 1000; ++w)
for (int x = 0; x < 1000; ++x)
for (int y = 0; y < 1000; ++y)
for (int z = 0; z < 1000; ++z)
for (int a = 0; a < 1000; ++a)
for (int b = 0; b < 1000; ++b)
bar ();
}
int
main ()
{
foo ();
}
reaches the maximum count already on the 11th loop.
Some other methods of profile_count like apply_scale already
do use MIN (val, max_count) before assignment to m_val, this patch
just extends that to operator{+,+=} methods.
Furthermore, one overload of apply_probability wasn't using
safe_scale_64bit and so could very easily overflow as well
- prob is required to be [0, 1] and if m_val is near the max_count,
it can overflow even with multiplications by 8.
2024-03-28 Jakub Jelinek
PR tree-optimization/112303
* profile-count.h (profile_count::operator+): Perform
addition in uint64_t variable and set m_val to MIN of that
val and max_count.
(profile_count::operator+=): Likewise.
(profile_count::operator-=): Formatting fix.
(profile_count::apply_probability): Use safe_scale_64bit
even in the int overload.
* gcc.c-torture/compile/pr112303.c: New test.
(cherry picked from commit d5a3b4afcdf4d517334a2717dbb65ae0d2c26507)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #53 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:06f9476a60bcf2d206b7b86e68ea433954f91f20 commit r13-8513-g06f9476a60bcf2d206b7b86e68ea433954f91f20 Author: Jakub Jelinek Date: Wed Mar 20 16:59:08 2024 +0100 csky: Fix up csky_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, csky seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/csky/csky.cc (csky_setup_incoming_varargs): Only skip csky_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit 68eca9b6aefeb40bdd4c55e42528cb32d1e2935b)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #57 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:91092c30eda6777e33705a66a2c3049d4a18569d commit r13-8517-g91092c30eda6777e33705a66a2c3049d4a18569d Author: Jakub Jelinek Date: Wed Mar 20 16:59:56 2024 +0100 nds32: Fix up nds32_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, nds32 seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/nds32/nds32.cc (nds32_setup_incoming_varargs): Only skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit b22a9c7dd29a14a217de8b86d3e100e4e8b7785e)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #56 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f3af5a241c820e564ef13614ae0ea7a57237bd50 commit r13-8516-gf3af5a241c820e564ef13614ae0ea7a57237bd50 Author: Jakub Jelinek Date: Wed Mar 20 16:59:43 2024 +0100 m32r: Fix up m32r_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, m32r seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/m32r/m32r.cc (m32r_setup_incoming_varargs): Only skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit 921eb457c5b105bcd84eaeac22067e9b03d5b9d1)
[Bug middle-end/111683] [11/12/13 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #28 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4320e8483bb88b49bf251451307324c06d33c0a4 commit r13-8521-g4320e8483bb88b49bf251451307324c06d33c0a4 Author: Jakub Jelinek Date: Sat Mar 23 11:17:44 2024 +0100 predcom: Punt for steps which aren't multiples of access size [PR111683] On the following testcases, there is no overlap between data references within a single iteration, but the data references have size which is twice as large as the step, which means the data references overlap with the next iteration which predcom doesn't take into account. As discussed in the PR, even if the reference size is smaller than step, if step isn't a multiple of the reference size, there could be overlaps with some other iteration later on. The initial version of the patch regressed (test still passed, but predcom didn't optimize anymore) pr71083.c which has a packed char, short structure and was reading/writing the short 2 bytes in there with step 3. The following patch deals with that by retrying for COMPONENT_REFs also the aggregate sizes etc., so that it then compares 3 bytes against step 3. In make check-gcc/check-g++ this patch I believe affects code generation for only the 2 new testcases according to statistics I've gathered. 2024-03-23 Jakub Jelinek PR middle-end/111683 * tree-predcom.cc (pcom_worker::suitable_component_p): If has_write and comp_step is RS_NONZERO, return false if any reference in the component doesn't have DR_STEP a multiple of access size. * gcc.dg/pr111683-1.c: New test. * gcc.dg/pr111683-2.c: New test. (cherry picked from commit 8fc5593df8e0d36cc5bd8ea21097a491a634a866)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #52 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:097999338bc0e298290ec965c946f69f2237729a commit r13-8511-g097999338bc0e298290ec965c946f69f2237729a Author: Jakub Jelinek Date: Tue Mar 19 09:49:59 2024 +0100 arc: Fix up arc_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, arc seems to be affected too. 2024-03-19 Jakub Jelinek PR target/114175 * config/arc/arc.cc (arc_setup_incoming_varargs): Only skip arc_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit 1f257714674cd8fd69db7367aecdd09b672d1db7)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #50 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:af189fa9c2c4a0c8230f308e1934f046df3e80f7 commit r13-8509-gaf189fa9c2c4a0c8230f308e1934f046df3e80f7 Author: Jakub Jelinek Date: Tue Mar 19 09:13:32 2024 +0100 rs6000: Fix up setup_incoming_varargs [PR114175] The c23-stdarg-8.c test (as well as the new test below added to cover even more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets as well. Like in the r14-9503-g218d174961 change on x86-64 we need to advance next_cum after the hidden return pointer argument even in case where there are no user arguments before ... in C23. The following patch does that. There is another TYPE_NO_NAMED_ARGS_STDARG_P use later on: if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl)) && targetm.calls.must_pass_in_stack (arg)) first_reg_offset += rs6000_arg_size (TYPE_MODE (arg.type), arg.type); but I believe it was added there in r13-3549-g4fe34cdc unnecessarily, when there is no hidden return pointer argument, arg.type is NULL and must_pass_in_stack_var_size as well as must_pass_in_stack_var_size_or_pad return false in that case, and for the TYPE_NO_NAMED_ARGS_STDARG_P case with hidden return pointer argument that argument should have pointer type and it is the first argument, so must_pass_in_stack shouldn't be true for it either. 2024-03-19 Jakub Jelinek PR target/114175 * config/rs6000/rs6000-call.cc (setup_incoming_varargs): Only skip rs6000_function_arg_advance_1 for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. * gcc.dg/c23-stdarg-9.c: New test. (cherry picked from commit 8f85b46337f90c3126b9cefd72ffd29eb9a4ebf3)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #55 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a2565fbb722f9ea9a990286b72ae1a95145af910 commit r13-8515-ga2565fbb722f9ea9a990286b72ae1a95145af910 Author: Jakub Jelinek Date: Wed Mar 20 16:59:32 2024 +0100 ft32: Fix up ft32_setup_incoming_varargs [PR114175] Like for x86-64, alpha or rs6000, ft32 seems to be affected too. Just visually checked differences in c23-stdarg-9.c assembly in a cross without/with the patch, committed to trunk. 2024-03-20 Jakub Jelinek PR target/114175 * config/ft32/ft32.cc (ft32_setup_incoming_varargs): Only skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit 22612a8b5e0853c530f98fc7c0d6f6812b36518d)
[Bug bootstrap/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8046a7e2aeeae80c15d99d55ae04755aedf46a2f commit r13-8512-g8046a7e2aeeae80c15d99d55ae04755aedf46a2f Author: Jakub Jelinek Date: Wed Mar 20 10:34:51 2024 +0100 system.h: rename vec_step to workaround powerpc/clang bug [PR114369] On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote: > Gerald Pfeifer writes: > > I have seen an increasing number of reports of GCC failing to > > build with clang on powerpc (on FreeBSD, though that's probably > > immaterial). > > > > Turns out that clang has vec_step as a reserved word on powerpc > > with AltiVec. > > > > We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c. > > > > > > The best approach I can see is to rename vec_step. Before I prepare > > a patch: what alternate name/spelling would you prefer? > > Would it work to #define vec_step to vec_step_ or something on affected > hosts, say in system.h? > > I'd prefer that to renmaing since "vec_step" does seem the most natural > name for the variable. The equivalent scalar variable is "step" and > other vector values in the surrounding code also use the "vec_" prefix. So like this? If/when clang finally fixes https://github.com/llvm/llvm-project/issues/85579 on their side, we can then limit it to clang versions which still have the bug. I've git grepped for vec_set and appart from altivec.h it is just used in tree-vect-loop.cc, some Ada files which aren't preprocessed, ChangeLogs, rs6000-vecdefines.h (but that header is only included from altivec.h and vec_step is then redefined to the function-like macro) and in rs6000-overload.def but that file is processed with a generator, not included in C/C++ sources. 2024-03-20 Jakub Jelinek PR bootstrap/114369 * system.h (vec_step): Define to vec_step_ when compiling with clang on PowerPC. (cherry picked from commit 5e64228fe1f7ec536da314246eec968aea0d704d)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #51 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d3faceaa7a18657cc73dff1405a54834e390624b commit r13-8510-gd3faceaa7a18657cc73dff1405a54834e390624b Author: Jakub Jelinek Date: Tue Mar 19 09:14:11 2024 +0100 alpha: Fix alpha_setup_incoming_varargs [PR114175] Like in the r14-9503 change on x86-64, I think Alpha also needs to function_arg_advance after the hidden return pointer argument if any. At least, the following patch changes the assembly of s1-s6 functions on the https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647956.html c23-stdarg-9.c testcase, and eyeballing the assembly for int f8 (...) the ... args are passed in 16..21 registers and then on the stack, while for struct S s8 (...) have hidden return pointer passed in 16 register and ... args in 17..21 registers and then on the stack, and seems without this patch the incoming varargs setup does the wrong thing (but I can't test on alpha easily). Many targets seem to be unaffected, e.g. aarch64, arm, s390*, so I'm not trying to change all targets together because such a change clearly isn't needed e.g. for targets which use special register for the hidden return pointer. 2024-03-19 Jakub Jelinek PR target/114175 * config/alpha/alpha.cc (alpha_setup_incoming_varargs): Only skip function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions if arg.type is NULL. (cherry picked from commit a185d8aeeed7a25a01505565aa61ccf8a876c6ff)
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #49 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:4e0a922db4dadaef704c68ed26693667903c5d0c
commit r13-8508-g4e0a922db4dadaef704c68ed26693667903c5d0c
Author: Jakub Jelinek
Date: Sat Mar 16 15:16:33 2024 +0100
i386: Fix setup of incoming varargs for (...) functions which return large
aggregates [PR114175]
The c23-stdarg-6.c testcase I've added recently apparently works fine with
-O0 but aborts with -O1 and higher on x86_64-linux.
The problem is in setup of incoming varargs.
Like function.cc before r14-9249 even ix86_setup_incoming_varargs assumes
that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there
is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
If the setup_incoming_varargs hook is called from the
if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl))
&& fnargs.is_empty ())
{
struct assign_parm_data_one data = {};
assign_parms_setup_varargs (, , false);
}
spot, i.e. where there is no hidden return argument passed, arg.type
is always NULL, while when it is called in the
if (cfun->stdarg && !DECL_CHAIN (parm))
assign_parms_setup_varargs (, , false);
spot, even when it is TYPE_NO_NAMED_ARGS_STDARG_P arg.type will be
non-NULL.
The tree-stdarg.cc pass in f in c23-stdarg-6.cc at -O1 or higher determines
that va_arg is used on integral types at most twice (loads 2 words),
and because ix86_setup_incoming_varargs doesn't advance, the code saves
just the %rdi and %rsi registers to the save area. But that isn't correct,
it should save %rsi and %rdx because %rdi is the hidden return argument.
With -O0 tree-stdarg.cc doesn't attempt to optimize and we save all the
registers, so it works fine in that case.
Now, I think we'll need the same fix also on
aarch64, alpha, arc, csky, ia64, loongarch, mips, mmix, nios2, riscv,
visium
which have pretty much the similarly looking snippet in their hooks
changed by the r13-3549 commit.
Then arm, epiphany, fr30, frv, ft32, m32r, mcore, nds32, rs6000, sh
have different changes but most likely need something similar too.
I don't have access to most of those, could test aarch64 and rs6000 I
guess.
2024-03-16 Jakub Jelinek
PR target/114175
* config/i386/i386.cc (ix86_setup_incoming_varargs): Only skip
ix86_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
* gcc.dg/c23-stdarg-7.c: New test.
* gcc.dg/c23-stdarg-8.c: New test.
(cherry picked from commit 218d17496122abe1fd831bd003f129310b32ca83)
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109849 --- Comment #6 from Andrew Pinski --- See PR 109849 for some of the improvements
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #5 from Rama Malladi --- (In reply to Andrew Pinski from comment #3) > Also do you have numbers with lto enabled? Or is these without lto? > > Does LTO improve the situation for Envoy too? These numbers are without lto. I haven't tried it but I can try and post an update.
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #4 from Rama Malladi --- (In reply to Andrew Pinski from comment #1) > Maybe we should figure out why the increase of the limits help and add extra > code to get better heuristics rather than just tweaking the limits. > > I know that there was some improvements for gcc 14 already for the > heuristics for c++ code. interesting... thank you.
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #48 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:6fc84f680d098f82c1c43435fdb206099f0df4df
commit r14-9728-g6fc84f680d098f82c1c43435fdb206099f0df4df
Author: Xi Ruoyao
Date: Wed Mar 20 15:09:21 2024 +0800
mips: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument. This is causing gcc.dg/c23-stdarg-{6,8,9}.c to
fail.
Fix the issue by checking if arg.type is NULL, as r14-9503 explains.
gcc/ChangeLog:
PR target/114175
* config/mips/mips.cc (mips_setup_incoming_varargs): Only skip
mips_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #3 from Andrew Pinski --- Also do you have numbers with lto enabled? Or is these without lto? Does LTO improve the situation for Envoy too?
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #2 from Andrew Pinski --- I suspect the implementation of the option should be changed slight as how does it interact with the user supplying the params too.
[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 --- Comment #1 from Andrew Pinski --- Maybe we should figure out why the increase of the limits help and add extra code to get better heuristics rather than just tweaking the limits. I know that there was some improvements for gcc 14 already for the heuristics for c++ code.
[Bug driver/114531] New: Feature proposal for an `-finline-functions-aggressive` compiler option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531 Bug ID: 114531 Summary: Feature proposal for an `-finline-functions-aggressive` compiler option Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: rvmallad at amazon dot com CC: rsandifo at gcc dot gnu.org Target Milestone: --- Created attachment 57837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57837=edit patch to implement -finline-functions-aggressive option in GCC This is a proposal for a user-visible GCC compiler option for aggressive inlining that is currently only available at -O3 as internal inline parameters (--param=early-inlining-insns=14 --param=inline-heuristics-hint-percent=600 --param=inline-min-speedup=15 --param=max-inline-insns-auto=30 --param=max-inline-insns-single=200). I got some perf data for Envoy (https://github.com/envoyproxy/envoy) and SPEC CPU2017 intrate benchmarks on C7g.2xlarge w Ubuntu22 + gcc-11.4.0. We see perf gains (2% - 5%) using these aggressive inline parameters (at -O2). Attached is a patch for this change. We do not want to add these inline limits at ‘-O2’ itself, as we see from one of the SPEC CPU tests that got slower. Also, more inline tuning at -O2 would make some of the symbols not to be available for probe/ debug (that are available when not using these aggressive inline params). --- Envoy load_balancer_benchmark – using only 1 CPU – Iterations, higher better $ bazel run -c opt //test/common/upstream:load_balancer_benchmark bazel-envoy/external/local_config_cc/BUILD can be changed for adding inline parameters/ options. Benchmark Iterations Baseline O2+ Inline Params Gain benchmarkRoundRobinLoad 1518 1596 1.05x BalancerBuild/500/50/50 benchmarkLeastRequestLoad1465 1514 1.03x BalancerChooseHost/100/3/1000 benchmarkRingHashLoadBalancer 33 34 1.03x ChooseHost/100/65536/10 benchmarkMaglevLoadBalancer69 72 1.04x Weighted/500/95/75/25/1 copies=8"-O2" "-Ofast" Gain "-O2 + Gain w w Ofastinlining" inlining 500.perlbench_r 36.534.3 94.0% 34.494.2% 502.gcc_r 45.447.6 104.8% 47.5104.6% 505.mcf_r 44.648.2 108.1% 44.399.3% 520.omnetpp_r 22.124.9 112.7% 21.999.1% 523.xalancbmk_r 43.846.3 105.7% 45.4103.7% 525.x264_r 44.389 200.9% 43.898.9% 531.deepsjeng_r 36 37.3 103.6% 37.5104.2% 541.leela_r 33.533.9 101.2% 34.2102.1% 548.exchange2_r 65.476.6 117.1% 65.399.8% 557.xz_r19.819.9 100.5% 19.9100.5% SPECrate..base 37.141.6 112.1% 37.3100.5% ---
[Bug libstdc++/103924] views::join combined with std::string cannot be used in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924 --- Comment #4 from 康桓瑋 --- (In reply to Patrick Palka from comment #2) > *** Bug 114530 has been marked as a duplicate of this bug. *** That's my lost memory.
[Bug go/114454] go.test/test/fixedbugs/issue27836.go FAILs with LANG=C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson --- This reminds me of PR105959, but no, I haven't actually jumped into the rabbithole^W^Wanalyzed the problem to any extent.
[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug ipa/114501] [11/12/13/14 Regression] ICE during modref with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug middle-end/114509] [11/12/13/14 Regression] an infinite loop or ICE with openmp after errors in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114509 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug target/114513] [11/12/13/14 Regression] [aarch64] floating-point registers are used when GPRs are preferred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114513 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug rtl-optimization/114522] [14 regression] gcc.target/arm/aes_xor_combine.c scan-assembler-not veor fails after r14-9692-g839bc42772ba7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114522 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug target/114510] [14 Regression] missed proping of multiply by 2 into address of load/stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114510 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #22 from Gerald Pfeifer --- (In reply to Dimitry Andric from comment #21) > Indeed, please merge both commits: > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=9970b576b7e4ae337af1268395ff221348c4b34a > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=5213047b1d50af63dfabb5e5649821a6cb157e33 Jakub, Ian, if you approve I volunteer to gradually push this to open release branches.
[Bug libstdc++/103924] views::join combined with std::string cannot be used in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
--- Comment #3 from Patrick Palka ---
>From PR114530:
#include
#include
static_assert(
std::ranges::distance(
std::views::single(std::views::cartesian_product(std::string{}))
| std::views::join
) == 0
);
[Bug libstdc++/114530] accessing 'std::__cxx11::basic_string::::_M_allocated_capacity' member instead of initialized 'std::__cxx11::basic_string::::_M_local_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114530 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- Let's call this a dup of PR103924 *** This bug has been marked as a duplicate of bug 103924 ***
[Bug libstdc++/103924] views::join combined with std::string cannot be used in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924 --- Comment #2 from Patrick Palka --- *** Bug 114530 has been marked as a duplicate of this bug. ***
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #22 from Peter Bergner --- I kicked off a 7450 build on one of our BE system and I can confirm we hit this error. I also saw us generating the 2 operand form of the mfcr instruction which also leads to an assembler error because the 7450 doesn't support that either. Were we are in the build is compiling libgcc and the routines for handling KFmode values. The build machinery is explicitly adding -mvsx -mfloat128 to the compiler options when building those source files and that seems bogus to me, since the 7450 does not have VSX hardware. It's the explicit addition of the -mvsx option to the command line that is causing the lfiwzx and 2 operand mfcr instructions to be generated, not some internal mishandling of the -mcpu=7450 option. My $0.02 worth is we should be generating an error when trying to use -msx with -mcpu=7450 or any other cpu that doesn't have VSX hardware. I also don't think we should be building these KFmode files which require VSX when the underlying cpu we're targeting doesn't support it.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #21 from Dimitry Andric --- (In reply to Iain Sandoe from comment #20) > This is fixed on trunk, but is needed on open release branches. Indeed, please merge both commits: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9970b576b7e4ae337af1268395ff221348c4b34a https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5213047b1d50af63dfabb5e5649821a6cb157e33
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #20 from Iain Sandoe --- This is fixed on trunk, but is needed on open release branches.
[Bug testsuite/112297] Failure of pr100936.c on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 --- Comment #3 from Iain Sandoe --- this seems to have been fixed by r14-6423-g02f562484c1752, does it need back porting? or should we close?
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Iain Sandoe --- thanks for the fixes, now passing on Darwin.
[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960 Michael Meissner changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #12 from Michael Meissner --- The test case actually shows on power8 GCC was generating incorrect code, and power9 is actually doing the right thing. But the test case was written assuming the previous behavior was correct. TL;DNR answer power8 generated STVX instead of STXVD2VX. Power9 generates STXV. To explain what the issue is, we need to go back in history. PowerPC processors (and Power before it) were originally designed for big endian environments. The Altivec instruction set had limited vector save and load instructions (STVX and LVX) which ignored the bottom 4 bits of the address. STVX and LVX did the correct byte swapping if the PowerPC was running in little endian mode. When power7 came out with the VSX instruction set, the vector save and load instructions (STXVD2X, STXV4X, LXVD2X, and LXV4X) were added. These instructions allowed saving and loading all 64 VSX registers (32 registers that overlapped with floating point registers, and 32 registers that overlapped with traditional Altivec registers). However, these instructions only store and load values using big endian ordering. After the power8 came out, the PowerPC Linux systems were moved from being big endian to little endian. This meant that after doing a vector load instruction, we had to do explicit byte swapping, and before a vector save we had to do the byte swapping of the value before doing the save. We added an optimization to GCC that in the special case of storing/loading temporaries on the stack, we would use the Altivec instructions STVX and LVX and elimiante the byte swapping instructions since we could insure that all temporaries were correctly aligned. But we couldn't use STVX and LVX in general due to these instructions ignoring the bottom 4 bits of the address and they restricted the vector registers to just the VSX registers that overlap with the Altivec registers. When power9 came out, we added new vector store and load instructions (STXV, STXVX, LXV, and LXVX) that did the correct byte swapping on little endian systems. GCC now generates these instructions and eliminates the special code to use the Altivec STVX and LVX instructions. In the test case, VerifyVecEqToActual takes 2 vector arguments, and creates 2 16 byte arrays, and stores each vector into the array. It uses reinterpret_cast to convert this into a store instruction. However, since the temporary is on the stack, on power8 this uses the Altivec STVX instruction and it gets byte swapped.
[Bug fortran/50410] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[11/12/13/14 Regression]|ICE in record_reference, |ICE in record_reference,|pointer variable in data |pointer variable in data|statement |statement | Keywords||diagnostic --- Comment #53 from anlauf at gcc dot gnu.org --- Removing the regression marker after the ICEs on the testcases are all resolved except: - comment#24 testcase z5: this is a coarray issue and has nothing to do with DATA initialization --> should be moved to a separate PR - missing diagnostics for overlapping initialization of DT components, and some sub-optimal error messages that could be improved So let's treat this PR further as any regular one.
[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #52 from GCC Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1611acc1f72cad30c7ecccb5c85246836c1d0299 commit r11-11299-g1611acc1f72cad30c7ecccb5c85246836c1d0299 Author: Harald Anlauf Date: Thu Mar 28 22:34:40 2024 +0100 Fortran: fix NULL pointer dereference on overlapping initialization [PR50410] gcc/fortran/ChangeLog: PR fortran/50410 * trans-expr.c (gfc_conv_structure): Check for NULL pointer. gcc/testsuite/ChangeLog: PR fortran/50410 * gfortran.dg/data_initialized_4.f90: New test. (cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)
[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #51 from GCC Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:cb72fbd49e1f0c1cbdf8a9e97860063b19b1f95e commit r12-10299-gcb72fbd49e1f0c1cbdf8a9e97860063b19b1f95e Author: Harald Anlauf Date: Thu Mar 28 22:34:40 2024 +0100 Fortran: fix NULL pointer dereference on overlapping initialization [PR50410] gcc/fortran/ChangeLog: PR fortran/50410 * trans-expr.cc (gfc_conv_structure): Check for NULL pointer. gcc/testsuite/ChangeLog: PR fortran/50410 * gfortran.dg/data_initialized_4.f90: New test. (cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)
[Bug fortran/113866] ice in generic_simplify_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5f9144021615f24d038890dab7db2a0b9e84f6d3 commit r13-8506-g5f9144021615f24d038890dab7db2a0b9e84f6d3 Author: Harald Anlauf Date: Tue Feb 13 20:19:10 2024 +0100 Fortran: fix passing of optional dummies to bind(c) procedures [PR113866] PR fortran/113866 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): When passing an optional dummy argument to an optional dummy argument of a bind(c) procedure and the dummy argument is passed via a CFI descriptor, no special presence check and passing of a default NULL pointer is needed. gcc/testsuite/ChangeLog: * gfortran.dg/bind_c_optional-2.f90: New test. (cherry picked from commit f4935df217ad89f884f908f39086b322e80123d0)
[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #50 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:250990298fb792635d9895e7642ccedbc2dd39d4 commit r13-8505-g250990298fb792635d9895e7642ccedbc2dd39d4 Author: Harald Anlauf Date: Thu Mar 28 22:34:40 2024 +0100 Fortran: fix NULL pointer dereference on overlapping initialization [PR50410] gcc/fortran/ChangeLog: PR fortran/50410 * trans-expr.cc (gfc_conv_structure): Check for NULL pointer. gcc/testsuite/ChangeLog: PR fortran/50410 * gfortran.dg/data_initialized_4.f90: New test. (cherry picked from commit 6fb253a25dff13253d63553f02e0fe72c5e3ab4e)
[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #3) > I can see why the assert is there but it is manifestly wrong for both the > assumed length target and a constant length. That's why I wanted to pass this on to you. I am not sure what the precise logic should be. > I was thrown a bit by the > distros nulling out the asserts so that it compiled just fine with the > system gfortran. If the system gfortran is based on 13.2 *release* then the bug is not yet there ;-) It entered 13-branch through backport r13-7986. > Your patch is perfect :- This compiles and runs correctly: > module m > contains > subroutine test_array_char(p, x) > character(*), target :: x(:) > character(:), pointer :: p(:) > p => x > end subroutine > end module > > use m > character(:), allocatable, target :: chr(:) > character(:), pointer :: p(:) > chr = ["ab","cd"] > call test_array_char (p, chr) > print '(l2,i4,2a4)', loc(chr) == loc(p), len(p), p > end The original testcase attached here has a second subroutine that ICEd: subroutine test_array_char_remap(p, x) character(*), target :: x(100) character(:), pointer :: p(:, :) p(2:11, 3:12) => x end subroutine It is also fixed by the patch, and checking the bounds etc. in the caller shows that it works correct too :-) program main implicit none character(3) :: x(100) = "* #" character(:), pointer :: p(:), q(:,:) call test_array_char (p, x) print *, associated (p) print *, size (p) print *, len (p) print *, p(5)(1:1) call test_array_char_remap (q, x) print *, associated (q) print *, size (q) print *, len (q) print *, lbound(q), ubound(q) print *, q(5,5)(3:3) contains subroutine test_array_char(p, x) character(*), target :: x(100) character(:), pointer :: p(:) p => x end subroutine subroutine test_array_char_remap(p, x) character(*), target :: x(100) character(:), pointer :: p(:, :) p(2:11, 3:12) => x end subroutine end
[Bug c/12411] Missed -Wsequence-point on functions (example reduced from historical GCC source)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12411 --- Comment #10 from Eric Gallager --- I think the dup is a point for reopening
[Bug c++/114479] [14 Regression] std::is_array_v changed from false to true in GCC 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I think the patch is simply --- a/gcc/cp/semantics.cc +++ b/gcc/cp/semantics.cc @@ -12439,7 +12439,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree type2) return CP_AGGREGATE_TYPE_P (type1); case CPTK_IS_ARRAY: - return type_code1 == ARRAY_TYPE; + return (type_code1 == ARRAY_TYPE + /* ??? We don't want to report T[0] as being an array type. */ + && !(TYPE_SIZE (type1) && integer_zerop (TYPE_SIZE (type1; case CPTK_IS_ASSIGNABLE: return is_xible (MODIFY_EXPR, type1, type2); but are we *sure* that we don't want to treat int[0] as an array type? It's not clear to me that https://github.com/llvm/llvm-project/pull/86652 reached a consensus.
[Bug libstdc++/114530] New: accessing 'std::__cxx11::basic_string::::_M_allocated_capacity' member instead of initialized 'std::__cxx11::basic_string::::_M_lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114530
Bug ID: 114530
Summary: accessing 'std::__cxx11::basic_string_M_allocated_capacity' member instead of
initialized
'std::__cxx11::basic_string_M_local_buf' member in constant expression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
GCC rejects the following:
#include
#include
static_assert(
std::ranges::distance(
std::views::single(std::views::cartesian_product(std::string{}))
| std::views::join
) == 0
);
https://godbolt.org/z/4xcYxsMW4
The above seems to be a valid constant expression.
It is worth noting that replacing std::string{} with std::vector{}
compiles fine, see https://godbolt.org/z/bKdexfzcz
It's unclear whether this is a library bug or a language bug.
[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956
--- Comment #3 from Paul Thomas ---
(In reply to anlauf from comment #2)
> Reduced testcase:
>
> subroutine test_array_char(p, x)
> character(*), target :: x(100)
> character(:), pointer :: p(:)
> p => x
> end subroutine
>
>
> We hit an assert that can be worked around with the following patch:
>
> diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> index d21e3956d6e..fa31f950363 100644
> --- a/gcc/fortran/trans-expr.cc
> +++ b/gcc/fortran/trans-expr.cc
> @@ -10534,12 +10535,9 @@ gfc_trans_pointer_assignment (gfc_expr * expr1,
> gfc_expr * expr2)
> {
> gfc_symbol *psym = expr1->symtree->n.sym;
> tmp = NULL_TREE;
> - if (psym->ts.type == BT_CHARACTER)
> - {
> - gcc_assert (psym->ts.u.cl->backend_decl
> - && VAR_P (psym->ts.u.cl->backend_decl));
> - tmp = psym->ts.u.cl->backend_decl;
> - }
> + if (psym->ts.type == BT_CHARACTER
> + && psym->ts.u.cl->backend_decl)
> + tmp = psym->ts.u.cl->backend_decl;
> else if (expr1->ts.u.cl->backend_decl
> && VAR_P (expr1->ts.u.cl->backend_decl))
> tmp = expr1->ts.u.cl->backend_decl;
>
>
> This fragment was touched by Paul's fix for pr67740 (r14-4583), so adding
> him.
>
> @Paul: can you please have a look?
I can see why the assert is there but it is manifestly wrong for both the
assumed length target and a constant length. I was thrown a bit by the distros
nulling out the asserts so that it compiled just fine with the system gfortran.
Your patch is perfect :- This compiles and runs correctly:
module m
contains
subroutine test_array_char(p, x)
character(*), target :: x(:)
character(:), pointer :: p(:)
p => x
end subroutine
end module
use m
character(:), allocatable, target :: chr(:)
character(:), pointer :: p(:)
chr = ["ab","cd"]
call test_array_char (p, chr)
print '(l2,i4,2a4)', loc(chr) == loc(p), len(p), p
end
Cheers
Paul
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #37 from Jakub Jelinek --- Created attachment 57836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57836=edit gcc14-pr106472.patch So what about the following (so far untested) patch instead? For ../configure --enable-languages=default,ada,obj-c++,lto,go,d,rust,m2 --enable-checking=yes,rtl,extra --enable-libstdcxx-backtrace=yes there is just one extra newline in the autoconf produced toplevel Makefile compared to vanilla trunk, while for ../configure --enable-languages=c,c++,lto,go the difference is: --- ../obj38a/Makefile2024-03-28 12:47:49.147754430 +0100 +++ Makefile2024-03-29 15:54:06.389512332 +0100 @@ -29376,6 +29376,14 @@ configure-bison: stage_last configure-flex: stage_last configure-m4: stage_last +configure-target-fastjar: maybe-configure-target-zlib +all-target-fastjar: maybe-all-target-zlib +all-target-libgo: maybe-all-target-libbacktrace +all-target-libgo: maybe-all-target-libatomic +all-target-libgm2: maybe-all-target-libatomic +configure-target-libgfortran: maybe-all-target-libbacktrace +configure-target-libgo: maybe-all-target-libbacktrace + # Dependencies for target modules on other target modules are # described by lang_env_dependencies; the defaults apply to anything
[Bug fortran/112407] [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #8 from Paul Thomas --- Created attachment 57835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57835=edit An alternative fix for the PR Hi Tomas, Would you prefer the compiler to give warning rather than letting the possible recursion to pass by silently? f951: Warning: Non-RECURSIVE procedure ‘newcopyother’ from module ‘ftldynarrayintmodule’ is possibly calling itself recursively in procedure ‘newcopyother’. Declare it RECURSIVE or use ‘-frecursive’ Cheers Paul
[Bug testsuite/114518] [14 regression] gcc.target/powerpc/combine-2-2.c fails after r14-9692-g839bc42772ba7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2024-03-29 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- Ah good. Reproduced, confirmed, all that. Thanks.
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #21 from Segher Boessenkool --- (2.06, whoops)
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #20 from Segher Boessenkool --- (In reply to Michael Meissner from comment #19) > When I wrote the VSX support many years ago, I intended that -mvsx enable > all of ISA 2.06 But that is not how we do things, and it can never work predictably and reliably. If you want ISA 2.07 you have to use -mcpu=power8, or any other CPU that implements that ISA level. Using other options is counterintuitive, confusing, and causes problems directly even. > The reason is the kernel needs to > be built without floating point support. The kernel and many other things. That's what -msoft-float, -mno-altivec, and -mno-vsx are for. Those options mean use no FPRs, no VRs, or no VSRs. Nothing more, nothing less. > If you say -mvsx, it should include the standard power7 integer instructions > (-mpopcntd), power6 server instructions (i.e. -mhard-dfp, -mcmpb, -mrecip, > -mpowerpc-gfxopt, and -mpowerpc-gpopt), etc. No. -mvsx means the compiler can use VSX things, is not prevented from it by -mno-vsx. There can be other reasons it can not use VSX, like, the targeted CPU does not support VSX. The option says absolutely nothing about any other instructions. > VSX support assumes it can use lfiwax and lfiwzx. Any CPU that supports VSX is ISA 2.07 at least, yes.
[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.3
CC||anlauf at gcc dot gnu.org,
||pault at gcc dot gnu.org
Keywords||ice-on-valid-code
Last reconfirmed||2024-03-29
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|[14 Regression] ice in |[13/14 Regression] ice in
|gfc_trans_pointer_assignmen |gfc_trans_pointer_assignmen
|t, at |t, at
|fortran/trans-expr.cc:10524 |fortran/trans-expr.cc:10524
--- Comment #2 from anlauf at gcc dot gnu.org ---
Reduced testcase:
subroutine test_array_char(p, x)
character(*), target :: x(100)
character(:), pointer :: p(:)
p => x
end subroutine
We hit an assert that can be worked around with the following patch:
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index d21e3956d6e..fa31f950363 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -10534,12 +10535,9 @@ gfc_trans_pointer_assignment (gfc_expr * expr1,
gfc_expr * expr2)
{
gfc_symbol *psym = expr1->symtree->n.sym;
tmp = NULL_TREE;
- if (psym->ts.type == BT_CHARACTER)
- {
- gcc_assert (psym->ts.u.cl->backend_decl
- && VAR_P (psym->ts.u.cl->backend_decl));
- tmp = psym->ts.u.cl->backend_decl;
- }
+ if (psym->ts.type == BT_CHARACTER
+ && psym->ts.u.cl->backend_decl)
+ tmp = psym->ts.u.cl->backend_decl;
else if (expr1->ts.u.cl->backend_decl
&& VAR_P (expr1->ts.u.cl->backend_decl))
tmp = expr1->ts.u.cl->backend_decl;
This fragment was touched by Paul's fix for pr67740 (r14-4583), so adding
him.
@Paul: can you please have a look?
[Bug lto/110710] LTO linker on Windows creates an invalid Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||48427.html Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |peter0x44 at disroot dot org --- Comment #14 from Eric Gallager --- (In reply to Peter Damianov from comment #13) > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648427.html > > Patch submitted. Couldn't figure out how to assign myself in bugzilla. There's a privilege for it; I just assigned you.
[Bug fortran/113956] [14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 David Binderman changed: What|Removed |Added Summary|ice in |[14 Regression] ice in |gfc_trans_pointer_assignmen |gfc_trans_pointer_assignmen |t, at |t, at |fortran/trans-expr.cc:10524 |fortran/trans-expr.cc:10524 --- Comment #1 from David Binderman --- It looks like a regression from gcc-13.2: test $ ~/gcc/results.13.2.asan.ubsan/bin/gfortran -c -w ./Lower/pointer-assignments.f90 test $ ~/gcc/results.20240327.asan.ubsan/bin/gfortran -c -w ./Lower/pointer-assignments.f90 ./Lower/pointer-assignments.f90:54:8: 54 | p => x |1 internal compiler error: in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10539
[Bug modula2/114529] profiledbootstrap fails to build and m2 causes odr violations during build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114529 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-03-29 --- Comment #1 from Gaius Mulley --- Confirmed.
[Bug modula2/114529] New: profiledbootstrap fails to build and m2 causes odr violations during build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114529
Bug ID: 114529
Summary: profiledbootstrap fails to build and m2 causes odr
violations during build
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: gaius at gcc dot gnu.org
Target Milestone: ---
Many warnings are seen during compilation, starting with:
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240324-r1/work/gcc-14-20240324/gcc/m2/mc-boot/GDynamicStrings.cc:109:8:
error: type Werror=odr][]]
109 | struct DynamicStrings_Contents_r {
|^
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240324-r1/work/gcc-14-20240324/gcc/m2/mc-boot/Gdecl.cc:834:8:
note: a different type is defined in another translation unit
834 | struct DynamicStrings_Contents_r {
|^
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240324-r1/work/gcc-14-20240324/gcc/m2/mc-boot/GDynamicStrings.cc:110:55:
note: the first difference of corresponding definitions is field ‘buf’
110 |DynamicStrings__T3 buf;
| ^
/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240324-r1/work/gcc-14-20240324/gcc/m2/mc-boot/Gdecl.cc:835:55:
note: a field of same name but different type is defined in another translation
unit
835 |DynamicStrings__T7 buf;
| ^
Resulting in:
make[3]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-14.0.1_pre20240324-r1/work/build/gcc'
rm gfdl.pod gcc.pod gfortran.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod
gpl.pod cpp.pod gcov.pod lto-dump.pod gccgo.pod gdc.pod
make[2]: *** [Makefile:4878: all-stageprofile-gcc] Error 2 shuffle=1047648447
make[1]: *** [Makefile:31142: stageprofile-bubble] Error 2 shuffle=1047648447
make: *** [Makefile:31396: profiledbootstrap] Error 2 shuffle=1047648447
* ERROR: sys-devel/gcc-14.0.1_pre20240324-r1::gentoo failed (compile phase):
* emake failed
[Bug fortran/50410] [11/12/13/14 Regression] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #49 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6fb253a25dff13253d63553f02e0fe72c5e3ab4e commit r14-9720-g6fb253a25dff13253d63553f02e0fe72c5e3ab4e Author: Harald Anlauf Date: Thu Mar 28 22:34:40 2024 +0100 Fortran: fix NULL pointer dereference on overlapping initialization [PR50410] gcc/fortran/ChangeLog: PR fortran/50410 * trans-expr.cc (gfc_conv_structure): Check for NULL pointer. gcc/testsuite/ChangeLog: PR fortran/50410 * gfortran.dg/data_initialized_4.f90: New test.
[Bug c/114361] ICE with c23 when creating mutually nested and compatible types with statement expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361 Martin Uecker changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #4 from Martin Uecker --- Though similar symptoms, this is not a duplicate for 114014
[Bug c/114361] ICE with c23 when creating mutually nested and compatible types with statement expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361 --- Comment #3 from Martin Uecker --- Created attachment 57834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57834=edit patch Tentative patch.
[Bug fortran/112407] [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #7 from Paul Thomas --- Created attachment 57833 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57833=edit A patch that fixes all the issues in this PR I apologise for taking so long to return to this problem. Daytime work and a long trip to Australia have removed my gaze from the ball. At this stage of the release cycle, I have decided to go for the safe, "hacky" fix of your problem. In the course of the investigation, I found that recursion involving type bound procedures was not being detected and that class objects with NULL default initializers were being applied to intent(OUT) dummies. These are both fixed. I will submit to the list as soon as I have written the ChangeLogs. Regards Paul
[Bug fortran/110987] [13/14 Regression] Segmentation fault after finalization of a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987 --- Comment #9 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6 commit r14-9719-g3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6 Author: Paul Thomas Date: Fri Mar 29 07:23:19 2024 + Fortran: Fix a gimplifier ICE/wrong result with finalization [PR36337] 2024-03-29 Paul Thomas gcc/fortran PR fortran/36337 PR fortran/110987 PR fortran/113885 * trans-expr.cc (gfc_trans_assignment_1): Place finalization block before rhs post block for elemental rhs. * trans.cc (gfc_finalize_tree_expr): Check directly if a type has no components, rather than the zero components attribute. Treat elemental zero component expressions in the same way as scalars. gcc/testsuite/ PR fortran/113885 * gfortran.dg/finalize_54.f90: New test. * gfortran.dg/finalize_55.f90: New test. gcc/testsuite/ PR fortran/110987 * gfortran.dg/finalize_56.f90: New test.
[Bug fortran/113885] [13/14 Regression] ice in gimplify_expr, at gimplify.cc:18658 with finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885 --- Comment #3 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6 commit r14-9719-g3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6 Author: Paul Thomas Date: Fri Mar 29 07:23:19 2024 + Fortran: Fix a gimplifier ICE/wrong result with finalization [PR36337] 2024-03-29 Paul Thomas gcc/fortran PR fortran/36337 PR fortran/110987 PR fortran/113885 * trans-expr.cc (gfc_trans_assignment_1): Place finalization block before rhs post block for elemental rhs. * trans.cc (gfc_finalize_tree_expr): Check directly if a type has no components, rather than the zero components attribute. Treat elemental zero component expressions in the same way as scalars. gcc/testsuite/ PR fortran/113885 * gfortran.dg/finalize_54.f90: New test. * gfortran.dg/finalize_55.f90: New test. gcc/testsuite/ PR fortran/110987 * gfortran.dg/finalize_56.f90: New test.
[Bug testsuite/36337] testsuite requires HOSTCC and HOSTCFLAGS from contrib/test_installed script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36337 --- Comment #2 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6 commit r14-9719-g3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6 Author: Paul Thomas Date: Fri Mar 29 07:23:19 2024 + Fortran: Fix a gimplifier ICE/wrong result with finalization [PR36337] 2024-03-29 Paul Thomas gcc/fortran PR fortran/36337 PR fortran/110987 PR fortran/113885 * trans-expr.cc (gfc_trans_assignment_1): Place finalization block before rhs post block for elemental rhs. * trans.cc (gfc_finalize_tree_expr): Check directly if a type has no components, rather than the zero components attribute. Treat elemental zero component expressions in the same way as scalars. gcc/testsuite/ PR fortran/113885 * gfortran.dg/finalize_54.f90: New test. * gfortran.dg/finalize_55.f90: New test. gcc/testsuite/ PR fortran/110987 * gfortran.dg/finalize_56.f90: New test.
