[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 #3 from Sam James --- I'm seeing this too. ``` Reading symbols from ../src/bootstrap-emacs... (gdb) r Starting program: /var/tmp/portage/app-editors/emacs-31.0./work/emacs/src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval \(setq\ load-prefer-newer\ t\ byte-compile-warnings\ \'all\) --eval \(setq\ org--inhibit-version-check\ t\) -l comp -f batch-byte+native-compile emacs-lisp/loaddefs-gen.el [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib64/libthread_db.so.1". Function(s) ^std::(move|forward|as_const|(__)?addressof) will be skipped when stepping. Function(s) ^std::(shared|unique)_ptr<.*>::(get|operator) will be skipped when stepping. Function(s) ^std::(basic_string|vector|array|deque|(forward_)?list|(unordered_|flat_)?(multi)?(map|set)|span)<.*>::(c?r?(begin|end)|front|back|data|size|empty) will be skipped when stepping. Function(s) ^std::(basic_string|vector|array|deque|span)<.*>::operator.] will be skipped when stepping. Program received signal SIGSEGV, Segmentation fault. 0x725f8007 in gcc::jit::wrapper_finalizer (ptr=0x7fffdc491e70) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/jit/jit-playback.cc:2094 2094 wrapper->finalizer (); (gdb) bt #0 0x725f8007 in gcc::jit::wrapper_finalizer (ptr=0x7fffdc491e70) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/jit/jit-playback.cc:2094 #1 0x72634402 in finalizer::call (this=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ggc-page.cc:333 #2 ggc_handle_finalizers () at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ggc-page.cc:1932 #3 ggc_collect (mode=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/ggc-page.cc:2232 #4 0x72707737 in cgraph_node::finalize_function (decl=0x7fffdc9b7d00, no_collect=no_collect@entry=false) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cgraphunit.cc:508 #5 0x725fed2f in gcc::jit::playback::function::postprocess (this=0x7fffdc675a00) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/jit/jit-playback.cc:2315 #6 0x72606350 in gcc::jit::playback::context::replay (this=0x7fffa2e0) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/jit/jit-playback.cc:3659 #7 0x72e35968 in compile_file () at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:453 #8 0x725aa2e5 in do_compile () at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:2213 #9 toplev::main (this=this@entry=0x7fffa24e, argc=, argv=) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:2373 #10 0x726051c5 in gcc::jit::playback::context::compile (this=this@entry=0x7fffa2e0) at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/jit/jit-playback.cc:2778 #11 0x725e588d in gcc::jit::recording::context::compile_to_file (this=0x5659be20, output_kind=GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY, output_path=0x56ebb040 "/var/tmp/portage/app-editors/emacs-31.0./work/emacs/native-lisp/31.0.50-f88d6d87/loaddefs-gen-e8a3ad9c-3bac3121bsYYK0.eln.tmp") at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/jit/jit-recording.cc:1671 #12 0x725c74ff in gcc_jit_context_compile_to_file (ctxt=0x5659be20, output_kind=GCC_JIT_OUTPUT_KIND_DYNAMIC_LIBRARY, output_path=0x56ebb040 "/var/tmp/portage/app-editors/emacs-31.0./work/emacs/native-lisp/31.0.50-f88d6d87/loaddefs-gen-e8a3ad9c-3bac3121bsYYK0.eln.tmp") at /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/jit/libgccjit.cc:3883 #13 0x557c3c8a in Fcomp__compile_ctxt_to_file0 (filename=0x560e8f24) at /var/tmp/portage/app-editors/emacs-31.0./work/emacs/src/lisp.h:1631 #14 0x557643d7 in eval_sub (form=) at /var/tmp/portage/app-editors/emacs-31.0./work/emacs/src/eval.c:2587 #15 0x55765590 in Fprogn (body=) at /var/tmp/portage/app-editors/emacs-31.0./work/emacs/src/eval.c:439 #16 Flet (args=) at /var/tmp/portage/app-editors/emacs-31.0./work/emacs/src/eval.c:1109 [...] ``` Frustratingly, I can't reproduce it on a more powerful machine to first bisect before poking more. So I'll do it slowly first.
[Bug c++/118513] ICE with modules and structured binding using std::tuple*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:20a4306793e4978dfff13ca669739eb46915d4e4 commit r15-7026-g20a4306793e4978dfff13ca669739eb46915d4e4 Author: Jakub Jelinek Date: Sat Jan 18 21:50:23 2025 +0100 c++: Copy over further 2 flags for !TREE_PUBLIC in copy_linkage [PR118513] The following testcase ICEs in import_export_decl. When cp_finish_decomp handles std::tuple* using structural binding, it calls copy_linkage to copy various VAR_DECL flags from the structured binding base to the individual sb variables. In this case the base variable is in anonymous union, so we call constrain_visibility (..., VISIBILITY_ANON, ...) on it which e.g. clears TREE_PUBLIC etc. (flags which copy_linkage copies) but doesn't copy over DECL_INTERFACE_KNOWN/DECL_NOT_REALLY_EXTERN. When cp_finish_decl calls determine_visibility on the individual sb variables, those have !TREE_PUBLIC since copy_linkage and so nothing tries to determine visibility and nothing sets DECL_INTERFACE_KNOWN and DECL_NOT_REALLY_EXTERN. Now, this isn't a big deal without modules, the individual variables are var_finalized_p and so nothing really cares about missing DECL_INTERFACE_KNOWN. But in the module case the variables are streamed out and in and care about those bits. The following patch is an attempt to copy over also those flags (but I've limited it to the !TREE_PUBLIC case just in case). Other option would be to call it unconditionally, or call constrain_visibility with VISIBILITY_ANON for !TREE_PUBLIC (but are all !TREE_PUBLIC constrained visibility) or do it only in the cp_finish_decomp case after the copy_linkage call there. 2025-01-18 Jakub Jelinek PR c++/118513 * decl2.cc (copy_linkage): If not TREE_PUBLIC, also set DECL_INTERFACE_KNOWN, assert it was set on decl and copy DECL_NOT_REALLY_EXTERN flags. * g++.dg/modules/decomp-3_a.H: New test. * g++.dg/modules/decomp-3_b.C: New test.
[Bug gcov-profile/118442] -fprofile-generate wrongly adds instrumentation after musttail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118442
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment #3 from Andi Kleen ---
Smaller test case:
struct Span {
int test[5];
};
void resolveToBufferSlow(Span *buffer);
__attribute__((noinline)) void resolveToBuffer(Span *buffer)
{
buffer->test[0] = 4;
[[clang::musttail]] return resolveToBufferSlow(buffer);
}
[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 #5 from Sam James --- Created attachment 60204 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60204&action=edit macroexp-2c3e1495-c0b1cf80_libgccjit_repro.c.xz Attached macroexp-2c3e1495-c0b1cf80_libgccjit_repro.c after patching Emacs to unconditionally dump it (it already had a debug path for it). The GC checking bool didn't change anything there. I can't reproduce it manually using this C file yet tho.
[Bug preprocessor/118542] Split -Wexpansion-to-defined for function vs. object like macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542 --- Comment #2 from Giuseppe D'Angelo --- Better testcase, I guess: https://gcc.godbolt.org/z/Yce4qEabM
[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 #4 from Sam James ---
(In reply to David Malcolm from comment #2)
> What does printing *wrapper in the debugger look like?
>
Program received signal SIGSEGV, Segmentation fault.
0x725f8007 in gcc::jit::wrapper_finalizer (ptr=0x7fffdc491e70) at
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/jit/jit-playback.cc:2094
2094 wrapper->finalizer ();
(gdb) p wrapper
$1 = (gcc::jit::playback::wrapper *) 0x7fffdc491e70
(gdb) p *wrapper
$2 = {_vptr.wrapper = 0x0}
[Bug target/116308] [15 Regression] ICE while compiling _Atomic _Float16 for riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116308 --- Comment #3 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:deb3a4ae5dc04616dff893de074de0797594c98e commit r15-7025-gdeb3a4ae5dc04616dff893de074de0797594c98e Author: Jeff Law Date: Sat Jan 18 13:44:33 2025 -0700 [RISC-V][PR target/116308] Fix generation of initial RTL for atomics While this wasn't originally marked as a regression, it almost certainly is given that older versions of GCC would have used libatomic and would not have ICE'd on this code. Basically this is another case where we directly used simplify_gen_subreg when we should have used gen_lowpart. When I fixed a similar bug a while back I noted the code in question as needing another looksie. I think at that time my brain saw the mixed modes (SI & QI) and locked up. But the QI stuff is just the shift count, not some deeper issue. So fixing is trivial. We just replace the simplify_gen_subreg with a gen_lowpart and get on with our lives. Tested on rv64 and rv32 in my tester. Waiting on pre-commit testing for final verdict. PR target/116308 gcc/ * config/riscv/riscv.cc (riscv_lshift_subword): Use gen_lowpart rather than simplify_gen_subreg. gcc/testsuite/ * gcc.target/riscv/pr116308.c: New test.
[Bug target/116308] [15 Regression] ICE while compiling _Atomic _Float16 for riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116308 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.
[Bug gcov-profile/118551] Autofdo regressed 538.imagick_r by ~10% with -march=x86-64-v3 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551 --- Comment #3 from Hongtao Liu --- (In reply to Andrew Pinski from comment #1) > I think this is similar to pr 113646 really. Looks like PR 113646 is PGO not autofdo, so the issue could be different.
[Bug gcov-profile/118551] Autofdo regressed 538.imagick_r by ~10% with -march=x86-64-v3 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551
--- Comment #2 from Hongtao Liu ---
A hack like below can recove performance and further improved 538.imagick_r by
5% w/ autofdo.
The hack prevents the scaling if ipa_count is zero but function body is hot.
diff --git a/gcc/predict.cc b/gcc/predict.cc
index ef31c48bfe2..7d4bf5261ad 100644
--- a/gcc/predict.cc
+++ b/gcc/predict.cc
@@ -4105,40 +4105,51 @@ estimate_bb_frequencies ()
if (freq_max < 16)
freq_max = 16;
profile_count ipa_count = ENTRY_BLOCK_PTR_FOR_FN (cfun)->count.ipa ();
- cfun->cfg->count_max = profile_count::uninitialized ();
- FOR_BB_BETWEEN (bb, ENTRY_BLOCK_PTR_FOR_FN (cfun), NULL, next_bb)
+
+ /* AutoFDO profile is a scaled profile, as a result, 0 sample does not
+ mean never executed. especially there's profile from function
+ body. Prevent combine_with_ipa_count·(ipa_count) from zeroing all
+ bb->count. */
+ if (!(ipa_count.quality () == AFDO
+ && cfun->cfg->count_max.quality () == AFDO
+ && !ipa_count.nonzero_p ()
+ && cfun->cfg->count_max.nonzero_p ()))
{
- sreal tmp = BLOCK_INFO (bb)->frequency;
- if (tmp >= 1)
+ cfun->cfg->count_max = profile_count::uninitialized ();
+ FOR_BB_BETWEEN (bb, ENTRY_BLOCK_PTR_FOR_FN (cfun), NULL, next_bb)
{
- gimple_stmt_iterator gsi;
- tree decl;
-
- /* Self recursive calls can not have frequency greater than 1
-or program will never terminate. This will result in an
-inconsistent bb profile but it is better than greatly confusing
-IPA cost metrics. */
- for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
- if (is_gimple_call (gsi_stmt (gsi))
- && (decl = gimple_call_fndecl (gsi_stmt (gsi))) != NULL
- && recursive_call_p (current_function_decl, decl))
- {
- if (dump_file)
- fprintf (dump_file, "Dropping frequency of recursive call"
- " in bb %i from %f\n", bb->index,
- tmp.to_double ());
- tmp = (sreal)9 / (sreal)10;
- break;
- }
+ sreal tmp = BLOCK_INFO (bb)->frequency;
+ if (tmp >= 1)
+ {
+ gimple_stmt_iterator gsi;
+ tree decl;
+
+ /* Self recursive calls can not have frequency greater than 1
+or program will never terminate. This will result in an
+inconsistent bb profile but it is better than greatly
confusing
+IPA cost metrics. */
+ for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+ if (is_gimple_call (gsi_stmt (gsi))
+ && (decl = gimple_call_fndecl (gsi_stmt (gsi))) != NULL
+ && recursive_call_p (current_function_decl, decl))
+ {
+ if (dump_file)
+ fprintf (dump_file, "Dropping frequency of recursive
call"
+ " in bb %i from %f\n", bb->index,
+ tmp.to_double ());
+ tmp = (sreal)9 / (sreal)10;
+ break;
+ }
+ }
+ tmp = tmp * freq_max;
+ profile_count count = profile_count::from_gcov_type
(tmp.to_nearest_int ());
+
+ /* If we have profile feedback in which this function was never
+executed, then preserve this info. */
+ if (!(bb->count == profile_count::zero ()))
+ bb->count = count.guessed_local ().combine_with_ipa_count
(ipa_count);
+ cfun->cfg->count_max = cfun->cfg->count_max.max (bb->count);
}
- tmp = tmp * freq_max;
- profile_count count = profile_count::from_gcov_type (tmp.to_nearest_int
());
-
- /* If we have profile feedback in which this function was never
-executed, then preserve this info. */
- if (!(bb->count == profile_count::zero ()))
- bb->count = count.guessed_local ().combine_with_ipa_count (ipa_count);
- cfun->cfg->count_max = cfun->cfg->count_max.max (bb->count);
}
[Bug gcov-profile/118551] Autofdo regressed 538.imagick_r by ~10% with -march=x86-64-v3 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113646 --- Comment #1 from Andrew Pinski --- I think this is similar to pr 113646 really.
[Bug gcov-profile/118551] Autofdo regressed 538.imagick_r by ~10% with -march=x86-64-v3 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551 --- Comment #4 from Andrew Pinski --- Try to see if using the ref set helps this case too? It might be train and ref are really that difference.
[Bug tree-optimization/118544] -fopt-info misreports unroll factor when using #pragma GCC unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118544 --- Comment #3 from Tibor Győri --- (In reply to Andrew Pinski from comment #2) > The unroll 2 is correct, it was unrolled one time; likewise 3 is unrolled > twice, etc. I suspect you are missunderstanding what the diagnostic is > saying, it is saying unrolled the loop one extra iteration. OK, I guess that does make sense, but it is unexpected that it does not follow the same "counting convention" as the pragma. In the pragma one requests an unroll factor, while the opt-info messages say how many iterations are unrolled. For what its worth, clang reports the unroll factor in its opt-info messages, which feels like the more natural choice of "counting convention" to me.
[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 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||GC Last reconfirmed||2025-01-18
[Bug rtl-optimization/118544] -fopt-info misreports unroll factor when using #pragma GCC unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118544 Andrew Pinski changed: What|Removed |Added URL|https://godbolt.org/z/x1eb6 | |5jWf| --- Comment #1 from Andrew Pinski --- https://godbolt.org/z/x1eb65jWf
[Bug fortran/81978] Passing component of a parameter array to a subroutine causes SIGBUS crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81978 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #60198|0 |1 is obsolete|| --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 60205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60205&action=edit Revised patch This patch handles slices of PARAMETER arrays as well as component references. Regtests fine.
[Bug c/118542] Split -Wexpansion-to-defined for function vs. object like macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2016-August/454527.html >* it's *always* active for object-like macros (dangerous in portable code); >* it's behind -Weverything / -pedantic for function-like macros (not even >-Wextra). Not at the time GCC added it, clang had it included in -Wall. and GCC decided to have it as -Wextra. Let me find the commits on the clang side to understand why they changed it.
[Bug c/118542] Split -Wexpansion-to-defined for function vs. object like macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/29271, ||https://github.com/llvm/llv ||m-project/issues/70025 --- Comment #4 from Andrew Pinski --- https://github.com/llvm/llvm-project/commit/b2348f4ced639e7247cf3a0bba900dd3ca855996
[Bug tree-optimization/118544] -fopt-info misreports unroll factor when using #pragma GCC unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118544 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Now `#pragma GCC unroll(5)` is just a misreporting of the number of > iterations; it was fully unrolled. A Note on why it is fully unroll even though there are 6 iterations. Since it is unrolled 4 times, there is only one iteration left so that is no longer considered a loop. So it is fully unrolled. that is 5+1 where 1 is leftovers that is needed for the prologue.
[Bug gcov-profile/118442] -fprofile-generate wrongly adds instrumentation after musttail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118442 --- Comment #4 from Andi Kleen --- The problem seems to be that the call BB has an extra fallthrough edge to the basic block containing the return. Perhaps it should just have an EXIT edge or not split the RETURN? (not sure if that is legal in GIMPLE) _Z19resolveToBufferSlowP4SpanD.2864 (buffer_2(D)); [must tail call] ;;succ: 3 [always] count:1073741824 (estimated locally, freq 1.) (FALLTHRU) ;;EXIT [never (guessed)] count:0 (estimated locally, freq 0.) (FAKE) ;; basic block 3, loop depth 0, count 1073741824 (estimated locally, freq 1.), maybe hot ;;prev block 2, next block 1, flags: (NEW) ;;pred: 2 [always] count:1073741824 (estimated locally, freq 1.) (FALLTHRU) # VUSE <.MEM_4> return; ;;succ: EXIT [always] count:1073741824 (estimated locally, freq 1.) (EXECUTABLE) ../../../tsrc/pr118442.cc:10:58 }
[Bug gcov-profile/118551] New: Autofdo regressed 538.imagick_r by ~10% with -march=x86-64-v3 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118551 Bug ID: 118551 Summary: Autofdo regressed 538.imagick_r by ~10% with -march=x86-64-v3 -O2 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: liuhongt at gcc dot gnu.org Target Milestone: --- Similar like PR116743, it's related to ipa scaling, but in different place(estimate_bb_frequencies). /* If we have profile feedback in which this function was never executed, then preserve this info. */ if (!(bb->count == profile_count::zero ())) bb->count = count.guessed_local ().combine_with_ipa_count (ipa_count); ipa_count is the count of the entry block and it's zero, but the whole function is hot. estimate_bb_frequencies scale every non-zero bb count to zero since ipa_count is zero, and GCC optimized those BB for size since it thought the bb is cold. part to gcov_dump from the hot function: MeanShiftImage total:17008941 head:0 2: 0 25: 0 26: 0 29: 0 30: 0 31: 0 32: 0 32.1: 0 34: 0 35: 0 39: 0 40: 0 41: 0 42: 0 47.1: 0 47.2: 0 61: 0 63: 0 64: 1 66: 1 71: 1 GetCacheViewVirtualIndexQueue:1 72.1: 2189 72.2: 2189 85: 2197 GetMagickPixelPacket:2268 87: 2171 88: 2171 89.1: 2171 105: 3788 106: 3788 107: 3811 GetMagickPixelPacket:3931 109: 3788 110: 3788 111: 0 111.1: 72754 111.2: 72754 116: 72731 116.1: 816545 116.2: 816545 118: 138 123: 967682 GetOneCacheViewVirtualPixel:998671
[Bug tree-optimization/118544] -fopt-info misreports unroll factor when using #pragma GCC unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118544 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|tree-optimization --- Comment #2 from Andrew Pinski --- The unroll 2 is correct, it was unrolled one time; likewise 3 is unrolled twice, etc. I suspect you are missunderstanding what the diagnostic is saying, it is saying unrolled the loop one extra iteration. Now `#pragma GCC unroll(5)` is just a misreporting of the number of iterations; it was fully unrolled.
[Bug go/118286] go crypto/tls test fails because of expired certificate? (TestVerifyConnection, bad certificate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118286 --- Comment #4 from Ian Lance Taylor --- If you have the time, please go ahead and do the backports. Thanks.
[Bug c++/118534] [15 Regression] constant evaluation failure with RAW_DATA_CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118534 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:413985b632afb07032d3b32d992029fced187814 commit r15-7014-g413985b632afb07032d3b32d992029fced187814 Author: Jakub Jelinek Date: Sat Jan 18 09:14:27 2025 +0100 c++: Fix up find_array_ctor_elt RAW_DATA_CST handling [PR118534] This is the third bug discovered today with the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673945.html hack but then turned into proper testcases where embed-24.C FAILed since introduction of optimized #embed support and the others when optimizing large C++ initializers using RAW_DATA_CST. find_array_ctor_elt already has RAW_DATA_CST support, but on the following testcases it misses one case I've missed. The CONSTRUCTORs in question went through the braced_list_to_string optimization which can turn INTEGER_CST RAW_DATA_CST INTEGER_CST into just larger RAW_DATA_CST covering even those 2 bytes around it (if they appear there in the underlying RAW_DATA_OWNER). With this optimization, RAW_DATA_CST can be the last CONSTRUCTOR_ELTS elt in a CONSTRUCTOR, either the sole one or say preceeded by some unrelated other elements. Now, if RAW_DATA_CST is the only one or if there are no RAW_DATA_CSTs earlier in CONSTRUCTOR_ELTS, we can trigger a bug in find_array_ctor_elt. It has a smart optimization for the very common case where CONSTRUCTOR_ELTS have indexes and index of the last elt is equal to CONSTRUCTOR_NELTS (ary) - 1, then obviously we know there are no RAW_DATA_CSTs before it and the indexes just go from 0 to nelts-1, so when we care about any of those earlier indexes, we can just return i; and not worry about anything. Except it uses if (i < end) return i; rather than if (i < end - 1) return i; For the latter cases, i.e. anything before the last elt, we know there are no surprises and return i; is right. But for the if (i == end - 1) case, return i; is only correct if the last elt is not RAW_DATA_CST, if it is RAW_DATA_CST, we still need to split it, which is handled by the code later in the function. So, for that we need begin = end - 1, so that the binary search will just care about that last element. 2025-01-18 Jakub Jelinek PR c++/118534 * constexpr.cc (find_array_ctor_elt): Don't return i early if i == end - 1 and the last elt's value is RAW_DATA_CST. * g++.dg/cpp/embed-24.C: New test. * g++.dg/cpp1y/pr118534.C: New test.
[Bug c++/118534] [15 Regression] constant evaluation failure with RAW_DATA_CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118534 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug d/118495] Unable to build gdc (D compiler) for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495 --- Comment #5 from Brecht Sanders --- Yes, it builds find with --with-libphobos-druntime-only
[Bug target/118541] Incorrect transformation to xscmpgtdp for Unordered Operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541 --- Comment #3 from Jeevitha --- (In reply to Florian Weimer from comment #2) > This is about these glibc test suite failures, right? > Yes
[Bug tree-optimization/118466] Not removing bounds checking enough to vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118466 --- Comment #4 from Sam James --- (In reply to Eric Gallager from comment #3) > Removing bounds checking seems like a dangerous idea in general... We do that in plenty of cases. It's provably false here. If anything, optimising bound checks better makes things safer as it means people aren't afraid to add checks knowing the compiler will optimise them out when they are redundant.
[Bug target/118538] throw not caught causing an seg fault rather than a `terminate called after throwing an instance of 'int'` message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538 --- Comment #10 from Sam James --- I can't reproduce either. Let me try 14.2.0.
[Bug middle-end/118537] [14/15 Regression] (20241102 -> 20241128) wrong initialization of member variable on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118537 --- Comment #21 from Sam James --- (In reply to Julian Andres Klode from comment #20) > OK sorry folks, further debugging on that hunch on d15 from the minimized > code led me to build libcrypto without assembler code and now apt works > correctly; so my guess here really is that the hand-written OpenSSL asm code > is wrong, and the gcc change really just makes it use the registers that > they forgot to save and restore. No worries. Can you cross-link the bugs when you file one with OpenSSL? Thanks.
[Bug d/118545] New: d: Not all language options get a url in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118545
Bug ID: 118545
Summary: d: Not all language options get a url in diagnostics
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gcc dot gnu.org
Target Milestone: ---
For example, the following error does not get a URL.
error ("bad argument for %<-fversion%>: %qs", arg);
I think this is because the option in lang.opt.urls is `-fversion=`.
Need to check all error/warning messages to ensure they are properly
referenced.
[Bug target/116308] [15 Regression] ICE while compiling _Atomic _Float16 for riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116308 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|ICE while compiling _Atomic |[15 Regression] ICE while |_Float16 for riscv64|compiling _Atomic _Float16 ||for riscv64 Last reconfirmed||2025-01-18 Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/118538] throw not caught causing an seg fault rather than a `terminate called after throwing an instance of 'int'` message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538 --- Comment #12 from Disservin --- (In reply to Sam James from comment #11) > Can't repro with that either. On which platform are you testing this?
[Bug gcov-profile/116743] [12/13/14/15 regression] Commit r12-5817-g3d9e6767939e96 causes ~10% perf regression w AutoFDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743 Sam James changed: What|Removed |Added Resolution|--- |FIXED Known to fail||12.4.0, 13.3.0, 14.2.0 Known to work||11.5.0, 12.4.1, 13.3.1, ||14.2.1, 15.0 Status|ASSIGNED|RESOLVED --- Comment #30 from Sam James --- All done.
[Bug target/118538] throw not caught causing an seg fault rather than a `terminate called after throwing an instance of 'int'` message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #13 from Sam James --- Neoverse-N1. But the CPU shouldn't matter when -march/-mcpu=XXX isn't passed, with the exception of some very rare issues (like ordering/atomics implementation).
[Bug c++/118509] [14/15 regression] Front-end produced uninitialized memory reference when compiling Nektar since r15-4595-gb25d3201b6338d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509
--- Comment #11 from Jakub Jelinek ---
Renamed/reformatted:
struct A { void foo () { a = 1; } int a = 0; };
struct B : virtual A {};
typedef void (A::*C) ();
__attribute__((noipa))
void foo (C x, B *y)
{
(y->*x) ();
}
int
main ()
{
B b;
foo (&A::foo, &b);
if (b.a != 1)
__builtin_abort ();
}
Note, r15-4595 has been backported to 14 branch in r14-10839, so it also a
regression from 14.2 to 14.3.
[Bug target/118538] throw not caught causing an seg fault rather than a `terminate called after throwing an instance of 'int'` message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538 --- Comment #9 from Disservin --- (In reply to Andrew Pinski from comment #8) > I think you should first report this to ubuntu since I can't reproduce it > with all upstream sources of GCC, glibc. I have opened a bug report here, https://bugs.launchpad.net/ubuntu/+source/gcc-14/+bug/2095206. Not sure if that was the place/package you thought of.
[Bug target/118541] Incorrect transformation to xscmpgtdp for Unordered Operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541 --- Comment #2 from Florian Weimer --- This is about these glibc test suite failures, right? FAIL: math/test-double-acospi FAIL: math/test-float-acospi FAIL: math/test-float32-acospi FAIL: math/test-float32x-acospi FAIL: math/test-float64-acospi I see those with GCC 11.5. The detailed test output looks like this: testing double (without inline functions) Failure: acospi (qNaN): Exception "Invalid operation" set Failure: acospi (-qNaN): Exception "Invalid operation" set Failure: acospi_downward (qNaN): Exception "Invalid operation" set Failure: acospi_downward (-qNaN): Exception "Invalid operation" set Failure: acospi_towardzero (qNaN): Exception "Invalid operation" set Failure: acospi_towardzero (-qNaN): Exception "Invalid operation" set Failure: acospi_upward (qNaN): Exception "Invalid operation" set Failure: acospi_upward (-qNaN): Exception "Invalid operation" set Test suite completed: 4 max error test cases, 444 input tests, - with 1784 tests for exception flags, - with 436 tests for errno executed. 8 errors occurred.
[Bug c++/118509] [14/15 regression] Front-end produced uninitialized memory reference when compiling Nektar since r15-4595-gb25d3201b6338d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Created attachment 60201 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60201&action=edit gcc15-pr118509.patch Untested fix.
[Bug preprocessor/118542] New: Split -Wexpansion-to-defined for function vs. object like macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542 Bug ID: 118542 Summary: Split -Wexpansion-to-defined for function vs. object like macros Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: dangelog at gmail dot com Target Milestone: --- -Wexpansion-to-defined is currently enabled by -Wextra (or -pedantic). While there is implementation divergence when expanding object-like macros (notably, GCC/Clang vs. MSVC without the new preprocessor), there actually isn't when expanding function-like macros. Usages like #define HAS(X) (defined(PLATFORM_HAS_ ## X) && (PLATFORM_HAS ## X)) are pretty common and reasonable (cf PR49928): https://gcc.godbolt.org/z/ajceb67rP For this reason, Clang's -Wexpansion-to-defined has two different severities: * it's *always* active for object-like macros (dangerous in portable code); * it's behind -Weverything / -pedantic for function-like macros (not even -Wextra). Would it be reasonable for GCC to do something along the same lines? (Or, even better, to split the warning, so that one can decide to raise/error on object-like macros, and suppress it for function-like.)
[Bug middle-end/118537] [14/15 Regression] (20241102 -> 20241128) wrong initialization of member variable on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118537 --- Comment #17 from Sam James --- (In reply to Julian Andres Klode from comment #16) I built apt and couldn't reproduce it using this yet with tip of 14 release branch and trunk too.
[Bug preprocessor/118542] Split -Wexpansion-to-defined for function vs. object like macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542 --- Comment #1 from Giuseppe D'Angelo --- Uhm, I think I am wrong about MSVC -- without the new preprocessor enabled, it doesn't seem it likes function-like macros anyhow.
[Bug target/118357] risc-v xtheadvector did not handle the logic of vsetvl properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118357 --- Comment #2 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:b9493e98da58c7689645b4ee1a2f653b86a5d758 commit r15-7021-gb9493e98da58c7689645b4ee1a2f653b86a5d758 Author: Jin Ma Date: Sat Jan 18 07:43:17 2025 -0700 [PR target/118357] RISC-V: Disable fusing vsetvl instructions by VSETVL_VTYPE_CHANGE_ONLY for XTheadVector. In RVV 1.0, the instruction "vsetvlizero,zero,*" indicates that the available vector length (avl) does not change. However, in XTheadVector, this same instruction signifies that the avl should take the maximum value. Consequently, when fusing vsetvl instructions, the optimization labeled "VSETVL_VTYPE_CHANGE_ONLY" is disabled for XTheadVector. PR target/118357 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc: Function change_vtype_only_p always returns false for XTheadVector. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/xtheadvector/pr118357.c: New test.
[Bug d/114434] gdc.test/runnable/test23514.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434
--- Comment #6 from Iain Buclaw ---
@Rainer, I think I've found the cause for discrepancy, a use of size_t vs.
widest integer for pointer offsets.
Can you give this a test?
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -1499,7 +1499,7 @@ public:
void visit (PtrExp *e) final override
{
Type *tnext = NULL;
-size_t offset;
+dinteger_t offset;
tree result;
if (e->e1->op == EXP::add)
@@ -2074,7 +2074,7 @@ public:
void visit (SymOffExp *e) final override
{
/* Build the address and offset of the symbol. */
-size_t soffset = e->isSymOffExp ()->offset;
+dinteger_t soffset = e->isSymOffExp ()->offset;
tree result = get_decl_tree (e->var);
TREE_USED (result) = 1;
[Bug c++/98893] [modules] start_cleanup_cnt needs modularizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98893
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
--- Comment #2 from Nathaniel Shead ---
Here's a small testcase for this issue:
// test.h
struct S {
~S() {}
};
inline void foo() {
static S a[1];
}
// main.cpp
import "f.h";
static S b[1];
int main() {
foo();
}
Attempting to assemble with e.g. 'g++ -fmodules -c test.h main.cpp' gives:
/tmp/ccTPPCTU.s: Assembler messages:
/tmp/ccTPPCTU.s:113: Error: symbol `__tcf_0' is already defined
/tmp/ccTPPCTU.s: Error: .size expression for __tcf_0 does not evaluate to a
constant
[Bug target/118357] risc-v xtheadvector did not handle the logic of vsetvl properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118357 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jeffrey A. Law --- Fixed on the trunk.
[Bug libstdc++/118546] New: std::experimental::simd operator== fails to compile with clang++ 19.1.0 on x86-64-v4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118546
Bug ID: 118546
Summary: std::experimental::simd operator== fails to compile
with clang++ 19.1.0 on x86-64-v4
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lee.imple at gmail dot com
Target Milestone: ---
The following code fails to compile with clang++ 19.1.0 with the compilation
options `-march=x86-64-v4 -std=c++20`. Online link:
https://godbolt.org/z/sxqsKrv9e .
```c++
#include
#include
using deduce_t_element = std::experimental::simd<
std::uint64_t,
std::experimental::simd_abi::deduce_t
>;
auto f(deduce_t_element e) {
return e == 0;
}
```
The error message (copied from godbolt):
```
In file included from :1:
In file included from
/opt/compiler-explorer/gcc-14.2.0/lib/gcc/x86_64-linux-gnu/14.2.0/../../../../include/c++/14.2.0/experimental/simd:80:
/opt/compiler-explorer/gcc-14.2.0/lib/gcc/x86_64-linux-gnu/14.2.0/../../../../include/c++/14.2.0/experimental/bits/simd_x86.h:4232:18:
error: static assertion failed due to requirement 'is_same_v'
4232 | static_assert(is_same_v<_Tp, __int_for_sizeof_t<_Tp>>);
| ^~~
/opt/compiler-explorer/gcc-14.2.0/lib/gcc/x86_64-linux-gnu/14.2.0/../../../../include/c++/14.2.0/experimental/bits/simd_x86.h:2244:26:
note: in instantiation of function template specialization
'std::experimental::_MaskImplX86Mixin::_S_to_bits' requested
here
2244 | return _MaskImpl::_S_to_bits(
| ^
/opt/compiler-explorer/gcc-14.2.0/lib/gcc/x86_64-linux-gnu/14.2.0/../../../../include/c++/14.2.0/experimental/bits/simd.h:5625:40:
note: in instantiation of function template specialization
'std::experimental::_SimdImplX86>::_S_equal_to' requested here
5625 | { return simd::_S_make_mask(_Impl::_S_equal_to(__x._M_data,
__y._M_data)); }
|^
:10:14: note: in instantiation of member function
'std::experimental::operator==' requested here
10 | return e == 0;
| ^
1 error generated.
Compiler returned: 1
```
[Bug c++/118513] ICE with modules and structured binding using std::tuple*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513 --- Comment #6 from Nathaniel Shead --- (In reply to Jason Merrill from comment #5) > (In reply to Nathaniel Shead from comment #4) > > Confirmed. Without having looked into it too much I think maybe doing > > `varpool_node::finalize_decl` might be the way to go to cover this and any > > other related issues that may be cropping up by not having done so? > > Why aren't we calling make_rtl_for_nonlocal_decl for imported decls, anyway? I'm not 100% sure why it wasn't done initially, but I think we probably should; at the very least, split out a version of it that is appropriate for modules without doubling up work that isn't necessary. I've had some quick attempts at this in the past but I've never sat down and properly worked out exactly when it needs to be called for what decls and how etc.
[Bug c++/118543] New: Previous forward declaration of enum causes early instantiation of later definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118543
Bug ID: 118543
Summary: Previous forward declaration of enum causes early
instantiation of later definition
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andre.brand at mailbox dot org
Target Milestone: ---
See here on Compiler-Explorer: https://godbolt.org/z/PshPT968x
template
struct S {
static constexpr T f(int) { return 0; };
// remove the opaque declaration and it will work
enum class E : T;
static constexpr T f(char) { return 1; };
enum class E : T { X = f(T{}) };
};
static_assert((int)S::E::X == 1);
This causes:
static assertion failed
13 | static_assert((int)S::E::X == 1);
| ~~~^~~~
:13:34: note: the comparison reduces to '(0 == 1)'
GCC seems to consider the overload set of f at the first declaration.
This is not the case for static constexpr data members of a nested class.
[Bug middle-end/118537] [14/15 Regression] (20241102 -> 20241128) wrong initialization of member variable on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118537
--- Comment #18 from Julian Andres Klode ---
(In reply to Sam James from comment #17)
> (In reply to Julian Andres Klode from comment #16)
>
> I built apt and couldn't reproduce it using this yet with tip of 14 release
> branch and trunk too.
I need to try building gcc-14 branch itself and see for myself, also if I can
still reproduce it on AWS, then I can bisect it to the commit introducing the
issue.
Meanwhile, my initial attempt at cvise on the full .ii was not fruitful as I
mocked that up using if (Encoding != Closes) exit(42) and cvise helpfully
trimmed it down to Encoding != Closes; exit(42) - that is, it always failed.
I started a second attempt where I split out the offending
BaseHttpMethod::Loop() into its own source file and then cvised that and that
reduced it to:
void BaseHttpMethod::Loop() {
while (1) {
Run();
Server = CreateServerState(URI(Queue->Uri));
Server->Open();
RequestState Req(this, Server.get());
switch (Server->RunHeaders(Req, Queue->Uri));
}
}
When downloading over https (i.e. Server->Open() makes OpenSSL calls), I get
the error, without OpenSSL calls, I do not get the error, so it sounds like
something messes up (register?) state there.
This boils down to:
isb
// 0 "" 2
// basehttp-loop.cc:12: time(&Date);
#NO_APP
ldr x0, [sp, 16]//, %sfp
// basehttp-loop.cc:11: : Server() {
str d15, [sp, 48] // tmp332, MEM [(void
*)&Req]
// basehttp-loop.cc:12: time(&Date);
bl time//
// basehttp-loop.cc:13: assert(Encoding == Closes);
ldr w0, [sp, 48]//, Req.Encoding
cmp w0, 1 // Req.Encoding,
bne .L56//,
// /usr/include/aarch64-linux-gnu/bits/stdio2.h:118: return __printf_chk
(__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ());
adrpx1, .LC3// tmp267,
mov w0, 2 //,
add x1, x1, :lo12:.LC3 //, tmp267,
bl __printf_chk//
.LEHE3:
// basehttp-loop.cc:41: __asm__("isb");
#APP
// 41 "basehttp-loop.cc" 1
isb
Now per ARM, `D part of V8-V15 need to be saved`, but the only other mention of
`d15` is
ldr d15, [x0, #:lo12:.LC4] // tmp332,
earlier in the function way before we call any of the other functions.
The question I'm not sure is D part of V15 caller-saved or callee-saved?
[Bug rtl-optimization/118544] New: -fopt-info misreports unroll factor when using #pragma GCC unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118544 Bug ID: 118544 Summary: -fopt-info misreports unroll factor when using #pragma GCC unroll Product: gcc Version: 15.0 URL: https://godbolt.org/z/x1eb65jWf Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tiborgyri at gmail dot com CC: tiborgyri at gmail dot com Target Milestone: --- Created attachment 60202 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60202&action=edit Test case -Wall -Wextra -Ofast -std=c++20 -march=znver3 -gno-as-loc-support Partially unrolling a loop with #pragma GCC unroll results in an "optimization passed" message that misreports the unroll factor. For example #pragma GCC unroll(2) results in this message "loop unrolled 1 times". This is misleading since GCC has correctly unrolled the loop by a factor of 2, as requested by the user. The number reported in the opt-info message is consistently 1 lower than the requested (and actual) unroll factor. Another manifestation of this, is when the requested unroll factor is 1 lower than the loop iteration count. For example, if a loop has 6 iterations, #pragma GCC unroll(5) results in the following message: "loop with 5 iterations completely unrolled" This is confusing, given that the the loop has 6 iterations, not 5. The only time this opt-info message is correct, is when the requested unroll factor is >= the total number of iterations, in which case GCC correctly reports that the loop was completely unrolled. I imagine that some other pass that does not emit opt-info messages unrolls 1 iteration, hence the confusing messages. See: https://godbolt.org/z/x1eb65jWf
[Bug middle-end/118537] [14/15 Regression] (20241102 -> 20241128) wrong initialization of member variable on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118537 --- Comment #19 from Sam James --- (In reply to Julian Andres Klode from comment #18) > Meanwhile, my initial attempt at cvise on the full .ii was not fruitful as I > mocked that up using if (Encoding != Closes) exit(42) and cvise helpfully > trimmed it down to Encoding != Closes; exit(42) - that is, it always failed. > You want your cvise script to test with gcc-14 ... -fno-tree-slp-vectorize and make sure that *doesn't* exit 42 as well.
[Bug tree-optimization/118529] [15 regression] ICE when building openssl-3.3.2 on sparc (in operator[], at vec.h:910)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118529 --- Comment #8 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c81543b3379fa11742d2178b87edbf1e72799d61 commit r15-7020-gc81543b3379fa11742d2178b87edbf1e72799d61 Author: Richard Biener Date: Fri Jan 17 15:41:19 2025 +0100 tree-optimization/118529 - ICE with condition vectorization On sparc we end up choosing vector(8) for the condition but vector(2) int for the value of a COND_EXPR but we fail to verify their shapes match and thus things go downhill. This is a missed-optimization on the pattern recognition side as well as unhandled vector decomposition in vectorizable_condition. The following plugs just the observed ICE for now. PR tree-optimization/118529 * tree-vect-stmts.cc (vectorizable_condition): Check the shape of the vector and condition vector type are compatible. * gcc.target/sparc/pr118529.c: New testcase.
[Bug tree-optimization/118529] [15 regression] ICE when building openssl-3.3.2 on sparc (in operator[], at vec.h:910)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118529 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Biener --- Should be fixed.
[Bug target/118538] throw not caught causing an seg fault rather than a `terminate called after throwing an instance of 'int'` message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538 Sam James changed: What|Removed |Added CC||doko at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2025-01-18 --- Comment #11 from Sam James --- Can't repro with that either.
[Bug middle-end/118537] [14/15 Regression] (20241102 -> 20241128) wrong initialization of member variable on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118537 --- Comment #20 from Julian Andres Klode --- OK sorry folks, further debugging on that hunch on d15 from the minimized code led me to build libcrypto without assembler code and now apt works correctly; so my guess here really is that the hand-written OpenSSL asm code is wrong, and the gcc change really just makes it use the registers that they forgot to save and restore.
[Bug go/118286] go crypto/tls test fails because of expired certificate? (TestVerifyConnection, bad certificate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118286 --- Comment #3 from Sam James --- Ian, would you mind backporting to 12/13/14 (or I can)?
[Bug middle-end/118537] [14/15 Regression] (20241102 -> 20241128) wrong initialization of member variable on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118537 Julian Andres Klode changed: What|Removed |Added See Also||https://github.com/openssl/ ||openssl/issues/26466 --- Comment #22 from Julian Andres Klode --- (In reply to Sam James from comment #21) > (In reply to Julian Andres Klode from comment #20) > > OK sorry folks, further debugging on that hunch on d15 from the minimized > > code led me to build libcrypto without assembler code and now apt works > > correctly; so my guess here really is that the hand-written OpenSSL asm code > > is wrong, and the gcc change really just makes it use the registers that > > they forgot to save and restore. > > No worries. Can you cross-link the bugs when you file one with OpenSSL? > Thanks.
[Bug middle-end/118549] -funreachable-traps doesn't transform trivial unreachable into trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118549 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Andrew Pinski --- Confirmed. It works for the added __builtin_unreachable if following through for C++ though.
[Bug middle-end/118549] -funreachable-traps doesn't transform trivial unreachable into trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118549 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-01-18 --- Comment #2 from Andrew Pinski --- .
[Bug tree-optimization/118550] Missed optimization for fusing two byte loads with offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118550 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |RESOLVED Component|rtl-optimization|tree-optimization Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 98953 ***
[Bug middle-end/118549] -funreachable-traps doesn't transform trivial unreachable into trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118549 --- Comment #3 from Sam James --- (In reply to Andrew Pinski from comment #1) > Confirmed. It works for the added __builtin_unreachable if following through > for C++ though. I can't get it to fail for C++ either? (https://godbolt.org/z/cnnKWYrrs)
[Bug tree-optimization/98953] Failure to optimize two reads from adjacent addresses into one due to having an offset (index)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98953 Andrew Pinski changed: What|Removed |Added CC||arseny.kapoulkine at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 118550 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/118550] Missed optimization for fusing two byte loads with offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118550
--- Comment #2 from Andrew Pinski ---
Simple workaround:
```
unsigned short readle(const unsigned char* data, TYPE offset)
{
const unsigned char *t = &data[offset];
unsigned char b0 = t[0], b1 = t[1];
return b0 | (b1 << 8);
}
```
[Bug middle-end/118549] -funreachable-traps doesn't transform trivial unreachable into trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118549 --- Comment #4 from Andrew Pinski --- (In reply to Sam James from comment #3) > (In reply to Andrew Pinski from comment #1) > > Confirmed. It works for the added __builtin_unreachable if following through > > for C++ though. > > I can't get it to fail for C++ either? (https://godbolt.org/z/cnnKWYrrs) You missed understood, I was talking about following through to the end of the function with a return type of non-void. e.g. https://godbolt.org/z/d7zqPeP4x
[Bug testsuite/118547] New: gcc.c-torture/compile/pr106433.c and others fail on aarch64 with an older binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118547 Bug ID: 118547 Summary: gcc.c-torture/compile/pr106433.c and others fail on aarch64 with an older binutils Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64 ``` Executing on host: /home/pinskia/src/upstream/gcc/objdir/gcc/xgcc -B/home/pinskia/src/upstream/gcc/objdir/gcc/-fdiagnostics-plain-output -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -w -c -o pr106433.o /home/pinskia/src/upstream/gcc/gcc/testsuite/gcc.c-torture/compile/pr106433.c (timeout = 300) spawn -ignore SIGHUP /home/pinskia/src/upstream/gcc/objdir/gcc/xgcc -B/home/pinskia/src/upstream/gcc/objdir/gcc/ -fdiagnostics-plain-output -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -w -c -o pr106433.o /home/pinskia/src/upstream/gcc/gcc/testsuite/gcc.c-torture/compile/pr106433.c /tmp/cc5dTiAq.s: Assembler messages: /tmp/cc5dTiAq.s:32: Error: unknown pseudo-op: `.variant_pcs' /tmp/cc5dTiAq.s:116: Error: unknown pseudo-op: `.variant_pcs' /tmp/cc5dTiAq.s:209: Error: unknown pseudo-op: `.variant_pcs' /tmp/cc5dTiAq.s:286: Error: unknown pseudo-op: `.variant_pcs' compiler exited with status 1 FAIL: gcc.c-torture/compile/pr106433.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) Excess errors: /tmp/cc5dTiAq.s:32: Error: unknown pseudo-op: `.variant_pcs' /tmp/cc5dTiAq.s:116: Error: unknown pseudo-op: `.variant_pcs' /tmp/cc5dTiAq.s:209: Error: unknown pseudo-op: `.variant_pcs' /tmp/cc5dTiAq.s:286: Error: unknown pseudo-op: `.variant_pcs' ``` as version: ``` pinskia@cfarm117:~/src/upstream$ as --version GNU assembler (GNU Binutils for Debian) 2.28 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `aarch64-linux-gnu'. ``` List of the ones that fail this way: gcc.c-torture/compile/pr97576.c gcc.dg/gomp/pr89246-2.c gcc.dg/vect/pr59984.c gcc.dg/vect/slp-simd-clone-*.c gcc.dg/vect/pr93069.c gcc.dg/vect/pr62021.c gcc.dg/vect/pr64421.c gcc.dg/vect/vect-simd-clone-*.c
[Bug target/118512] [15 regression] Bootstrap failure on SPARC with -O3 -mcpu=niagara4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512 --- Comment #10 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:d309844d6fe02e695eb82cbd30fd135e836f24eb commit r15-7023-gd309844d6fe02e695eb82cbd30fd135e836f24eb Author: Eric Botcazou Date: Sat Jan 18 18:58:02 2025 +0100 Fix bootstrap failure on SPARC with -O3 -mcpu=niagara4 This is a regression present on the mainline only, but the underlying issue has been latent for years: the compiler and the assembler disagree on the support of the VIS 3B SIMD ISA, the former bundling it with VIS 3 but not the latter. IMO the documentation is not very clear, so this patch just aligns the compiler with the assembler. gcc/ PR target/118512 * config/sparc/sparc-c.cc (sparc_target_macros): Deal with VIS 3B. * config/sparc/sparc.cc (dump_target_flag_bits): Likewise. (sparc_option_override): Likewise. (sparc_vis_init_builtins): Likewise. * config/sparc/sparc.md (fpcmp_vis): Replace TARGET_VIS3 with TARGET_VIS3B. (vec_cmp): Likewise. (fpcmpu_vis): Likewise. (vec_cmpu): Likewise. (vcond_mask_): Likewise. * config/sparc/sparc.opt (VIS3B): New target mask. * doc/invoke.texi (SPARC options): Document -mvis3b. gcc/testsuite/ * gcc.target/sparc/20230328-1.c: Pass -mvis3b instead of -mvis3. * gcc.target/sparc/20230328-4.c: Likewise. * gcc.target/sparc/fucmp.c: Likewise. * gcc.target/sparc/vis3misc.c: Likewise.
[Bug target/118512] [15 regression] Bootstrap failure on SPARC with -O3 -mcpu=niagara4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Eric Botcazou --- This should be fixed.
[Bug testsuite/118548] New: gcc.target/aarch64/acle/rwsr-2.c fails with older glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118548 Bug ID: 118548 Summary: gcc.target/aarch64/acle/rwsr-2.c fails with older glibc Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64 ``` FAIL: gcc.target/aarch64/acle/rwsr-2.c (test for errors, line 12) FAIL: gcc.target/aarch64/acle/rwsr-2.c (test for errors, line 13) FAIL: gcc.target/aarch64/acle/rwsr-2.c (test for errors, line 20) FAIL: gcc.target/aarch64/acle/rwsr-2.c (test for errors, line 21) FAIL: gcc.target/aarch64/acle/rwsr-2.c (test for errors, line 22) FAIL: gcc.target/aarch64/acle/rwsr-2.c (test for errors, line 23) FAIL: gcc.target/aarch64/acle/rwsr-2.c (test for errors, line 24) FAIL: gcc.target/aarch64/acle/rwsr-2.c (test for excess errors) Excess errors: /home/pinskia/src/upstream/gcc/gcc/testsuite/gcc.target/aarch64/acle/rwsr-2.c:12:3: error: unknown type name '__uint64_t'; did you mean 'uint64_t'? /home/pinskia/src/upstream/gcc/gcc/testsuite/gcc.target/aarch64/acle/rwsr-2.c:19:3: error: unknown type name '__uint64_t'; did you mean 'uint64_t'? ``` I am not sure why the testcase uses __uint64_t .
[Bug testsuite/118548] gcc.target/aarch64/acle/rwsr-2.c fails with older glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118548 --- Comment #1 from Andrew Pinski --- gcc.target/aarch64/acle/rwsr.c fails too.
[Bug rtl-optimization/118550] New: Missed optimization for fusing two byte loads with offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118550
Bug ID: 118550
Summary: Missed optimization for fusing two byte loads with
offsets
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arseny.kapoulkine at gmail dot com
Target Milestone: ---
When presented with the following code:
uint16_t readle(const unsigned char* data, TYPE offset)
{
uint8_t b0 = data[offset], b1 = data[offset + 1];
return b0 | (b1 << 8);
}
gcc always generates inefficient code when targeting x64 that loads two bytes
separately regardless of the type of offset (int, size_t, ptrdiff_t).
For example, with int offset, gcc trunk generates:
movsx rsi, esi
movzx eax, BYTE PTR [rdi+1+rsi]
movzx edx, BYTE PTR [rdi+rsi]
sal eax, 8
or eax, edx
clang generates efficient code that just has a single 2-byte load for all types
of offset except for "unsigned int" where it needs to handle overflow. This
includes size_t (where overflow is well defined, but presumably offset can
never be SIZE_MAX because that would result in a pointer overflow?). For int
offset, clang generates:
movsxd rax, esi
movzx eax, word ptr [rdi + rax]
See https://gcc.godbolt.org/z/6fcnedqPM for a full comparison of different
types
[Bug middle-end/118549] -funreachable-traps doesn't transform user provided unreachable into trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118549 --- Comment #5 from Sam James --- Oh! Yeah, that case works.
[Bug c++/118543] Previous forward declaration of enum causes early instantiation of later definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118543 --- Comment #2 from Andrew Pinski --- I suspect this code is IFNDR because a non-template form is invalid . And GCC produces: :14:25: error: 'static constexpr T S::f(char)' called in a constant expression before its definition is complete
[Bug c++/118543] Previous forward declaration of enum causes early instantiation of later definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118543 --- Comment #3 from Andrew Pinski --- Created attachment 60203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60203&action=edit Full testcase
[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to anlauf from comment #7) > This has just been implemented on 15-trunk as r15-6887-g20b8500cfa522e . > > Please try it out! We have a lot of the frontend features yet to implement so feedback welcome.
[Bug target/118512] [15 regression] Bootstrap failure on SPARC with -O3 -mcpu=niagara4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512 --- Comment #12 from Sam James --- Cheers Eric.
[Bug c/118549] New: -funreachable-traps doesn't transform trivial unreachable into trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118549
Bug ID: 118549
Summary: -funreachable-traps doesn't transform trivial
unreachable into trap
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
I was looking into a project getting a conversion to C23 unreachable wrong and
stumbled upon this.
```
[[gnu::noipa]]
void x(int x) {
if (x == 1)
__builtin_unreachable();
__builtin_printf("got x=%d\n", x);
}
int main() {
x(1);
x(2);
x(1);
}
```
`-funreachable-traps` is enabled for -O0 and -Og, but we don't ever trap here.
-fsanitize=undefined works, though.
[Bug middle-end/118537] [14/15 Regression] (20241102 -> 20241128) wrong initialization of member variable on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118537 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #23 from Andrew Pinski --- https://github.com/openssl/openssl/pull/23233 looks like fixed it.
[Bug c++/118543] Previous forward declaration of enum causes early instantiation of later definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118543 Andrew Pinski changed: What|Removed |Added URL|https://godbolt.org/z/PshPT | |968x| --- Comment #1 from Andrew Pinski --- https://godbolt.org/z/PshPT968x
[Bug c++/118543] Previous forward declaration of enum causes early instantiation of later definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118543
--- Comment #4 from Andrew Pinski ---
There are defect reports in this area too.
I can also get an ICE with:
```
template
struct S {
enum class E : T;
enum E0 : T;
static constexpr T f(int) { return 0; };
static constexpr T f(char) { return 1; };
};
template
enum class S::E : T { X = S::f(T{}) };
template
enum S::E0 : T { X2 = S::f(T{}) };
typedef S S0;
static_assert((int)S0::E::X == 1);
static_assert((int)S0::X2 == 1);
```
[Bug c++/57342] [C++11] Warning for narrowing conversion has ugly formatting for floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57342
--- Comment #5 from Peter Damianov ---
This still happens on current gcc 15 trunk.
This also applies in to instances like:
```
struct s {};
void f (s) {}
void foo() {
f(2.0f);
};
```
Which results in:
: In function 'void foo()':
:5:7: error: could not convert '2.0e+0f' from 'float' to 's'
5 | f(2.0f);
| ^~~~
| |
| float
https://gcc.godbolt.org/z/6bxajbrhW
