[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2025-07-14
Status|UNCONFIRMED |NEW
--- Comment #3 from Richard Biener ---
(In reply to Robin Dapp from comment #2)
> Those zve32 tests often do single-element vectorization.
>
> In zve32f-1.c we don't vectorize
>
> void
> foo1 (int16_t *__restrict f, int32_t *__restrict d, int n)
> {
> for (int i = 0; i < n; ++i)
> {
> f[i * 2 + 0] = 1;
> f[i * 2 + 1] = 2;
> d[i] = 3;
> }
> }
>
> any more due to
>
> if (known_le (TYPE_VECTOR_SUBPARTS (stmt_vectype), 1U))
> return opt_result::failure_at (STMT_VINFO_STMT (stmt_info),
> "not vectorized: unsupported "
> "data-type in %G",
> STMT_VINFO_STMT (stmt_info));
>
> where we give up on the single-element store (but the load has two elements).
>
> Without having had a closer look, would we not only want to fail when all
> statements have known_le (..., 1U) rather than just one?
I guess yes, this then depends on "partial vectorization" being done via
having vector(1) for all stmts not vectorizable. Note there isn't a
convenient place to assess this when only doing SLP. But I'll think
of one. Note there is the opposite testsuite coverage to verify we
are not vectorizing a loop with only vector(1) types.
[Bug tree-optimization/121067] [16 Regression] wrong code at -Os with "-fno-tree-pre -fno-code-hoisting -fno-tree-dominator-opts -fno-tree-fre" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121067 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > a = _6; > slsr_18 = d_14 * 2; > _8 = _6 - slsr_18; And that introduces an overflow ... > > > From: > _5 = (int) e_12; > _6 = _5 + d_14; > a = _6; > _7 = (int) e_12; > _8 = _7 - d_14;
[Bug middle-end/120614] 525.x264_r is ~30% slower with AutoFDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614 --- Comment #18 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614 > > --- Comment #16 from kugan at gcc dot gnu.org --- > I ran spec2017 again with recent gcc and SPE based autofdo (with local patches > to enable SPE based profiling support for autofdo tools). I am seeing > following > compared PGO: > > 621.wrf_s -23% > 549.fotonik3d_r -21% > 525.x264_r -17% > 644.nab_s -14% > 603.bwaves_s -13% > 625.x264_s -12% > 623.xalancbmk_s -12% > 600.perlbench_s -11% > 500.perlbench_r -10% LNT tester reports the following regressions: SPEC/SPEC2017/FP/521.wrf_r 110.97% SPEC/SPEC2017/FP/538.imagick_r 67.70% SPEC/SPEC2017/FP/554.roms_r 15.77% SPEC/SPEC2017/FP/503.bwaves_r 12.67% SPEC/SPEC2017/INT/523.xalancbmk_r 11.29% SPEC/SPEC2017/INT/548.exchange2_r 10.72% SPEC/SPEC2017/FP/508.namd_r 8.78% SPEC/SPEC2017/INT/531.deepsjeng_r 7.26% SPEC/SPEC2017/INT/541.leela_r 6.54% SPEC/SPEC2017/FP/519.lbm_r 5.72% SPEC/SPEC2017/FP/549.fotonik3d_r3.37% SPEC/SPEC2017/INT/525.x264_r3.09% SPEC/SPEC2017/FP/510.parest_r 2.97% SPEC/SPEC2017/FP/527.cam4_r 2.23% SPEC/SPEC2017/INT/505.mcf_r 2.22% In our setup wrf training is broken and does nothing without failing the verification (which is odd). As a result profile is almost empty and everything is optimized for size. I wonder if that is true for you as well? You can do gcov_dump and see if you get any reasobly large numbers. I am quite puzzled by this issue but did not have time to debug it yet. imagemagick has broken train dataset in spec (it does not train the hot loop which disables vectorization). I hacked runspec so I can use -train_with=refrun and them imagemagick actually runs faster with autofdo than without. So i think it is non-issue. (with this hack autofdo now seems overall win for SPECfp modulo wrf) Roms regresses due to disabled vectorization due to header BB having very low count. This is caused by vectorizer not doing very good job on updating debu gstatement but also triggers problem in create_gcov not consumming dwarf correctly. LLVM has 3-layer discriminators that can record multiplicity, so vectorization can keep iterations count accurate. I think it is useful feature we should implement as well. https://lists.llvm.org/pipermail/llvm-dev/2020-November/146694.html fotonik was quite random for us, so we hacked the config file to train every binary 8 times which reduced noise in profile obtained. Here is history of runs https://lnt.opensuse.org/db_default/v4/SPEC/graph?highlight_run=69309&plot.0=1370.527.0&plot.1=1288.527.0 and one can see that the randomness went away. Some of regressions goes away for me with -fprofile-partial-training since IPA code is still havind some issues with AFDO 0 not actually being 0. In particular if funcction has only 0 samples in it, it will get 0 AFDO profile with local profile preserved. If later function with non-zero AFDO profile is inlined to it, it wil get 0 AFDO profile and end up optimized for size. I did not look into other regressions yet. I think it would be interesting to unerstand leela, deepsjent and xalancbnk since they are quite C++ heavy. povray, omnetpp, perlbench, gcc sees out of noise improvmeents in our setup. It would be interesting why perlbench regresses for you https://lnt.opensuse.org/db_default/v4/SPEC/graph?highlight_run=69309&plot.0=1370.327.0&plot.1=1288.327.0 https://lnt.opensuse.org/db_default/v4/SPEC/69309?compare_to=69261
[Bug tree-optimization/121067] [16 Regression] wrong code at -Os with "-fno-tree-pre -fno-code-hoisting -fno-tree-dominator-opts -fno-tree-fre" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121067 --- Comment #2 from Andrew Pinski --- a = _6; slsr_18 = d_14 * 2; _8 = _6 - slsr_18; From: _5 = (int) e_12; _6 = _5 + d_14; a = _6; _7 = (int) e_12; _8 = _7 - d_14;
[Bug c/121064] Loongarch: FFmpeg build fail when enable autovectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121064 --- Comment #2 from Xi Ruoyao --- I tried to reproduce the issue by mimicking what the test does, but I get: ffmpeg version N-120255-g35a6de137a Copyright (c) 2000-2025 the FFmpeg developers built with gcc 14.3.0 (GCC) 20250523 (AOSC OS, Core) configuration: libavutil 60. 4.101 / 60. 4.101 libavcodec 62. 6.100 / 62. 6.100 libavformat62. 1.103 / 62. 1.103 libavdevice62. 0.100 / 62. 0.100 libavfilter11. 1.101 / 11. 1.101 libswscale 9. 0.100 / 9. 0.100 libswresample 6. 0.100 / 6. 0.100 Input #0, ape, from 'luckynight-mac388-c4000.ape': Duration: 00:01:00.48, start: 0.00, bitrate: 43 kb/s Stream #0:0: Audio: ape (APE / 0x20455041), 44100 Hz, stereo, s16p Stream mapping: Stream #0:0 -> #0:0 (ape (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help Output #0, crc, to 'pipe:': Metadata: encoder : Lavf62.1.103 Stream #0:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s Metadata: encoder : Lavc62.6.100 pcm_s16le CRC=0x5d08c17e The outputted CRC value is same as the reference value in tests/fate/monkeysaudio.mak. Thus please elaborate more about how to reproduce the issue.
[Bug tree-optimization/120980] Vectorizer (early exit) introduces out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #12 from Krister Walfridsson ---
> For now, I think a workable solution is to set a limit on how far
> out-of-bounds an access may be, and to allow fully out-of-bounds loads
> within that range (as long as they are on the same page as the last byte of
> the object). And maybe only when loading using a vector type? [...]
This did not work.
I started by enabling this only for vector types, but that failed because the
store-merging pass transforms element-wise copying of bytes like:
_101 = BIT_FIELD_REF [(char *)in_12], 8, 56>;
MEM[(char *)out_14 + 7B] = _101;
_98 = BIT_FIELD_REF [(char *)in_12], 8, 48>;
MEM[(char *)out_14 + 6B] = _98;
...
_61 = BIT_FIELD_REF [(char *)in_12], 8, 0>;
*out_14 = _61;
into a single copy using unsigned long:
_60 = MEM [(char *)in_12];
MEM [(char *)out_14] = _60;
So we must handle out-of-bounds accesses for all types, not just vectors. But
doing that gives me many new failures due to aliasing issues.
A simple example of the problem can be seen by compiling the following function
for x86_64 with -O3 -fno-strict-aliasing:
char c;
int foo(int *p)
{
c = 0;
int retval = *p;
c = 1;
return retval;
}
The problem is that the dead store elimination pass removes c=0, but the store
is not dead if out-of-bounds loads are allowed, because the function could be
called as foo(&c).
[Bug target/113236] WebP benchmark is 20% slower vs. Clang on AMD Zen 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113236 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- Looks like the same is true on aarch64: https://www.phoronix.com/review/snapdragon-x1-gcc-clang/2
[Bug fortran/121060] ICE when argument is associate name created from type-bound operator result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121060 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- associate(laplacian_phi => laplacian (phi)) works as expected. For some reason, matching_typebound_op is failing to find the specific procedure; ie. 'laplacian'. Paul
[Bug middle-end/121065] [16 regression] ice in optab_for_tree_code, at optabs-tree.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121065 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-07-14 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689456.html
[Bug middle-end/121065] [16 regression] ice in optab_for_tree_code, at optabs-tree.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121065 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Target||Arm
[Bug tree-optimization/121059] [15/16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r15-5383-g8f68d9cb7897df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059 Richard Biener changed: What|Removed |Added Summary|[15 regression] ICE when|[15/16 regression] ICE when |building|building |imagemagick-7.1.1-47|imagemagick-7.1.1-47 |(vect_get_loop_mask, at |(vect_get_loop_mask, at |tree-vect-loop.cc:10960)|tree-vect-loop.cc:10960) |since |since |r15-5383-g8f68d9cb7897df|r15-5383-g8f68d9cb7897df Known to work|16.0| --- Comment #15 from Richard Biener --- Fix was reverted.
[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324 --- Comment #10 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689515.html
[Bug tree-optimization/119920] Missed vectorization for conditioned adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920 --- Comment #10 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689515.html
[Bug target/121062] integer registers of vector constant load shouldn't go through memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121062 --- Comment #4 from Uroš Bizjak --- Created attachment 61864 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61864&action=edit Actually tested version v3
[Bug tree-optimization/121035] [15/16 Regression] ICE on valid code at -O{2,3} with "-fno-tree-dce -fno-tree-dse -fno-expensive-optimizations -fno-ssa-phiopt" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121035 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P2 Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- I will have a look.
[Bug tree-optimization/121037] [16 Regression] 4-6% slowdown of 482.sphinx3 since r16-2088-ge9079e4f43d135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121037 --- Comment #1 from Richard Biener --- Might be enough of a change to identify the problematic loop. I'll queue, but don't hesitate to beat me to it ;)
[Bug target/120908] *tls_(local|global)_dynamic_64_ has an implicit RDI clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120908 --- Comment #8 from GCC Commits --- The releases/gcc-15 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:fcc6ce1a4934a45bfd4e8e21e118d3f1046d3d85 commit r15-9967-gfcc6ce1a4934a45bfd4e8e21e118d3f1046d3d85 Author: H.J. Lu Date: Thu Jul 3 10:54:39 2025 +0800 x86-64: Add RDI clobber to 64-bit dynamic TLS patterns *tls_global_dynamic_64_largepic, *tls_local_dynamic_64_ and *tls_local_dynamic_base_64_largepic use RDI as the __tls_get_addr argument. Add RDI clobber to these patterns to show it. gcc/ PR target/120908 * config/i386/i386.cc (legitimize_tls_address): Pass RDI to gen_tls_local_dynamic_64. * config/i386/i386.md (*tls_global_dynamic_64_largepic): Add RDI clobber and use it to generate LEA. (*tls_local_dynamic_64_): Likewise. (*tls_local_dynamic_base_64_largepic): Likewise. (@tls_local_dynamic_64_): Add a clobber. gcc/testsuite/ PR target/120908 * gcc.target/i386/pr120908.c: New test. Signed-off-by: H.J. Lu (cherry picked from commit d8d5e2a8031e74f08f61ccdd727476f97940c5a6)
[Bug target/120908] *tls_(local|global)_dynamic_64_ has an implicit RDI clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120908 --- Comment #7 from GCC Commits --- The releases/gcc-15 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:3f6e48cdb1969dc718d702d045cc4d349f53f239 commit r15-9966-g3f6e48cdb1969dc718d702d045cc4d349f53f239 Author: H.J. Lu Date: Tue Jul 1 17:17:06 2025 +0800 x86-64: Add RDI clobber to tls_global_dynamic_64 patterns *tls_global_dynamic_64_ uses RDI as the __tls_get_addr argument. Add RDI clobber to tls_global_dynamic_64 patterns to show it. PR target/120908 * config/i386/i386.cc (legitimize_tls_address): Pass RDI to gen_tls_global_dynamic_64. * config/i386/i386.md (*tls_global_dynamic_64_): Add RDI clobber and use it to generate LEA. (@tls_global_dynamic_64_): Add a clobber. Signed-off-by: H.J. Lu (cherry picked from commit 7710d513a552f1fa1b7485ec6b318bafaa6d4cd7)
[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048 Richard Biener changed: What|Removed |Added Target||riscv Target Milestone|--- |16.0 Keywords||testsuite-fail Component|tree-optimization |target Version|unknown |16.0 --- Comment #1 from Richard Biener --- This wasn't really expected - on the aarch64 side there was fallout with using the VF in costing in the scalar side. So, it needs to be investigated why this happens, I suspect a similar reason on the costing side in the backend.
[Bug ipa/120987] [13/14/15/16 regression] gdb build with lto triggers use after free since r12-5541-g2cadaa1f134bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 --- Comment #26 from Tom de Vries --- Eventually, a-test-2.c.121t.retslot has: ... [count: 0]: : _3 = MEM[(struct __shared_count *)&file_exception + 8B]._M_pi; if (_3 != 0B) ... and then the following a-test-2.c.122t.fre3 introduces the wrong code: ... [count: 0]: : if (_15 != 0B) ... where _15 is the initial nonnull value of file_exception.message._M_refcount._M_pi, and we need the actual value as updated by throw_exception, which is null.
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4 since r16-2088-ge9079e4f43d135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #12 from Richard Biener --- I will look at this at some point but will prioritize the issues also affecting GCC 15 first.
[Bug c++/121055] [15/16 Regression] __is_invocable built-in doesn't match std::invoke for rvalue-ref qualified member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121055 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.2
[Bug tree-optimization/121059] [15/16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|16.0|15.2 Priority|P3 |P2 --- Comment #7 from Richard Biener --- I will have a look somewhen later this week.
[Bug ada/121056] Assertion failure on object notation applied to access value with -gnatX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2025-07-14 Summary|Assertion failure triggered |Assertion failure on object |by access-type dispatch in |notation applied to access |Implementation Extension|value with -gnatX |mode| Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Target Milestone|--- |16.0 --- Comment #2 from Eric Botcazou --- You should be using 15.x at this point, 16.0 is too experimental.
[Bug ada/121056] Assertion failure on object notation applied to access value with -gnatX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/95702] ranges::transform missing vectorization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95702 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2021-07-22 00:00:00 |2025-7-14 CC||pinskia at gcc dot gnu.org
[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #18 from H.J. Lu ---
(In reply to Filip Kastl from comment #17)
> This is the replacement that causes the slowdown (well, two replacements):
>
> --
> Replace:
>
> (insn 2224 2228 20 (set (reg:V4DF 1604)
> (vec_duplicate:V4DF (mem/u/c:DF (symbol_ref/u:DI ("*.LC3") [flags
> 0x2]) [0 S8 A64]))) 9260 {vec_dupv4df}
> (expr_list:REG_EQUAL (const_vector:V4DF [
> (const_double:DF
> 2.7776235801354687282582744956016540527344e-2
> [0x0.e38e38e38e38ep-5]) repeated x4
> ])
> (nil)))
>
> with:
>
> (insn 2224 2228 20 (set (reg:V4DF 1604)
> (reg:V4DF 1655)) 2428 {movv4df_internal}
> (expr_list:REG_EQUAL (const_vector:V4DF [
> (const_double:DF
> 2.7776235801354687282582744956016540527344e-2
> [0x0.e38e38e38e38ep-5]) repeated x4
> ])
> (nil)))
>
> deferring rescan insn with uid = 2224.
>
> Replace:
>
> (insn 2228 2224 377 20 (set (reg:V2DF 1603)
> (vec_duplicate:V2DF (mem/u/c:DF (symbol_ref/u:DI ("*.LC3") [flags
> 0x2]) [0 S8 A64]))) 7168 {vec_dupv2df}
> (expr_list:REG_EQUAL (const_vector:V2DF [
> (const_double:DF
> 2.7776235801354687282582744956016540527344e-2
> [0x0.e38e38e38e38ep-5]) repeated x2
> ])
> (nil)))
>
> with:
>
> (insn 2228 2224 377 20 (set (reg:V2DF 1603)
> (subreg:V2DF (reg:V4DF 1655) 0)) 2429 {movv2df_internal}
> (expr_list:REG_EQUAL (const_vector:V2DF [
> (const_double:DF
> 2.7776235801354687282582744956016540527344e-2
> [0x0.e38e38e38e38ep-5]) repeated x2
> ])
> (nil)))
>
> deferring rescan insn with uid = 2228.
> --
>
> These instructions are inside function "main". Though, the last RTL debug
> instruction is
>
> (debug_insn 272 271 273 19 (debug_marker) "lbm.c":275:2 discrim 1 -1
> (nil))
>
> so I expect that function "LBM_performStreamCollideTRT" was inlined into
> main and is the original source of these vector instructions.
>
> Hopefully this helps. If you meant something else by "testcase", do tell me.
>
>
> What I did in more detail:
>
> I used a custom debug counter. If I set the 9-th call of
> ix86_broadcast_inner() to return null (I adapted what hjl's patch does), I
> get rid of the slowdown.
>
> On r16-1644-gaba3b9d3a48a07 I added the debug counter and did:
>
> /home/fkastl/gcc/inst/bin/gcc -std=gnu99 -m64 -c -o lbm.o -DSPEC -DNDEBUG
> -DSPEC_AUTO_SUPPRESS_OPENMP -Ofast -march=native -mtune=native -g -flto=32
> -fpermissive -std=gnu17 -DSPEC_LP64 lbm.c
> -fdbg-cnt=foo_counter:10-10
> /home/fkastl/gcc/inst/bin/gcc -std=gnu99 -m64 -c -o main.o -DSPEC -DNDEBUG
> -DSPEC_AUTO_SUPPRESS_OPENMP -Ofast -march=native -mtune=native -g -flto=32
> -fpermissive -std=gnu17 -DSPEC_LP64 main.c
> -fdbg-cnt=foo_counter:10-10
>
> /home/fkastl/gcc/inst/bin/gcc -std=gnu99 -m64
> -Wl,-rpath,/home/fkastl/gcc/inst/lib64 -Ofast -march=native -mtune=native
> -g -flto=32 -fpermissive -std=gnu17 lbm.o main.o -lm -o
> lbm_r -fdbg-cnt=foo_counter:9-9 -fdump-rtl-all
>
> -> 3m43s
>
> /home/fkastl/gcc/inst/bin/gcc -std=gnu99 -m64
> -Wl,-rpath,/home/fkastl/gcc/inst/lib64 -Ofast -march=native -mtune=native
> -g -flto=32 -fpermissive -std=gnu17 lbm.o main.o -lm -o
> lbm_r -fdbg-cnt=foo_counter:10-10 -fdump-rtl-all
>
> -> 2m50s
>
> Then I compared the *.rrvl rtl dumps. Btw I had to "backport" the
>
> Replace:
> ...
> with:
>
> and
>
> Add:
> ...
>
> dumping from a newer commit.
Please extract something I can use it to reproduce.
[Bug tree-optimization/121020] [16 regression] genrecog miscompiled since r16-1624-g6deab186535a5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020 --- Comment #9 from Sam James --- (In reply to Sam James from comment #8) FWIW, I've checked that this reproduces it in a Debian stable container too (i.e. there's nothing special that the stage1 gcc-trunk/g++-trunk that CC/CXX should point to must be configured with).
[Bug c++/120955] [15/16 Regression] 50 % increase in data segment size on avr-gcc for -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955 --- Comment #10 from fiesh at zefix dot tv --- Naturally, but it doesn't go away: avr-size on all individual object files: textdata bss dec hex filename 88 0 0 88 58 /b_os_nolto/subprojects/avr/libarduinocore-main-mduinoplus.a.p/cores_industrialshields_main.cpp.o textdata bss dec hex filename 0 0 0 0 0 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_CDC.cpp.o textdata bss dec hex filename 372 0 0 372 174 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_wiring_pulse.c.o textdata bss dec hex filename 714 0 0 714 2ca /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_HardwareSerial.cpp.o textdata bss dec hex filename 8 0 0 8 8 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_abi.cpp.o textdata bss dec hex filename 1002 16 01018 3fa /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_WInterrupts.c.o textdata bss dec hex filename 2 0 0 2 2 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_hooks.c.o textdata bss dec hex filename 802 0 0 802 322 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_wiring_digital.c.o textdata bss dec hex filename 254 0 0 254 fe /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_wiring_shift.c.o textdata bss dec hex filename 588 1 0 589 24d /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_wiring_analog.c.o textdata bss dec hex filename 278 0 157 435 1b3 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_HardwareSerial0.cpp.o textdata bss dec hex filename 1833 0 01833 729 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_Print.cpp.o textdata bss dec hex filename 420 0 0 420 1a4 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_IPAddress.cpp.o textdata bss dec hex filename 278 0 157 435 1b3 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_HardwareSerial1.cpp.o textdata bss dec hex filename 0 0 0 0 0 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_HardwareSerial2.cpp.o textdata bss dec hex filename 544 0 9 553 229 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_wiring.c.o textdata bss dec hex filename 0 0 0 0 0 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_HardwareSerial3.cpp.o textdata bss dec hex filename 456 0 0 456 1c8 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_IndustrialShields.cpp.o textdata bss dec hex filename 80 0 1 81 51 /b_os_nolto/subprojects/avr/libarduinocore-mduinoplus.a.p/cores_industrialshields_Watchdog.cpp.o textdata bss dec hex filename 758 0 159 917 395 /b_os_nolto/subprojects/avr/libraries/RS485/libarduinocore-rs485-mduinoplus.a.p/src_RS485.cpp.o textdata bss dec hex filename 272 0 5 277 115 /b_os_nolto/subprojects/avr/libraries/SPI/libarduinocore-spi-mduinoplus.a.p/src_SPI.cpp.o textdata bss dec hex filename 32 0 0 32 20 /b_os_nolto/subprojects/avr/libraries/Utils/libarduinocore-utils-mduinoplus.a.p/src_BCD.cpp.o textdata bss dec hex filename 2048 0 1162164 874 /b_os_nolto/subprojects/avr/libraries/Wire/libarduinocore-wire-mduinoplus.a.p/src_utility_twi.c.o textdata bss dec hex filename 892 0 86 978 3d2 /b_os_nolto/subprojects/avr/libraries/Wire/libarduinocore-wire-mduinoplus.a.p/src_Wire.cpp.o textdata bss dec hex filename 1468 0 431511 5e7 /b_os_nolto/subprojects/avr/libraries/Ethernet2/libarduinocore-ethernet2-mduinoplus.a.p/src_Ethernet2.cpp.o textdata bss dec hex filename 589 0 6 595 253 /b_os_nolto/subprojects/avr/libraries/Ethernet2/li
[Bug target/121064] Loongarch: FFmpeg test failure when enable autovectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121064 Xi Ruoyao changed: What|Removed |Added Attachment #61863|0 |1 is obsolete|| --- Comment #8 from Xi Ruoyao --- Created attachment 61868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61868&action=edit draft patch Attempt to fix an ICE building libgfortran with the previous draft.
[Bug target/121064] Loongarch: FFmpeg test failure when enable autovectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121064 --- Comment #9 from jiawei --- Thanks for your help, if there any plan to merge it into the trunk?
[Bug target/121064] Loongarch: FFmpeg test failure when enable autovectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121064 --- Comment #10 from Xi Ruoyao --- (In reply to jiawei from comment #9) > Thanks for your help, if there any plan to merge it into the trunk? I'll submit it to gcc-patches for review if it passes regression test.
[Bug rtl-optimization/106553] pre-register allocation scheduler is not RMW aware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106553 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-07-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||pinskia at gcc dot gnu.org Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- For GCC 15, -O2/-Os disables the pre-RA scheduler for aarch64. So maybe this is the way forward for -O3+ and figure out how to resolve the -O3 regressions.
[Bug middle-end/120935] [15/16 Regression] ICE building libstdc++ for mmix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120935 Hans-Peter Nilsson changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/119430] profiledbootstrap fails on armv7a-unknown-linux-gnueabhif (crashes in elists__append_elmt during stagefeedback)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430 --- Comment #21 from Sam James --- Indeed works too.
[Bug c++/63164] unnecessary calls to __dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164 --- Comment #10 from Thomas de Bock --- After some searching and testing, I realise this optimization does in fact malfunction from (at least version 17.0.1) clang when used with dlopen and RTLD_LOCAL, though the optimization can be disabled with -fno-assume-unique-vtables. I think at least the possiblity to make use of this optimization should also be present in gcc. I think a good way to go about this would be with the addition of an "assume-unique-vtables" (or similar) compiler flag, enabling the optimization. Curious to hear if this would be an acceptable compromise, in which case I'd be more than happy to submit a PR for it.
[Bug target/120999] Assembler warning about MOVPRFX generation for NBSL instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120999 --- Comment #3 from GCC Commits --- The releases/gcc-15 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:944ecdf085219453e91831100e0bbf1c76f44f46 commit r15-9975-g944ecdf085219453e91831100e0bbf1c76f44f46 Author: Kyrylo Tkachov Date: Wed Jul 9 10:04:01 2025 -0700 aarch64: PR target/120999: Adjust operands for movprfx alternative of NBSL implementation of NOR While the SVE2 NBSL instruction accepts MOVPRFX to add more flexibility due to its tied operands, the destination of the movprfx cannot be also a source operand. But the offending pattern in aarch64-sve2.md tries to do exactly that for the "=?&w,w,w" alternative and gas warns for the attached testcase. This patch adjusts that alternative to avoid taking operand 0 as an input in the NBSL again. So for the testcase in the patch we now generate: nor_z: movprfx z0, z1 nbslz0.d, z0.d, z2.d, z1.d ret instead of the previous: nor_z: movprfx z0, z1 nbslz0.d, z0.d, z2.d, z0.d ret which generated a gas warning. Bootstrapped and tested on aarch64-none-linux-gnu. Signed-off-by: Kyrylo Tkachov gcc/ PR target/120999 * config/aarch64/aarch64-sve2.md (*aarch64_sve2_nor): Adjust movprfx alternative. gcc/testsuite/ PR target/120999 * gcc.target/aarch64/sve2/pr120999.c: New test. (cherry picked from commit b7bd72ce71df5266e7a7039da318e49862389a72)
[Bug tree-optimization/121059] [15 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r15-5383-g8f68d9cb7897df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059
--- Comment #14 from rguenther at suse dot de ---
On Mon, 14 Jul 2025, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059
>
> --- Comment #10 from Richard Sandiford ---
> (In reply to Richard Biener from comment #9)
> > vectorizable_operation during transform does
> >
> > /* When combining two masks check if either of them is elsewhere
> > combined with a loop mask, if that's the case we can mark that
> > the
> > new combined mask doesn't need to be combined with a loop mask.
> > */
> > if (masked_loop_p
> > && code == BIT_AND_EXPR
> > && VECTOR_BOOLEAN_TYPE_P (vectype))
> > {
> > if (loop_vinfo->scalar_cond_masked_set.contains ({ op0, 1 }))
> > {
> > mask = vect_get_loop_mask (loop_vinfo, gsi, masks,
> > vec_num, vectype, i);
> >
> > but that's not reflected by analysis, which misses to record a loop mask
> > for !mask_out_inactive operations. So the fix is as simple as the
> > following,
> > but this might put us to using masks? There is no good way to do this
> > I guess. The scalar_cond_masked_set optimization does not have a
> > corresponding
> > len operation. I'm not sure what we can do here?
> >
> > diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> > index 4aa69da2218..55002bd0cc2 100644
> > --- a/gcc/tree-vect-stmts.cc
> > +++ b/gcc/tree-vect-stmts.cc
> > @@ -6978,6 +6978,16 @@ vectorizable_operation (vec_info *vinfo,
> > LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) = false;
> > }
> > }
> > + else if (loop_vinfo
> > + && LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
> > + && code == BIT_AND_EXPR
> > + && VECTOR_BOOLEAN_TYPE_P (vectype))
> > + vect_record_loop_mask (loop_vinfo, masks, vec_num, vectype, NULL);
> >
> >/* Put types on constant and invariant SLP children. */
> >if (!vect_maybe_update_slp_op_vectype (slp_op0, vectype)
> Yeah, we shouldn't do that. The question is why op0 is in
> scalar_cond_masked_set with masked_loop_p true if there's no associated loop
> mask.
Possibly because with AVX512 the "sharing" of masks doesn't work the
same way as for SVE? I have meanwhile pushed the above with added
&& !masks.is_empty (). But with your remark I'm not sure that's
the correct fix. See how vect_get_loop_mask distinguishes
LOOP_VINFO_PARTIAL_VECTORS_STYLE between
vect_partial_vectors_while_ult and vect_partial_vectors_avx512.
For the testcase I get vector(8):1 as mask but the mask operands are
vector(16):1
[Bug c++/121069] in tsubst_pack_expansion, at cp/pt.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121069
--- Comment #1 from Andrew Pinski ---
/* internal compiler error: Check code */
int main() {
auto func = [](auto... args) constexpr {
return (([](Ts arg) {
return arg;
}(args)),...);
};
func(2, 6, 7);
}
Arise same issue:
:6:25: internal compiler error: in tsubst_pack_expansion, at
cp/pt.cc:14039
4 | return (([](Ts arg) {
|~~
5 | return arg;
| ~~~
6 | }(args)),...);
| ^
0x287a025 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289bd06 internal_error(char const*, ...)
???:0
0xaf4a22 fancy_abort(char const*, int, char const*)
???:0
0xd7993d instantiate_decl(tree_node*, bool, bool)
???:0
0xc01e23 maybe_instantiate_decl(tree_node*)
???:0
0xc03b97 mark_used(tree_node*, int)
???:0
0xb31163 build_op_call(tree_node*, vec**, int)
???:0
0xda442e finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xd21723 c_parse_file()
???:0
0xe8b9d9 c_common_parse_file()
???:0
[Bug c++/88982] ICE in tsubst_pack_expansion, at cp/pt.c:12221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88982 --- Comment #5 from Andrew Pinski --- (In reply to MARIO RODRIGUEZ BEJAR from comment #4) > /* internal compiler error: Check code */ This is definitely a different issue.
[Bug c++/121069] in tsubst_pack_expansion, at cp/pt.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121069 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109017 --- Comment #2 from Andrew Pinski --- Most likely a dup of bug 109017.
[Bug c++/121068] New: Placement new of array element is rejected at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
Bug ID: 121068
Summary: Placement new of array element is rejected at
compile-time
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tkaminsk at gcc dot gnu.org
Target Milestone: ---
For the following code:
```
consteval int
foo()
{
using T = int;
union { T arr[3]; };
new(arr) T[3];
for (int i = 0; i < 3; ++i)
arr[i].~T();
new (arr + 2) T{10}; // A
return 1;
};
constexpr int g = foo();
```
https://godbolt.org/z/4bdPbqqvz
Placement new at line A is rejected with following error:
:19:22: in 'constexpr' expansion of 'foo()'
:14:23: error: accessing uninitialized member 'foo()arr'
14 | new (arr + 2) T{10};
| ^
:9:15: note: initializing 'foo()arr' requires a
member access expression as the left operand of the assignment
9 | union { T arr[3]; };
| ^~~
Compiler returned: 1
[Bug c++/63164] unnecessary calls to __dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164 --- Comment #12 from Jakub Jelinek --- I'd think it should just optimize __dynamic_cast to std::type_info::operator== in that case (if that is available) or, if not (i.e. not included) to if (__name == __arg.__name) return true; return __name[0] != '*' && __builtin_strcmp (__name, __arg.__name) == 0; or so.
[Bug sanitizer/121070] bounds sanitizer should instrument arrays inside a structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121070 --- Comment #4 from qinzhao at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) > Or with -fstrict-flex-arrays . Ah, you are right, I forgot about this.. adding -fstrict-flex-arrays fixed this issue.
[Bug tree-optimization/121059] [15 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r15-5383-g8f68d9cb7897df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059 Richard Biener changed: What|Removed |Added Known to work||16.0 Summary|[15/16 regression] ICE when |[15 regression] ICE when |building|building |imagemagick-7.1.1-47|imagemagick-7.1.1-47 |(vect_get_loop_mask, at |(vect_get_loop_mask, at |tree-vect-loop.cc:10960)|tree-vect-loop.cc:10960) |since |since |r15-5383-g8f68d9cb7897df|r15-5383-g8f68d9cb7897df --- Comment #13 from Richard Biener --- Should be fixed on trunk.
[Bug tree-optimization/121059] [15/16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r15-5383-g8f68d9cb7897df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059 --- Comment #12 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:66346b6d800fc4baae876e0fe4e932401bcc85fa commit r16-2236-g66346b6d800fc4baae876e0fe4e932401bcc85fa Author: Richard Biener Date: Mon Jul 14 14:09:28 2025 +0200 tree-optimization/121059 - record loop mask when required For loop masking we need to mask a mask AND operation with the loop mask. The following makes sure we have a corresponding mask available. There's no good way to distinguish loop masking from len masking here, so assume we have recorded a mask for the operands mask producers. PR tree-optimization/121059 * tree-vect-stmts.cc (vectorizable_operation): Record a loop mask for mask AND operations. * gcc.dg/vect/pr121059.c: New testcase.
[Bug c++/63164] unnecessary calls to __dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #11 from Andi Kleen --- There is already -fno-semantic-interposition Also -flto / -fwhole-program should probably enable it.
[Bug target/121064] Loongarch: FFmpeg build fail when enable autovectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121064 Xi Ruoyao changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED --- Comment #4 from Xi Ruoyao --- Alright, I forgot AOSC GCC is configured to use -march=loongarch64 (no vectors) by default. With --extra-cflags=-march=la64v1.0: CRC=0x0504ab23 and that is wrong.
[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #9 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #3) > There are a series of patches involved here. > > The first failure occurs at: > > commit 1be1970f97d05a07851cd826132fcf466827ebe5 > Author: Andre Vehreschild > Date: Fri Mar 14 14:20:18 2025 +0100 > > Fortran: Unify handling of STAT= and ERRMSG= optional arguments [PR87939] > > The failure is: > > Start 23: sync_team > 23/88 Test #23: sync_team > .***Failed Required regular > expression not found. Regex=[Test passed. > ] 0.47 sec > > After the following patch, the tests hang ... > On the first failure identified using current trunk to build OpenCoarrays, the sync_team test segfaults. $ /home/jerry/dev/opencoarrays-clean/bin/caf sync-team.f90 $ /home/jerry/dev/opencoarrays-clean/bin/cafrun -np 8 ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. (backtrace not shown)
[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #10 from Jerry DeLisle --- Andre has sent a fixer patch for these. Building now and will test.
[Bug rtl-optimization/117922] [15/16/16 Regression] fold-mem-offsets pass is slow and memory hungry because UD/UD chain usage and the RD df problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922 Sam James changed: What|Removed |Added Keywords|deferred|patch --- Comment #27 from Sam James --- This came up on IRC with someone hitting the -Wdisabled-optimization note, so as an update: patch is at https://inbox.sourceware.org/gcc-patches/20250626133844.1426923-1-christoph.muell...@vrull.eu/.
[Bug tree-optimization/121049] [16 regression] timezone-data miscompiled with -O3 -march=x86-64-v4 -mtune=znver4 since r16-1729-ga0af6fd825d533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121049 Sam James changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120927 Summary|[16 regression] |[16 regression] |timezone-data miscompiled |timezone-data miscompiled |with -O3 -march=x86-64-v4 |with -O3 -march=x86-64-v4 |-mtune=znver4 since |-mtune=znver4 since |r16-2088-ge9079e4f43d135|r16-1729-ga0af6fd825d533 --- Comment #13 from Sam James --- (In reply to rguent...@suse.de from comment #11) > Probably related to PR120927 then. Thanks for the hint. Indeed that lets me bisect it back to r16-1729-ga0af6fd825d533 (w/ --param vect-partial-vector-usage=1 -O3 -march=x86-64-v4 -mtune=znver4). I fear that is not too helpful either though.
[Bug target/121048] [16 Regression] Recent vectorizer changes cause RISC-V testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121048
Robin Dapp changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2 from Robin Dapp ---
Those zve32 tests often do single-element vectorization.
In zve32f-1.c we don't vectorize
void
foo1 (int16_t *__restrict f, int32_t *__restrict d, int n)
{
for (int i = 0; i < n; ++i)
{
f[i * 2 + 0] = 1;
f[i * 2 + 1] = 2;
d[i] = 3;
}
}
any more due to
if (known_le (TYPE_VECTOR_SUBPARTS (stmt_vectype), 1U))
return opt_result::failure_at (STMT_VINFO_STMT (stmt_info),
"not vectorized: unsupported "
"data-type in %G",
STMT_VINFO_STMT (stmt_info));
where we give up on the single-element store (but the load has two elements).
Without having had a closer look, would we not only want to fail when all
statements have known_le (..., 1U) rather than just one?
[Bug target/121062] New: integer registers of vector constant load shouldn't go through memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121062
Bug ID: 121062
Summary: integer registers of vector constant load shouldn't go
through memory
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-zen4-1 pr121015]$ cat x.c
typedef int __attribute__((__vector_size__ (4))) S;
extern int bar (S);
int
foo ()
{
return bar ((S){-1});
}
[hjl@gnu-zen4-1 pr121015]$ gcc -Og -fno-dce -mtune=generic -S x.c
[hjl@gnu-zen4-1 pr121015]$ cat x.s
.file "x.c"
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl.LC0(%rip), %edi
We should generate "movl $-1, %edi" here.
callbar
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC0:
.long -1
.ident "GCC: (GNU) 15.1.1 20250521 (Red Hat 15.1.1-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-zen4-1 pr121015]$
[Bug target/120297] [15/16 Regression] RISC-V: Miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297 --- Comment #5 from Robin Dapp --- Tried to reproduce again with the latest trunk and didn't succeed. I'm always getting 234635118 no matter the VLEN and options. I'll try to bisect a failing commit.
[Bug ada/121057] New: Assertion failure triggered by access-type dispatch in Implementation Extension mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121057 Bug ID: 121057 Summary: Assertion failure triggered by access-type dispatch in Implementation Extension mode Product: gcc Version: 16.0 Status: RESOLVED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dennis at przytarski dot com CC: dkm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: ebotcazou at gcc dot gnu.org Resolution: DUPLICATE This code pragma Extensions_Allowed (On); -- remove procedure Example is package A is type A is tagged null record; type A_Ptr is access A; procedure Proc (This : in out A'Class; Some_Parameter : A_Ptr) is null; Obj : A_Ptr := new A'(null record); end A; package body A is -- this part is empty begin Obj.Proc (null); -- replace Obj by Obj.all end A; begin null; end Example; fails with gnatmake: "" compilation error +===GNAT BUG DETECTED==+ | 16.0.0 20250713 (experimental) (x86_64-linux-gnu) Assert_Failure failed precondition from einfo-entities.ads:4348| | Error detected at example.adb:15:10 | | Compiling| The GNAT bug disappears when either: * the pragma is removed, or * the access object (Obj) is dereferenced. --- Comment #1 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 121056 ***
[Bug tree-optimization/121020] [16 regression] genrecog miscompiled since r16-1624-g6deab186535a5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020 --- Comment #10 from Pengfei Li --- (In reply to Sam James from comment #9) > (In reply to Sam James from comment #8) > > FWIW, I've checked that this reproduces it in a Debian stable container too > (i.e. there's nothing special that the stage1 gcc-trunk/g++-trunk that > CC/CXX should point to must be configured with). Thank you for the information. I've tried with your approach in the past few days. It works, but the behavior is not stable - some GCC trunk commits reproduce it, others don't. After going through all potentially miscompiled functions, I have created a much smaller reproducer that can stably triggers the SegFault. So far, I've done some analysis and found that the problem seems to be related to misaligned access in over-unrolled loops. In fact, the same SegFault can be observed when compiling my reproducer with GCC 15 release (GCC 14 is ok), so the issue seems to have been introduced between 14 and 15. Given this, I don't think my patch is the root cause. It may just expose the issue more frequently. I feel I'm getting very close to identifying the root cause. I expect to give you another update soon in this week.
[Bug ada/121056] New: Assertion failure triggered by access-type dispatch in Implementation Extension mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056 Bug ID: 121056 Summary: Assertion failure triggered by access-type dispatch in Implementation Extension mode Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dennis at przytarski dot com CC: dkm at gcc dot gnu.org Target Milestone: --- This code pragma Extensions_Allowed (On); -- remove procedure Example is package A is type A is tagged null record; type A_Ptr is access A; procedure Proc (This : in out A'Class; Some_Parameter : A_Ptr) is null; Obj : A_Ptr := new A'(null record); end A; package body A is -- this part is empty begin Obj.Proc (null); -- replace Obj by Obj.all end A; begin null; end Example; fails with gnatmake: "" compilation error +===GNAT BUG DETECTED==+ | 16.0.0 20250713 (experimental) (x86_64-linux-gnu) Assert_Failure failed precondition from einfo-entities.ads:4348| | Error detected at example.adb:15:10 | | Compiling| The GNAT bug disappears when either: * the pragma is removed, or * the access object (Obj) is dereferenced. --- Comment #1 from Eric Botcazou --- *** Bug 121057 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/121059] [15/16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r15-5383-g8f68d9cb7897df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059 Sam James changed: What|Removed |Added CC||rdapp at gcc dot gnu.org Summary|[15/16 regression] ICE when |[15/16 regression] ICE when |building|building |imagemagick-7.1.1-47|imagemagick-7.1.1-47 |(vect_get_loop_mask, at |(vect_get_loop_mask, at |tree-vect-loop.cc:10960)|tree-vect-loop.cc:10960) ||since ||r15-5383-g8f68d9cb7897df Keywords|needs-bisection | --- Comment #8 from Sam James --- r15-5383-g8f68d9cb7897df
[Bug sanitizer/119356] [15 Regression] libsanitizer fails to build on riscv musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119356 --- Comment #9 from Sam James --- Thanks Jeff! r16-1750-g5111ea055f5699 works on trunk.
[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #7 from Tobias Burnus --- (In reply to Jerry DeLisle from comment #2) > However, I do see the following on gcc-15 pulled this morning. Can you check what branch you checked out? Because the test files > FAIL: gfortran.dg/goacc/parameter-3.f90 -O (test for excess errors) > FAIL: gfortran.dg/goacc/parameter-4.f90 -O (test for excess errors) do not exist on GCC 15 but only on mainline (GCC 16; since r16-2213-g451b6dbf475959). Can you provide more details about those fails? Namely: what system you configured for, which git revision - and, in particular, which excess errors you get? It works here and I also see no FAIL at https://gcc.gnu.org/ml/gcc-testresults/current (It probably makes sense to start a new PR for this issue.)
[Bug target/120645] macOS number changes again with macOS 26 Tahoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120645 Rainer Orth changed: What|Removed |Added Target Milestone|--- |16.0 Last reconfirmed||2025-07-14 Ever confirmed|0 |1 CC||ro at gcc dot gnu.org Target|aarch64-apple-darwin25 |*-apple-darwin25 Status|UNCONFIRMED |NEW --- Comment #2 from Rainer Orth --- Confirmed: I had a similar patch on macOS 26/x86_64.
[Bug ada/121056] Assertion failure on object notation applied to access value with -gnatX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Eric Botcazou --- .
[Bug ada/121056] Assertion failure on object notation applied to access value with -gnatX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056 --- Comment #3 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:b513e4f3e0914ade0a31a51625e1e2fe42093622 commit r16-2226-gb513e4f3e0914ade0a31a51625e1e2fe42093622 Author: Eric Botcazou Date: Mon Jul 14 12:11:44 2025 +0200 Ada: Add missing guard before accessing the Underlying_Record_View field It is necessary when GNAT extensions are enabled (-gnatX switch). gcc/ada/ PR ada/121056 * sem_ch4.adb (Try_Object_Operation.Try_Primitive_Operation): Add test on Is_Record_Type before accessing Underlying_Record_View. gcc/testsuite/ * gnat.dg/deref4.adb: New test. * gnat.dg/deref4_pkg.ads: New helper.
[Bug target/121062] integer registers of vector constant load shouldn't go through memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121062 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com Last reconfirmed||2025-07-14 --- Comment #1 from H.J. Lu --- Created attachment 61859 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61859&action=edit A patch I am testing this.
[Bug target/120297] [15/16 Regression] RISC-V: Miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297 --- Comment #6 from Robin Dapp --- I was able to reproduce it on our internal tree. Disabling scheduling as well as using the simple vsetvl strategy make the problem disappear so everything points to a vsetvl issue.
[Bug middle-end/120608] [15 regression] error: cannot tail-call: other reasons when using address sanitizer with musttail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120608 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #25 from Jakub Jelinek --- Fixed.
[Bug ada/121058] overloading of functions returning types that have an implicit dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121058 Eric Botcazou changed: What|Removed |Added Target Milestone|16.0|--- Depends on||120669 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120669 [Bug 120669] overloading of functions returning type that has an implicit dereference
[Bug target/120986] ICE when expanding svdot_lane_fpm intrinsic with compile time know FPMR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986 Spencer Abson changed: What|Removed |Added CC||sabson at gcc dot gnu.org --- Comment #6 from Spencer Abson --- > The insn is recognised if +fp8dot4 is added, so I suspect the gating of this > insn is also wrong in the backend. Yeah, I suspect the issue is that: "TARGET_SSVE_FP8DOT4 && !(mode == VNx8HFmode && !TARGET_SSVE_FP8DOT2)" Relies on TARGET_SSVE_FPDOT2 implying TARGET_SSVE_FP8DOT4. This is true architecturally, but was relaxed in https://inbox.sourceware.org/gcc-patches/7bcbb211-2658-f517-e189-a23e6b984...@e124511.cambridge.arm.com/.
[Bug target/121062] integer registers of vector constant load shouldn't go through memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121062 --- Comment #2 from Uroš Bizjak --- Created attachment 61860 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61860&action=edit Slightly cleaned version Slightly cleaned up version of the patch, also fixes splitter for constant vector stores.
[Bug gcov-profile/121063] New: [GCOV] dead "return;" was marked as executed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121063
Bug ID: 121063
Summary: [GCOV] dead "return;" was marked as executed.
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
Target Milestone: ---
gcc version:
gcc version 16.0.0 20250704 (experimental) (GCC)
$ cat test.c
#include
#include
#include
#include
void example_func(int x) {
static int count = 0;
if (x <= 0)
return;
char buffer[32];
int result = strfromd(buffer, sizeof(buffer), "%g", x * 1.5);
if (result != 0) {
errno = EINVAL;
return;
}
}
int main(void) {
example_func(2);
return 0;
}
$ cat test.c.gcov
-:1:#include
-:2:#include
-:3:#include
-:4:#include
1:5:void example_func(int x) {
-:6:static int count = 0;
1:7:if (x <= 0)
1*:8:return;
-:9:char buffer[32];
1: 10:int result = strfromd(buffer, sizeof(buffer), "%g", x *
1.5);
1: 11:if (result != 0) {
1: 12:errno = EINVAL;
1: 13:return;
-: 14:}
-: 15:}
1: 16:int main(void) {
1: 17:example_func(2);
1: 18:return 0;
-: 19:}
Line 8 should not be executed.
[Bug gcov-profile/121066] New: [GCOV] Strange coverage statistics logic about statement expressions and ternary operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121066
Bug ID: 121066
Summary: [GCOV] Strange coverage statistics logic about
statement expressions and ternary operators
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
Target Milestone: ---
gcc version:
gcc version 16.0.0 20250704 (experimental) (GCC)
option:
--coverage -std=c2x
$ cat test.c
#include
int main() {
volatile int a = 0, b = 0;
int result = (a = 1, a)+
((b = 2, b)
?(a = 8, a)
:(b = 4, b));
printf("a=%d,b=%d,result=%d\n",a,b,result);
return 0;
}
output：
a=8,b=2,result=16
$ cat test.c.gcov
-:1:#include
1:2:int main() {
1:3:volatile int a = 0, b = 0;
2:4:int result = (a = 1, a)+
1:5: ((b = 2, b)
2:6:?(a = 8, a)
1*:7::(b = 4, b));
1:8:printf("a=%d,b=%d,result=%d\n",a,b,result);
1:9:return 0;
-: 10:}
coverage statistics of line 4,5,6 should be consistent, and line 7 was not
executed.
[Bug target/119100] RISC-V: missed opportunities for vector-scalar instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100 --- Comment #12 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:99a3c71db6edb8dc8c426cb2530f9cefbb5bfc9e commit r16-2230-g99a3c71db6edb8dc8c426cb2530f9cefbb5bfc9e Author: Paul-Antoine Arras Date: Mon Jul 14 06:10:44 2025 -0600 [PATCH v2] RISC-V: Vector-scalar widening multiply-(subtract-)accumulate [PR119100] This pattern enables the combine pass (or late-combine, depending on the case) to merge a float_extend'ed vec_duplicate into a plus-mult or minus-mult RTL instruction. Before this patch, we have three instructions, e.g.: fcvt.s.h fa5,fa5 vfmv.v.f v24,fa5 vfmadd.vv v8,v24,v16 After, we get only one: vfwmacc.vf v8,fa5,v16 PR target/119100 gcc/ChangeLog: * config/riscv/autovec-opt.md (*vfwmacc_vf_): New pattern to handle both vfwmacc and vfwmsac. (*extend_vf_): New pattern that serves as an intermediate combine step. * config/riscv/vector-iterators.md (vsubel): New mode attribute. This is just the lower-case version of VSUBEL. * config/riscv/vector.md (@pred_widen_mul__scalar): Reorder and swap operands to match the RTL emitted by expand, i.e. first float_extend then vec_duplicate. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f16.c: Add vfwmacc and vfwmsac. * gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f32.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f16.c: Likewise. Also check for fcvt and vfmv. * gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f32.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f16.c: Add vfwmacc and vfwmsac. * gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f32.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f16.c: Likewise. Also check for fcvt and vfmv. * gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f32.c: Likewise. * gcc.target/riscv/rvv/autovec/vx_vf/vf_mulop.h: Add support for widening variants. * gcc.target/riscv/rvv/autovec/vx_vf/vf_mulop_widen_run.h: New test helper. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwmacc-run-1-f16.c: New test. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwmacc-run-1-f32.c: New test. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwmsac-run-1-f16.c: New test. * gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwmsac-run-1-f32.c: New test.
[Bug tree-optimization/121059] [15/16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r15-5383-g8f68d9cb7897df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059
--- Comment #10 from Richard Sandiford ---
(In reply to Richard Biener from comment #9)
> vectorizable_operation during transform does
>
> /* When combining two masks check if either of them is elsewhere
> combined with a loop mask, if that's the case we can mark that
> the
> new combined mask doesn't need to be combined with a loop mask.
> */
> if (masked_loop_p
> && code == BIT_AND_EXPR
> && VECTOR_BOOLEAN_TYPE_P (vectype))
> {
> if (loop_vinfo->scalar_cond_masked_set.contains ({ op0, 1 }))
> {
> mask = vect_get_loop_mask (loop_vinfo, gsi, masks,
> vec_num, vectype, i);
>
> but that's not reflected by analysis, which misses to record a loop mask
> for !mask_out_inactive operations. So the fix is as simple as the following,
> but this might put us to using masks? There is no good way to do this
> I guess. The scalar_cond_masked_set optimization does not have a
> corresponding
> len operation. I'm not sure what we can do here?
>
> diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> index 4aa69da2218..55002bd0cc2 100644
> --- a/gcc/tree-vect-stmts.cc
> +++ b/gcc/tree-vect-stmts.cc
> @@ -6978,6 +6978,16 @@ vectorizable_operation (vec_info *vinfo,
> LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) = false;
> }
> }
> + else if (loop_vinfo
> + && LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
> + && code == BIT_AND_EXPR
> + && VECTOR_BOOLEAN_TYPE_P (vectype))
> + vect_record_loop_mask (loop_vinfo, masks, vec_num, vectype, NULL);
>
>/* Put types on constant and invariant SLP children. */
>if (!vect_maybe_update_slp_op_vectype (slp_op0, vectype)
Yeah, we shouldn't do that. The question is why op0 is in
scalar_cond_masked_set with masked_loop_p true if there's no associated loop
mask.
[Bug target/120645] macOS number changes again with macOS 26 Tahoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120645 --- Comment #3 from GCC Commits --- The master branch has been updated by Francois-Xavier Coudert : https://gcc.gnu.org/g:cc4f3397331f6ecd5e775cf963c65face0145f3f commit r16-2231-gcc4f3397331f6ecd5e775cf963c65face0145f3f Author: Francois-Xavier Coudert Date: Mon Jul 14 12:14:00 2025 +0200 Darwin: account for macOS 26 darwin25 will be named macOS 26 (codename Tahoe). This is a change from darwin24, which was macOS 15. We need to adapt the driver to this new numbering scheme. 2025-07-14 François-Xavier Coudert gcc/ChangeLog: PR target/120645 * config/darwin-driver.cc: Account for latest macOS numbering scheme. gcc/testsuite/ChangeLog: * gcc.dg/darwin-minversion-link.c: Account for macOS 26.
[Bug ada/121058] [16 regression] internal error on overloaded functions returning Implicit_Dereference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121058 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |16.0 Status|UNCONFIRMED |NEW Last reconfirmed||2025-07-14 Summary|GNAT bug when identically |[16 regression] internal |named generic function |error on overloaded |instantiations return |functions returning |Implicit_Dereference types |Implicit_Dereference types --- Comment #1 from Eric Botcazou --- Again this works with 15.x but not on the mainline.
[Bug target/120297] [15/16 Regression] RISC-V: Miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297 --- Comment #7 from Robin Dapp --- Picking a random commit in May (r16-649-g5c012971969db9) also shows the issue. It looks as if we pick the wrong LMUL for a store and this rule is to blame: DEF_SEW_LMUL_RULE ( ratio_and_ge_sew, sew_only, sew_only, sew_le_and_next_sew_le_prev_max_sew_and_prev_ratio_valid_for_next_sew_p, always_false, use_next_sew_with_prev_ratio) Looking into it.
[Bug ada/121058] [16 regression] internal error on overloaded functions returning Implicit_Dereference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121058 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug ada/121058] internal error on overloaded functions returning Implicit_Dereference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121058 Eric Botcazou changed: What|Removed |Added Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org Summary|[16 regression] internal|internal error on |error on overloaded |overloaded functions |functions returning |returning |Implicit_Dereference types |Implicit_Dereference types Status|ASSIGNED|NEW Keywords||wrong-code --- Comment #2 from Eric Botcazou --- This generates wrong code with released compilers though.
[Bug c/121064] New: Loongarch: FFmpeg build fail when enable autovectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121064
Bug ID: 121064
Summary: Loongarch: FFmpeg build fail when enable
autovectorization.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jiawei at iscas dot ac.cn
Target Milestone: ---
When enabled -ftree-vectorize in GCC version larger than 13, FFmpeg build will
get a fatal error,but it build fine for other architecture:
https://patchwork.ffmpeg.org/check/125495/
```
tests/checkasm/h264chroma.c: In function 'check_chroma_mc':
tests/checkasm/h264chroma.c:54:18: warning: 'size' is used uninitialized
[-Wuninitialized]
54 | for (int size = 0; size < 4; size++) {
| ^~~~
make: *** [tests/Makefile:316: fate-lossless-monkeysaudio-388-extrahigh] Error
1
make: *** [tests/Makefile:316: fate-lossless-monkeysaudio-392b2-extrahigh]
Error 1
make: *** [tests/Makefile:315: fate-lossless-monkeysaudio-389b1-extrahigh]
Error 1
make: *** [tests/Makefile:315: fate-lossless-monkeysaudio-391b1-extrahigh]
Error 1
cpu_flags(raw) = 0x0003
cpu_flags_str(raw) = lsx lasx
cpu_flags(effective) = 0x0003
cpu_flags_str(effective) = lsx lasx
threads = 1 (cpu_count = 64)
make: Target 'fate' not remade because of errors.
```
Regarding TODO list
Hi all, we would like to contribute to this open source community as a fresher / less experience, and would like to know about the small contributions to be done as initially. We have hands on experience on embedded, c, python and c++. 4 Kindly guide us if there is any TODO list. Thanks & Regards Akshaya S
[Bug c/121065] New: ice in optab_for_tree_code, at optabs-tree.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121065
Bug ID: 121065
Summary: ice in optab_for_tree_code, at optabs-tree.cc:85
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
_Accum sa;
char c;
void div_csa() { c /= sa; }
on raspberry pi 5, does this:
$ for i in ~/gcc/results.202507*/bin/gcc; do echo $i; $i -c -w bug1109.c; done
/home/dcb/gcc/results.20250702/bin/gcc
/home/dcb/gcc/results.20250710/bin/gcc
/home/dcb/gcc/results.20250713/bin/gcc
during RTL pass: expand
bug1109.c: In function ‘div_csa’:
bug1109.c:3:20: internal compiler error: in optab_for_tree_code, at
optabs-tree.
cc:85
3 | void div_csa() { c /= sa; }
|^~
The code breaks sometime between g:e3d1b3cce8766303
and g:598455fd73b2061e
[Bug target/120941] [16 Regression] 24-40% slowdown of 519.lbm_r on Zen2 and 470.lbm on Zen5 since r16-1644-gaba3b9d3a48a07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
Filip Kastl changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #17 from Filip Kastl ---
This is the replacement that causes the slowdown (well, two replacements):
--
Replace:
(insn 2224 2228 20 (set (reg:V4DF 1604)
(vec_duplicate:V4DF (mem/u/c:DF (symbol_ref/u:DI ("*.LC3") [flags 0x2])
[0 S8 A64]))) 9260 {vec_dupv4df}
(expr_list:REG_EQUAL (const_vector:V4DF [
(const_double:DF
2.7776235801354687282582744956016540527344e-2
[0x0.e38e38e38e38ep-5]) repeated x4
])
(nil)))
with:
(insn 2224 2228 20 (set (reg:V4DF 1604)
(reg:V4DF 1655)) 2428 {movv4df_internal}
(expr_list:REG_EQUAL (const_vector:V4DF [
(const_double:DF
2.7776235801354687282582744956016540527344e-2
[0x0.e38e38e38e38ep-5]) repeated x4
])
(nil)))
deferring rescan insn with uid = 2224.
Replace:
(insn 2228 2224 377 20 (set (reg:V2DF 1603)
(vec_duplicate:V2DF (mem/u/c:DF (symbol_ref/u:DI ("*.LC3") [flags 0x2])
[0 S8 A64]))) 7168 {vec_dupv2df}
(expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF
2.7776235801354687282582744956016540527344e-2
[0x0.e38e38e38e38ep-5]) repeated x2
])
(nil)))
with:
(insn 2228 2224 377 20 (set (reg:V2DF 1603)
(subreg:V2DF (reg:V4DF 1655) 0)) 2429 {movv2df_internal}
(expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF
2.7776235801354687282582744956016540527344e-2
[0x0.e38e38e38e38ep-5]) repeated x2
])
(nil)))
deferring rescan insn with uid = 2228.
--
These instructions are inside function "main". Though, the last RTL debug
instruction is
(debug_insn 272 271 273 19 (debug_marker) "lbm.c":275:2 discrim 1 -1
(nil))
so I expect that function "LBM_performStreamCollideTRT" was inlined into main
and is the original source of these vector instructions.
Hopefully this helps. If you meant something else by "testcase", do tell me.
What I did in more detail:
I used a custom debug counter. If I set the 9-th call of
ix86_broadcast_inner() to return null (I adapted what hjl's patch does), I get
rid of the slowdown.
On r16-1644-gaba3b9d3a48a07 I added the debug counter and did:
/home/fkastl/gcc/inst/bin/gcc -std=gnu99 -m64 -c -o lbm.o -DSPEC -DNDEBUG
-DSPEC_AUTO_SUPPRESS_OPENMP -Ofast -march=native -mtune=native -g -flto=32
-fpermissive -std=gnu17 -DSPEC_LP64 lbm.c
-fdbg-cnt=foo_counter:10-10
/home/fkastl/gcc/inst/bin/gcc -std=gnu99 -m64 -c -o main.o -DSPEC -DNDEBUG
-DSPEC_AUTO_SUPPRESS_OPENMP -Ofast -march=native -mtune=native -g -flto=32
-fpermissive -std=gnu17 -DSPEC_LP64 main.c
-fdbg-cnt=foo_counter:10-10
/home/fkastl/gcc/inst/bin/gcc -std=gnu99 -m64
-Wl,-rpath,/home/fkastl/gcc/inst/lib64 -Ofast -march=native -mtune=native -g
-flto=32 -fpermissive -std=gnu17 lbm.o main.o -lm -o lbm_r
-fdbg-cnt=foo_counter:9-9 -fdump-rtl-all
-> 3m43s
/home/fkastl/gcc/inst/bin/gcc -std=gnu99 -m64
-Wl,-rpath,/home/fkastl/gcc/inst/lib64 -Ofast -march=native -mtune=native -g
-flto=32 -fpermissive -std=gnu17 lbm.o main.o -lm -o lbm_r
-fdbg-cnt=foo_counter:10-10 -fdump-rtl-all
-> 2m50s
Then I compared the *.rrvl rtl dumps. Btw I had to "backport" the
Replace:
...
with:
and
Add:
...
dumping from a newer commit.
[Bug tree-optimization/121059] [15/16 regression] ICE when building imagemagick-7.1.1-47 (vect_get_loop_mask, at tree-vect-loop.cc:10960) since r15-5383-g8f68d9cb7897df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #9 from Richard Biener ---
vectorizable_operation during transform does
/* When combining two masks check if either of them is elsewhere
combined with a loop mask, if that's the case we can mark that the
new combined mask doesn't need to be combined with a loop mask.
*/
if (masked_loop_p
&& code == BIT_AND_EXPR
&& VECTOR_BOOLEAN_TYPE_P (vectype))
{
if (loop_vinfo->scalar_cond_masked_set.contains ({ op0, 1 }))
{
mask = vect_get_loop_mask (loop_vinfo, gsi, masks,
vec_num, vectype, i);
but that's not reflected by analysis, which misses to record a loop mask
for !mask_out_inactive operations. So the fix is as simple as the following,
but this might put us to using masks? There is no good way to do this
I guess. The scalar_cond_masked_set optimization does not have a corresponding
len operation. I'm not sure what we can do here?
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 4aa69da2218..55002bd0cc2 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -6978,6 +6978,16 @@ vectorizable_operation (vec_info *vinfo,
LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) = false;
}
}
+ else if (loop_vinfo
+ && LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
+ && code == BIT_AND_EXPR
+ && VECTOR_BOOLEAN_TYPE_P (vectype))
+ vect_record_loop_mask (loop_vinfo, masks, vec_num, vectype, NULL);
/* Put types on constant and invariant SLP children. */
if (!vect_maybe_update_slp_op_vectype (slp_op0, vectype)
[Bug ada/121056] Assertion failure on object notation applied to access value with -gnatX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121056 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:762ca0be09e00d02a72bd65fe8c3027a056d4a81 commit r15-9968-g762ca0be09e00d02a72bd65fe8c3027a056d4a81 Author: Eric Botcazou Date: Mon Jul 14 12:11:44 2025 +0200 Ada: Add missing guard before accessing the Underlying_Record_View field It is necessary when GNAT extensions are enabled (-gnatX switch). gcc/ada/ PR ada/121056 * sem_ch4.adb (Try_Object_Operation.Try_Primitive_Operation): Add test on Is_Record_Type before accessing Underlying_Record_View. gcc/testsuite/ * gnat.dg/deref4.adb: New test. * gnat.dg/deref4_pkg.ads: New helper.
[Bug c++/117785] [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785 --- Comment #41 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9b6b7fed78c5d3514a180f7ae9f7d86824f45735 commit r16-2228-g9b6b7fed78c5d3514a180f7ae9f7d86824f45735 Author: Jonathan Wakely Date: Fri Jul 11 23:49:27 2025 +0100 libstdc++: Correct value of __cpp_lib_constexpr_exceptions [PR117785] Only P3068R6 (Allowing exception throwing in constant-evaluation) is implemented in the library so far, so the value of the constexpr_exceptions feature test macro should be 202411L. Once we support the library changes in P3378R2 (constexpr exception types) then we can set the value to 202502L again. libstdc++-v3/ChangeLog: PR libstdc++/117785 * include/bits/version.def (constexpr_exceptions): Define correct value. * include/bits/version.h: Regenerate. * libsupc++/exception: Check correct value. * testsuite/18_support/exception/version.cc: New test.
[Bug gcov-profile/121063] [GCOV] dead "return;" was marked as executed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121063 --- Comment #1 from Anonymous --- option: gcc --coverage -std=c2x
[Bug gcov-profile/120881] [16 Regression] -pg may not call mount at function entry by r16-1550-g9244ea4bf55638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881 --- Comment #29 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:07d8de9174c421d719649639a1452b8b9f2eee32 commit r16-2232-g07d8de9174c421d719649639a1452b8b9f2eee32 Author: H.J. Lu Date: Wed Jul 2 08:58:23 2025 +0800 x86-64: Add --enable-x86-64-mfentry When profiling is enabled with shrink wrapping, the mcount call may not be placed at the function entry after pushq %rbp movq %rsp,%rbp As the result, the profile data may be skewed which makes PGO less effective. Add --enable-x86-64-mfentry to enable -mfentry by default to use __fentry__, added to glibc in 2010 by: commit d22e4cc9397ed41534c9422d0b0ffef8c77bfa53 Author: Andi Kleen Date: Sat Aug 7 21:24:05 2010 -0700 x86: Add support for frame pointer less mcount instead of mcount, which is placed before the prologue so that -pg can be used with -fshrink-wrap-separate enabled at -O1. This option is 64-bit only because __fentry__ doesn't support PIC in 32-bit mode. The default it to enable -mfentry when targeting glibc. Also warn -pg without -mfentry with shrink wrapping enabled. The warning is disable for PIC in 32-bit mode. gcc/ PR target/120881 * config.in: Regenerated. * configure: Likewise. * configure.ac: Add --enable-x86-64-mfentry. * config/i386/i386-options.cc (ix86_option_override_internal): Enable __fentry__ in 64-bit mode if ENABLE_X86_64_MFENTRY is set to 1. Warn -pg without -mfentry with shrink wrapping enabled. * doc/install.texi: Document --enable-x86-64-mfentry. gcc/testsuite/ PR target/120881 * gcc.dg/20021014-1.c: Add additional -mfentry -fno-pic options for x86. * gcc.dg/aru-2.c: Likewise. * gcc.dg/nest.c: Likewise. * gcc.dg/pr32450.c: Likewise. * gcc.dg/pr43643.c: Likewise. * gcc.target/i386/pr104447.c: Likewise. * gcc.target/i386/pr113122-3.c: Likewise. * gcc.target/i386/pr119386-1.c: Add additional -mfentry if not ia32. * gcc.target/i386/pr119386-2.c: Likewise. * gcc.target/i386/pr120881-1a.c: New test. * gcc.target/i386/pr120881-1b.c: Likewise. * gcc.target/i386/pr120881-1c.c: Likewise. * gcc.target/i386/pr120881-1d.c: Likewise. * gcc.target/i386/pr120881-2a.c: Likewise. * gcc.target/i386/pr120881-2b.c: Likewise. * gcc.target/i386/pr82699-1.c: Add additional -mfentry. * lib/target-supports.exp (check_effective_target_fentry): New. Signed-off-by: H.J. Lu
[Bug gcov-profile/120881] [16 Regression] -pg may not call mount at function entry by r16-1550-g9244ea4bf55638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #30 from H.J. Lu --- Fixed.
[Bug target/121064] Loongarch: FFmpeg build fail when enable autovectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121064 --- Comment #5 from Xi Ruoyao --- Something goes wrong compiling libavcodec/apedec.c. Disabling vectorization alone for it covers up the issue.
[Bug sanitizer/121070] bounds sanitizer should instrument arrays inside a structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121070 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Or with -fstrict-flex-arrays .
[Bug sanitizer/121070] New: bounds sanitizer should instrument arrays inside a structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121070
Bug ID: 121070
Summary: bounds sanitizer should instrument arrays inside a
structure
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
currently, the bounds sanitizer fails to instrument arrays inside a structure.
for example:
struct inside_array {
int b;
int c[10];
} *p_array;
void __attribute__((__noinline__)) setup ( )
{
p_array
= (struct inside_array *) __builtin_malloc (sizeof (struct inside_array));
return;
}
void __attribute__((__noinline__)) test (int index)
{
p_array->c[index] = 2;
}
int main(int argc, char *argv[])
{
setup ();
test (11);
return 0;
}
$ gcc t.c -O -g -fsanitize=bounds -o ./t.exe -fdump-tree-original
$ ./t.exe
$ egrep UBSAN t.c.006t.original
$
should we instrument such array reference inside a structure?
[Bug sanitizer/121070] bounds sanitizer should instrument arrays inside a structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121070 --- Comment #1 from Andrew Pinski --- >should we instrument such array reference inside a structure? We do if it is not the last field ...
[Bug target/121007] [15 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Segher Boessenkool --- Vlad fixed this, see #c15.
[Bug sanitizer/121070] bounds sanitizer should instrument arrays inside a structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121070 --- Comment #3 from Andrew Pinski --- See https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/C-Dialect-Options.html#index-fstrict-flex-arrays too.
[Bug rtl-optimization/120423] ICE in avr-gcc extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120423 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #6 from Georg-Johann Lay --- *** Bug 117914 has been marked as a duplicate of this bug. ***
[Bug other/117914] [reload][avr] In function __objc_add_class_to_hash class-i.c:2162:1: error: insn does not satisfy its constraints:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117914 Georg-Johann Lay changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Georg-Johann Lay --- dup *** This bug has been marked as a duplicate of bug 120423 ***
[Bug c++/121069] New: in tsubst_pack_expansion, at cp/pt.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121069 Bug ID: 121069 Summary: in tsubst_pack_expansion, at cp/pt.cc Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mario.rodriguezb1 at um dot es Target Milestone: ---
[Bug c++/88982] ICE in tsubst_pack_expansion, at cp/pt.c:12221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88982
MARIO RODRIGUEZ BEJAR changed:
What|Removed |Added
CC||mario.rodriguezb1 at um dot es
--- Comment #4 from MARIO RODRIGUEZ BEJAR ---
/* internal compiler error: Check code */
int main() {
auto func = [](auto... args) constexpr {
return (([](Ts arg) {
return arg;
}(args)),...);
};
func(2, 6, 7);
}
Arise same issue:
:6:25: internal compiler error: in tsubst_pack_expansion, at
cp/pt.cc:14039
4 | return (([](Ts arg) {
|~~
5 | return arg;
| ~~~
6 | }(args)),...);
| ^
0x287a025 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x289bd06 internal_error(char const*, ...)
???:0
0xaf4a22 fancy_abort(char const*, int, char const*)
???:0
0xd7993d instantiate_decl(tree_node*, bool, bool)
???:0
0xc01e23 maybe_instantiate_decl(tree_node*)
???:0
0xc03b97 mark_used(tree_node*, int)
???:0
0xb31163 build_op_call(tree_node*, vec**, int)
???:0
0xda442e finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xd21723 c_parse_file()
???:0
0xe8b9d9 c_common_parse_file()
???:0
[Bug target/115259] [15 Regressions] GCN vs. "tree-optimization/115144 - improve sinking destination choice"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115259 Thomas Schwinge changed: What|Removed |Added Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120817 Status|NEW |RESOLVED --- Comment #16 from Thomas Schwinge --- These regressions recently disappeared, and I've bisected this to be due to commit r16-2062-g439b14e222571da76da2bfec04b9035fb9f1862d "tree-optimization/120817 - bogus DSE of .MASK_STORE". I've not investigated any further. I assume that GCC 15 commit r15-9941-g0ebeed53983dbcefcf7b950895c9d88c85342cf4 likewise resolved this (and will report in due time if not), therefore closing this PR.
