[Bug tree-optimization/118950] [14 regression] RISC-V: rv64gcv runtime mismatch at -O3 since r14-4038-gb975c0dc3be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 --- Comment #12 from rguenther at suse dot de --- On Tue, 25 Feb 2025, rdapp at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950 > > --- Comment #11 from Robin Dapp --- > I figured this particular problem on RISC-V won't be fixed on GCC 14 because > we > don't have the zeroing of masked elements there. But you're referring to > backporting just this patch, right? Yes, but please wait a while to watch out for problems.
[Bug c++/118923] [15 regression] Wrong code generated for member function pointer call in range-for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118923 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a41b3f54c13890b1327bb3d4fbae8f7feb37d00b commit r15-7690-ga41b3f54c13890b1327bb3d4fbae8f7feb37d00b Author: Jakub Jelinek Date: Tue Feb 25 09:26:46 2025 +0100 c++: Fix range for with PMFs [PR118923] The following testcases segfault because the new range for -frange-for-ext-temps temporary extension extends even the internal TARGET_EXPRs created by get_member_function_from_ptrfunc. The following patch fixes that by using get_internal_target_expr for those instead of force_target_expr (similarly in cp_finish_decl and build_comparison_op) and using force_target_expr inside of get_internal_target_expr. 2025-02-25 Jakub Jelinek PR c++/118923 * tree.cc (get_internal_target_expr): Use force_target_expr instead of build_target_expr_with_type. * typeck.cc (get_member_function_from_ptrfunc): Use get_internal_target_expr instead of force_target_expr. * decl.cc (cp_finish_decl): Likewise. * method.cc (build_comparison_op): Likewise. * g++.dg/cpp0x/pr118923.C: New test. * g++.dg/cpp1y/pr118923.C: New test.
[Bug c++/118876] [15 Regression][OpenMP] ICE in add_stmt, at cp/semantics.cc:551 - register_dtor_fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118876 --- Comment #5 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:86a4af2793393e47af6b78cb7094c97914890091 commit r15-7691-g86a4af2793393e47af6b78cb7094c97914890091 Author: Jakub Jelinek Date: Tue Feb 25 09:29:39 2025 +0100 openmp: Fix handling of declare target statics with array type which need destruction [PR118876] The following testcase ICEs because it attempts to emit the __tcfa function twice, once when handling the host destruction and once when handling nohost destruction. This patch fixes it by using __omp_tcfa function for the nohost case and marks it with the needed "omp declare target" and "omp declare target nohost" attributes. 2025-02-25 Jakub Jelinek PR c++/118876 * cp-tree.h (register_dtor_fn): Add a bool argument defaulted to false. * decl.cc (start_cleanup_fn): Add OMP_TARGET argument, use "__omp_tcf" prefix rather than "__tcf" in that case. Add "omp declare target" and "omp declare target nohost" attributes to the fndecl. (register_dtor_fn): Add OMP_TARGET argument, pass it down to start_cleanup_fn. * decl2.cc (one_static_initialization_or_destruction): Add OMP_TARGET argument, pass it down to register_dtor_fn. (emit_partial_init_fini_fn): Pass omp_target to one_static_initialization_or_destruction. (handle_tls_init): Pass false to one_static_initialization_or_destruction. * g++.dg/gomp/pr118876.C: New test.
[Bug c++/118923] [15 regression] Wrong code generated for member function pointer call in range-for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118923 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c/119000] [OpenMP] Function parameter incorrectly reported as set but not used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119000 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cdffc76393488a73671b70481cf8a4b7c289029d commit r15-7692-gcdffc76393488a73671b70481cf8a4b7c289029d Author: Jakub Jelinek Date: Tue Feb 25 09:33:21 2025 +0100 openmp: Mark OpenMP atomic write expression as read [PR119000] The following testcase was emitting false positive warning that the rhs of #pragma omp atomic write was stored but not read, when the atomic actually does read it. The following patch fixes that by calling default_function_array_read_conversion on it, so that it is marked as read as well as converted from lvalue to rvalue. Furthermore, the code had if (code == NOP_EXPR) ... else ... if (code == NOP_EXPR) ... with none of ... parts changing code, so I've merged the two ifs. 2025-02-25 Jakub Jelinek PR c/119000 * c-parser.cc (c_parser_omp_atomic): For omp write call default_function_array_read_conversion on the rhs expression. Merge the two adjacent if (code == NOP_EXPR) blocks. * c-c++-common/gomp/pr119000.c: New test.
[Bug c++/118876] [15 Regression][OpenMP] ICE in add_stmt, at cp/semantics.cc:551 - register_dtor_fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118876 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/114921] Optimization flags cause _Float16 to __bf16 casting to do nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:98fe2ae8afa5dea19034d48876011a636dc23043 commit r13-9391-g98fe2ae8afa5dea19034d48876011a636dc23043 Author: Richard Biener Date: Thu May 2 13:55:15 2024 +0200 tree-optimization/114921 - _Float16 -> __bf16 isn't noop The vectorizer handles a _Float16 to __bf16 conversion through vectorizable_assignment, thinking it's a noop. The following fixes this by requiring the same vector component mode when checking for CONVERT_EXPR_CODE_P, being stricter than for VIEW_CONVERT_EXPR. PR tree-optimization/114921 * tree-vect-stmts.cc (vectorizable_assignment): Require same vector component modes for input and output for CONVERT_EXPR_CODE_P. (cherry picked from commit 87e35da16df74cd1c4729a55d94e7bc592487f48)
[Bug tree-optimization/117119] [12/13 Regression] ICE in int_cst_value, at tree.cc:11115 since r0-87460-g5b78fc3ed4960c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117119 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:55c8de5d87509234cfb9fed025a4d4d7c0277a92 commit r13-9393-g55c8de5d87509234cfb9fed025a4d4d7c0277a92 Author: Richard Biener Date: Mon Jan 13 09:12:23 2025 +0100 tree-optimization/117119 - ICE with int128 IV in dataref analysis Here's another fix for a missing check that an IV value fits in a HIW. It's originally from Stefan. PR tree-optimization/117119 * tree-data-ref.cc (initialize_matrix_A): Check whether an INTEGER_CST fits in HWI, otherwise return chrec_dont_know. * gcc.dg/torture/pr117119.c: New testcase. Co-Authored-By: Stefan Schulze Frielinghaus (cherry picked from commit d3904a3ad9d7b4c8e5e536e5166b89548510fd48)
[Bug tree-optimization/117912] [12/13 regression] Linux Kernel 6.13-rc1 Build Failure: 'Detected write beyond size of object' since r0-118806-g17742d62a2438144b6235
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117912 --- Comment #26 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:56f5e71a5b3de4a07a6f93bac670df5cd4a61734 commit r13-9397-g56f5e71a5b3de4a07a6f93bac670df5cd4a61734 Author: Richard Biener Date: Thu Dec 5 10:47:13 2024 +0100 tree-optimization/117912 - bogus address equivalences for __builtin_object_size VN again is the culprit for exploiting address equivalences before __builtin_object_size got the chance to do its job. This time it isn't about union members but adjacent structure fields where an address to one after the last element of an array field can spill over to the next field. The following protects all out-of-bound accesses on the upper bound side (singling out TYPE_MAX_VALUE + 1 is more expensive). It ignores other out-of-bound addresses that would invoke UB. Zero-sized arrays are a bit awkward because the C++ represents them with a -1U upper bound. There's a similar issue for zero-sized components whose address can be the same as the adjacent field in C. PR tree-optimization/117912 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): For addresses of zero-sized components do not set ->off if the object size pass didn't run. For OOB ARRAY_REF accesses in address expressions avoid setting ->off if the object size pass didn't run. (valueize_refs_1): Likewise. * c-c++-common/torture/pr117912-1.c: New testcase. * c-c++-common/torture/pr117912-2.c: Likewise. * c-c++-common/torture/pr117912-3.c: Likewise. (cherry picked from commit 233972ab3b5338d7a5d1d7af9108c1f366170e44)
[Bug middle-end/115641] [12/13 Regression] GCC crashes on function has const attribute since r10-3830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115641 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ac2bfec1d87d53df6bf7eec9f999781e7fa718b0 commit r13-9395-gac2bfec1d87d53df6bf7eec9f999781e7fa718b0 Author: Richard Biener Date: Thu Jul 18 13:35:33 2024 +0200 middle-end/115641 - invalid address construction fold_truth_andor_1 via make_bit_field_ref builds an address of a CALL_EXPR which isn't valid GENERIC and later causes an ICE. The following simply avoids the folding for f ().a != 1 || f ().b != 2 as it is a premature optimization anyway. The alternative would have been to build a TARGET_EXPR around the call. To get this far f () has to be const as otherwise the two calls are not semantically equivalent for the optimization. PR middle-end/115641 * fold-const.cc (decode_field_reference): If the inner reference isn't something we can take the address of, fail. * gcc.dg/torture/pr115641.c: New testcase. (cherry picked from commit 3670c70c561656a19f6bff36dd229f18120af127)
[Bug c/119000] [OpenMP] Function parameter incorrectly reported as set but not used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119000 --- Comment #3 from Jakub Jelinek --- Fixed for 15.1 so far.
[Bug tree-optimization/118717] [12/13 Regression] GCC 15 produces ICE with ruby-3.4.1 when lto is used: ractor.c:592:1: internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118717 --- Comment #15 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:08852469a263da1a05f020041c647e42c5cff09a commit r13-9394-g08852469a263da1a05f020041c647e42c5cff09a Author: Richard Biener Date: Mon Feb 3 09:55:50 2025 +0100 tree-optimization/118717 - store commoning vs. abnormals When we sink common stores in cselim or the sink pass we have to make sure to not introduce overlapping lifetimes for abnormals used in the ref. The easiest is to avoid sinking stmts which reference abnormals at all which is what the following does. PR tree-optimization/118717 * tree-ssa-phiopt.cc (cond_if_else_store_replacement_1): Do not common stores referencing abnormal SSA names. * tree-ssa-sink.cc (sink_common_stores_to_bb): Likewise. * gcc.dg/torture/pr118717.c: New testcase. (cherry picked from commit fbcbbfe2bf83eb8b1347144eeca37b06be5a8bb5)
[Bug tree-optimization/114921] Optimization flags cause _Float16 to __bf16 casting to do nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:9abe274a320c61e0e2cf653f3fb64ea2ae8e146c commit r13-9392-g9abe274a320c61e0e2cf653f3fb64ea2ae8e146c Author: Richard Biener Date: Mon May 6 12:03:09 2024 +0200 tree-optimization/114921 - _Float16 -> __bf16 isn't noop fixup The following further strengthens the check which convert expressions we allow to vectorize as simple copy by resorting to tree_nop_conversion_p on the vector components. PR tree-optimization/114921 * tree-vect-stmts.cc (vectorizable_assignment): Use tree_nop_conversion_p to identify converts we can vectorize with a simple assignment. (cherry picked from commit d0d6dcc019cd32eebf85d625f56e0f7573938319)
[Bug tree-optimization/114921] Optimization flags cause _Float16 to __bf16 casting to do nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.3.1 Target Milestone|--- |13.4 Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- Fixed.
[Bug fortran/108233] [Coarray] bcast to non-allocatable COMPLEX scalar coarray may generate wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108233 Andre Vehreschild changed: What|Removed |Added Last reconfirmed||2025-02-25 CC||vehre at gcc dot gnu.org Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/119010] New: [15 Regression] 444.namd shows a huge compile-time regression with -mtune=znver5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119010 Bug ID: 119010 Summary: [15 Regression] 444.namd shows a huge compile-time regression with -mtune=znver5 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- With -Ofast -march=znver5 444.namd compile time (the ComputeNonbondedUtil.C TU), sky-rockets from taking 8s with GCC 14 to more than 40s. A similar slowdown can be observed on other archs, for example icelake: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=904.120.8&plot.1=1086.120.8&plot.2=798.120.8&; the revision range of that points to early-break vectorization with alignment peeling being the likely cause. For the znver5 arch the main time is spent in scheduling 2: scheduling 2 : 34.26 ( 75%) the vectorization likely exposes more loops triggering latent compile-time issues on the RTL side. znver[432] do not exhibit the above issue, nor does icelake-server. -march=znver4 -mtune=znver5 is enough to trigger the scheduling issue.
[Bug target/119009] New: AArch64: Commit 'Node clones share order' causes regression in Snappy workload for -mcpu=neoverse-v2 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119009 Bug ID: 119009 Summary: AArch64: Commit 'Node clones share order' causes regression in Snappy workload for -mcpu=neoverse-v2 with LTO Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jschmitz at gcc dot gnu.org CC: mjires at gcc dot gnu.org Target Milestone: --- Target: aarch64 Created attachment 60581 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60581&action=edit Script to reproduce snappy regression The commit 'Node clones share order' (https://gcc.gnu.org/g:0895aef01c64c317b489811dbe4ac55f9c13aab3) causes a performance regression in the Snappy workload for AArch64 with -mcpu=neoverse-v2 and LTO: the test UIOVecSink/0 shows ~25% longer runtime. In the attachment is a script to reproduce the regression. It builds GCC from commits bad3714b and 0895aef0 and runs Snappy with O3 -Wl,-z,muldefs -lm -flto=auto -Wl,-sort-section=name -mcpu=neoverse-v2 Use the script like this: parentdir= ./instructions_to_reproduce.sh
[Bug tree-optimization/116850] [12/13 Regression] ICE at -O{s,2,3} on x86_64-linux-gnu: in verify_dominators, at dominance.cc:1194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116850 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:160e6aeb5c6bf17325c6b7b5dccf32d6eeaf9c32 commit r13-9396-g160e6aeb5c6bf17325c6b7b5dccf32d6eeaf9c32 Author: Richard Biener Date: Thu Sep 26 15:41:59 2024 +0200 tree-optimization/116850 - corrupt post-dom info Path isolation computes post-dominators on demand but can end up splitting blocks after that, wrecking it. We can delay splitting of blocks until we no longer need the post-dom info which is what the following patch does to solve the issue. PR tree-optimization/116850 * gimple-ssa-isolate-paths.cc (bb_split_points): New global. (insert_trap): Delay BB splitting if post-doms are computed. (find_explicit_erroneous_behavior): Process delayed BB splitting after releasing post dominators. (gimple_ssa_isolate_erroneous_paths): Do not free post-dom info here. * gcc.dg/pr116850.c: New testcase. (cherry picked from commit 64163657ba7e70347087a63bb2b32d83b52ea7d9)
[Bug target/119009] [15 regression] AArch64: Commit 'Node clones share order' (r15-6345-g0895aef01c64c3) causes regression in Snappy workload for -mcpu=neoverse-v2 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119009 Sam James changed: What|Removed |Added Target Milestone|--- |15.0 Keywords||missed-optimization Summary|AArch64: Commit 'Node |[15 regression] AArch64: |clones share order' causes |Commit 'Node clones share |regression in Snappy|order' |workload for|(r15-6345-g0895aef01c64c3) |-mcpu=neoverse-v2 with LTO |causes regression in Snappy ||workload for ||-mcpu=neoverse-v2 with LTO
[Bug middle-end/119010] [15 Regression] 444.namd shows a huge compile-time regression with -mtune=znver5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119010 Sam James changed: What|Removed |Added Blocks||26163 Target Milestone|--- |15.0 Keywords||compile-time-hog Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/118999] [15 regression] AArch64: Switching off early scheduling (r15-6661-gc5db3f50bdf34e) causes regressions in Snappy workload for -mcpu=neoverse-v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118999 Sam James changed: What|Removed |Added Summary|AArch64: Switching off |[15 regression] AArch64: |early scheduling causes |Switching off early |regressions in Snappy |scheduling |workload for|(r15-6661-gc5db3f50bdf34e) |-mcpu=neoverse-v2 |causes regressions in ||Snappy workload for ||-mcpu=neoverse-v2 Target Milestone|--- |15.0 CC||rsandifo at gcc dot gnu.org
[Bug rtl-optimization/119010] [15 Regression] 444.namd shows a huge compile-time regression with -mtune=znver5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119010 Richard Biener changed: What|Removed |Added Component|middle-end |rtl-optimization CC||hubicka at gcc dot gnu.org Target||x86_64-*-* --- Comment #1 from Richard Biener --- Honza, maybe you want to investigate what goes wrong with scheduling or what's so special about the znver5 automaton? Samples: 183K of event 'cycles:P', Event count (approx.): 189054710169 Overhead Samples Command Shared Object Symbol 33.60% 61318 cc1plus cc1plus[.] max_issue(ready_list*, int, void*, bool, int*) 11.00% 20108 cc1plus cc1plus[.] internal_min_issue_delay(int, DFA_chip*) 7.98% 14585 cc1plus cc1plus[.] state_transition(void*, rtx_def*) 6.42% 11765 cc1plus cc1plus[.] internal_state_transition(int, DFA_chip*) 6.05% 11036 cc1plus libc.so.6 [.] __memmove_avx_unaligned_erms
[Bug target/119009] [15 regression] AArch64: Commit 'Node clones share order' (r15-6345-g0895aef01c64c3) causes regression in Snappy workload for -mcpu=neoverse-v2 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119009 --- Comment #1 from Sam James --- (Thanks for giving the nice repro scripts. Often we don't get those for benchmarks (understandably with SPEC, but still).)
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 --- Comment #16 from Nadav Har'El --- Two newer duplicates of this issue not yet listed as duplicates: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117394 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112596
[Bug c++/112680] g++-13 segfault on std::regex_match with c++11 or above -O2 and lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680 Nadav Har'El changed: What|Removed |Added CC||nyh at math dot technion.ac.il --- Comment #3 from Nadav Har'El --- I think this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
[Bug fortran/107635] [Coarray] Allocatable components of types defined in module's interface are not handled correctly when used in coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107635 --- Comment #13 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:cc81363c33a3b5768daf2d8a62ae1a80db12ef96 commit r15-7693-gcc81363c33a3b5768daf2d8a62ae1a80db12ef96 Author: Andre Vehreschild Date: Wed Feb 19 09:04:47 2025 +0100 Fortran: Use correct size when transferring between images [PR107635] gcc/fortran/ChangeLog: PR fortran/107635 * trans-intrinsic.cc (conv_caf_sendget): Use the size of data transferred between the two images and not the descritor's size.
[Bug fortran/107635] [Coarray] Allocatable components of types defined in module's interface are not handled correctly when used in coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107635 --- Comment #14 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:af73228fdb2e61c6354f972987ba2a746c3519f7 commit r15-7694-gaf73228fdb2e61c6354f972987ba2a746c3519f7 Author: Andre Vehreschild Date: Fri Feb 21 14:06:28 2025 +0100 Fortran: Fix detection of descriptor arrays in coarray [PR107635] Look at the formal arguments generated type in the function declaration to figure if an argument is a descriptor arrays. Fix handling of class types while splitting coarray expressions. PR fortran/107635 gcc/fortran/ChangeLog: * coarray.cc (fixup_comp_refs): For class types set correct component (class) type. (split_expr_at_caf_ref): Provide location. * trans-intrinsic.cc (conv_caf_send_to_remote): Look at generated formal argument and not declared one to detect descriptor arrays. (conv_caf_sendget): Same.
[Bug target/118992] Redundant argument set up for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992 --- Comment #10 from H.J. Lu --- (In reply to Hongtao Liu from comment #9) > > > Remove check of 2 hooks regressed > > gcc: gcc.target/i386/pr111673.c check-function-bodies advance > unix/-m32: gcc: gcc.target/i386/pr49095.c scan-assembler-not \\(%eax\\), % > > > I've also benchmarked SPEC2017 with Ofast, no big difference from > performance data. It is because ia32 has very few registers.
[Bug c/119011] New: -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
Bug ID: 119011
Summary: -Wsign-compare: Split it into several levels
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alx at kernel dot org
Target Milestone: ---
It is usual to compare the return value of a function with -1 (the usual error
code).
Sometimes, functions returning that code do return an unsigned integer type,
such as size_t or time_t.
Programmers currently need to use a cast for the comparison to not trigger
-Wsign-compare:
alx@debian:~/tmp$ cat f.c
int
main(void)
{
unsigned long i = 3;
if (i == -1)
return 1;
return 0;
}
alx@debian:~/tmp$ gcc -Wsign-compare f.c
f.c: In function ‘main’:
f.c:6:15: warning: comparison of integer expressions of different signedness:
‘long unsigned int’ and ‘int’ [-Wsign-compare]
6 | if (i == -1)
| ^~
But a cast will silence diagnostics, so one usually wants to avoid the cast.
Indeed, I've seen code placing the cast in the wrong place of this comparison,
and then resulting in bogus code that cannot be diagnosed.
Then, one might consider adding a suffix to the integer literal, to match the
sign. However, that's also a bug if the width of the literal doesn't match the
width of the variable:
time_t t = -1;
if (t == -1u)
The code above is a bug in platforms where time_t and unsigned int are of
different width.
The only reasonable solution is having the compiler just not warn on comparison
of an unsigned against -1, as long as the -1 will be converted to an unsigned
type (and not the other way around).
So, I propose adding -Wsign-compare=1 and -Wsign-compare=2, with -Wsign-compare
defaulting to one of those (I prefer =1, but I don't care too much). =1
shouldn't warn about comparison to an unsuffixed literal, as long as the rank
of the literal is lower than the rank of the unsigned variable.
[Bug libstdc++/117394] evil regex causes a stack overflow and a crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117394 Nadav Har'El changed: What|Removed |Added CC||nyh at math dot technion.ac.il --- Comment #3 from Nadav Har'El --- I think this issue is more accurately a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164. That bug is very sad, it has been open for seven years now and has led to a mass exodus from std::regex to boost::regex which doesn't have this bug - because it's a serious bug with serious symptoms (crash) that applications have no way to avoid: Issue 61601 was a less serious issue because it was about a very complex regular expression, which users can simply avoid. But issue 86164 and the one reported here is much more serious: Here the regular expression is simple - but the user input is just longer, something which is hard for applications to avoid. Even worse - the failure mode isn't some sort of clean "error", it is an outright crash of the application.
[Bug bootstrap/119012] New: [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 Bug ID: 119012 Summary: [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs Product: gcc Version: 14.2.1 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rsworktech at outlook dot com Target Milestone: --- Host: riscv64-linux-gnu Target: riscv64-linux-gnu Build: riscv64-linux-gnu I am building gcc 14.2.1+r730+gc061ad5a36ba-1 with gcc 14.2.1+r134+gab884fffe3fc-2 A bootstrap comparison failure occurred for gcc/rust/rust-lex.o. Comparing stages 2 and 3 Bootstrap comparison failure! gcc/rust/rust-lex.o differs The configure options are here in this build script: https://paste.rs/578r4 And full build logs are available here: - https://github.com/user-attachments/files/18727269/gcc-14.2.1%2Br730%2Bgc061ad5a36ba-1-riscv64-prepare.log - https://github.com/user-attachments/files/18727277/gcc-14.2.1%2Br730%2Bgc061ad5a36ba-1-riscv64-build.log Two rust-lex.o from stage 2 and stage 3: https://github.com/user-attachments/files/18727282/rust-lex.zip When rust is disabled, the bootstrap could succeed. Output of diffoscope: https://repos.kxxt.dev/temp/diff.htm The most different section is .gnu.lto_.jmpfuncs.1. Other differences are mostly offsets and lto opts. The diff of disasm of this section is too big to read: Output from diff -u <(objdump --disassemble-all --section .gnu.lto_.jmpfuncs.1 rust-lex.2.o) <(objdump --disassemble-all --section .gnu.lto_.jmpfuncs.1 rust-lex.3.o) > diff.log https://github.com/user-attachments/files/18749578/diff.log
[Bug target/118835] [12/13/14 Regression] ICE in s390_valid_shift_count since r10-1731-ge2839e47894f0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118835 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Stefan Schulze Frielinghaus : https://gcc.gnu.org/g:ce4cb48c3396837cf1562882b3f23f768558945b commit r14-11342-gce4cb48c3396837cf1562882b3f23f768558945b Author: Stefan Schulze Frielinghaus Date: Thu Feb 13 09:13:06 2025 +0100 s390: Fix s390_valid_shift_count() for TI mode [PR118835] During combine we may end up with (set (reg:DI 66 [ _6 ]) (ashift:DI (reg:DI 72 [ x ]) (subreg:QI (and:TI (reg:TI 67 [ _1 ]) (const_wide_int 0x0aabf)) 15))) where the shift count operand does not trivially fit the scheme of address operands. Reject those operands, especially since strip_address_mutations() expects expressions of the form (and ... (const_int ...)) and fails for (and ... (const_wide_int ...)). Thus, be more strict here and accept only CONST_INT operands. Done by replacing immediate_operand() with const_int_operand() which is enough since the former only additionally checks for LEGITIMATE_PIC_OPERAND_P and targetm.legitimate_constant_p which are always true for CONST_INT operands. While on it, fix indentation of the if block. gcc/ChangeLog: PR target/118835 * config/s390/s390.cc (s390_valid_shift_count): Reject shift count operands which do not trivially fit the scheme of address operands. gcc/testsuite/ChangeLog: * gcc.target/s390/pr118835.c: New test. (cherry picked from commit ac9806dae30d07ab082ac341fe5646987753adcb)
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #1 from Alejandro Colomar --- Or maybe we can just make -Wsign-compare not warn on that, without adding levels at all.
[Bug fortran/107635] [Coarray] Allocatable components of types defined in module's interface are not handled correctly when used in coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107635 Andre Vehreschild changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Andre Vehreschild --- Should be fixed by last commits.
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug 83700 depends on bug 107635, which changed state. Bug 107635 Summary: [Coarray] Allocatable components of types defined in module's interface are not handled correctly when used in coarrays. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107635 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/119001] [15 Regression] ICE: in output_constructor_regular_field, at varasm.cc:5833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
union U {
int i;
char a[];
};
union U u[2] = {{.a = "12345"}};
is accepted but does the wrong thing (the u[0] content overlaps into the u[1]
one).
union U {
int i;
char a[];
};
union U u[2] = {{.a = "12345"},{.i = 3 }};
ICEs in a different spot.
Note,
struct U {
int i;
char a[];
};
struct U u[2] = {{.a = "123"}};
is rejected with
pr119001-2.c:5:24: error: initialization of flexible array member in a nested
context
5 | struct U u[2] = {{.a = "123"}};
|^
pr119001-2.c:5:24: note: (near initialization for ‘u[0]’)
so I think we should emit the same error for the union case as well.
[Bug tree-optimization/86270] [12/13/14 Regression] Simple loop needs an extra register and an extra instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86270 --- Comment #20 from Martin Jambor --- We no longer track Zen1 performence, but this hasbrought about a dramatic improvement of 465.tonto on our SomeKindOfLake machine: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=464.230.0 Thanks!
[Bug libstdc++/117394] evil regex causes a stack overflow and a crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117394 --- Comment #4 from Jonathan Wakely --- (In reply to Nadav Har'El from comment #3) > I think this issue is more accurately a duplicate of > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164. Which is the same problem as Bug 61601. > That bug is very sad, it has been open for seven years now and has led to a > mass exodus from std::regex to boost::regex which doesn't have this bug - > because it's a serious bug with serious symptoms (crash) that applications > have no way to avoid: There are other reasons to prefer boost::regex, so maybe it's good that people are using a better implementation. Our std::regex is unlikely to ever be fast or efficient, due to ABI compatibility reasons. Even if/when Bug 61601 is fixed, it will still be slow. > Issue 61601 was a less serious issue because it was about a very complex > regular expression, which users can simply avoid. But issue 86164 and the > one reported here is much more serious: Here the regular expression is > simple - but the user input is just longer, something which is hard for > applications to avoid. Even worse - the failure mode isn't some sort of > clean "error", it is an outright crash of the application. It's still the same underlying bug though.
[Bug c/119001] [15 Regression] ICE: in output_constructor_regular_field, at varasm.cc:5833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001
--- Comment #4 from Jakub Jelinek ---
So IMHO at least we want something like:
--- gcc/c/c-typeck.cc.jj2025-02-13 14:10:52.934623189 +0100
+++ gcc/c/c-typeck.cc 2025-02-25 10:47:02.220272763 +0100
@@ -12124,6 +12124,42 @@ retry:
warning (OPT_Wtraditional, "traditional C rejects initialization "
"of unions");
+ /* Error for non-static initialization of a flexible array member.
*/
+ if (fieldcode == ARRAY_TYPE
+ && !require_constant_value
+ && TYPE_SIZE (fieldtype) == NULL_TREE)
+ {
+ error_init (loc, "non-static initialization of a flexible "
+ "array member");
+ break;
+ }
+
+ /* Error for initialization of a flexible array member with
+a string constant if the structure is in an array. E.g.:
+union U { int x; char y[]; };
+union U s[] = { { 1, "foo" } };
+is invalid. */
+ if (string_flag
+ && fieldcode == ARRAY_TYPE
+ && constructor_depth > 1
+ && TYPE_SIZE (fieldtype) == NULL_TREE)
+ {
+ bool in_array_p = false;
+ for (struct constructor_stack *p = constructor_stack;
+ p && p->type; p = p->next)
+ if (TREE_CODE (p->type) == ARRAY_TYPE)
+ {
+ in_array_p = true;
+ break;
+ }
+ if (in_array_p)
+ {
+ error_init (loc, "initialization of flexible array "
+ "member in a nested context");
+ break;
+ }
+ }
+
/* Accept a string constant to initialize a subarray. */
if (value.value != NULL_TREE
&& fieldcode == ARRAY_TYPE
--- gcc/varasm.cc.jj2025-01-03 17:59:48.816160159 +0100
+++ gcc/varasm.cc 2025-02-25 10:52:08.043968775 +0100
@@ -5827,10 +5827,13 @@ output_constructor_regular_field (oc_loc
and the FE splits them into dynamic initialization. */
gcc_checking_assert (fieldsize >= fldsize);
/* Given a non-empty initialization, this field had better
-be last. Given a flexible array member, the next field
-on the chain is a TYPE_DECL of the enclosing struct. */
+be last except in unions. Given a flexible array member, the next
+field on the chain is a TYPE_DECL of the enclosing struct. */
const_tree next = DECL_CHAIN (local->field);
- gcc_assert (!fieldsize || !next || TREE_CODE (next) != FIELD_DECL);
+ gcc_assert (!fieldsize
+ || !next
+ || TREE_CODE (next) != FIELD_DECL
+ || TREE_CODE (local->type) == UNION_TYPE);
}
else
fieldsize = tree_to_uhwi (DECL_SIZE_UNIT (local->field));
--- gcc/testsuite/gcc.dg/pr119001-1.c.jj2025-02-25 11:06:07.717169471
+0100
+++ gcc/testsuite/gcc.dg/pr119001-1.c 2025-02-25 11:21:04.947577152 +0100
@@ -0,0 +1,35 @@
+/* PR c/119001 */
+/* { dg-do run } */
+/* { dg-options "" } */
+
+union U { char a[]; int i; };
+union U u = { "12345" };
+union U v = { .a = "6789" };
+union U w = { { 1, 2, 3, 4, 5, 6 } };
+union U x = { .a = { 7, 8, 9 } };
+union V { int i; char a[]; };
+union U y = { .a = "abcdefghijk" };
+union U z = { .a = { 10, 11, 12, 13, 14, 15, 16, 17 } };
+
+int
+main ()
+{
+ for (int i = 0; i < 6; ++i)
+if (u.a[i] != "12345"[i])
+ __builtin_abort ();
+ for (int i = 0; i < 5; ++i)
+if (v.a[i] != "6789"[i])
+ __builtin_abort ();
+ for (int i = 0; i < 6; ++i)
+if (w.a[i] != i + 1)
+ __builtin_abort ();
+ for (int i = 0; i < 3; ++i)
+if (x.a[i] != i + 7)
+ __builtin_abort ();
+ for (int i = 0; i < 12; ++i)
+if (y.a[i] != "abcdefghijk"[i])
+ __builtin_abort ();
+ for (int i = 0; i < 8; ++i)
+if (z.a[i] != i + 10)
+ __builtin_abort ();
+}
--- gcc/testsuite/gcc.dg/pr119001-2.c.jj2025-02-25 11:06:28.124882967
+0100
+++ gcc/testsuite/gcc.dg/pr119001-2.c 2025-02-25 11:17:56.341223024 +0100
@@ -0,0 +1,12 @@
+/* PR c/119001 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+union U { char a[]; int i; };
+union U u[1] = { { "12345" } };/* { dg-error
"initialization of flexible array member in a nested context" } */
+union U v[1] = { { .a = "6789" } };/* { dg-error "initialization
of flexible array member in a nested context" } */
+union U w[1] = { { { 1, 2, 3, 4, 5, 6 } } }; /* { dg-error "initialization
of flexible array member in a nested context" } */
+union U x[1] = { { .a = { 7, 8, 9 } } }; /* { dg-error "initialization
of flexible array member in a nested context" } */
+union V { int i; char a[]; };
+union V y[1] = { { .a = "6789" } };/* { dg-error "initialization
of flexib
[Bug c/119001] [15 Regression] ICE: in output_constructor_regular_field, at varasm.cc:5833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001 --- Comment #5 from Jakub Jelinek --- Created attachment 60582 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60582&action=edit gcc15-pr119001.patch Full untested patch.
[Bug tree-optimization/119016] [15 regression] svn miscompiled with -O2 -mavx -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Keywords||wrong-code --- Comment #2 from Andrew Pinski --- Feels like early exit vectorizer ...
[Bug tree-optimization/119016] [15 regression] svn miscompiled with -O2 -mavx -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016 Sam James changed: What|Removed |Added Attachment #60588|0 |1 is obsolete|| --- Comment #3 from Sam James --- Created attachment 60589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60589&action=edit eol.c
[Bug middle-end/117342] .base64 emitted when gas doesn't support it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342 --- Comment #18 from Khem Raj --- (In reply to Andrew Pinski from comment #16) > (In reply to Khem Raj from comment #15) > > My problem was that I made the version to be 15.1.0 > > How? in yocto, we copy the tools/symlinks into locations manually to match gcc's expected paths, they do have version info the path string. if it does not match then it falls back to next search path for tools. see https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/gcc/gcc-cross.inc#n97
[Bug tree-optimization/119016] [15 regression] svn miscompiled with -O2 -mavx -fno-vect-cost-model since r15-6807-g68326d5d1a593d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016 Sam James changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org Summary|[15 regression] svn |[15 regression] svn |miscompiled with -O2 -mavx |miscompiled with -O2 -mavx |-fno-vect-cost-model|-fno-vect-cost-model since ||r15-6807-g68326d5d1a593d --- Comment #4 from Sam James --- r15-6807-g68326d5d1a593d
[Bug c++/119017] error on valid user defined literal friend in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119017 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-02-25 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. Looks like always been an issue.
[Bug c++/119017] error on valid user defined literal friend in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119017 Andrew Pinski changed: What|Removed |Added Attachment #60591|0 |1 is obsolete|| --- Comment #3 from Andrew Pinski --- Created attachment 60592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60592&action=edit Reduced testcase
[Bug c++/119017] error on valid user defined literal friend in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119017 --- Comment #1 from Andrew Pinski --- Created attachment 60591 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60591&action=edit C++11 testcase
[Bug fortran/108680] Wrong DTIO arguments with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680 --- Comment #11 from kargls at comcast dot net --- On 2/25/25 12:43, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680 > > --- Comment #10 from anlauf at gcc dot gnu.org --- > (In reply to Jerry DeLisle from comment #9) >> We can have only one default integer otherwise its not a default. Our >> default integer is KIND=4 > > Forgive me for being stupid, but leaving aside the -fdefault-integer-*, > where in the standard does it require *default integer* for the unit number? > Could it be integer(2)? If not, why not? > > I simply cannot find the text. > If we're discussing derived-type IO, then it is clear from Fortran 2023, 12.6.4.8.2, (see p. 255) that the unit number has the default integer kind with the DT edit descriptor.
[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069 --- Comment #6 from Hongtao Liu --- It looks like the testcase is fragile, it's supposed to check the compiler ability of generating code_6_gottpoff_reloc instruction, but failed since there's a seg_prefixed memory usage(r14-6242-gd564198f960a2f). mov r13, QWORD PTR j@gottpoff[rip] mov r12, QWORD PTR a@gottpoff[rip] mov rbp, QWORD PTR [rsp+1040] lea rbx, [rsp+1040] add r14, QWORD PTR fs:0, r12
[Bug c/119014] Extending _Float16 constant at compile and run time differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #8 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #6) > I don't think that is true. Indeed, it seems that I did some mistake when searching the standard, which is a bit contradictory about the case FLT_EVAL_METHOD = 0. In 5.2.5.3.2, this case expresses the fact that there is no extended precision for any floating type (so, the safest behavior), but this is no longer true with Annex H! Note that extended precision brings confusion for users, with more risks of issues than benefits: see bug 323 and its 103 duplicates! IMHO, it should really be avoided by default.
[Bug fortran/108680] Wrong DTIO arguments with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680 --- Comment #12 from Jerry DeLisle --- "The keyword INTEGER with no kind-selector specifies type integer with default kind; the kind type parameter value is equal to KIND (0). The decimal exponent range of default integer shall be at least 5." -- 7.4.3.1 Integer type Just playing last night: program ranger implicit none integer(2) :: two integer(4) :: four integer(8) :: eight real(4) :: tworeal,foureal four = huge(four) eight = huge(eight) tworeal = real(huge(two)) ! log10 does no accept integer arguments foureal = real(huge(four)) print *, range(two), huge(two), log10(tworeal), int(log10(tworeal)) print *, range(four), huge(four), log10(foureal), int(log10(foureal)) end program ranger integer(2) range is 4, less than 5, so does not meet requirement for default INTEGER.
[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #19 from Jerry DeLisle --- Created attachment 60593 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60593&action=edit Possible patch to change compile behavior This patch changes the fortran/lang-spec.h as a possible better approach. $ gfc pr108369.f pr108369.f:10:17: 10 | CALL SN512(C1N001(5)(2:9),CVCOMP) | 1 Warning: Actual argument contains too few elements for dummy argument ‘c1d001’ (19/48) at (1) and $ gfc -x f77 pr108369.f pr108369.f:10:17: 10 | CALL SN512(C1N001(5)(2:9),CVCOMP) | 1 Warning: Actual argument contains too few elements for dummy argument ‘c1d001’ (19/48) at (1) What this is doing is invoking -std=legacy for files with suffixes that imply legacy files such as .f This is my first dive on the lang-spec file so there may be something a little different we do.
[Bug ipa/119009] [15 regression] AArch64: Commit 'Node clones share order' (r15-6345-g0895aef01c64c3) causes regression in Snappy workload for -mcpu=neoverse-v2 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119009 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-02-25 Component|target |ipa Keywords||needs-reduction, ||needs-source Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- Can you narrow down slightly where the regression is? Since the commit is only supposed to change the order of clones it is hard to tell if the issue is just an accident (icache differences) or something more obvious wrong.
[Bug target/118753] [15 Regression] [meta-bug] GCC 15 Regression on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118753 Bug 118753 depends on bug 117069, which changed state. Bug 117069 Summary: [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/118992] Redundant argument set up for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992 --- Comment #12 from Hongtao Liu --- (In reply to H.J. Lu from comment #11) > Created attachment 60590 [details] > A patch > > Can you try this on SPEC CPU? Sure.
[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069 --- Comment #4 from Andrew Pinski --- (In reply to Hongtao Liu from comment #3) > Fixed. Do we know what fixed it? As this requires a new binutils i have not tested it yet.
[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069 Hongtao Liu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Hongtao Liu --- Fixed.
[Bug middle-end/117342] .base64 emitted when gas doesn't support it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #15 from Khem Raj --- I ran into this problem as well while cross building gcc-trunk for yocto. My problem was that I made the version to be 15.1.0 instead of 15.0.1 which is what it should have been as of now. Since the version string was wrong, it did not pick the assembler from my cross-toolchain but resorted to fallback path from /usr/bin and it was an older assembler on my debian-11 host resulting in this error. It happened only when target was x86_64 since it could resort to use the assembler from host install, cross compiling for dissimilar target architecture ( e.g. riscv64) it failed to find the assembler and thats how I narrowed down to my issue.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #54 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2256e30874af2ef804bb19d2eba40f9c92953beb commit r15-7706-g2256e30874af2ef804bb19d2eba40f9c92953beb Author: Jonathan Wakely Date: Tue Feb 25 18:06:46 2025 + libstdc++: Fix typo in std::fill SFINAE constraint [PR93059] The r15-4321-gd8ef4471cb9c9f change incorrectly used __value as the member of the __memcpyable_integer trait, but it should have been __width. That meant this overload was not being used for _Tp != _Up. Also return after doing the loop for the consteval case. The missing return wasn't causing incorrect behaviour because the consteval loop increments the iterator until it equals the end of the range, so the memset isn't done. But it's still better to return and not even try to do the memset. libstdc++-v3/ChangeLog: PR libstdc++/93059 * include/bits/stl_algobase.h (__fill_a1): Fix typo in SFINAE constraint.
[Bug testsuite/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs since r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 --- Comment #11 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:892ee5ffba0760794a932e36771863a86ef2b271 commit r15-7705-g892ee5ffba0760794a932e36771863a86ef2b271 Author: Andrew Pinski Date: Thu Feb 20 13:03:51 2025 -0800 i386: Fix pr101950-2.c [PR115028] So what is happening here is that after r15-268-g9dbff9c05520a7, a move instruction still exists after combine and the register allocator choses different register allocation order for the xor and because the input operand of lzcntq is not the same as output operand, there is an extra xor that happens (due to an errata). This fixes the testcase by using loading from a pointer instead of a function argument directly. The register allocator has more freedom since the load has no hard register associated with it (rdi) so it can be in eax register right away. Tested for both -m32 and -m64 on x86_64-linux-gnu. gcc/testsuite/ChangeLog: PR testsuite/115028 * gcc.target/i386/pr101950-2.c: Use a pointer argument instead of the argument directly. Signed-off-by: Andrew Pinski
[Bug testsuite/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs since r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Andrew Pinski --- Fixed.
[Bug target/118753] [15 Regression] [meta-bug] GCC 15 Regression on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118753 Bug 118753 depends on bug 117069, which changed state. Bug 117069 Summary: [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c since r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069 Hongtao Liu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Hongtao Liu --- (In reply to Andrew Pinski from comment #4) > (In reply to Hongtao Liu from comment #3) > > Fixed. > > Do we know what fixed it? As this requires a new binutils i have not tested > it yet. I thought it was fixed with latest binutils, but it's not.(NOTE, we already have dg-require-effective-target code_6_gottpoff_reloc in the testcase, so it should not fail both w/ and w/o latest binutils). I'm sorry for the oversight.
[Bug libstdc++/119018] New: Some iota_view constructors are missing explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119018
Bug ID: 119018
Summary: Some iota_view constructors are missing explicit
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: luigighiron at gmail dot com
Target Milestone: ---
libstdc++ does not correctly mark some of iota_view's constructors as explicit,
for example:
#include
std::ranges::iota_viewfoo(){
return{0,5};
}
This compiles fine using libstdc++, but is rejected when using libc++ or MSVC
STL. Here are the definitions of the iota_view constructors in libstdc++:
> iota_view() requires default_initializable<_Winc> = default;
>
> ...
>
> constexpr explicit
> iota_view(_Winc __value)
>
> ...
>
> constexpr
> iota_view(type_identity_t<_Winc> __value,
> type_identity_t<_Bound> __bound)
>
> ...
>
> constexpr
> iota_view(_Iterator __first, _Iterator __last)
> requires same_as<_Winc, _Bound>
>
> ...
>
> constexpr
> iota_view(_Iterator __first, unreachable_sentinel_t __last)
> requires same_as<_Bound, unreachable_sentinel_t>
>
> ...
>
> constexpr
> iota_view(_Iterator __first, _Sentinel __last)
> requires (!same_as<_Winc, _Bound>) && (!same_as<_Bound,
> unreachable_sentinel_t>)
>
> ...
Interestingly, the single argument constructor is marked explicit. All
constructors here except the first two should have explicit added.
[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #20 from kargls at comcast dot net --- (In reply to Jerry DeLisle from comment #19) > > What this is doing is invoking -std=legacy for files with suffixes that > imply legacy files such as .f > > This is my first dive on the lang-spec file so there may be something a > little different we do. The .f suffix denotes fixed-form source code, which is independent of what -std=legacy originally meant. The -std=legacy allows a bunch of nonstandard Fortran or deleted features. IMO, it should not be used as a hammer. Here's an example where -std=legacy may be unintentionally accepting code that a programmer may otherwise want flagged for an error. PROGRAM FOO REAL DX, X DX = 1.e0 C The next line was allowed in Fortran 66 and 77(?). DO X = 0., 10., DX PRINT *, X END DO END
[Bug libstdc++/119018] Some iota_view constructors are missing explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119018 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- So a dup. *** This bug has been marked as a duplicate of bug 114298 ***
[Bug libstdc++/119018] Some iota_view constructors are missing explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119018 --- Comment #1 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2711r1.html
[Bug libstdc++/114298] std::lazy_split_view constructor is currently not explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114298 Andrew Pinski changed: What|Removed |Added CC||luigighiron at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 119018 has been marked as a duplicate of this bug. ***
[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #21 from Jerry DeLisle --- (In reply to kargls from comment #20) > (In reply to Jerry DeLisle from comment #19) > > > > What this is doing is invoking -std=legacy for files with suffixes that > > imply legacy files such as .f > > > > This is my first dive on the lang-spec file so there may be something a > > little different we do. > > The .f suffix denotes fixed-form source code, which is independent > of what -std=legacy originally meant. The -std=legacy allows a bunch > of nonstandard Fortran or deleted features. IMO, it should not be > used as a hammer. > It breaks some test cases as well. At this point I am undecided bewteen changing this or adding to the documentation that -std=legacy may be needed when using -x f77 and leave everything alone.
[Bug middle-end/118994] GCC fails to optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to PAVGB/PAVGW (or equivalent instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994 --- Comment #7 from Hongtao Liu --- diff --git a/gcc/match.pd b/gcc/match.pd index 5c679848bdf..d6a465c963c 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -11348,3 +11348,28 @@ and, } (if (full_perm_p) (vec_perm (op@3 @0 @1) @3 @2)) + +#if GIMPLE +/* Simplify (a >> 1) + (b >> 1) + ((a | b) & 1) to .AVG_CEIL (a, b). + Similar for (a | b) - ((a ^ b) >> 1). */ + +(simplify + (plus:c +(plus (rshift @0 integer_onep@1) (rshift @2 @1)) +(bit_and (bit_ior @0 @2) integer_onep@3)) + (if (cfun && (cfun->curr_properties & PROP_last_full_fold) != 0 + && VECTOR_TYPE_P (type) + && direct_internal_fn_supported_p (IFN_AVG_CEIL, + type, OPTIMIZE_FOR_BOTH)) + (IFN_AVG_CEIL @0 @2))) + +(simplify + (minus +(bit_ior @0 @2) +(rshift (bit_xor @0 @2) integer_onep@1)) + (if (cfun && (cfun->curr_properties & PROP_last_full_fold) != 0 + && VECTOR_TYPE_P (type) + && direct_internal_fn_supported_p (IFN_AVG_CEIL, + type, OPTIMIZE_FOR_BOTH)) + (IFN_AVG_CEIL @0 @2))) +#endif I'm testing the above.
[Bug tree-optimization/118464] [15 Regression] gcc-15.0.0_pre20250112 ICE with opencv-4.10.0 using -O2/-ftree-loop-vectorize: memory_descriptor_ref.cpp:94:19: internal compiler error: in exact_div, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118464 --- Comment #15 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:ebe7cd9f2833a79877fbc56829c4f37a518a9b1d commit r15-7711-gebe7cd9f2833a79877fbc56829c4f37a518a9b1d Author: Tamar Christina Date: Wed Feb 26 07:31:28 2025 + testsuite: Add pragma novector to more tests [PR118464] These loops will now vectorize the entry finding loops. As such we get more failures because they were not expecting to be vectorized. Fixed by adding #pragma GCC novector. gcc/testsuite/ChangeLog: PR tree-optimization/118464 PR tree-optimization/116855 * g++.dg/ext/pragma-unroll-lambda-lto.C: Add pragma novector. * gcc.dg/tree-ssa/gen-vect-2.c: Likewise. * gcc.dg/tree-ssa/gen-vect-25.c: Likewise. * gcc.dg/tree-ssa/gen-vect-32.c: Likewise. * gcc.dg/tree-ssa/ivopt_mult_2g.c: Likewise. * gcc.dg/tree-ssa/ivopts-5.c: Likewise. * gcc.dg/tree-ssa/ivopts-6.c: Likewise. * gcc.dg/tree-ssa/ivopts-7.c: Likewise. * gcc.dg/tree-ssa/ivopts-8.c: Likewise. * gcc.dg/tree-ssa/ivopts-9.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-1.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-10.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-11.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-12.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-2.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-3.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-4.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-5.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-6.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-7.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-8.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-9.c: Likewise. * gcc.target/i386/pr90178.c: Likewise.
[Bug tree-optimization/116855] [14/15 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855 --- Comment #9 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:ebe7cd9f2833a79877fbc56829c4f37a518a9b1d commit r15-7711-gebe7cd9f2833a79877fbc56829c4f37a518a9b1d Author: Tamar Christina Date: Wed Feb 26 07:31:28 2025 + testsuite: Add pragma novector to more tests [PR118464] These loops will now vectorize the entry finding loops. As such we get more failures because they were not expecting to be vectorized. Fixed by adding #pragma GCC novector. gcc/testsuite/ChangeLog: PR tree-optimization/118464 PR tree-optimization/116855 * g++.dg/ext/pragma-unroll-lambda-lto.C: Add pragma novector. * gcc.dg/tree-ssa/gen-vect-2.c: Likewise. * gcc.dg/tree-ssa/gen-vect-25.c: Likewise. * gcc.dg/tree-ssa/gen-vect-32.c: Likewise. * gcc.dg/tree-ssa/ivopt_mult_2g.c: Likewise. * gcc.dg/tree-ssa/ivopts-5.c: Likewise. * gcc.dg/tree-ssa/ivopts-6.c: Likewise. * gcc.dg/tree-ssa/ivopts-7.c: Likewise. * gcc.dg/tree-ssa/ivopts-8.c: Likewise. * gcc.dg/tree-ssa/ivopts-9.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-1.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-10.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-11.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-12.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-2.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-3.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-4.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-5.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-6.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-7.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-8.c: Likewise. * gcc.dg/tree-ssa/predcom-dse-9.c: Likewise. * gcc.target/i386/pr90178.c: Likewise.
[Bug tree-optimization/119016] [15 regression] svn miscompiled with -O2 -mavx -fno-vect-cost-model since r15-6807-g68326d5d1a593d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016
Tamar Christina changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed||2025-02-26
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #5 from Tamar Christina ---
Confirmed.
Slightly easier to digest case:
---
#include
#include
__attribute__((noipa)) char *svn_eol__find_eol_start(char *buf, size_t len) {
for (; len > sizeof(uintptr_t);
buf += sizeof(uintptr_t), len -= sizeof(uintptr_t)) {
uintptr_t chunk = *(const uintptr_t *)buf;
uintptr_t r_test = chunk ^ 0x0a0a0a0a0a0a0a0a;
uintptr_t n_test = chunk ^ 0x0d0d0d0d0d0d0d0d;
r_test |= (r_test & 0x7f7f7f7f7f7f7f7f) + 0x7f7f7f7f7f7f7f7f;
n_test |= (n_test & 0x7f7f7f7f7f7f7f7f) + 0x7f7f7f7f7f7f7f7f;
if ((r_test & n_test & 0x8080808080808080) != 0x8080808080808080)
break;
}
#pragma GCC novector
for (; len > 0; ++buf, --len) {
if (*buf == '\n' || *buf == '\r')
return buf;
}
return ((void *)0);
}
int main() {
char p[] = {
0x2f, 0x2a, 0xa, 0x20, 0x20, 0x20, 0x62, 0x75, 0x67, 0x33, 0x33, 0x37,
0x39, 0x37, 0x32, 0x33, 0x2e, 0x63, 0xa, 0x2a, 0x2f, 0xa, 0xa, 0x23,
0x69, 0x6e, 0x63,
};
size_t len;
char *end = p + (sizeof(p) / sizeof(p[0]));
int i = 0;
do {
char *start = p + len;
const char *eol = svn_eol__find_eol_start(start, end - start);
len += (eol ? eol : end) - start;
i++;
} while (((end - p) > len + 2) && i < 100);
}#include
#include
__attribute__((noipa)) char *svn_eol__find_eol_start(char *buf, size_t len) {
for (; len > sizeof(uintptr_t);
buf += sizeof(uintptr_t), len -= sizeof(uintptr_t)) {
uintptr_t chunk = *(const uintptr_t *)buf;
uintptr_t r_test = chunk ^ 0x0a0a0a0a0a0a0a0a;
uintptr_t n_test = chunk ^ 0x0d0d0d0d0d0d0d0d;
r_test |= (r_test & 0x7f7f7f7f7f7f7f7f) + 0x7f7f7f7f7f7f7f7f;
n_test |= (n_test & 0x7f7f7f7f7f7f7f7f) + 0x7f7f7f7f7f7f7f7f;
if ((r_test & n_test & 0x8080808080808080) != 0x8080808080808080)
break;
}
#pragma GCC novector
for (; len > 0; ++buf, --len) {
if (*buf == '\n' || *buf == '\r')
return buf;
}
return ((void *)0);
}
int main() {
char p[] = {
0x2f, 0x2a, 0xa, 0x20, 0x20, 0x20, 0x62, 0x75, 0x67, 0x33, 0x33, 0x37,
0x39, 0x37, 0x32, 0x33, 0x2e, 0x63, 0xa, 0x2a, 0x2f, 0xa, 0xa, 0x23,
0x69, 0x6e, 0x63,
};
size_t len;
char *end = p + (sizeof(p) / sizeof(p[0]));
int i = 0;
do {
char *start = p + len;
const char *eol = svn_eol__find_eol_start(start, end - start);
len += (eol ? eol : end) - start;
i++;
} while (((end - p) > len + 2) && i < 100);
}
---
The code is peeled but the address ends up being not aligned:
Program received signal SIGSEGV, Segmentation fault.
0x0040135f in svn_eol__find_eol_start (buf=,
buf@entry=0x7fffe2f2 "\n bug3379723.c\n*/\n\n#inc\027", len=, len@entry=25) at oel.c:8
8 uintptr_t chunk = *(const uintptr_t *)buf;
(gdb) display/i $pc
1: x/i $pc
=> 0x40135f : movdqa (%rdi,%rsi,1),%xmm10
(gdb) p/x $rdi+$rsi
$1 = 0x7fffe2f2
which is not 16-bytes aligned, hence the alignment fault.
[Bug c++/119020] New: Problem of constexpr static lambda and maybe GCC accepts invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119020
Bug ID: 119020
Summary: Problem of constexpr static lambda and maybe GCC
accepts invalid
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: qurong at ios dot ac.cn
Target Milestone: ---
For this program:
```
struct TestClass {
void testFinction() {}
static TestClass* ptr_;
constexpr static auto funcPtr = +[](){ ptr_->testFinction(); };
};
TestClass* TestClass::ptr_ = new TestClass();
int main() {
return 0;
}
```
This causes an error in clang, but GCC didn't report the error.
Compiler Explorer link: https://godbolt.org/z/x9bYrGqTn
[Bug c/119019] New: -Wshadow false negative for function parameter (used as array length expression) shadowing a global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119019 Bug ID: 119019 Summary: -Wshadow false negative for function parameter (used as array length expression) shadowing a global variable Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: alx at kernel dot org Target Milestone: --- alx@debian:~/tmp$ cat f.c extern int n; void f(int a[n], int n); alx@debian:~/tmp$ gcc -Wall -Wextra -Wshadow -S f.c alx@debian:~/tmp$ clang -Weverything -Wno-vla -S f.c alx@debian:~/tmp$ That program obviously has a bug. The number of elements of 'a' is intended to be $2, but it is actually controlled by the global variable 'n'. I think -Wshadow should diagnose this.
[Bug target/118835] [12/13 Regression] ICE in s390_valid_shift_count since r10-1731-ge2839e47894f0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118835 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Stefan Schulze Frielinghaus : https://gcc.gnu.org/g:b7466cff8cd4984cea6a2a134c54ca18e20f3fb3 commit r13-9399-gb7466cff8cd4984cea6a2a134c54ca18e20f3fb3 Author: Stefan Schulze Frielinghaus Date: Thu Feb 13 09:13:06 2025 +0100 s390: Fix s390_valid_shift_count() for TI mode [PR118835] During combine we may end up with (set (reg:DI 66 [ _6 ]) (ashift:DI (reg:DI 72 [ x ]) (subreg:QI (and:TI (reg:TI 67 [ _1 ]) (const_wide_int 0x0aabf)) 15))) where the shift count operand does not trivially fit the scheme of address operands. Reject those operands, especially since strip_address_mutations() expects expressions of the form (and ... (const_int ...)) and fails for (and ... (const_wide_int ...)). Thus, be more strict here and accept only CONST_INT operands. Done by replacing immediate_operand() with const_int_operand() which is enough since the former only additionally checks for LEGITIMATE_PIC_OPERAND_P and targetm.legitimate_constant_p which are always true for CONST_INT operands. While on it, fix indentation of the if block. gcc/ChangeLog: PR target/118835 * config/s390/s390.cc (s390_valid_shift_count): Reject shift count operands which do not trivially fit the scheme of address operands. gcc/testsuite/ChangeLog: * gcc.target/s390/pr118835.c: New test. (cherry picked from commit ac9806dae30d07ab082ac341fe5646987753adcb)
[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #22 from kargls at comcast dot net --- On 2/25/25 20:28, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 > > --- Comment #21 from Jerry DeLisle --- > (In reply to kargls from comment #20) >> (In reply to Jerry DeLisle from comment #19) >>> >>> What this is doing is invoking -std=legacy for files with suffixes that >>> imply legacy files such as .f >>> >>> This is my first dive on the lang-spec file so there may be something a >>> little different we do. >> >> The .f suffix denotes fixed-form source code, which is independent >> of what -std=legacy originally meant. The -std=legacy allows a bunch >> of nonstandard Fortran or deleted features. IMO, it should not be >> used as a hammer. >> > It breaks some test cases as well. At this point I am undecided bewteen > changing this or adding to the documentation that -std=legacy may be needed > when using -x f77 and leave everything alone. > I think documenting that the '-x f77' option may also require the '-std=legacy' option is decent solution. If the '-x f77' was added by g77, the we could state that requirements from newer standards leads to the need to -std=legacy.
[Bug tree-optimization/119016] New: [15 regression] svn miscompiled with -O2 -mavx -fno-vect-cost-model
,
0x3d, 0x20, 0x7e, 0x69, 0x41, 0x6e, 0x64, 0x4d, 0x61, 0x73, 0x6b, 0x3b,
0xa, 0x9, 0x72, 0x47, 0x50, 0x49, 0x4f, 0x5f, 0x42, 0x5f, 0x49, 0x6e, 0x70,
0x75, 0x74, 0x5f, 0x45, 0x6e,
0x61, 0x62, 0x6c, 0x65, 0x20, 0x26, 0x3d, 0x20, 0x69, 0x41, 0x6e, 0x64,
0x4d, 0x61, 0x73, 0x6b, 0x3b, 0xa, 0x9, 0x72, 0x47, 0x50, 0x49, 0x4f, 0x5f,
0x42, 0x5f, 0x4f, 0x75, 0x74,
0x70, 0x75, 0x74, 0x5f, 0x45, 0x6e, 0x61, 0x62, 0x6c, 0x65, 0x20, 0x7c,
0x3d, 0x20, 0x69, 0x4f, 0x72, 0x4d, 0x61, 0x73, 0x6b, 0x3b, 0x9, 0xa, 0x9,
0x72, 0x47, 0x50, 0x49, 0x4f, 0x5f,
0x42, 0x20, 0x7c, 0x3d, 0x20, 0x69, 0x4f, 0x72, 0x4d, 0x61, 0x73, 0x6b,
0x3b, 0xa, 0x9, 0x69, 0x56, 0x61, 0x6c, 0x20, 0x3d, 0x20, 0x72, 0x47, 0x50,
0x49, 0x4f, 0x5f, 0x42, 0x3b, 0xa,
0x9, 0x69, 0x56, 0x61, 0x6c, 0x20, 0x26, 0x3d, 0x20, 0x69, 0x41, 0x6e,
0x64, 0x4d, 0x61, 0x73, 0x6b, 0x3b, 0xa, 0x9, 0x72, 0x47, 0x50, 0x49, 0x4f,
0x5f, 0x42, 0x20, 0x26, 0x3d, 0x20,
0x69, 0x41, 0x6e, 0x64, 0x4d, 0x61, 0x73, 0x6b, 0x3b, 0xa, 0x9, 0x72, 0x47,
0x50, 0x49, 0x4f, 0x5f, 0x42, 0x5f, 0x4f, 0x75, 0x74, 0x70, 0x75, 0x74, 0x5f,
0x45, 0x6e, 0x61, 0x62,
0x6c, 0x65, 0x20, 0x26, 0x3d, 0x20, 0x69, 0x41, 0x6e, 0x64, 0x4d, 0x61,
0x73, 0x6b, 0x3b, 0x9, 0xa, 0x9, 0x72, 0x47, 0x50, 0x49, 0x4f, 0x5f, 0x42,
0x5f, 0x49, 0x6e, 0x70, 0x75, 0x74,
0x5f, 0x45, 0x6e, 0x61, 0x62, 0x6c, 0x65, 0x20, 0x7c, 0x3d, 0x20, 0x69,
0x4f, 0x72, 0x4d, 0x61, 0x73, 0x6b, 0x3b, 0xa, 0xa, 0x9, 0x72, 0x65, 0x74,
0x75, 0x72, 0x6e, 0x20, 0x69, 0x56,
0x61, 0x6c, 0x3b, 0xa, 0x7d, 0xa, 0x23, 0x65, 0x6e, 0x64, 0x69, 0x66, 0xa,
0xa, 0x76, 0x6f, 0x69, 0x64, 0xa, 0x74, 0x65, 0x73, 0x74, 0x42, 0x75, 0x67,
0x20, 0x28, 0x76, 0x6f, 0x69,
0x64, 0x29, 0xa, 0x7b, 0xa, 0x20, 0x20, 0x41, 0x53, 0x53, 0x45, 0x52, 0x54,
0x20, 0x28, 0x31, 0x29, 0x3b, 0xa, 0x7d, 0xa, 0xa};
char* end = p + (sizeof(p) / sizeof(p[0]));
const char* eol = NULL;
char* start;
int i = 0;
do {
start = p + len;
const char* eol = svn_eol__find_eol_start(start, end - start);
len += (eol ? eol : end) - start;
i++;
} while (((end - p) > len + 2) && i < 100);
}
```
```
$ gcc eol.c -std=gnu90 -O2 -mavx -o eol && ./eol
$ gcc eol.c -std=gnu90 -O2 -mavx -o eol -fno-vect-cost-model && ./eol
Segmentation fault (core dumped) ./eol
$ valgrind ./eol
[...]
==714951== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==714951== General Protection Fault
==714951==at 0x10868D: svn_eol__find_eol_start (in
/home/sam/bugs/subversion/subversion-1.14.5/build-maybe/eol)
==714951==by 0x10839A: main (in
/home/sam/bugs/subversion/subversion-1.14.5/build-maybe/eol)
==714951==
```
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,m2,rust
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 15.0. p, commit
2f960908caaad18d54ce7cb764ac470656e664c4' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--enable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250225 (experimental)
2d812eecc36e69b5c39ad49b80ab9965c63fdd09 (Gentoo Hardened 15.0. p, commit
2f960908caaad18d54ce7cb764ac470656e664c4)
```
[Bug tree-optimization/119016] [15 regression] svn miscompiled with -O2 -mavx -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119016 --- Comment #1 from Sam James --- Created attachment 60588 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60588&action=edit eol.c
[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Component|bootstrap |ipa Keywords||needs-source Last reconfirmed||2025-02-25 --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source for rust-lex.cc ? The big difference between stage1 and stage2 is debug info. Can can you post the exact configure command that you are building with rather than the build script since it is NOT obvious the options being used. Also the comparison script is different from the what you are doing for comparison so what you think is the different is incorrect. It uses $(srcdir)/contrib/compare-lto to the comparison.
[Bug target/118753] [15 Regression] [meta-bug] GCC 15 Regression on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118753 Bug 118753 depends on bug 115028, which changed state. Bug 115028 Summary: [15 regression] gcc.target/i386/pr101950-2.c FAILs since r15-268-g9dbff9c05520a7 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/117342] .base64 emitted when gas doesn't support it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342 --- Comment #16 from Andrew Pinski --- (In reply to Khem Raj from comment #15) > My problem was that I made the version to be 15.1.0 How?
[Bug target/118992] Redundant argument set up for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992 --- Comment #11 from H.J. Lu --- Created attachment 60590 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60590&action=edit A patch Can you try this on SPEC CPU?
[Bug middle-end/117342] .base64 emitted when gas doesn't support it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342 --- Comment #17 from Sam James --- (In reply to Khem Raj from comment #15) I don't think this is really the same problem. It can easily happen if you e.g. build gcc 15 with newer binutils then downgrade (with any sort of gymnastics in-between). It's not clear what David's original problem was but it was likely the same thing.
[Bug c++/119017] New: error on valid user defined literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119017
Bug ID: 119017
Summary: error on valid user defined literal
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
The following code compiles fine with clang and MSVC. gcc errors
https://godbolt.org/z/1MPvrjfaK
```
#include
template
struct S {
friend consteval S operator""_S(const char*, size_t) noexcept;
friend consteval S operator""_S(const wchar_t*, size_t) noexcept;
friend consteval S operator""_S(const char16_t*, size_t)
noexcept;
friend consteval S operator""_S(const char32_t*, size_t)
noexcept;
};
inline consteval S operator""_S(const char* str, size_t) noexcept {
return S{};
}
inline consteval S operator""_S(const wchar_t* str, size_t) noexcept {
return S{};
}
inline consteval S operator""_S(const char16_t* str,
size_t) noexcept {
return S{};
}
inline consteval S operator""_S(const char32_t* str,
size_t) noexcept {
return S{};
}
constexpr auto a = "a"_S;
```
Error:
```
:5:30: error: 'consteval S operator""_S(const char*, size_t)' has
invalid argument list [-Wtemplate-body]
5 | friend consteval S operator""_S(const char*, size_t)
noexcept;
| ^~~~
:6:33: error: 'consteval S operator""_S(const wchar_t*,
size_t)' has invalid argument list [-Wtemplate-body]
6 | friend consteval S operator""_S(const wchar_t*, size_t)
noexcept;
| ^~~~
:7:34: error: 'consteval S operator""_S(const char16_t*,
size_t)' has invalid argument list [-Wtemplate-body]
7 | friend consteval S operator""_S(const char16_t*, size_t)
noexcept;
| ^~~~
:8:34: error: 'consteval S operator""_S(const char32_t*,
size_t)' has invalid argument list [-Wtemplate-body]
8 | friend consteval S operator""_S(const char32_t*, size_t)
noexcept;
| ^~~~
Compiler returned: 1
```
[Bug libstdc++/118083] __possibly_const_range misses input_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118083 --- Comment #2 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1b9e4fe2ff5f4711406cdcf0e6e183b247d9f42b commit r15-7698-g1b9e4fe2ff5f4711406cdcf0e6e183b247d9f42b Author: Patrick Palka Date: Tue Feb 25 13:35:04 2025 -0500 libstdc++: Implement LWG 4027 change to possibly-const-range [PR118083] LWG 4027 effectively makes the const range access CPOs ranges::cfoo behave more consistently across C++23 and C++20 (pre-P2278R4) and also more consistently with the std::cfoo range accessors, as the below testcase adjustments demonstrate (which mostly consist of reverting workarounds added by r14-3771-gf12e26f3496275 and r13-7186-g0d94c6df183375). In passing fix PR118083 which reports that the input_range constraint on possibly-const-range is missing in our implementation. A consequence of this is that the const range access CPOs now consistently reject a non-range argument, and so in some our of tests we need to introduce otherwise unused begin/end members. PR libstdc++/118083 libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (ranges::__access::__possibly_const_range): Adjust logic as per LWG 4027. Add missing input_range constraint. * testsuite/std/ranges/access/cbegin.cc (test05): Verify LWG 4027 testcases. * testsuite/std/ranges/access/cdata.cc: Adjust, simplify and consolidate some tests after the above. * testsuite/std/ranges/access/cend.cc: Likewise. * testsuite/std/ranges/access/crbegin.cc: Likewise. * testsuite/std/ranges/access/crend.cc: Likewise. * testsuite/std/ranges/adaptors/join.cc: Likewise. * testsuite/std/ranges/adaptors/take_while.cc: Likewise. * testsuite/std/ranges/adaptors/transform.cc: Likewise. Reviewed-by: Jonathan Wakely
[Bug libstdc++/118083] __possibly_const_range misses input_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118083 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.3
[Bug c/119001] [15 Regression] ICE: in output_constructor_regular_field, at varasm.cc:5833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001 qinzhao at gcc dot gnu.org changed: What|Removed |Added Assignee|qinzhao at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > Created attachment 60582 [details] > gcc15-pr119001.patch > > Full untested patch. thanks a lot, I think the fix is reasonable. one question, should we clarify this in the documentation of Flexible Array Members in Unions
[Bug fortran/108680] Wrong DTIO arguments with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #9) > We can have only one default integer otherwise its not a default. Our > default integer is KIND=4 Forgive me for being stupid, but leaving aside the -fdefault-integer-*, where in the standard does it require *default integer* for the unit number? Could it be integer(2)? If not, why not? I simply cannot find the text.
[Bug target/119010] [15 Regression] 444.namd shows a huge compile-time regression with -mtune=znver5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119010
Richard Biener changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #3 from Richard Biener ---
So possibly an issue with issue_rate, dfa_lookahead and max_lookahead_tries.
On x86 for sched2 we have dfa_lookahead == issue_rate == 4 for znver4 and below
but 6 for znver5 (and spr). This results in increasing of max_lookahead
by a factor of 182 (4*4*4*4 vs. 6*6*6*6*6*6) or a complexity increase from
4**4 to 6**6.
The comment mentions
"We would not need this constraint if all real insns (with non-negative codes)
had reservations because in this case the algorithm complexity is
O(DFA_LOOKAHEAD**ISSUE_RATE). Unfortunately, the dfa descriptions
might be incomplete and such insn might occur."
so maybe this is the case here. The following ICEs quite quickly after
4665600 tries. So what does this do? Does it really try to brute force
finding #issue-width ready insns that can be issued in parallel? Does the
automaton have 6 ports to issue to?
diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index 63eb06b2d82..cd1f3a6db0a 100644
--- a/gcc/haifa-sched.cc
+++ b/gcc/haifa-sched.cc
@@ -6049,7 +6049,7 @@ max_issue (struct ready_list *ready, int privileged_n,
state_t state,
{
tries_num++;
if (tries_num > max_lookahead_tries)
- break;
+ gcc_unreachable ();//break;
insn = ready_element (ready, i);
delay = state_transition (state, insn);
if (delay < 0)
for the first ICE we have
;; max_issue among 18 insns: 1682:221:prio=1 1681:220:prio=1
1680:219:prio=1 1321:213:prio=1 1320:212:prio=1 46:205:prio=1 45:204:prio=1
44:203:prio=1 43:202:prio=1 1510:179:prio=1 1674:216:prio=1 367:200:prio=1
47:206:prio=1 2303:180:prio=4 356:183:prio=7 359:187:prio=42
2415:188:prio=46 1957:185:prio=49
and some of those are
;; | 47 |1 | xmm11=0.0 nothing
;; | 1320 |1 | xmm22=[`*.LC2']nothing
;; | 1321 |1 | xmm21=[`*.LC3']nothing
;; | 1680 |1 | [sp+0xf0]=r8 nothing
;; | 1681 |1 | [sp+0xf8]=r12 nothing
;; | 1682 |1 | [sp+0x100]=r9 nothing
;; | 1683 |1 | [sp+0xc0]=ax nothing
[Bug translation/118991] Wrong extracted text in avr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991
--- Comment #5 from Jakub Jelinek ---
Fix for avr:
2025-02-25 Jakub Jelinek
PR translation/118991
* config/avr/avr.cc (avr_print_operand): Print ival into
a temporary buffer and use %s in output_operand_lossage to make
the diagnostics translatable.
--- gcc/config/avr/avr.cc.jj2025-02-24 00:06:25.0 +0100
+++ gcc/config/avr/avr.cc 2025-02-25 13:45:58.960806467 +0100
@@ -2750,10 +2750,19 @@ avr_print_operand (FILE *file, rtx x, in
fprintf (file, HOST_WIDE_INT_PRINT_HEX, ival - sfr0);
}
else
- output_operand_lossage
- ("bad I/O address 0x" HOST_WIDE_INT_PRINT_HEX_PURE
-" outside of valid range [0x%x, 0x%x] for %%i operand",
-ival, sfr0, sfr0 + 0x3f);
+ {
+ char buf[17];
+ /* Printed indirectly through buffer, as
+ output_operand_lossage is translatable but uses printf
+ format strings, so HOST_WIDE_INT_PRINT_HEX_PURE macro can't
+ be used thre to make translation possible and how exactly
+ can be HOST_WIDE_INT printed is host dependent. */
+ snprintf (buf, sizeof buf, HOST_WIDE_INT_PRINT_HEX_PURE,
+ ival);
+ output_operand_lossage ("bad I/O address 0x%s outside of "
+ "valid range [0x%x, 0x%x] for %%i "
+ "operand", buf, sfr0, sfr0 + 0x3f);
+ }
}
break; // CONST_INT
[Bug middle-end/118874] [15 regression] ICE in copy_rtx, at rtl.cc:372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Jakub Jelinek --- > Even just [...] > ICEs the same way, so this doesn't seem to be related to range for. > Does this ICE even with older gcc versions which do support coroutines (14, > 13, > 12, 11, 10)? Some of those need -fcoroutines. I've tried with local versions of g++ all the way back to gcc 10: gcc-14 down to gcc-11 do ICE indeed with -m64 -O -fcoroutines, while gcc-10 does not. Btw., the Solaris cfarm systems do have various versions of gcc installed in parallel, both bundled (in /usr/gcc/ with a limited set of languages) and the full monty in /opt/cfarm/gcc-* (with all supported languages), just in case.
[Bug c/119014] Extending _Float16 constant at compile and run time differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- That is the normal behavior of extended precision. Because without -fexcess-precision=16 _Float16 is evaluated in float precision, the first 42.42f16 is actually 42.42f returned in _Float16 and thus converted to the _Float16 precision, while in the x != 42.42f16 case there is no explicit cast or assignment and so you're actually comparing against 42.42f. You can use x != (_Float16) 42.42f16 if the constant is supposed to be in _Float16 precision.
[Bug c/119014] Extending _Float16 constant at compile and run time differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #5 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #2) > That is the normal behavior of extended precision. If you think of FLT_EVAL_METHOD, then this applies *only* to float, double and long double. The ISO C23 standard does not allow extended precision for the other floating-point types, such as _Float16. So, clearly, with -std=c23, GCC is buggy and this bug is valid.
[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047 --- Comment #22 from David Malcolm --- Created attachment 60584 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60584&action=edit Contents of /proc/cpuinfo on a machine that this crash *doesn't* happen on
[Bug fortran/108233] [Coarray] bcast to non-allocatable COMPLEX scalar coarray may generate wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108233 Andre Vehreschild changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from Andre Vehreschild --- Awaiting review of: https://gcc.gnu.org/pipermail/fortran/2025-February/061782.html
[Bug fortran/117430] gfortran allows type(C_ptr) in I/O list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117430 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerry DeLisle --- Closing as fixed on gcc-15
[Bug translation/118991] Wrong extracted text in avr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991 --- Comment #6 from Roland Illig --- (In reply to Jakub Jelinek from comment #5) > Fix for avr: Looks good to me, apart from the typo "thre" in the comment.
[Bug translation/118991] Wrong extracted text in avr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991 --- Comment #7 from Roland Illig --- On the other hand, since you already limit the temporary buffer to 16 hex digits, you could as well use %#llx directly, as ULLONG_MAX is guaranteed to be at least 2^64-1 since C99. Or can GCC itself be built in C90, where there is no ULLONG_MAX?
[Bug c/119014] Extending _Float16 constant at compile and run time differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92875 --- Comment #3 from Andrew Pinski --- See pr 92875 also.
