[Bug c/112485] datestamp on -v recently broken ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112485 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gccadmin/2023q4/020594.html
[Bug c/112485] datestamp on -v recently broken ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112485 --- Comment #1 from Andrew Pinski --- Changelog generation is broken due to a commit.
[Bug c/112485] New: datestamp on -v recently broken ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112485 Bug ID: 112485 Summary: datestamp on -v recently broken ? Product: gcc Version: 14.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 morning's gcc trunk compiler: $ ~/gcc/results.20231112.asan.ubsan/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/dcb38/gcc/results.20231112.asan.ubsan/bin/gcc COLLECT_LTO_WRAPPER=/home/dcb38/gcc/results.20231112.asan.ubsan/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk.year/configure --prefix=/home/dcb38/gcc/results.20231112.asan.ubsan --disable-multilib --disable-bootstrap --with-build-config=bootstrap-asan --with-build-config=bootstrap-ubsan --with-pkgversion=e0787da263322fc1 --enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231109 (experimental) (e0787da263322fc1) ~ $ The date 20231109 at the end looks wrong. It should be 20231112.
[Bug ipa/105326] aarch64: functions affected by irrelevant function changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105326 --- Comment #6 from Andrew Pinski --- (In reply to Sam James from comment #5) > (In reply to Keiya Nobuta from comment #4) > > Thank you for the information. > > Can it be suppressed by option? > > You can use the noipa function attribute and there's a bunch of -fno-ipa-* > flags (see https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html). Some --param options which talk about TU size and documented there: ipa-cp-large-unit-insns inline-unit-growth ipa-cp-unit-growth large-unit-insns
[Bug debug/92444] [11/12/13/14 regression] gcc generates wrong debug information at -O2 and -O3 since r10-4122-gf658ad3002a0af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92444 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org Summary|gcc generates wrong debug |[11/12/13/14 regression] |information at -O2 and -O3 |gcc generates wrong debug ||information at -O2 and -O3 ||since ||r10-4122-gf658ad3002a0af --- Comment #2 from Sam James --- I've not reconfirmed this, but fixing summary based on bisect info.
[Bug ipa/105326] aarch64: functions affected by irrelevant function changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105326 Sam James changed: What|Removed |Added Last reconfirmed||2023-11-12 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #5 from Sam James --- (In reply to Keiya Nobuta from comment #4) > Thank you for the information. > Can it be suppressed by option? You can use the noipa function attribute and there's a bunch of -fno-ipa-* flags (see https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html).
[Bug target/112476] Unrecognizable insn with -O2 -march=la464 on loongarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476 Xi Ruoyao changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Novembe ||r/636156.html --- Comment #5 from Xi Ruoyao --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636156.html
[Bug target/112484] New: [14 Regression] 26_numerics/random/{poisson_distribution,negative_binomial_distribution}/operators/values.cc fails on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112484
Bug ID: 112484
Summary: [14 Regression]
26_numerics/random/{poisson_distribution,negative_bino
mial_distribution}/operators/values.cc fails on
loongarch64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
With r14-5366:
FAIL: 26_numerics/random/poisson_distribution/operators/values.cc -std=gnu++17
execution test
FAIL: 26_numerics/random/negative_binomial_distribution/operators/values.cc
-std=gnu++17 execution test
This is a very recent regression but I've not bisected yet. I'm not sure if
the component field is correct either.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #39 from John David Anglin ---
In the f-m-o pass, the following three insns that set call clobbered
registers r20-r22 are pulled from loop:
(insn 186 183 190 29 (set (reg/f:SI 22 %r22 [478])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
(const_int 388 [0x184]))) "../Python/compile.c":5964:9 120 {addsi3}
(nil))
(insn 190 186 187 29 (set (reg/f:SI 21 %r21 [479])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
(const_int 392 [0x188]))) "../Python/compile.c":5964:9 120 {addsi3}
(nil))
(insn 194 191 195 29 (set (reg/f:SI 20 %r20 [480])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
(const_int 396 [0x18c]))) "../Python/compile.c":5964:9 120 {addsi3}
(nil))
They are used in the following insns before call to compiler_visit_expr1:
(insn 242 238 258 32 (set (mem:SI (reg/f:SI 22 %r22 [478]) [4 MEM[(int
*)prephit
mp_37 + 388B]+0 S4 A32])
(reg:SI 23 %r23 [orig:173 vect__102.2442 ] [173]))
"../Python/compile.c"
:5968:22 42 {*pa.md:2193}
(expr_list:REG_DEAD (reg:SI 23 %r23 [orig:173 vect__102.2442 ] [173])
(expr_list:REG_DEAD (reg/f:SI 22 %r22 [478])
(nil
(insn 258 242 246 32 (set (reg:SI 26 %r26)
(reg/v/f:SI 5 %r5 [orig:198 c ] [198])) "../Python/compile.c":5969:15
42 {*pa.md:2193}
(nil))
(insn 246 258 250 32 (set (mem:SI (reg/f:SI 21 %r21 [479]) [4 MEM[(int
*)prephitmp_37 + 392B]+0 S4 A32])
(reg:SI 29 %r29 [orig:169 vect__102.2443 ] [169]))
"../Python/compile.c":5968:22 42 {*pa.md:2193}
(expr_list:REG_DEAD (reg:SI 29 %r29 [orig:169 vect__102.2443 ] [169])
(expr_list:REG_DEAD (reg/f:SI 21 %r21 [479])
(nil
(insn 250 246 254 32 (set (mem:SI (reg/f:SI 20 %r20 [480]) [4 MEM[(int
*)prephitmp_37 + 396B]+0 S4 A32])
(reg:SI 31 %r31 [orig:145 vect__102.2444 ] [145]))
"../Python/compile.c":5968:22 42 {*pa.md:2193}
(expr_list:REG_DEAD (reg:SI 31 %r31 [orig:145 vect__102.2444 ] [145])
(expr_list:REG_DEAD (reg/f:SI 20 %r20 [480])
(nil
After the call, we have:
(insn 1241 269 273 30 (set (reg/f:SI 22 %r22 [478])
(reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
"../Python/compile.c":5970:20 -1
(nil))
(insn 273 1241 1242 30 (set (mem:SI (plus:SI (reg/f:SI 22 %r22 [478])
(const_int 388 [0x184])) [4 MEM[(int *)_107 + 388B]+0 S4 A32])
(reg:SI 14 %r14 [orig:167 vect_pretmp_36.2450 ] [167]))
"../Python/compile.c":5970:20 42 {*pa.md:2193}
(nil))
(insn 1242 273 277 30 (set (reg/f:SI 21 %r21 [479])
(reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
"../Python/compile.c":5970:20 -1
(nil))
(insn 277 1242 1243 30 (set (mem:SI (plus:SI (reg/f:SI 21 %r21 [479])
(const_int 392 [0x188])) [4 MEM[(int *)_107 + 392B]+0 S4 A32])
(reg:SI 13 %r13 [orig:156 vect_pretmp_36.2451 ] [156]))
"../Python/compile.c":5970:20 42 {*pa.md:2193}
(nil))
(insn 1243 277 281 30 (set (reg/f:SI 20 %r20 [480])
(reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127]))
"../Python/compile.c":5970:20 -1
(nil))
(insn 281 1243 299 30 (set (mem:SI (plus:SI (reg/f:SI 20 %r20 [480])
(const_int 396 [0x18c])) [4 MEM[(int *)_107 + 396B]+0 S4 A32])
(reg:SI 12 %r12 [orig:134 vect_pretmp_36.2452 ] [134]))
"../Python/compile.c":5970:20 42 {*pa.md:2193}
(nil))
We have lost the offsets that were added initially to r20, r21 and r22.
Previous ce3 pass had:
(insn 272 269 273 30 (set (reg/f:SI 22 %r22 [478])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
(const_int 388 [0x184]))) "../Python/compile.c":5970:20 120
{addsi3}
(nil))
(insn 273 272 276 30 (set (mem:SI (reg/f:SI 22 %r22 [478]) [4 MEM[(int *)_107 +
388B]+0 S4 A32])
(reg:SI 14 %r14 [orig:167 vect_pretmp_36.2450 ] [167]))
"../Python/compile.c":5970:20 42 {*pa.md:2193}
(nil))
(insn 276 273 277 30 (set (reg/f:SI 21 %r21 [479])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
(const_int 392 [0x188]))) "../Python/compile.c":5970:20 120
{addsi3}
(nil))
(insn 277 276 280 30 (set (mem:SI (reg/f:SI 21 %r21 [479]) [4 MEM[(int *)_107 +
392B]+0 S4 A32])
(reg:SI 13 %r13 [orig:156 vect_pretmp_36.2451 ] [156]))
"../Python/compile.c":5970:20 42 {*pa.md:2193}
(nil))
(insn 280 277 281 30 (set (reg/f:SI 20 %r20 [480])
(plus:SI (reg/f:SI 19 %r19 [orig:127 prephitmp_37 ] [127])
(const_int 396 [0x18c]))) "../Python/compile.c":5970:20 120
{addsi3}
(nil))
(insn 281 280 284 30 (set (mem:SI (reg/f:SI 20 %r20 [480]) [4 MEM[(int *)_107 +
396B]+0 S4 A32])
(reg:SI 12 %r12 [orig:134 vect_pretmp_36.2452 ] [134]))
"../Python/compile.c":5970:20 42 {*pa.md:2193}
(nil))
So, this is a f-m-o bug.
[Bug target/112483] New: [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Bug ID: 112483 Summary: [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- With r14-5366 on loongarch64-linux-gnu: FAIL: gfortran.dg/ieee/ieee_2.f90 -O1 execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -O2 execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -O3 -g execution test FAIL: gfortran.dg/ieee/ieee_2.f90 -Os execution test This is a very recent regression but I've not bisected yet. I'm not sure if the component field is correct either.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-11-11 --- Comment #38 from Sam James --- Confirming since Dave repro'd too.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #37 from John David Anglin --- (In reply to Sam James from comment #35) > If you still need dumps off me, please let me know which. I've attached > those w/ f-o-m on for the fold-mem-offsets pass. If you need others, just > say. I have a set of dumps. The problem is determining where the wrong RTL occurs in compiler_call_helper. It changes a lot in pass to pass. Many of the changes in f-m-o seem to get destroyed by later transformations.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #36 from John David Anglin --- Created attachment 56562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56562=edit fold_mem_offsets, prop_hardreg, rtl_dce and bbro dumps Comment #33 is wrong. The issue is not reload. It's okay to pick a call clobbered register as the code stands. The initialization of the register used for the store at offset 392B ends up outside the loop. It ends up in a call clobbered register and clobbered by the call to compiler_visit_expr1 in the loop. This occurs around the second call to compiler_visit_expr1 in compiler_call_helper Various initializations get moved out of the loop between the f-m-o and bbro passes. I think it's the bbro pass that's at fault but it could be something that happens before that causes the initialization to get moved outside the loop.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #35 from Sam James --- If you still need dumps off me, please let me know which. I've attached those w/ f-o-m on for the fold-mem-offsets pass. If you need others, just say.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #34 from John David Anglin --- Same wrong code is generated with x86-64 cross to hppa-linux-gnu. This it seems this bug is not due to gcc being miscompiled.
[Bug tree-optimization/112430] [14 Regression] ICE: verify_ssa failed, missing definition since r14-1837-g43a3252c42af12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/112430] [14 Regression] ICE: verify_ssa failed, missing definition since r14-1837-g43a3252c42af12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112430 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7610e5cc82bd6316cfe0bfee6d9f12d8c2cfa9c3 commit r14-5366-g7610e5cc82bd6316cfe0bfee6d9f12d8c2cfa9c3 Author: Jakub Jelinek Date: Sat Nov 11 20:15:53 2023 +0100 tree-ssa-math-opts: Fix up gsi_remove order in match_uaddc_usubc [PR112430] The following testcase ICEs, because the temp_stmts were removed in wrong order, from the ones appearing earlier in the IL to the later ones, so insert_debug_temps_for_defs can reintroduce dead SSA_NAMEs back into the IL. The following patch fixes that by removing them in the order they were pushed into the vector, which is from later ones to earlier ones. Additionally, I've noticed I forgot to call release_defs on the removed stmts. 2023-11-11 Jakub Jelinek PR middle-end/112430 * tree-ssa-math-opts.cc (match_uaddc_usubc): Remove temp_stmts in the order they were pushed rather than in reverse order. Call release_defs after gsi_remove. * gcc.dg/pr112430.c: New test.
[Bug c/112428] Wnonnull outputs wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug c/110815] [static] not as useful as the nonnull attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/112413] Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413 --- Comment #5 from Mikael Pettersson --- Created attachment 56561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56561=edit proposed fix, only compile-tested for now
[Bug target/112478] riscv: asm clobbers not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112478 --- Comment #3 from Michael T. Kloos --- Created attachment 56560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56560=edit Sample program to reproduce the bug I have created and attached a small simple program which shows the bug. If compiled with an earlier version of GCC, it runs fine. If compiled with a later version, after the aforementioned commit, it goes into an infinite loop. The problem is that the ra register clobber is not being honored. You can see the difference in objdump disassembly of the the call_invert_and_sum() function. Here is the disassembly of the good version: 000101e0 : 101e0: ff010113add sp,sp,-16 101e4: 00112623sw ra,12(sp) 101e8: f21ff0efjal 10108 101ec: 00c12083lw ra,12(sp) 101f0: 01010113add sp,sp,16 101f4: 8067ret Here is the disassembly of the bad version: 000101e0 : 101e0: f29ff0efjal 10108 101e4: 8067ret This should make it very clear why the program gets trapped in an infinite loop in the second example.
[Bug target/112476] Unrecognizable insn with -O2 -march=la464 on loongarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476
Xi Ruoyao changed:
What|Removed |Added
Component|rtl-optimization|target
Status|NEW |ASSIGNED
--- Comment #4 from Xi Ruoyao ---
The buggy nested subreg RTX is generated by LoongArch specific code
loongarch_expand_vec_cond_mask_expr.
Draft patch:
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index d9b7a1076a2..0c7bafb5fb1 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -11197,7 +11197,9 @@ loongarch_expand_vec_cond_mask_expr (machine_mode mode,
machine_mode vimode,
if (mode != vimode)
{
xop1 = gen_reg_rtx (vimode);
- emit_move_insn (xop1, gen_rtx_SUBREG (vimode, operands[1], 0));
+ emit_move_insn (xop1,
+ simplify_gen_subreg (vimode, operands[1],
+ mode, 0));
}
emit_move_insn (src1, xop1);
}
@@ -11214,7 +11216,9 @@ loongarch_expand_vec_cond_mask_expr (machine_mode mode,
machine_mode vimode,
if (mode != vimode)
{
xop2 = gen_reg_rtx (vimode);
- emit_move_insn (xop2, gen_rtx_SUBREG (vimode, operands[2], 0));
+ emit_move_insn (xop2,
+ simplify_gen_subreg (vimode, operands[2],
+ mode, 0));
}
emit_move_insn (src2, xop2);
}
@@ -11233,7 +11237,8 @@ loongarch_expand_vec_cond_mask_expr (machine_mode mode,
machine_mode vimode,
gen_rtx_AND (vimode, mask, src1));
/* The result is placed back to a register with the mask. */
emit_insn (gen_rtx_SET (mask, bsel));
- emit_move_insn (operands[0], gen_rtx_SUBREG (mode, mask, 0));
+ emit_move_insn (operands[0], simplify_gen_subreg (mode, mask,
+ vimode, 0));
}
}
[Bug tree-optimization/111671] [14 Regression] ICE in get_default_value, at tree-ssa-ccp.cc:312 since r14-2965-gc83528d2367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111671 --- Comment #3 from Shaohua Li --- Yes, I cannot reproduce it anymore. Any idea about which commit fixed it?
[Bug rtl-optimization/112476] Unrecognizable insn with -O2 -march=la464 on loongarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476 Xi Ruoyao changed: What|Removed |Added CC||chenglulu at loongson dot cn --- Comment #3 from Xi Ruoyao --- GCC internal says: ‘subreg’s of ‘subreg’s are not supported. Using ‘simplify_gen_subreg’ is the recommended way to avoid this problem.
[Bug rtl-optimization/112476] Unrecognizable insn with -O2 -march=la464 on loongarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476 Xi Ruoyao changed: What|Removed |Added Last reconfirmed||2023-11-11 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Xi Ruoyao --- Confirmed with latest master.
[Bug c/110815] [static] not as useful as the nonnull attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815 uecker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||uecker at gcc dot gnu.org --- Comment #4 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459 --- Comment #3 from Paul Thomas --- Hi Sebastien, I have posted the patch to the gfortran list. Hopefully, the bug will be fixed this weekend. Thanks for the report. Paul
[Bug c/110815] [static] not as useful as the nonnull attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- IIUC this is fixed now?
[Bug c/112428] Wnonnull outputs wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from uecker at gcc dot gnu.org --- Fixed on trunk because the specific incorrect warning version is removed and replaced by the more generic but correct version using the nonnull attribute.
[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 Bug 95507 depends on bug 112428, which changed state. Bug 112428 Summary: Wnonnull outputs wrong type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c/110815] [static] not as useful as the nonnull attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110815 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:c58b426d64ac2513dc0ed19165740604e891e9df commit r14-5353-gc58b426d64ac2513dc0ed19165740604e891e9df Author: Martin Uecker Date: Thu Jul 27 13:41:33 2023 +0200 c: Synthesize nonnull attribute for parameters declared with static [PR110815] Parameters declared with `static` are nonnull. We synthesize an artifical nonnull attribute for such parameters to get the same warnings and optimizations. Bootstrapped and regression tested on x86. PR c/110815 PR c/112428 gcc/c-family: * c-attribs.cc (build_attr_access_from_parms): Synthesize nonnull attribute for parameters declared with `static`. gcc: * gimple-ssa-warn-access.cc (pass_waccess::maybe_check_access_sizes): remove warning for parameters declared with `static`. gcc/testsuite: * gcc.dg/Wnonnull-8.c: Adapt test. * gcc.dg/Wnonnull-9.c: New test.
[Bug c/112428] Wnonnull outputs wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112428 --- Comment #1 from CVS Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:c58b426d64ac2513dc0ed19165740604e891e9df commit r14-5353-gc58b426d64ac2513dc0ed19165740604e891e9df Author: Martin Uecker Date: Thu Jul 27 13:41:33 2023 +0200 c: Synthesize nonnull attribute for parameters declared with static [PR110815] Parameters declared with `static` are nonnull. We synthesize an artifical nonnull attribute for such parameters to get the same warnings and optimizations. Bootstrapped and regression tested on x86. PR c/110815 PR c/112428 gcc/c-family: * c-attribs.cc (build_attr_access_from_parms): Synthesize nonnull attribute for parameters declared with `static`. gcc: * gimple-ssa-warn-access.cc (pass_waccess::maybe_check_access_sizes): remove warning for parameters declared with `static`. gcc/testsuite: * gcc.dg/Wnonnull-8.c: Adapt test. * gcc.dg/Wnonnull-9.c: New test.
[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307 Alexander Monakov changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #15 from Alexander Monakov --- It did not bring enlightenment. It looks like INT_MIN REG_EH_REGION annotating a call that *does not* perform a non-local goto was a late addition, breaking the assumption "EH_REGION notes may appear only on insns that may throw exceptions", and now a few places in the compiler look as if they may forget to preserve the special INT_MIN REG_EH_REGION note. Uros, would you mind reading the discussion in this bug? Do you have suggestions how to proceed here?
[Bug tree-optimization/110043] [12/13/14 Regression] ice in size_remaining, at pointer-query.cc:875 since r12-6606-g9d6a0f388eb048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110043 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org Summary|[14 Regression] ice in |[12/13/14 Regression] ice |size_remaining, at |in size_remaining, at |pointer-query.cc:875|pointer-query.cc:875 since ||r12-6606-g9d6a0f388eb048 --- Comment #4 from Sam James --- 9d6a0f388eb048f8d87f47af78f07b5ce513bfe6 is the first bad commit commit 9d6a0f388eb048f8d87f47af78f07b5ce513bfe6 Author: Martin Sebor Date: Sat Jan 15 16:41:40 2022 -0700 Add -Wdangling-pointer [PR63272]. Resolves: PR c/63272 - GCC should warn when using pointer to dead scoped variable with in the same function i.e. r12-6606-g9d6a0f388eb048
