[Bug c++/117175] Internal compiler error in gimple_add_tmp_var, at gimplify.cc:802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117175 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2025-02-17 Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- This ICE is still present.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 102455, which changed state. Bug 102455 Summary: ICE in verify_ctor_sanity with vector types in constexpr and variable template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102455 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/115773] gcc crashed with an init-capture which introduces a pack inside another lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115773 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-02-17 CC||mpolacek at gcc dot gnu.org
[Bug tree-optimization/118910] Promote an expression equivalence to a name equivalence in DOM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118910 Sam James changed: What|Removed |Added Last reconfirmed||2025-02-17 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81958 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug c++/116568] [modules] ICE when exporting template using of unevaluated lambda in key_mergeable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116568 Marek Polacek changed: What|Removed |Added Last reconfirmed||2025-02-17 Status|UNCONFIRMED |ASSIGNED CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/102455] ICE in verify_ctor_sanity with vector types in constexpr and variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102455 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug target/116078] [15 Regression] 10-12% slowdown of 436.cactusADM on AMD Zen2 since r15-2187-g838999bb23303e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078 --- Comment #8 from Filip Kastl --- Hmm, reverting the commit in question on the current trunk to see if it still causes a slowdown doesn't work.
[Bug c++/107399] [c++ modules] ICE in cpp_maybe_module_directive, at libcpp/lex.cc:3454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107399 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-02-17 --- Comment #1 from Marek Polacek --- Still ICEs.
[Bug c++/107623] Using a parameter pack twice results in ambiguous overloaded function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107623 Marek Polacek changed: What|Removed |Added Last reconfirmed||2025-02-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Still ICEs: $ ./cc1plus -quiet 107623.C -std=c++20 107623.C: In function ‘int main()’: 107623.C:9:11: internal compiler error: in comptypes, at cp/typeck.cc:1712 9 | test(f, 1); | ^~ 0x30303e5 internal_error(char const*, ...) /home/mpolacek/src/gcc/gcc/diagnostic-global-context.cc:517 0x2fffd19 fancy_abort(char const*, int, char const*) /home/mpolacek/src/gcc/gcc/diagnostic.cc:1722 0x89354c comptypes(tree_node*, tree_node*, int) /home/mpolacek/src/gcc/gcc/cp/typeck.cc:1712 0x7d5d5a unify /home/mpolacek/src/gcc/gcc/cp/pt.cc:25360 0x7dab21 more_specialized_fn(tree_node*, tree_node*, int) /home/mpolacek/src/gcc/gcc/cp/pt.cc:26274 0x439b6d joust /home/mpolacek/src/gcc/gcc/cp/call.cc:13497 0x43b5c2 tourney /home/mpolacek/src/gcc/gcc/cp/call.cc:13812 0x418647 perform_overload_resolution /home/mpolacek/src/gcc/gcc/cp/call.cc:5126 0x41894f build_new_function_call(tree_node*, vec**, int) /home/mpolacek/src/gcc/gcc/cp/call.cc:5218 0x8201a1 finish_call_expr(tree_node*, vec**, bool, bool, int) /home/mpolacek/src/gcc/gcc/cp/semantics.cc:3504 0x6cf11e cp_parser_postfix_expression /home/mpolacek/src/gcc/gcc/cp/parser.cc:8477 0x6d27f4 cp_parser_unary_expression /home/mpolacek/src/gcc/gcc/cp/parser.cc:9733 0x6d3fcf cp_parser_cast_expression /home/mpolacek/src/gcc/gcc/cp/parser.cc:10648 0x6d40d2 cp_parser_binary_expression /home/mpolacek/src/gcc/gcc/cp/parser.cc:10751 0x6d527e cp_parser_assignment_expression /home/mpolacek/src/gcc/gcc/cp/parser.cc:11096 0x6d57ba cp_parser_expression /home/mpolacek/src/gcc/gcc/cp/parser.cc:11279 0x6dbe4b cp_parser_expression_statement /home/mpolacek/src/gcc/gcc/cp/parser.cc:13580 0x6db497 cp_parser_statement /home/mpolacek/src/gcc/gcc/cp/parser.cc:13324 0x6dc7a2 cp_parser_statement_seq_opt /home/mpolacek/src/gcc/gcc/cp/parser.cc:13843 0x6dc312 cp_parser_compound_statement /home/mpolacek/src/gcc/gcc/cp/parser.cc:13690
[Bug c++/102047] ICE in template_parms_to_args passing lambda-quoted constraint to meta-concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102047
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2025-02-17
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
Still ICEs:
$ ./cc1plus -quiet 102047.C -std=c++20
102047.C:6:18: internal compiler error: Segmentation fault
6 | { t.x } -> M<[](){}>;
| ^
0x30303e5 internal_error(char const*, ...)
/home/mpolacek/src/gcc/gcc/diagnostic-global-context.cc:517
0x11c45ce crash_signal
/home/mpolacek/src/gcc/gcc/toplev.cc:322
0x7f9c124df04f ???
/usr/src/debug/glibc-2.40-21.fc41.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x40644d tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3686
0x76be52 template_parms_to_args(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:4996
0x79f87c tsubst_template_decl
/home/mpolacek/src/gcc/gcc/cp/pt.cc:15248
0x7be34b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20289
0x7c9587 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:22292
0x7922ce tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:13054
0x4bd6ff tsubst_parameter_mapping
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:1805
0x4bf454 satisfy_atom
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2395
0x4bfb88 satisfy_constraint_r
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2495
0x4bfc39 satisfy_normalized_constraints
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2520
0x4c0100 satisfy_nondeclaration_constraints
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2601
0x4c0cb6 constraint_satisfaction_value
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2766
0x4c0e0f constraints_satisfied_p(tree_node*, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2798
0x7f5e9d do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:31840
0x4bc40e type_deducible_p
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:1444
0x4bc85e tsubst_compound_requirement
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:1510
0x4bcd2c tsubst_requirement
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:1602
[Bug c++/96570] Warnings desired for time_t to int coversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570 --- Comment #14 from Andrew Pinski --- *** Bug 118326 has been marked as a duplicate of this bug. ***
[Bug c/118326] time_t conversion warnings wanted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118326 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Still a dup . *** This bug has been marked as a duplicate of bug 96570 ***
[Bug c/118326] time_t conversion warnings wanted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118326 --- Comment #4 from Andrew Pinski --- (In reply to Xi Ruoyao from comment #3) > The OP wants a warning from int to time_t, not from time_t to int. > > Thus not a dup. The warning should be both ways, otherwise it is not very useful ...
[Bug tree-optimization/118910] New: Promote an expression equivalence to a name equivalence in DOM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118910 Bug ID: 118910 Summary: Promote an expression equivalence to a name equivalence in DOM Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- Created attachment 60517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60517&action=edit POC patch In the context of bz81958 I speculated that improving the way we handle conditional equivalences a bit could improve jump threading and ultimately resolve the missed optimization leading to the false positive uninitialized warning. Since then we've moved away from DOM threading, so those ideas won't solve that particular bz's problem. But the ideas may still be found and provide value. The purpose of this bz is to record the ideas independently and trigger an evaluation of whether or not they are worth pushing beyond the initial proof of concept code. We have a structure which records equivalenes related to edges so that we can add those equivalences to the various tables as we traverse edges. There are two forms of edge equivalences we track. [01] = a COND b Is used to record the equivalences created by the branch itself. We can look the RHS up in the expression table and it'll report back the LHS (a constant indicating branch direction). Second are simple a = b equivalences. THe idea is that we can promote an expression equivalence to a simple equivalence by propagating known const/copy values into the expression equivalence and simplifying. So if the edge had 1 = a GE b If we know that a has the value zero we propagate that in resulting in 1 = 0 GE b We then fold/simplify the RHS. In the case I was looking at B is an unsigned type. So the net after simplificatoin is 1 = (0 EQ b) meaning we can record b = 0 as we traverse the edge. I'll attach a very rough POC that could probably be used for some initial evaluation. I have a suspicion this would be generally useful as I've seen it identify caess for promotion. What I haven't done is run a wide body of code through it to see if it helps in practice (and to generate any tests).
[Bug target/117270] [15 Regression] 9% exec time slowdown of 538.imagick_r on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270 --- Comment #6 from Filip Kastl --- Are you sure this is fixed? On our machine the slowdown didn't go away. See the graph https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=585.507.0. Maybe the weird codegen wasn't the cause of the slowdown?
[Bug c++/102455] ICE in verify_ctor_sanity with vector types in constexpr and variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102455 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:1787119229abca0c78f9c902eeb7c88efed37ce0 commit r15-7592-g1787119229abca0c78f9c902eeb7c88efed37ce0 Author: Marek Polacek Date: Mon Feb 17 12:36:05 2025 -0500 c++: add fixed test [PR102455] Fixed by r13-4564 but the tests are very different. PR c++/102455 gcc/testsuite/ChangeLog: * g++.dg/ext/vector43.C: New test.
[Bug c++/118905] [15 regression] g++.dg/asan/pr118763.C fails since r15-7532-ge96e1bb69c7b46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118905 Sam James changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sam James --- Fixed by r15-7591-g720c8f685210af, thanks!
[Bug fortran/86679] invalid code involving TARGET attribute is not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86679 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2018-07-27 00:00:00 |2025-2-17 CC||tkoenig at gcc dot gnu.org Keywords|accepts-invalid |diagnostic Severity|normal |enhancement --- Comment #5 from Thomas Koenig --- The code is invalid, but hard to diagnose (and it is not a constraint).
[Bug tree-optimization/118902] missing predicated VN due to Canonical order of comparison with invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118902 --- Comment #3 from Richard Biener --- (In reply to Richard Biener from comment #2) > I wonder why GIMPLE tree_swap_operands_p doesn't swap? Isn't an invariant > ADDR_EXPR TREE_CONSTANT according to recompute_tree_invariant_for_addr_expr? > That might mishandle MEM_REF[&decl] though. Oh, so we only consider staticp as TREE_CONSTANT which does not include any automatic vars.
[Bug middle-end/118889] attribute "common" ignored with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889 --- Comment #4 from Georg-Johann Lay --- (In reply to rguent...@suse.de from comment #3) > On Mon, 17 Feb 2025, gjl at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889 > > --- Comment #2 from Georg-Johann Lay --- > > (In reply to Richard Biener from comment #1) > > > I think variables with 'static' linkage cannot be 'common'? > > > > Shouldn't they go into .lcomm, i.e. lcomm_section? > > Never heard of that ;) In my understanding 'common' and 'local' > exclude themselves, locals should go to .bss (possibly .lcomm is > a thing on targets w/o .bss?). It's hard to find specification of that stuff. I just worked backwards from varasm.cc trying to make the said variable attribute work. And one part could be throwing a "common" attribute at VAR_DECLs in the local case. > > What I am trying to achieve is to implement a variable attribute, and to get > > some noswitch section attached to a VAR_DECL in static storage. > > > > Since common static variables are not in lcomm_section, the attribute fails > > for > > local variables. > > > > FYI, regarding the variable attribute, what also doesn't work is to return a > > custom noswitch section in TARGET_ASM_SELECT_SECTION since that hook is not > > called for all static storage VAR_DECLs. More on the background can be > > found > > at https://gcc.gnu.org/pipermail/gcc-help/2025-February/143983.html > > I suppose trying to fix either is sound. There is nothing to "fix". NOT calling TARGET_ASM_SELECT_SECTION in some situations like when bss_initializer_p(decl) is a FEATURE implanted by varasm.cc, not a bug.
[Bug fortran/84386] Implicitly declared variables in BLOCK have scope of including program unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84386 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- This is fixed, already in 13.3.0. Commit a test case and close? Or is this already covered in the testsuite?
[Bug middle-end/118889] attribute "common" ignored with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889 --- Comment #3 from rguenther at suse dot de --- On Mon, 17 Feb 2025, gjl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889 > > --- Comment #2 from Georg-Johann Lay --- > (In reply to Richard Biener from comment #1) > > I think variables with 'static' linkage cannot be 'common'? > > Shouldn't they go into .lcomm, i.e. lcomm_section? Never heard of that ;) In my understanding 'common' and 'local' exclude themselves, locals should go to .bss (possibly .lcomm is a thing on targets w/o .bss?). > What I am trying to achieve is to implement a variable attribute, and to get > some noswitch section attached to a VAR_DECL in static storage. > > Since common static variables are not in lcomm_section, the attribute fails > for > local variables. > > FYI, regarding the variable attribute, what also doesn't work is to return a > custom noswitch section in TARGET_ASM_SELECT_SECTION since that hook is not > called for all static storage VAR_DECLs. More on the background can be found > at https://gcc.gnu.org/pipermail/gcc-help/2025-February/143983.html I suppose trying to fix either is sound.
[Bug tree-optimization/118895] [15 regression] ICE: during GIMPLE pass: pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118895 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:dfd0ced98fcf62c4d24979b74c1d52334ff62bfc commit r15-7589-gdfd0ced98fcf62c4d24979b74c1d52334ff62bfc Author: Richard Biener Date: Mon Feb 17 11:40:01 2025 +0100 tree-optimization/118895 - ICE during PRE When we simplify a NARY during PHI translation we have to make sure to not inject not available operands into it given that might violate the valueization hook constraints and we'd pick up invalid context-sensitive data in further simplification or as in this case later ICE when we try to insert the expression. PR tree-optimization/118895 * tree-ssa-sccvn.cc (vn_nary_build_or_lookup_1): Only allow CSE if we can verify the result is available. * gcc.dg/pr118895.c: New testcase.
[Bug c++/118908] New: c++ include defines uintptr_t *sometimes*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908
Bug ID: 118908
Summary: c++ include defines uintptr_t *sometimes*
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
previously uintptr_t was always defined after #include
but gcc-15 does this only in an unpredictable way, consider this
example:
$ cat test.cc
#include
uintptr_t x;
int main()
{
return 0;
}
$ gcc test.cc
test.cc:3:1: error: ‘uintptr_t’ does not name a type
3 | uintptr_t x;
| ^
test.cc:2:1: note: ‘uintptr_t’ is defined in header ‘’; this is
probably fixable by adding ‘#include ’
1 | #include
+++ |+#include
2 |
$ gcc -fsanitize=address test.cc
test.cc:3:1: error: ‘uintptr_t’ does not name a type
3 | uintptr_t x;
| ^
test.cc:2:1: note: ‘uintptr_t’ is defined in header ‘’; this is
probably fixable by adding ‘#include ’
1 | #include
+++ |+#include
2 |
$ gcc -fsanitize=thread test.cc
$ gcc --std=c++20 test.cc
This funny behavior started with the following commit:
commit 3a817a4a5a6d94da9127af3be9f84a74e3076ee2 (HEAD)
Author: Jonathan Wakely
AuthorDate: Thu Dec 7 12:13:59 2023 +
Commit: Jonathan Wakely
CommitDate: Thu Aug 1 21:56:56 2024 +0100
libstdc++: Remove unnecessary uses of
We don't need to include all of when we only need uintptr_t
from it. By using GCC's internal macro we avoid unnecessarily declaring
everything in . This helps users to avoid accidentally relying
on those names being declared without explicitly including the header.
libstdc++-v3/ChangeLog:
* include/bits/align.h (align, assume_aligned): Use
__UINTPTR_TYPE__ instead of uintptr_t. Do not include
.
* include/bits/atomic_base.h (__atomic_ref): Likewise.
* include/bits/atomic_wait.h (__waiter_pool_base::_S_for):
Likewise.
* include/std/atomic: Include .
[Bug fortran/66182] Unneeded temporary for elemental functions of function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66182 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2015-08-30 00:00:00 |2025-2-17 --- Comment #3 from Thomas Koenig --- Changing c = conjg(matmul(a,b)) into c = matmul(conjg(a),conjg(b)) would allow inlining.
[Bug c++/118905] [15 regression] g++.dg/asan/pr118763.C fails since r15-7532-ge96e1bb69c7b46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118905 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-02-17 --- Comment #1 from Richard Biener --- confirmed.
[Bug fortran/58786] module function with passed character array of explicit length causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58786 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Known to fail||13.3.0 --- Comment #6 from Thomas Koenig --- No longer ICEs, the fix seems to have been more recent, 13.3.0 still ICEs.
[Bug middle-end/118889] attribute "common" ignored with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118889
--- Comment #5 from Georg-Johann Lay ---
...the respective part of varasm.cc reads:
get_variable_section (tree decl, bool prefer_noswitch_p)
{
...
if (ADDR_SPACE_GENERIC_P (as)
&& !DECL_THREAD_LOCAL_P (decl)
&& !DECL_NOINIT_P (decl)
&& !(prefer_noswitch_p && targetm.have_switchable_bss_sections)
&& bss_initializer_p (decl))
{
if (!TREE_PUBLIC (decl)
&& !((flag_sanitize & SANITIZE_ADDRESS)
&& asan_protect_global (decl)))
return lcomm_section;
if (bss_noswitch_section)
return bss_noswitch_section;
}
return targetm.asm_out.select_section (decl, reloc,
get_variable_align (decl));
}
Plus, what also does not work is to add a "noinit" attribute to coax
into calling targetm.asm_out.select_section, since with "noinit"
and -fdata-sections, the object if effectively in a named section.
And named sections don't have a section callback, so no custom asm
is possible.
[Bug c++/96570] Warnings desired for time_t to int coversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570 --- Comment #12 from Bernhard M. Wiedemann --- @Xi: that is a cast from time_t to int, but I want a warning for conversion from int to time_t And IMHO we don't have to force warnings for explicit casts.
[Bug c++/99800] ICE Segmentation fault when put lambda in template parameter list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99800 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #4 from Marek Polacek --- Fixed by r12-100.
[Bug target/118888] GCC only optimize 1 bits-manipulation function out of many despite having the same implementations; not using BTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 Andrew Pinski changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- *** Bug 118907 has been marked as a duplicate of this bug. ***
[Bug ipa/118907] ICF optimises bit selection differently based on declaration order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118907 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 11 ***
[Bug tree-optimization/87332] [meta-bug] Issues related to Identical Code Folding (ICF) and Tail Merging (-ftree-tail-merge)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87332 Bug 87332 depends on bug 118907, which changed state. Bug 118907 Summary: ICF optimises bit selection differently based on declaration order https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118907 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/86959] Use of a variadic alias template unexpectedly breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86959 Marek Polacek changed: What|Removed |Added Last reconfirmed||2025-02-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- Still ICEs.
[Bug target/118764] [avr] Add support for Compact Vector Table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118764 --- Comment #5 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:230678c19cb5e2f8a4855b9790794042fc6ad068 commit r15-7588-g230678c19cb5e2f8a4855b9790794042fc6ad068 Author: Georg-Johann Lay Date: Mon Feb 17 14:31:25 2025 +0100 AVR: ad target/118764 - Mention CVT availability in device-specs comment. gcc/ PR target/118764 * config/avr/gen-avr-mmcu-specs.cc (print_mcu) [has CVT]: Mention CVT in header comment of generated specs file.
[Bug libgomp/118909] New: OpenMP reduction array is always allocated on stack, cause stack overflow with large array reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118909
Bug ID: 118909
Summary: OpenMP reduction array is always allocated on stack,
cause stack overflow with large array reduction.
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: z00823823 at outlook dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Dear maintainer:
The openmp always alloc the recution array on stack, cause stack overflow with
large array. Here is an example:
```c
#include
#include
#include
#include
int main() {
double *test = NULL;
for (size_t size = 1;; size += 1024) {
test = malloc(size * sizeof(double));
if (test == NULL) {
printf("Failed to allocate %zu doubles\n", size);
break;
}
printf("test: %p\n", test);
#pragma omp parallel reduction(+ : test[0 : size]) num_threads(2)
{
test[0] = 0;
#pragma omp critical
{
printf("frame address: %p\n", __builtin_frame_address(0));
printf("test: %p\n", test);
}
}
free(test);
printf("Allocated %zu doubles\n\n", size);
}
}
```
Run it for a while until it crashs. On my laptop it crashs with size > 1046529
(approximately 8MB).
An online version can be found here: https://godbolt.org/z/v1o6K9a1b
[Bug libstdc++/118908] c++ include defines uintptr_t *sometimes*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- Not a bug, nor a "broken feature." For implementing C++20 needs to include more other headers than implementing C++17, thus happens to be included. For building with the thread sanitizer has to use sanitizer/tsan_interface.h, and the latter happens to include . It's just some coincidence and you cannot rely on a coincidence.
[Bug c++/115695] spurious warning for -Wsign-compare with c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115695 Marek Polacek changed: What|Removed |Added Last reconfirmed||2025-02-17 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Marek Polacek --- Confirmed.
[Bug libgomp/118909] OpenMP reduction array is always allocated on stack, cause stack overflow with large array reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118909 --- Comment #1 from LXYan --- output with address sanitizer: ``` …… test: 0x7f61e971f800 frame address: 0x7f61f8700dd0 test: 0x7f61f7f04820 frame address: 0x7ffdff0f7020 test: 0x7ffdfe8faa60 Allocated 1046695 doubles test: 0x7f61f4709800 AddressSanitizer:DEADLYSIGNAL = ==48539==ERROR: AddressSanitizer: stack-overflow on address 0x7ffdfe8f9ff8 (pc 0x7f61fae474c0 bp 0x0070 sp 0x7ffdfe8fa000 T0) #0 0x7f61fae474c0 in char_is_one_of ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:43 #1 0x7f61fae474c0 in format_is_integer_conv ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:70 #2 0x7f61fae474c0 in format_get_value_size ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:112 #3 0x7f61fae72979 in printf_get_value_size ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:454 #4 0x7f61fae72979 in printf_common ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:526 #5 0x7f61fae731fa in __interceptor_vprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1657 #6 0x7f61fae732d6 in __interceptor_printf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1715 #7 0x555f9c42 in main._omp_fn.0 /home/lxyan/Code/cpp/poc/src/poc_c/poc_c.c:19 #8 0x7f61fadcc0b5 in GOMP_parallel (/lib/x86_64-linux-gnu/libgomp.so.1+0x140b5) #9 0x555f9c5553a1 in main /home/lxyan/Code/cpp/poc/src/poc_c/poc_c.c:14 #10 0x7f61fabfe249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #11 0x7f61fabfe304 in __libc_start_main_impl ../csu/libc-start.c:360 #12 0x555f9c555170 in _start (/home/lxyan/Code/cpp/poc/src/poc_c/a.out+0x1170) SUMMARY: AddressSanitizer: stack-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:43 in char_is_one_of ==48539==ABORTING ```
[Bug lto/118125] [15 Regression] 7-16% slowdown of 510.parest_r on x86-64(-v3) since r15-6110-g92e0e0f8177530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Martin Jambor --- (In reply to Filip Kastl from comment #0) > As seen here > > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1118.457.0 > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=959.457.0 > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=475.457.0 > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.457.0 > All graphs dropped to the previous levels, so let's close this and discuss the other attributes in the new bug. Thanks everyone for your input.
[Bug lto/118858] Missing builtin attributes handling for DEF_ATTR_IDENT with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118858 Bug 118858 depends on bug 118125, which changed state. Bug 118125 Summary: [15 Regression] 7-16% slowdown of 510.parest_r on x86-64(-v3) since r15-6110-g92e0e0f8177530 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 118125, which changed state. Bug 118125 Summary: [15 Regression] 7-16% slowdown of 510.parest_r on x86-64(-v3) since r15-6110-g92e0e0f8177530 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/84386] Implicitly declared variables in BLOCK have scope of including program unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84386 --- Comment #3 from kargls at comcast dot net --- (In reply to Thomas Koenig from comment #2) > This is fixed, already in 13.3.0. > > Commit a test case and close? Or is this already covered in the > testsuite? The test still fails for me with 14.2 and top-of-tree. % gfortran14 -o z a.f90 % ./z STOP 1 % gfcx -o z a.f90 % ./z STOP 1 The subroutine BLOCK1 fails as indicated in the comment. Perhaps, you have a local change in your git repository.
[Bug libstdc++/118908] c++ include defines uintptr_t *sometimes*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908 --- Comment #2 from Bernd Edlinger --- (In reply to Richard Biener from comment #1) > I'd say it's a feature, not a bug? Yeah, kind of, just why does the outcome depend on those completely unrelated compiler options? Is this "feature" somehow broken?
[Bug tree-optimization/118895] [15 regression] ICE: during GIMPLE pass: pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118895 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Keywords|needs-bisection | --- Comment #5 from Richard Biener --- Fixed. Caused by r15-7472-g0a1d2ea57722c2
[Bug rtl-optimization/118611] LRA inserts unneeded reload on FMA chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118611 --- Comment #9 from Richard Sandiford --- (In reply to Vladimir Makarov from comment #7) > Unfortunately, although the patch solves the problem but it adds 2 x86-64 > failures of tests expecting smaller number of moves. It also adds 2 > failures for aarch64 tests but I found the code quality is the same > (probably something wrong with regexps used to check the assembler code). Yeah, this is more than possible. Please don't reject the patch based on the aarch64 failures if the output code looks as good. And please leave us to do the testsuite update if you prefer. Although I realise it's controversial, I'm personally a big fan of using tests to “defend” code quality, not just correctness. The aarch64 testsuite now does that quite heavily. But the downside is that sometimes new FAILs are harmless, or even improvements. In the latter case, the response is to change the test to “defend” the new output. In the former case, the response is to generalise the test to accept both forms. I do try to look out for cases where regexps are too strict (and I'm sure others do too), but it's easy to miss cases.
[Bug target/117978] Optimise 128-bit-predicated SVE loads to Advanced SIMD LDRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978 --- Comment #4 from ktkachov at gcc dot gnu.org --- (In reply to Richard Sandiford from comment #3) > I think this would be better done in expand rather than gimple. The gimple > representation would be a vector load in a 128-bit type, followed by a > zeroing extension to the original SVE type. I'm not sure how easy it is to > represent the zeroing extension as things stand, but either way, it would be > converting one load into one load + one other operation. The result seems > more complicated in gimple terms, so I think the natural gimple fold would > be in the opposite direction. > > If we do it in expand, we'll be able to see the constant if we use an > appropriate predicate. > > Also: > > * We should do this for 8-bit, 16-bit, 32-bit, and 64-bit quantities, not > just 128-bit. > > * We should do the same thing for LD2/3/4 and ST2/3/4 (64-bit and 128-bit > only). > > * Except for the single-element case, the optimisation is only valid for > little-endian targets. Do we also need to guard this under TARGET_NON_STREAMING?
[Bug tree-optimization/118896] The fortran compiler is unable to devirtualize typebound indirect calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118896 Thomas Koenig changed: What|Removed |Added Severity|normal |enhancement CC||tkoenig at gcc dot gnu.org Component|fortran |tree-optimization --- Comment #5 from Thomas Koenig --- Maybe a middle end problem?
[Bug fortran/58786] module function with passed character array of explicit length causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58786 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #6) > No longer ICEs, the fix seems to have been more recent, > 13.3.0 still ICEs. The occurence of LEN_TRIM suggests to look at Paul's fix: r15-2072-g9f966b6a8ff024, backported as r14-10834-g944d585d8a566e . Might therefore be a duplicate of PR84868.
[Bug tree-optimization/106103] [12/13/14/15 regression] ICE in binds_to_current_def_p when source object files are compiled with -flto -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106103 Sam James changed: What|Removed |Added Keywords||needs-bisection Summary|ICE in |[12/13/14/15 regression] |binds_to_current_def_p when |ICE in |source object files are |binds_to_current_def_p when |compiled with -flto -Os |source object files are ||compiled with -flto -Os --- Comment #7 from Sam James --- If 11 works, it's a regression then. A bisect may be helpful.
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Hana Dusíková changed:
What|Removed |Added
CC||hanicka at hanicka dot net
--- Comment #1 from Hana Dusíková ---
It's not part of the wording as CWG told me to take it out. But it's very
useful when an exception is not caught to call it's `.what()` and print
resulting message as part of the error. If there is no `.what()` available,
just print it structurally.
https://compiler-explorer.com/z/Gn6xYbKoY
```c++
struct division_by_zero {
constexpr const char * what() const noexcept {
return "thou shall not divide by nothing 😱";
}
};
constexpr unsigned divide(unsigned a, unsigned b) {
if (b == 0) {
throw division_by_zero{};
}
return a / b;
}
constexpr auto v = divide(3, 0);
```
Gives this error in my prototype:
```c++
:14:16: error: constexpr variable 'v' must be initialized by a constant
expression
14 | constexpr auto v = divide(3, 0);
|^
:9:9: note: unhandled exception: thou shall not divide by nothing 😱
9 | throw division_by_zero{};
| ^
```
Even further (and I'm still working on it) would be good to implement extension
which takes anything convertible to `basic_string_view` and then print it.
Note P3560R0 "Error Handling in Reflection" has std::meta::exception type with
`u8string_view what()` member.
[Bug c++/102455] ICE in verify_ctor_sanity with vector types in constexpr and variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102455 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Marek Polacek --- Got fixed by commit d081807d8d70e3e87eae41e1560e54d503f4d465 Author: Jason Merrill Date: Tue Dec 6 09:51:51 2022 -0500 c++: avoid initializer_list [PR105838] I think we should have the Comment 1 test since the commit above added a different test.
[Bug c++/96364] ICE on valid code in cp_finish_decl with auto return type and double attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96364 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:5954c5a7c23fbdf3afc011d703c9fce15db04cbd commit r15-7590-g5954c5a7c23fbdf3afc011d703c9fce15db04cbd Author: Marek Polacek Date: Mon Feb 17 12:12:55 2025 -0500 c++: add fixed test [PR96364] We were rejecting this, but the test compiles correctly since r14-6346. PR c++/96364 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/gen-attrs-88.C: New test.
[Bug fortran/84386] Implicitly declared variables in BLOCK have scope of including program unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84386 --- Comment #4 from Thomas Koenig --- (In reply to kargls from comment #3) > Perhaps, you have a local change in your git repository. I just compiled the wrong test case, that's all :-)
[Bug c++/118763] [12/13 regression] memory leak involving early return from statement expressions since r12-6325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118763 --- Comment #10 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:720c8f685210af9fc9c31810e224751102f1481e commit r15-7591-g720c8f685210af9fc9c31810e224751102f1481e Author: Jason Merrill Date: Sun Feb 16 11:00:36 2025 +0100 c++: extended temps and statement-exprs [PR118763] My last patch for 118856 broke the test for 118763 (which my testing didn't catch, for some reason), because it effectively reverted Jakub's recent fix (r15-7415) for that bug. It seems we need a new flag to indicate internal temporaries. In that patch Jakub wondered if other uses of CLEANUP_EH_ONLY would have the same issue with jumps out of a statement-expr, and indeed it seems that maybe_push_temp_cleanup and now set_up_extended_ref_temp have the same problem. Since maybe_push_temp_cleanup already uses a flag, we can easily stop setting CLEANUP_EH_ONLY there as well. Since set_up_extended_ref_temp doesn't, working around this issue there will be more involved. PR c++/118856 PR c++/118763 gcc/cp/ChangeLog: * cp-tree.h (TARGET_EXPR_INTERNAL_P): New. * call.cc (extend_temps_r): Check it instead of CLEANUP_EH_ONLY. * tree.cc (get_internal_target_expr): Set it instead. * typeck2.cc (maybe_push_temp_cleanup): Don't set CLEANUP_EH_ONLY. gcc/testsuite/ChangeLog: * g++.dg/ext/stmtexpr29.C: New test.
[Bug c++/118856] [15 Regression] ICE in gimplify_var_or_parm_decl at gimplify.cc:3346 on mesonlsp-4.3.7 since r15-7481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118856 --- Comment #13 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:720c8f685210af9fc9c31810e224751102f1481e commit r15-7591-g720c8f685210af9fc9c31810e224751102f1481e Author: Jason Merrill Date: Sun Feb 16 11:00:36 2025 +0100 c++: extended temps and statement-exprs [PR118763] My last patch for 118856 broke the test for 118763 (which my testing didn't catch, for some reason), because it effectively reverted Jakub's recent fix (r15-7415) for that bug. It seems we need a new flag to indicate internal temporaries. In that patch Jakub wondered if other uses of CLEANUP_EH_ONLY would have the same issue with jumps out of a statement-expr, and indeed it seems that maybe_push_temp_cleanup and now set_up_extended_ref_temp have the same problem. Since maybe_push_temp_cleanup already uses a flag, we can easily stop setting CLEANUP_EH_ONLY there as well. Since set_up_extended_ref_temp doesn't, working around this issue there will be more involved. PR c++/118856 PR c++/118763 gcc/cp/ChangeLog: * cp-tree.h (TARGET_EXPR_INTERNAL_P): New. * call.cc (extend_temps_r): Check it instead of CLEANUP_EH_ONLY. * tree.cc (get_internal_target_expr): Set it instead. * typeck2.cc (maybe_push_temp_cleanup): Don't set CLEANUP_EH_ONLY. gcc/testsuite/ChangeLog: * g++.dg/ext/stmtexpr29.C: New test.
[Bug c++/96364] ICE on valid code in cp_finish_decl with auto return type and double attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96364 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug target/118891] [14/15 regression] gcc 14 fails to build from source on aarch64_be: "error: ‘dynamic_cast’ not permitted with ‘-fno-rtti’"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891 --- Comment #14 from marcus at mc dot pp.se --- Thanks. Running tests now, will get back when the results are in. :-)
[Bug ipa/118907] ICF optimises bit selection differently based on declaration order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118907 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-02-17 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- ICF doesn't try any re-association and the first canonicalizing reassoc is after ICF.
[Bug c++/115695] spurious warning for -Wsign-compare with c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115695 Mamoru TASAKA changed: What|Removed |Added Version|14.1.1 |15.0 --- Comment #3 from Mamoru TASAKA --- Just note that Fedora's gcc (GCC) 15.0.1 20250204 (Red Hat 15.0.1-0) Copyright (C) 2025 Free Software Foundation, Inc (gcc-c++-15.0.1-0.7.fc42.x86_64) still reproduces this issue.
[Bug libstdc++/118908] c++ include defines uintptr_t *sometimes*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908 Richard Biener changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Richard Biener --- I'd say it's a feature, not a bug?
[Bug libstdc++/118908] c++ include defines uintptr_t *sometimes*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118908 --- Comment #4 from Xi Ruoyao --- The standard library has no obligation to make it "predictable" except it must be available with #include .
[Bug c++/96570] Warnings desired for time_t to int coversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96570 --- Comment #13 from Xi Ruoyao --- (In reply to Bernhard M. Wiedemann from comment #12) > @Xi: that is a cast from time_t to int, but I want a warning for conversion > from int to time_t > > And IMHO we don't have to force warnings for explicit casts. Then this is different from comment 0.
[Bug c/118326] time_t conversion warnings wanted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118326 Xi Ruoyao changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||xry111 at gcc dot gnu.org Resolution|DUPLICATE |--- --- Comment #3 from Xi Ruoyao --- The OP wants a warning from int to time_t, not from time_t to int. Thus not a dup.
[Bug c++/114997] [11/12 Only] ICE: unexpected expression ‘static_cast('\"')’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114997 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #5 from Marek Polacek --- Fixed by r13-4807. I don't think we'll backport that.
[Bug ipa/118318] [15 regression] ICE when building firefox-134.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318 --- Comment #11 from Sam James --- I'm not sure what to do next. I can write up instructions for reproducing it manually w/ a full Firefox build, but that doesn't help much. I know I need to identify some training input but FF is itself huge and trains itself on many tests. How do I break this down into something manageable?
[Bug target/118916] AARCH64: rtl-cse2 Option in O3 Level Optimization Ignores "volatile", Causing 'Invalid Instruction Syndrome'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118916
Tomas Chang changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #5 from Tomas Chang ---
(In reply to Andrew Pinski from comment #3)
> str w1, [x2]
> str wzr, [x2], -4
> .L6:
> ldr w1, [x2]
>
> is correct as the gimple code is:
>
> MEM[(volatile unsigned int *)1099193386136B] ={v} 1;
> MEM[(volatile unsigned int *)1099193386136B] ={v} 0;
>
>[local count: 1073741824]:
> _3 ={v} MEM[(volatile unsigned int *)1099193386132B];
>
> That is the load is loading from `the original address - 4`.
>
> If this memory mapped register does NOT support all stores, then you need to
> use inline-asm and NOT volatile.
>
> volatile just talks about the store/loads happening in assembly in the same
> order as written and in the GCC 14.2 case with -O3 they are. But you have
> also a write back or post increment instruction which sets x2 to the next
> address. There is no volatile violation here since the stores/load happen in
> the same. just the memory location does not support all instructions.
Hi Andrew,
Many thanks to your explanation.
I understand this case now.
I also found that the Linux kernel has implemented such code in ASM to make
sure it works in hypervisor mode.
I'll change my code accordingly.
[Bug rtl-optimization/117081] [15 Regression] FAIL: gcc.target/i386/pr91384.c since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081 --- Comment #20 from Hongtao Liu --- > > W/o more usage of callee-saved registers, callee needs to restore them > before exit which is not needed if more caller-saved register are used. W/ https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675714.html the codegen is like foo: .LFB0: .cfi_startproc pushq %r12 .cfi_def_cfa_offset 16 .cfi_offset 12, -16 movq%rsi, %r12 pushq %rbp .cfi_def_cfa_offset 24 .cfi_offset 6, -24 movq%rdi, %rbp pushq %rbx .cfi_def_cfa_offset 32 .cfi_offset 3, -32 movq%rdx, %rbx subq$32, %rsp .cfi_def_cfa_offset 64 leaq16(%rsp), %rcx leaq24(%rsp), %r8 callbar movl%eax, %edx testl %eax, %eax je .L1 vmovsd 16(%rsp), %xmm0 vxorpd %xmm1, %xmm1, %xmm1 vcomisd %xmm1, %xmm0 jbe .L18 vmovsd .LC1(%rip), %xmm1 vcomisd %xmm0, %xmm1 ja .L21 .L18: xorl%edx, %edx .L3: vmovsd 24(%rsp), %xmm0 vxorpd %xmm1, %xmm1, %xmm1 vcomisd %xmm1, %xmm0 jbe .L1 vmovsd .LC1(%rip), %xmm1 vcomisd %xmm0, %xmm1 ja .L22 .L1: addq$32, %rsp .cfi_remember_state .cfi_def_cfa_offset 32 movl%edx, %eax popq%rbx .cfi_def_cfa_offset 24 popq%rbp .cfi_def_cfa_offset 16 popq%r12 .cfi_def_cfa_offset 8 ret .p2align 4,,10 .p2align 3 There're 3 pops, more than best one(2 pops), less than worst one(4 pops), but it looks more reasonable since we do want to keep rsi in callee-saved register to preserve it across call.
[Bug target/118916] AARCH64: rtl-cse2 Option in O3 Level Optimization Ignores "volatile", Causing 'Invalid Instruction Syndrome'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118916 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- .
[Bug target/118916] AARCH64: rtl-cse2 Option in O3 Level Optimization Ignores "volatile", Causing 'Invalid Instruction Syndrome'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118916 --- Comment #2 from Tomas Chang --- (In reply to Andrew Pinski from comment #1) > There is no ignoring volatile here since the exact memory locations are > written. > > Rather you have a memory location which needs to be written using an exact > instruction which has no post increment. > > Thus would mean the definition of __raw_writel is incorrect and you have to > use inline-asm to not get the increment for the address. Hi Andrew, Many thanks to your reply. My question is that the same code runs successfully if it is compiled with GCC 12 using -O3 optimization. -O3 and -O3 -fdisable-rtl-cse2 generates the same code by GCC 12
[Bug tree-optimization/118915] [12/13/14/15 Regression] Miscompile at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915 --- Comment #3 from Andrew Pinski --- I am kinda of shock that smtgcc didn't find this earlier.
[Bug rtl-optimization/117081] [15 Regression] FAIL: gcc.target/i386/pr91384.c since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117081
--- Comment #19 from Hongtao Liu ---
(In reply to H.J. Lu from comment #18)
> (In reply to Haochen Jiang from comment #17)
> >
> > For reproduce, not only on ADL, the fix patch showed regression on all
> > Cascade Lake/Ice Lake/Sapphire Rapids with ~2-4% for 511.povary_r with
> > o2_generic_v3.
>
> Can you extract some testcases to show more PUSH and POP?
The original case was a bit more complicated, so I tried to mimic it by writing
a similar.
extern int bar (double* a, double* b, double* c, double* d, double* e);
extern bool foo2 (double* a, double b);
int
foo (double* a, double* b, double *c)
{
int rr = 0;
double d1;
double d2;
if (bar (a, b, c, &d1, &d2)) --- mostly false;
{
if (d1 > 0.0 && d1 < 100.0)
{
c[0] = a[0] + d1 * b[0];
c[1] = a[1] + d1 * b[1];
c[2] = a[2] + d1 * b[2];
if (foo2 (c, d1))
rr = 1;
}
if (d2 > 0.0 && d2 < 100.0)
{
c[0] = a[0] + d2 * b[0];
c[1] = a[1] + d2 * b[1];
c[2] = a[2] + d2 * b[2];
if (foo2 (c, d2))
rr = 1;
}
}
return rr;
}
Before r15-7400
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rdi, %rbp
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
movq%rdx, %rbx
subq$40, %rsp
.cfi_def_cfa_offset 64
leaq16(%rsp), %rcx
leaq24(%rsp), %r8
movq%rsi, 8(%rsp)
callbar
movl%eax, %edx
testl %eax, %eax
je .L1
vmovsd 16(%rsp), %xmm0
vxorpd %xmm1, %xmm1, %xmm1
movq8(%rsp), %rsi
vcomisd %xmm1, %xmm0
jbe .L18
vmovsd .LC1(%rip), %xmm1
vcomisd %xmm0, %xmm1
ja .L21
.L18:
xorl%edx, %edx
.L3:
vmovsd 24(%rsp), %xmm0
vxorpd %xmm1, %xmm1, %xmm1
vcomisd %xmm1, %xmm0
jbe .L1
vmovsd .LC1(%rip), %xmm1
vcomisd %xmm0, %xmm1
ja .L22
.L1:
addq$40, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
movl%edx, %eax
popq%rbx
.cfi_def_cfa_offset 16
popq%rbp
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
after r15-7400
foo:
.LFB0:
.cfi_startproc
pushq %r13
.cfi_def_cfa_offset 16
.cfi_offset 13, -16
movq%rsi, %r13
pushq %r12
.cfi_def_cfa_offset 24
.cfi_offset 12, -24
movq%rdi, %r12
pushq %rbp
.cfi_def_cfa_offset 32
.cfi_offset 6, -32
movq%rdx, %rbp
pushq %rbx
.cfi_def_cfa_offset 40
.cfi_offset 3, -40
subq$24, %rsp
.cfi_def_cfa_offset 64
movq%rsp, %rcx
leaq8(%rsp), %r8
callbar
movl%eax, %ebx
testl %eax, %eax
je .L1
vmovsd (%rsp), %xmm0
vxorpd %xmm1, %xmm1, %xmm1
vcomisd %xmm1, %xmm0
jbe .L18
vmovsd .LC1(%rip), %xmm1
vcomisd %xmm0, %xmm1
ja .L21
.L18:
xorl%ebx, %ebx
.L3:
vmovsd 8(%rsp), %xmm0
vxorpd %xmm1, %xmm1, %xmm1
vcomisd %xmm1, %xmm0
jbe .L1
vmovsd .LC1(%rip), %xmm1
vcomisd %xmm0, %xmm1
ja .L22
.L1:
addq$24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 40
movl%ebx, %eax
popq%rbx
.cfi_def_cfa_offset 32
popq%rbp
.cfi_def_cfa_offset 24
popq%r12
.cfi_def_cfa_offset 16
popq%r13
.cfi_def_cfa_offset 8
ret
W/o more usage of callee-saved registers, callee needs to restore them before
exit which is not needed if more caller-saved register are used.
[Bug target/118916] AARCH64: rtl-cse2 Option in O3 Level Optimization Ignores "volatile", Causing 'Invalid Instruction Syndrome'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118916 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- There is no ignoring volatile here since the exact memory locations are written. Rather you have a memory location which needs to be written using an exact instruction which has no post increment. Thus would mean the definition of __raw_writel is incorrect and you have to use inline-asm to not get the increment for the address.
[Bug target/118901] RISC-V: bfloat16-complex.c:(.text.startup+0x5f6): undefined reference to `__divbc3' when zfh or zvfh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118901 --- Comment #2 from Jeffrey A. Law --- Should we declare this a duplicate or do you want to keep them separate Andrew?
[Bug target/118916] AARCH64: rtl-cse2 Option in O3 Level Optimization Ignores "volatile", Causing 'Invalid Instruction Syndrome'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118916
--- Comment #3 from Andrew Pinski ---
str w1, [x2]
str wzr, [x2], -4
.L6:
ldr w1, [x2]
is correct as the gimple code is:
MEM[(volatile unsigned int *)1099193386136B] ={v} 1;
MEM[(volatile unsigned int *)1099193386136B] ={v} 0;
[local count: 1073741824]:
_3 ={v} MEM[(volatile unsigned int *)1099193386132B];
That is the load is loading from `the original address - 4`.
If this memory mapped register does NOT support all stores, then you need to
use inline-asm and NOT volatile.
volatile just talks about the store/loads happening in assembly in the same
order as written and in the GCC 14.2 case with -O3 they are. But you have also
a write back or post increment instruction which sets x2 to the next address.
There is no volatile violation here since the stores/load happen in the same.
just the memory location does not support all instructions.
[Bug target/118540] RISC-V: ICE for unsupported target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118540
--- Comment #2 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:17b95cfc310c0b3ef191cd47ceb3b4ee1205e8bf
commit r15-7600-g17b95cfc310c0b3ef191cd47ceb3b4ee1205e8bf
Author: Pan Li
Date: Sat Feb 15 14:33:35 2025 +0800
RISC-V: Fix ICE for target attributes has different xlen size
This patch would like to avoid the ICE when the target attribute
specific the xlen different to the cmd. Aka compile with rv64gc
but target attribute with rv32gcv_zbb. For example as blow:
1 â long foo (long a, long b)
2 â __attribute__((target("arch=rv32gcv_zbb")));
3 â
4 â long foo (long a, long b)
5 â {
6 â return a + (b * 2);
7 â }
when compile with rv64gc -O3, it will have ICE similar as below
during RTL pass: fwprop1
test.c: In function âfooâ:
test.c:10:1: internal compiler error: in add_use, at
rtl-ssa/accesses.cc:1234
10 | }
| ^
0x44d6b9d internal_error(char const*, ...)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/diagnostic-global-context.cc:517
0x44a26a6 fancy_abort(char const*, int, char const*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/diagnostic.cc:1722
0x408fac9 rtl_ssa::function_info::add_use(rtl_ssa::use_info*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/accesses.cc:1234
0x40a5eea
rtl_ssa::function_info::create_reg_use(rtl_ssa::function_info::build_info&,
rtl_ssa::insn_info*, rtl_ssa::resource_info)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/insns.cc:496
0x4456738
rtl_ssa::function_info::add_artificial_accesses(rtl_ssa::function_info::build_info&,
df_ref_flags)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/blocks.cc:900
0x4457297
rtl_ssa::function_info::start_block(rtl_ssa::function_info::build_info&,
rtl_ssa::bb_info*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/blocks.cc:1082
0x4453627
rtl_ssa::function_info::bb_walker::before_dom_children(basic_block_def*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/blocks.cc:118
0x3e9f3fb dom_walker::walk(basic_block_def*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/domwalk.cc:311
0x445806f rtl_ssa::function_info::process_all_blocks()
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/blocks.cc:1298
0x40a22d3 rtl_ssa::function_info::function_info(function*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/functions.cc:51
0x3ec3f80 fwprop_init
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/fwprop.cc:893
0x3ec420d fwprop
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/fwprop.cc:963
0x3ec43ad execute
Consider stage 4, we just report error for the above scenario when
detect the cmd xlen is different to the target attribute during the
target hook TARGET_OPTION_VALID_ATTRIBUTE_P implementation.
PR target/118540
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc
(riscv_target_attr_parser::parse_arch):
Report error when cmd xlen is different with target attribute.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr118540-1.c: New test.
* gcc.target/riscv/rvv/base/pr118540-2.c: New test.
Signed-off-by: Pan Li
[Bug target/118916] AARCH64: rtl-cse2 Option in O3 Level Optimization Ignores "volatile", Causing 'Invalid Instruction Syndrome'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118916 --- Comment #4 from Andrew Pinski --- (In reply to Tomas Chang from comment #2) > > My question is that the same code runs successfully if it is compiled with > GCC 12 using -O3 optimization. Because it just happened to work ...
[Bug ipa/118318] [15 regression] ICE when building firefox-134.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
Summary|ICE when building |[15 regression] ICE when
|firefox-134.0 with PGO and |building firefox-134.0 with
|LTO |PGO and LTO
--- Comment #7 from Sam James ---
(In reply to Jan Hubicka from comment #6)
> Do you know why compatible_p returns false? It looks like mixing IPA and
> function local profiles together..
```
Breakpoint 2.2, profile_count::operator+= (this=0x76e7e888, other=...) at
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/profile-count.h:932
932 gcc_checking_assert (compatible_p (other));
(gdb) p other
$1 = (const profile_count &) @0x7fff72c0: {
static n_bits = 61,
static max_count = 2305843009213693950,
static uninitialized_count = 2305843009213693951,
m_val = 3694,
m_quality = ADJUSTED
}
(gdb) call compatible_p(other)
$3 = false
[...]
Breakpoint 3.10, profile_count::compatible_p (this=0x76e7e888, other=...)
at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/profile-count.h:783
783 || other == zero ())
(gdb) n
787 if (ipa ().nonzero_p ()
(gdb) n
790 if (other.ipa ().nonzero_p ()
(gdb) n
791 && !(ipa () == *this))
(gdb) n
during IPA pass: cp
/var/tmp/portage/www-client/firefox-134.0/work/firefox-134.0/media/ffvpx/libavutil/tx.c:
At top level:
/var/tmp/portage/www-client/firefox-134.0/work/firefox-134.0/media/ffvpx/libavutil/tx.c:939:1:
internal compiler error: in operator+=, at profile-count.h:932
0x56e495aa internal_error(char const*, ...)
```
so your theory is right, I think.
[Bug ipa/118318] [15 regression] ICE when building firefox-134.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318 --- Comment #8 from Sam James --- ``` (gdb) bt #0 profile_count::operator+= (this=0x76e7e888, other=...) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/profile-count.h:932 #1 profile_count::operator+= (this=0x76e7e888, other=...) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/profile-count.h:919 #2 0x56d872bd in adjust_clone_incoming_counts(cgraph_node*, desc_incoming_count_struct*) [clone .isra.0] (desc=0x7fff72b0, node=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:4604 #3 0x557111b0 in update_counts_for_self_gen_clones (orig_node=0x76fc4440, self_gen_clones=...) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:4720 #4 decide_whether_version_node (node=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:6082 #5 0x5776f65f in ipcp_decision_stage (topo=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:6247 #6 ipcp_driver () at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:6422 #7 (anonymous namespace)::pass_ipa_cp::execute (this=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ipa-cp.cc:6495 #8 0x555cd414 in execute_one_pass (pass=pass@entry=0x58963540) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:2659 #9 0x5775cf47 in execute_ipa_pass_list (pass=0x58963540) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:3112 #10 0x56f3bff4 in ipa_passes () at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cgraphunit.cc:2286 #11 symbol_table::compile (this=0x77006000) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cgraphunit.cc:2351 #12 0x57795bc9 in symbol_table::finalize_compilation_unit (this=0x77006000) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cgraphunit.cc:2603 #13 0x5773d7c1 in compile_file () at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:480 #14 0x576e8882 in do_compile () at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:2213 #15 toplev::main (this=this@entry=0x7fffd576, argc=, argv=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:2375 #16 0x576e7aca in main (argc=, argv=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/main.cc:39 (gdb) p debug_tree(orig_node.decl) > QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76fb6b28 arg-types chain chain >>> pointer_to_this > addressable used nothrow static decl_5 QI /var/tmp/portage/www-client/firefox-134.0/work/firefox-134.0/media/ffvpx/libavutil/tx.c:264:13 align:8 warn_if_not_align:0 context initial result ignored VOID /var/tmp/portage/www-client/firefox-134.0/work/firefox-134.0/media/ffvpx/libavutil/tx.c:264:8 align:8 warn_if_not_align:0 context > arguments sizes-gimplified public unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76e889d8 pointer_to_this > used unsigned read DI /var/tmp/portage/www-client/firefox-134.0/work/firefox-134.0/media/ffvpx/libavutil/tx.c:264:36 size unit-size align:64 warn_if_not_align:0 context arg-type chain used read SI /var/tmp/portage/www-client/firefox-134.0/work/firefox-134.0/media/ffvpx/libavutil/tx.c:264:43 size unit-size align:32 warn_if_not_align:0 context arg-type >> struct-function 0x76fa5b60 chain > $17 = void ```
[Bug ipa/118318] [15 regression] ICE when building firefox-134.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318 --- Comment #9 from Sam James --- Ah, nicer output: ``` (gdb) p orig_node->debug() reset_ctx/108 (reset_ctx) Type: function definition analyzed Visibility: semantic_interposition prevailing_def_ironly Aux: @0x58ac1440 References: Referring: Availability: local Profile id: 1901877736 Function flags: count:3694 (adjusted) first_run:42 body local hot Called by: reset_ctx.constprop.3/156 (1478 (adjusted),0.40 per call) ```
[Bug ipa/118318] [15 regression] ICE when building firefox-134.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318 --- Comment #10 from Sam James --- (In reply to Sam James from comment #9) tx.gcda: 0100: 12:FUNCTION ident=1901877736, lineno_checksum=0xb50ca648, cfg_checksum=0x0166fe38 tx.gcda:01a1: 104:COUNTERS arcs 13 counts tx.gcda: 0: 0 18470 14776 14776 11082 0 7388 0 tx.gcda: 8: 18470 18470 18470 18470 18470 tx.gcda:01a7: 0:COUNTERS topn 0 counts tx.gcda:01a9: 16:COUNTERS indirect_call 2 counts tx.gcda: 0: 0 0 tx.gcda:01af: 8:COUNTERS time_profiler 1 counts tx.gcda: 0: 42
[Bug ipa/118318] [15 regression] ICE when building firefox-134.0 with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318 --- Comment #12 from Sam James --- (In reply to Sam James from comment #11) > I'm not sure what to do next. I can write up instructions for reproducing it > manually w/ a full Firefox build, but that doesn't help much. > > I know I need to identify some training input but FF is itself huge and > trains itself on many tests. How do I break this down into something > manageable? Or is that the wrong way to do this? Should I instead just try and artificially construct some caller of these functions in tx.i and hope that works out?
[Bug c/118916] New: AARCH64: rtl-cse2 Option in O3 Level Optimization Ignores "volatile", Causing 'Invalid Instruction Syndrome'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118916
Bug ID: 118916
Summary: AARCH64: rtl-cse2 Option in O3 Level Optimization
Ignores "volatile", Causing 'Invalid Instruction
Syndrome'
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: changyp6 at gmail dot com
Target Milestone: ---
Created attachment 60520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60520&action=edit
rct-cse2 test case
I have a program sets registers in AARCH64 EL2 mode
1 #define RCT_BASE0xFFED08
2 #define RCT_REG(x) (RCT_BASE + (x))
3
4
5 #define REF_CLK_FREQ2400UL
6
7 #define RCT_TIMER2_REG 0xFFED080494
8 #define RCT_TIMER2_CTRL_REG 0xFFED080498
9
10 #define __raw_writel(v, a) (*(volatile unsigned int *)(unsigned
long)(a) = (v))
11 #define __raw_readl(a) (*(volatile unsigned int *)(unsigned
long)(a))
12
13 #define writel(p, v)__raw_writel(v, p)
14 #define readl(p)__raw_readl(p)
15
16 typedef unsigned int u32;
17
18 u32 rct_timer2_tick2ms(u32 s_tck, u32 e_tck)
19 {
20 return (e_tck - s_tck) / (REF_CLK_FREQ / 1000);
21 }
22
23 void rct_timer2_reset_count()
24 {
25 /* reset timer */
26 writel(RCT_TIMER2_CTRL_REG, 0x1);
27 /* enable timer */
28 writel(RCT_TIMER2_CTRL_REG, 0x0);
29 }
30
31 u32 rct_timer2_get_count()
32 {
33 return rct_timer2_tick2ms(0x, readl(RCT_TIMER2_REG));
34 }
35
36 void rct_timer2_dly_ms(u32 dly_tim)
37 {
38 u32 cur_tim;
39
40 rct_timer2_reset_count();
41 while (1) {
42 cur_tim = rct_timer2_get_count();
43 if (cur_tim >= dly_tim)
44 break;
45 }
46 }
When building this program by toolchain from ARM:
https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none-linux-gnu.tar.xz
if using -O2, or -O3 -fdisable-rtl-cse2, program runs OK
if using -O3, program reports 'Invalid Instruction Syndrome'
After debugging, I found that this is caused by 'rtl-cse2' optimization.
Disassembles shows that the 'Invalid Instruction Syndrome' happens on line
'84: b81fc45fstr wzr, [x2], #-4'
this line runs OK in EL1 mode, however, According to ARM Architecture Reference
Manual, ISV bit in ESR_EL2 would be 0 while instruction is performing register
writeback, indicating 'Invalid Instruction Syndrome'
(Refer to:
https://developer.arm.com/documentation/ddi0601/2024-12/AArch64-Registers/ESR-EL2--Exception-Syndrome-Register--EL2-)
-O3 compiled:
0064 :
64: d2809301mov x1, #0x498 // #1176
68: 52800024mov w4, #0x1// #1
6c: f2bda101movkx1, #0xed08, lsl #16
70: 52833e23mov w3, #0x19f1 // #6641
74: f2c01fe1movkx1, #0xff, lsl #32
78: 72a0aec3movkw3, #0x576, lsl #16
7c: aa0103e2mov x2, x1
80: b924str w4, [x1]
84: b81fc45fstr wzr, [x2], #-4
88: b9400041ldr w1, [x2]
8c: 9ba37c21umull x1, w1, w3
90: d369fc21lsr x1, x1, #41
94: 6b01001fcmp w0, w1
98: 5488b.hi88 // b.pmore
9c: d65f03c0ret
Following is compiled with '-O3 -fdisable-rtl-cse2', which runs successfully
0064 :
64: d2809301mov x1, #0x498 // #1176
68: d2809283mov x3, #0x494 // #1172
6c: f2bda101movkx1, #0xed08, lsl #16
70: 52800024mov w4, #0x1// #1
74: f2c01fe1movkx1, #0xff, lsl #32
78: f2bda103movkx3, #0xed08, lsl #16
7c: 52833e22mov w2, #0x19f1 // #6641
80: f2c01fe3movkx3, #0xff, lsl #32
84: 72a0aec2movkw2, #0x576, lsl #16
88: b924str w4, [x1]
8c: b93fstr wzr, [x1]
90: b9400061ldr w1, [x3]
94: 9ba27c21umull x1, w1, w2
98: d369fc21lsr x1, x1, #41
9c: 6b01001fcmp w0, w1
a0: 5488b.hi90 // b.pmore
a4: d65f03c0ret
In my program on line 10, 11, the register address is 'volatile unsigned int
*', which tells compiler NOT TO OPTIMIZE it.
Attached is the test case for this issue.
1. Download ARM toolchain from
https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none-linux-gnu.tar.xz
and extract this toolchain by command `sudo tar Jxvf
arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /usr/loc
[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 #14 from Tamar Christina --- Still being worked on, I'll send v3 of the patch today or tomorrow.
[Bug middle-end/118691] [15 Regression] gcc_r in SPECCPU 2017 miscompare on train dataset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118691 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Tamar Christina --- Fixed by g:589d79e6268b055422a7b6c11cd0a8a4f2531a8c
[Bug tree-optimization/98845] [12/13/14/15 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 23 which are marked as MUST COALESCE.) since r6-528-g465770e43996a132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845 --- Comment #17 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:6b8a8c9fd68c5dabaec5ddbc25efeade44f37a14 commit r15-7602-g6b8a8c9fd68c5dabaec5ddbc25efeade44f37a14 Author: Richard Biener Date: Mon Feb 17 15:53:11 2025 +0100 tree-optimization/98845 - ICE with tail-merging and DCE/DSE disabled The following shows that tail-merging will make dead SSA defs live in paths where it wasn't before, possibly introducing UB or as in this case, uses of abnormals that eventually fail coalescing later. The fix is to register such defs for stmt comparison. PR tree-optimization/98845 * tree-ssa-tail-merge.cc (stmt_local_def): Consider a def with no uses not local. * gcc.dg/pr98845.c: New testcase. * gcc.dg/pr81192.c: Adjust.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 118691, which changed state. Bug 118691 Summary: [15 Regression] gcc_r in SPECCPU 2017 miscompare on train dataset https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118691 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libgomp/118909] OpenMP reduction array is always allocated on stack, cause stack overflow with large array reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118909 --- Comment #2 from Jakub Jelinek --- User error. Either you need to use larger stack if you want to do something like this, or use allocate clause and specify an allocator. The normal way of privatization is on the stack.
[Bug fortran/107659] C procedure with no global scope is seen as global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107659 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Keywords|rejects-valid |needs-stdcheck Status|NEW |WAITING --- Comment #3 from Thomas Koenig --- (In reply to urbanjost from comment #0) > gfortran -c xbug.f90 > xbug.f90:42:27: > >13 |function c_remove(c_path) bind(c,name="remove") result(c_err) > | 2 > .. >42 | call remove(self%key) > | 1 > Error: Global binding name ‘remove’ at (1) is already being used as a > FUNCTION at (2) Hmm... I believe this is code is invalid, and gfortran is right in issuing the error. According to F2023, 19.2, Global identifiers, the binding label "remove" is a global identifier, as is the name of an external procedure which you call (without a prototype or importing it from a module) as call remove(self%key) Also, "The global identifier of an entity shall not be the same as the global identifier of any other entity. Furthermore, a binding label shall not be the same as the global identifier of any other global entity, ignoring differences in case." Comments?
[Bug target/116901] [15 Regression] pr110625_4.c fails on aarch64 since r15-3794-g2c04f175de4f39
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901 --- Comment #2 from Andrew Pinski --- FAIL: gcc.target/aarch64/pr110625_2.c scan-tree-dump vect "reduction latency = 8" FAIL: gcc.target/aarch64/pr110625_4.c scan-tree-dump-not vect "LOOP VECTORIZED"
[Bug c/118542] Split -Wexpansion-to-defined for function vs. object like macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542 Hubert Tong changed: What|Removed |Added CC||hstong at ca dot ibm.com --- Comment #5 from Hubert Tong --- (In reply to Andrew Pinski from comment #4) > https://github.com/llvm/llvm-project/commit/ > b2348f4ced639e7247cf3a0bba900dd3ca855996 The "compilers seem to not have differing behavior in that case" claim made as part of the Clang rationale warning less about the function-like macro case is can be disproved. https://godbolt.org/z/5se6Pe83Y demonstrates, three different behaviours using five extant implementations for the following: #define PLATFORM_HAS_ALPHA 1 #define HAS(X) (defined(PLATFORM_HAS_ ## X) && (PLATFORM_HAS_ ## X)) #define NOT(X) !(X) #if NOT(HAS(ALPHA)) static_assert(false, "Hi"); #endif
[Bug target/118911] [15 Regression] bitfield-bitint-abi-align{8,16}.c fails on aarch64-linux-gnu since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118911 --- Comment #1 from Andrew Pinski --- Created attachment 60519 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60519&action=edit Simplified testcase
[Bug target/118911] [15 Regression] bitfield-bitint-abi-align{8,16}.c fails on aarch64-linux-gnu since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118911 --- Comment #2 from Andrew Pinski --- We are expecting: g1: mov x2, x0 mov x3, 0 and x4, x2, 9223372036854775807 mov w0, w1 and x2, x2, 1 b f1 But currently getting: g1: sbfxx2, x0, 0, 63 mov x3, 0 and x4, x2, 9223372036854775807 mov w0, w1 and x2, x2, 1 b f1 That is the sbfx has NOT been merge into x4 and x2.
[Bug target/118911] [15 Regression] bitfield-bitint-abi-align{8,16}.c fails on aarch64-linux-gnu since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118911
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-02-18
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||pinskia at gcc dot gnu.org
--- Comment #3 from Andrew Pinski ---
>From https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655261.html:
gcc.target/aarch64/bitfield-bitint-abi-align{16,8}.c would need
quite a few updates for the late-combine output. That might be
worth doing, but it seems too complex to do as part of this patch.
[Bug tree-optimization/118805] [15 Regression] wrong code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop -fno-tree-forwprop -fno-tree-fre" on x86_64-linux-gnu since r15-6173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118805 --- Comment #6 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:3768bedf7b5fcdd63a18871ecfce665ae1b8d87e commit r15-7597-g3768bedf7b5fcdd63a18871ecfce665ae1b8d87e Author: Alexandre Oliva Date: Mon Feb 17 23:17:21 2025 -0300 [ifcombine] cope with signbit tests of extended values A compare with zero may be taken as a sign bit test by fold_truth_andor_for_ifcombine, but the operand may be extended from a narrower field. If the operand was narrower, the bitsize will reflect the narrowing conversion, but if it was wider, we'll only know whether the field is sign- or zero-extended from unsignedp, but we won't know whether it needed to be extended, because arg will have changed to the narrower variable when we get to the point in which we can compute the arg width. If it's sign-extended, we're testing the right bit, but if it's zero-extended, there isn't any bit we can test. Instead of punting and leaving the foldable compare to be figured out by another pass, arrange for the sign bit resulting from the widening zero-extension to be taken as zero, so that the modified compare will yield the desired result. While at that, avoid swapping the right-hand compare operands when we've already determined that it was a signbit test: it no use to even try. for gcc/ChangeLog PR tree-optimization/118805 * gimple-fold.cc (fold_truth_andor_for_combine): Detect and cope with zero-extension in signbit tests. Reject swapping right-compare operands if rsignbit. for gcc/testsuite/ChangeLog PR tree-optimization/118805 * gcc.dg/field-merge-26.c: New.
[Bug fortran/58786] module function with passed character array of explicit length causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58786 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||12.4.1, 13.3.1, 14.2.1 Resolution|--- |DUPLICATE Status|NEW |RESOLVED Known to fail||11.5.0, 14.2.0 --- Comment #8 from anlauf at gcc dot gnu.org --- All branches which received backports from the fix for pr84868 seem to be fine. Closing as duplicate. *** This bug has been marked as a duplicate of bug 84868 ***
[Bug fortran/84868] [12/13/14 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||stefan.mauerberger at gmail dot co ||m --- Comment #24 from anlauf at gcc dot gnu.org --- *** Bug 58786 has been marked as a duplicate of this bug. ***
[Bug fortran/58787] ICE (error recovery) in check_proc_interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787 Bug 58787 depends on bug 58786, which changed state. Bug 58786 Summary: module function with passed character array of explicit length causes an ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58786 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/118903] constexpr variables with co_await expression in its initialization expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118903 --- Comment #1 from Andrew Pinski --- Dop you have a full example because the code snipit here definitely is rejected.
[Bug c++/118903] constexpr variables with co_await expression in its initialization expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118903 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-02-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed. Yes looks like GCC ignores constexpr with co_await.
